Текст Oracle СОДЕРЖИТ и НРАВИТСЯ: разные результаты

Есть две проблемы:

  • разные результаты при использовании LIKE и CONTAINS
  • серьезная нехватка скорости при поиске одного символа с помощью CONTAINS

Я пытаюсь избавиться от поиска с помощью LIKE из соображений производительности, но текст оракула у меня не работает должным образом.

Я не уверен, важно ли это, но CLOB содержит в основном русский текст. На мой взгляд, это не имеет значения, потому что CONTAINS поиск не использует словари и не анализирует лексические элементы.

Общее количество строк в таблице: 215577

-- index creation
create index schema_name.idx_01 on schema_name.t_searchable_table(clob_value)
  indextype is ctxsys.context 
  parameters ('DATASTORE CTXSYS.DEFAULT_DATASTORE sync (on commit)');

-- index sync
begin
  ctx_ddl.sync_index('SCHEMA_NAME.IDX_01');
end;


Насколько я вижу, индекс успешно обновлен с фиксацией, но я не могу найти никакого визуального подтверждения этого.

Вот несколько запросов, которые я пробовал, результаты поиска LIKE предназначены для сравнения производительности и количества. Я тестирую производительность с вставкой данных в таблицу (время запроса достаточно стабильно).

--- String search
-- original "not tuned" query with like '%%'
-- 116643 rows inserted in 8,653 seconds
insert into schema_name.t_search_results t
  (session_id, entity_id)
  select 'a', a.entity_id
   from schema_name.t_searchable_table a
  where lower(a.clob_value) like '%про%';

-- this is not correct query due to documentation but it's fast and sql%rowcount is same
-- 116643 rows inserted in 2,959 seconds
insert into schema_name.t_search_results t
  (session_id, entity_id)
  select 'a', a.entity_id
    from schema_name.t_searchable_table a
   where contains(a.clob_value, '%про%',1 ) > 0;

-- correct query due to oracle docs but absolutely incorrect amount
-- 11 rows inserted in 0,081 seconds
insert into schema_name.t_search_results t
  (session_id, entity_id)
  select 'a', a.entity_id
    from schema_name.t_searchable_table a
   where contains(a.clob_value, 'про',1 ) > 0;

--- Number search
-- original "not tuned" query with like '%%'
-- 121918 rows inserted in 8,045 seconds
insert into schema_name.t_search_results t
  (session_id, entity_id)
  select 'a', a.entity_id
   from schema_name.t_searchable_table a
  where lower(a.clob_value) like '%1%';

-- Little differs by amount but fast. 
-- 117228 rows inserted in 2,065 seconds
insert into schema_name.t_search_results t
  (session_id, entity_id)
  select 'a', a.entity_id
    from schema_name.t_searchable_table a
   where contains(a.clob_value, '1',1 ) > 0;

-- Lost one row here (not sure why) but SUPERSLOW
-- 121917 rows inserted in 97,760 seconds
insert into schema_name.t_search_results t
  (session_id, entity_id)
  select 'a', a.entity_id
    from schema_name.t_searchable_table a
   where contains(a.clob_value, '%1%',1 ) > 0;


-- Single character
-- original "not tuned" query with like '%%'
-- 124095 rows inserted in 9,112 seconds
insert into schema_name.t_search_results t
  (session_id, entity_id)
  select 'a', a.entity_id
   from schema_name.t_searchable_table a
  where lower(a.clob_value) like '%а%';

-- Incorrect syntax, amount is good, performance is awful
-- 124095 rows inserted in 94,927 seconds
insert into schema_name.t_search_results t
  (session_id, entity_id)
  select 'a', a.entity_id
    from schema_name.t_searchable_table a
   where contains(a.clob_value, '%а%',1 ) > 0;

-- correct syntax, fast and smooth (and almost double rows lost)
-- 60345 rows inserted in 1,215 seconds
insert into schema_name.t_search_results t
  (session_id, entity_id)
  select 'a', a.entity_id
    from schema_name.t_searchable_table a
   where contains(a.clob_value, 'а',1 ) > 0;

person John Doe    schedule 01.08.2019    source источник
comment
Я понял, что contains(a.clob_value, 'про',1 ) > 0; работает неправильно для меня, потому что ищет только целые слова. Вот почему использование %% дало правильные результаты.   -  person John Doe    schedule 02.08.2019
comment
Итак, осталось только одно: как мне перестроить индекс для работы с частями слов размером, например, в 3 символа.   -  person John Doe    schedule 02.08.2019


Ответы (1)


Вы можете попробовать перестроить с помощью BASIC_WORDLIST и указать TRUE для SUBSTRING_INDEX атрибут.

Мы надеемся, что это должно повысить производительность при поиске подстановочных знаков '%npo%'.

Вы можете использовать эту подстроку пример предпочтения в качестве руководства и настройте его в соответствии с вашими потребностями.

person John A    schedule 14.08.2019