Настройка производительности SOLR

Question

Я прочитал следующее:

http://wiki.apache.org/solr/SolrPerformanceFactors

http://wiki.apache.org/solr/SolrCaching

http://www.lucidimagination.com/content/scaling-lucene-and-solr

И у меня есть вопросы о несколькихвещи:

1. Если я использую опцию JVM -XX:+UseCompressedStrings, какой экономии памяти я могу достичь?Для простоты, если у меня есть 1 индексированное поле (строка) и 1 сохраненное поле (строка) с omitNorms = true и omitTf = true, какую экономию в кеше индекса и документов можно ожидать?Я предполагаю около 50%, но, возможно, это слишком оптимистично.
2. Когда именно работает кэш фильтра Solr?Если я просто делаю простой запрос с AND и несколькими OR и сортирую по баллам, нужен ли он мне вообще?
3. Если я хочу кэшировать все документы в кеше документов, как бы я вычислилтребуется место?Используя приведенный выше пример, если у меня 20M документов, используются сжатые строки, а средняя длина хранимого поля составляет 25 символов, требуется ли пространство в основном (25 байт + small_admin_overhead) * 20M?
4. , если вседокументы находятся в кеше документов, насколько важен кеш запросов?
5. Если я хочу автоматически разогревать каждый документ в кеше документов, будет ли автоподогрев запроса *:* делать это?
6. МасштабированиеВ статье -lucene-and-solr говорится, что FuzzyQuery работает медленно.Если я использую функцию проверки орфографии в solr, то я в основном использую нечеткий запрос, верно (потому что проверка орфографии выполняет тот же расчет расстояния редактирования)?Итак, предположительно, проверка орфографии и нечеткий запрос одинаково «медленны»?
7. Раздел, описывающий кеш поля lucene для строк, немного сбивает с толку.Правильно ли я понимаю, что требуемое пространство - это в основном размер индексированного строкового поля + целочисленный массив, равный количеству уникальных терминов в этом поле?
8. Наконец, при максимизации пропускной способности есть утверждение ооставляя достаточно места для дискового кэша ОС.В нем говорится: «В целом, для крупномасштабного индекса лучше всего убедиться, что у вас есть хотя бы несколько гигабайт оперативной памяти сверх того, что вы предоставляете JVM».Так что, если у меня есть 12 ГБ памяти (в качестве примера), я должен предоставить ОС как минимум 2-3 ГБ?Могу ли я оценить объем дискового кеша, необходимый ОС, взглянув на размер индекса на диске?

Answer 1

1. Единственный способ убедиться в этом - попробовать.Тем не менее, я ожидал бы очень небольшую экономию в индексе, поскольку индекс будет содержать фактическую строку только один раз каждый раз, остальное - данные о расположении этой строки в документах.Они не являются большой частью индекса.
2. Кэш фильтра только кэширует запросы фильтра.Это может быть бесполезно для вашего конкретного случая использования, но многие находят их полезными.Например, сужение результатов по стране, языку, типу продукта и т. Д. Solr может избежать пересчета результатов запроса для подобных вещей, если вы часто их используете.
3. Реально, вам просто нужно попробовать и измерить егопрофилировщик.Без глубокого знания точно используемой структуры данных, все остальное - чистая SWAG.Ваши расчеты так же хороши, как и все остальные без профилирования.
4. Кэш документов только экономит время при получении результатов ПОСЛЕ того, как запрос был рассчитан.Если вы тратите большую часть своего времени на вычисление запросов, кеш документов не принесет вам пользы.Кеш запросов полезен только для повторных запросов.Если ни один из ваших запросов не повторяется, то кэш запросов бесполезен
5. да, если предположить, что кэш документов достаточно большой, чтобы вместить их все.

6-8 Не положительно.

Исходя из моего собственного опыта настройки производительности Solr, вы должны оставить Solr для обработки запросов, а не для хранения документов.Большинство ваших вопросов касаются того, как документы занимают место.Solr - это поисковая система, а не хранилище документов.Если вы хотите, чтобы Solr был БЫСТРОМ и занимал минимальное количество памяти, то единственное, на что он должен опираться - это индексировать информацию для целей поиска.Сами документы должны храниться, извлекаться и предоставляться в другом месте.Предпочтительно в системе, которая оптимизирована специально для этой работы.Единственное поле, которое вы должны хранить в своем документе Solr, - это идентификатор для извлечения из системы хранения документов.

Answer 2

Кэши

В общем, кэширование выглядит хорошей идеей для повышения производительности, но это также имеет много проблем:

• кэшируемые объектыскорее всего, перейдет к старому поколению сборщика мусора, который стоит дороже,
• управление вставками и удалениями добавляет некоторые издержки.

Более того, кэширование вряд ли улучшит вашуЗадержка поиска очень велика, если в ваших запросах нет шаблонов.Напротив, если 20% вашего трафика приходится на несколько запросов, то кеш результатов запросов может быть интересен.Настройка кешей требует, чтобы вы хорошо знали свои запросы и документы.Если вы этого не сделаете, вам, вероятно, следует отключить кэширование.

Даже если вы отключите все кэши, производительность все равно может быть довольно хорошей благодаря кешу ввода-вывода операционной системы.На практике это означает, что если вы снова и снова читаете одну и ту же часть файла, вполне вероятно, что он будет считан с диска только в первый раз, а затем из кэша ввода-вывода.А отключение всех кэшей позволяет вам выделить меньше памяти для JVM, чтобы было больше памяти для кэша ввода-вывода.Если ваша система имеет 12 ГБ памяти и если вы предоставляете 2 ГБ для JVM, это означает, что кэш ввода-вывода может кэшировать до 10 ГБ вашего индекса (в зависимости от того, какие другие приложения работают, и для них тоже требуется память).

Я рекомендую вам прочитать это, чтобы получить больше информации о кеше уровня приложения и о кеше ввода / вывода:

https://www.varnish -cache.org / trac / wiki / ArchitectNotes

http://antirez.com/post/what-is-wrong-with-2006-programming.html

Кэш поля

Размер кэша поля для строки равен (один массив целых чисел длины maxDoc) + (одинмассив для всех уникальных экземпляров строки).Таким образом, если у вас есть индекс с одним строковым полем, которое имеет в среднем N экземпляров размера S, и если ваш индекс имеет M документов, то размер кэша полей для этого поля будет приблизительно M * 4 + N * S.

* 1033.* Кэш поля в основном используется для фасетов и сортировки.Даже очень короткие строки (менее 10 символов) превышают 40 байт , это означает, что вы должны ожидать, что Solr потребует много памяти, если вы сортируете или фасете в поле String, которое имеет большое числоуникальные значения.

Нечеткий запрос

FuzzyQuery работает медленно в Lucene 3.x, но намного быстрее в Lucene 4.x.

Это зависит от выбранной вами реализации проверки орфографии, но я думаю, что программа проверки орфографии Solr 3.x использует N-граммы для поиска кандидатов (именно поэтому ему необходим выделенный индекс), а затем вычисляет только расстояния на этом наборе для кандидатов,так что производительность все еще достаточно хорошая.