|
|
|
Oracle Text - очень медленно работает contains и near
|
|||
|---|---|---|---|
|
#18+
Всем привет! Есть задача - аналитическая таблица, содержащая 15 млн. документов. Размер каждого документа от 20 до 100 страниц. Текстовка выгружена в CLOB. На эту таблицу построен Oracle Text индекс типа CONTEXT: Код: sql 1. Выполняем поиск по этой таблице - ищем упоминания людей по фамилии, имени и отчеству: contains(txt,'NEAR (((Бирюков),(Алексей),(Игоревич)),5)'). Когда фамилия редкая (Бирюков) поиск занимает 9 секунд, но когда фамилия распространенная (Иванов) - поиск занимает 310 секунд. Когда мы ищем по четырем словам (с годом рождения) запрос выполняется несколько часов. Я запрашивал информацию Oracle Text Trace (приведена ниже), но это не объяснило разницу в поиске. Прошу знатоков Oracle Text объяснить почему так происходит и как можно ускорить поиск? SQL-case со статистикой: ============================== Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. Статистическая информация Oracle - приведена статистика 2 запросов по метрикам, где они отличаются в 2 запросах (Бирюков и Иванов) на 1 и более: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2017, 23:45 |
|
||
|
Oracle Text - очень медленно работает contains и near
|
|||
|---|---|---|---|
|
#18+
Для каждого решения - свой инструмент. Поставить apache solr и забыть как в страшном сне глючнейший oracle text. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2017, 11:08 |
|
||
|
Oracle Text - очень медленно работает contains и near
|
|||
|---|---|---|---|
|
#18+
:) Нужен именно Oracle Text. В целом он работает хорошо и делает то, что нужно. Как видно из приведенных логов, 37255 документов, где содержатся одновременно слова "Иванов AND Алексей AND Игоревич" он находит за 15 секунд. Но на то, чтобы понять что эти слова находятся рядом у него уходит куча времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2017, 13:05 |
|
||
|
Oracle Text - очень медленно работает contains и near
|
|||
|---|---|---|---|
|
#18+
BMan, Не уверен, но за сколько отрабатывает Код: plsql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2017, 14:03 |
|
||
|
Oracle Text - очень медленно работает contains и near
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньев, Хм, идея интересная - завтра попробую. Сейчас запустили CTX_DDL.OPTIMIZE_INDEX в режиме FAST - выполняется уже 3-й час. Глянем, что получится. Хотя, я не очень надеюсь на успех этой операции, т.к. индекс строился за один раз - данные в таблице после построения индекса не менялись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2017, 19:38 |
|
||
|
Oracle Text - очень медленно работает contains и near
|
|||
|---|---|---|---|
|
#18+
BMan, BManХм, идея интересная - завтра попробую. Сейчас запустили CTX_DDL.OPTIMIZE_INDEX в режиме FAST - выполняется уже 3-й час. Глянем, что получится. Хотя, я не очень надеюсь на успех этой операции, т.к. индекс строился за один раз - данные в таблице после построения индекса не менялись. optimize я делаю, когда есть значительная фрагментация. Фрагментацию через ctxsys.ctx_report.index_stats можно посмотреть. Для удобства я использую следующий скрипт (нужно указать вместо &1: INDEX_OWNER.INDEX_NAME ). Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. На AskTom-е бы тест-кейс привели и указанием, где это быстрее и на сколько (apache solr или где еще), пока они там стандартную отписку про I/O написали, видимо, статистики не читали, по которым видно, что тут на CPU все ушло. статистикиSTAT...recursive cpu usage 922 30,811 29,889 STAT...CPU used by this sessio 922 30,811 29,889 STAT...Elapsed Time 1,223 33,559 32,336 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2017, 04:16 |
|
||
|
Oracle Text - очень медленно работает contains и near
|
|||
|---|---|---|---|
|
#18+
А чего не делаешь, если удалённых много? Я юзаю estimated_ row fragmentation и estimated garbage size ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2017, 12:01 |
|
||
|
Oracle Text - очень медленно работает contains и near
|
|||
|---|---|---|---|
|
#18+
SeaGateoptimize я делаю, когда есть значительная фрагментация. Фрагментацию через ctxsys.ctx_report.index_stats можно посмотреть. Для удобства я использую следующий скрипт (нужно указать вместо &1: INDEX_OWNER.INDEX_NAME ). На AskTom-е бы тест-кейс привели и указанием, где это быстрее и на сколько (apache solr или где еще), пока они там стандартную отписку про I/O написали, видимо, статистики не читали, по которым видно, что тут на CPU все ушло. Индекс всё ещё ребилдится, как закончит - посмотрю, что с ним получилось. На Ask Tom - ага, для них со статистикой старался - всё по Том Кайту :) Конечно, ввод-вывод вообще не причем. Сервак мощный, памяти достаточно + СХД подключена с SSD винтами. Да и по статистике видно, что блоки он почти не считывает при обработке запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2017, 19:06 |
|
||
|
Oracle Text - очень медленно работает contains и near
|
|||
|---|---|---|---|
|
#18+
Shtock, Shtock А чего не делаешь, если удалённых много? Я юзаю estimated_ row fragmentation и estimated garbage size Да, упустил этот момент. Надо делать, т.к. это покрывает больше сценариев работы с данными, чем только estimated row fragmentation. Вообще, я пока знаю два сценария, когда фрагментации нет, а garbage есть. Это после ctx_ddl.optimize_index с FAST (я использую FULL). И после DELETE строк базовой таблицы (у меня это очень редко). У тебя есть garbage с нулевой/малой фрагментацией при других условиях? Все про ctxsys.context. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2017, 08:24 |
|
||
|
Oracle Text - очень медленно работает contains и near
|
|||
|---|---|---|---|
|
#18+
Слушай, я не парился разыскивая такие сценарии. Я прикинул, что при превышении неких границ этих параметров надо делать оптимизацию и написал код. что забавно, фрагментация в процентах, а удалённые данные в мегабайтах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2017, 10:45 |
|
||
|
Oracle Text - очень медленно работает contains и near
|
|||
|---|---|---|---|
|
#18+
у меня к сожалению delete очень частый, причём по много записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2017, 10:45 |
|
||
|
Oracle Text - очень медленно работает contains и near
|
|||
|---|---|---|---|
|
#18+
BMan, BManобъяснить почему так происходит и как можно ускорить поиск?по-моему тут все очевидно: BMan Код: plsql 1. этому предикату нужно лишь проверить что у строки есть каждый из этих токенов, т.е. берутся все строки у которых есть Бирюков, Алексей и Игоревич и возвращается только их пересечение. BMan Код: plsql 1. а в данном случае, надо посчитать расстояния между всеми этими токенами, поэтому при увеличении их количества, время выполнения растет экспоненциально ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2017, 23:13 |
|
||
|
Oracle Text - очень медленно работает contains и near
|
|||
|---|---|---|---|
|
#18+
xtenderпо-моему тут все очевидно: В общем-то да, почему так происходит мы разобрались :) теперь пытаемся придумать как это ускорить изменя сами условия поиска Ребилд индекса делался около 1,5 суток. Дропнули его, создали заново (с другими параметрами) - сутки создавался где-то. В общем, это не ускорило процедуру поиска, но начали думать как искать по другому, например: 'Near (((Иванов), (Игорь Анатольевич)),5) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2017, 14:35 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39390845&tid=1886564]: |
0ms |
get settings: |
11ms |
get forum list: |
23ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
177ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 228ms |
| total: | 517ms |

| 0 / 0 |
