Исправление shahid, (текущая версия) :
А нельзя как-то сказать Solr/ES, чтобы убрал из индекса термы, которые встречаются всего 1 раз?
Теоретически, это возможно. Но очень плохо вписывается в концепции работы lucene и движков полнотекстовой индексации в целом.
1. Все lucene-фильтры накладываются на индексируемую информацию только при инзерте этой самой информации в индекс. К моменту, когда информация уже залита в ES/Solr-индекс, оригинал документа может уже не существовать, т.к. они не обязаны сохранять исходник индексируемого документа (это задается в настройках индекса). Для переиндексации (пересохранения) надо иметь исходник документа на руках.
2. Любая смена конфигурации фильтров уже заполненного индекса (кроме добавления новых фильтров) вызовет ошибку ещё до начала выполнения, т.к. получится, что все данные индекса устарели и становятся несовместимыми с конфигурацией. Fatal error, rollback. Почему это происходит? Потому что конфигурация фильтров индекса накладывается не только на документы, но и на все поисковые запросы к этому индексу (это тоже можно отключить, только поиск работать не будет).
3. Допустим, конфигурация фильтров изменилась. Обновление целого индекса наживую («ребилд индекса», «reindex») — это перезаливка всех документов в индекс, а это создаст в существующем индексе новые сегменты, содержащие все данные предыдущих сегментов внутри себя (ибо существующие сегменты - не изменяемы). Т.е. получается как бы два индекса внутри одного, пока не вызвать оптимизацию, которой понадобится в несколько раз больше времени, чтобы вычистить старые сегменты, выяснить какие документы должны остаться, а какие должны быть вычищены и т.д. Оптимизация блокирует индекс на некоторое время, зависящее от iops'ов винча и размеров RAM.
Иными словами - при изменении конфигурации индекса (в частности, настроек вышеупомянутого фильтра стоп-слов), надо создать новый индекс, в него заливать новую конфигурацию, включать bulk indexing, затем заливать все доки, отключать bulk indexing, оптимизировать индекс, и в конце пути дропнуть старый индекс. Для небольшого облегчения этого процесса в elasticsearch есть алиасы. Автоматизация этого процесса небезопасна, т.к. появление нового индекса удваивает потребление RAM, а оптимизация целого индекса - ещё хлеще. Может вылететь OutOfMemory, если сильно не повезёт.
Определить неправославные термы можно через Map-reduce-задачу подсчета слов.
Исправление shahid, :
А нельзя как-то сказать Solr/ES, чтобы убрал из индекса термы, которые встречаются всего 1 раз?
Теоретически, это возможно. Но очень плохо вписывается в концепции работы lucene и движков полнотекстовой индексации в целом.
1. Все lucene-фильтры накладываются на индексируемую информацию только при инзерте этой самой информации в индекс. К моменту, когда информация уже залита в ES/Solr-индекс, оригинал документа может уже не существовать, т.к. они не обязаны сохранять исходник индексируемого документа (это задается в настройках индекса). Для переиндексации (пересохранения) надо иметь исходник документа на руках.
2. Любая смена конфигурации фильтров уже заполненного индекса (кроме добавления новых фильтров) вызовет ошибку ещё до начала выполнения, т.к. получится, что все данные индекса устарели и становятся несовместимыми с конфигурацией. Fatal error, rollback. Почему это происходит? Потому что конфигурация фильтров индекса накладывается не только на документы, но и на все поисковые запросы к этому индексу (это тоже можно отключить, только поиск работать не будет).
3. Допустим, конфигурация фильтров изменилась. Обновление целого индекса наживую («ребилд индекса», «reindex») — это перезаливка всех документов в индекс, а это создаст в существующем индексе новые сегменты, содержащие все данные предыдущих сегментов внутри себя (ибо существующие сегменты - не изменяемы). Т.е. получается как бы два индекса внутри одного, пока не вызвать оптимизацию, которой понадобится в несколько раз больше времени, чтобы вычистить старые сегменты, выяснить какие документы должны остаться, а какие должны быть вычищены и т.д. Оптимизация блокирует индекс на некоторое время, зависящее от iops'ов винча и размеров RAM.
Иными словами - при изменении конфигурации индекса (в частности, настроек вышеупомянутого фильтра стоп-слов), надо создать новый индекс, в него заливать новую конфигурацию, включать bulk indexing, затем заливать все доки, отключать bulk indexing, оптимизировать индекс, и в конце пути дропнуть старый индекс. Для небольшого облегчения этого процесса в elasticsearch есть алиасы.
Определить неправославные термы можно через Map-reduce-задачу подсчета слов.
Исходная версия shahid, :
А нельзя как-то сказать Solr/ES, чтобы убрал из индекса термы, которые встречаются всего 1 раз?
Теоретически, это возможно. Но очень плохо вписывается в концепции работы lucene и движков полнотекстовой индексации в целом.
1. Все lucene-фильтры накладываются на индексируемую информацию только при инзерте этой самой информации в индекс. К моменту, когда информация уже залита в ES/Solr-индекс, оригинал документа может уже не существовать, т.к. они не обязаны сохранять исходник индексируемого документа (это задается в настройках индекса). Для переиндексации (пересохранения) надо иметь исходник документа на руках.
2. Любая смена конфигурации фильтров уже заполненного индекса (кроме добавления новых фильтров) вызовет ошибку ещё до начала выполнения, т.к. получится, что все данные индекса устарели и становятся несовместимыми с конфигурацией. Fatal error, rollback. Почему это происходит? Потому что конфигурация фильтров индекса накладывается не только на документы, но и на все поисковые запросы к этому индексу (это тоже можно отключить, только поиск работать не будет).
3. Допустим, конфигурация фильтров изменилась. Обновление целого индекса наживую — это перезаливка всех документов в индекс, а это создаст в существующем индексе новые сегменты, содержащие все данные предыдущих сегментов внутри себя (ибо существующие сегменты - не изменяемы). Т.е. в таком получится два индекса внутри одного, пока не вызвать оптимизацию, которой понадобится в несколько раз больше времени, чтобы вычистить старые сегменты, выяснить какие документы должны остаться, а какие должны быть вычищены и т.д.
Иными словами - при изменении конфигурации индекса (в частности, настроек вышеупомянутого фильтра стоп-слов), надо создать новый индекс, в него заливать новую конфигурацию, включать bulk indexing, затем заливать все доки, отключать bulk indexing, оптимизировать индекс, и в конце пути дропнуть старый индекс. Для небольшого облегчения этого процесса в elasticsearch есть алиасы.
Определить неправославные термы можно через Map-reduce-задачу подсчета слов.