Работа в Lucid Imagination дает мне возможность проанализировать и оценить огромное число установок Solr, работающих как в крупнейших компаниях из списка Fortune 500, так и в самых маленьких стартапах. Этот опыт позволил мне выделить многие типичные ошибки и ловушки, в которые попадают либо в начале работы с новой установкой Solr, либо не следя за последними усовершенствованиями и изменениями.
Спасибо моему коллеге Саймону Розенталю (Simon Rosenthal) за предложение названия статьи, и Саймону, Лэнсу Норскогу (Lance Norskog) и Тому Хиллу (Tom Hill) за полезные замечания и предложения.
Итак, без лишних слов ... семь смертных грехов Solr.
Грех № 1: Лень
Давайте определим лень как медлительность или безразличие. Она время от времени нападает практически на каждого из нас. Мы просто не можем сопротивляться желанию пойти наикратчайшим путем, или мы просто отказываемся осознать объем требуемых усилий, необходимых для выполнения работы надлежащим образом. В конечном итоге мы за это платим свою цену, зачастую с процентами. Вот несколько примеров того, как медлительность или безразличие приводят к проблемам с Solr.
- Общее отсутствие заинтересованности или в Solr или в проекте поиска как таковом. Иногда это можно увидеть, когда компания решает перейти от коммерческого приложения поиска к альтернативному варианту с открытым исходным кодом, например Lucene и Solr. Инженеры, занятые в проекте, привыкли к "старой технологии" и не горят желанием овладеть другой технологией поиска. Так что не приложив даже малейших усилий, они будут утверждать, что Solr неэффективен, труден для изучения, не стоит усилий, и т.д. Если вы проголодались, бесполезно стоять и ждать, пока жареная курятина полетит прямо в рот, нужно приложить хоть немного усилий для поиска еды. Программное обеспечение с открытым исходным текстом является гибким, адаптируемым и мощным, а разработчиками-экспертами в решениях с открытыми исходными текстами становятся те, кто не боится засучить рукава и изучить то, что им нужно. Участвуйте в списках рассылки. Откройте исходный код. Читайте документацию и вики. Я работал с клиентами, которые занялись Solr и стали экспертами в достаточно короткий промежуток времени, и даже присылали патчи через несколько недель после начала своего проекта. С другой стороны, я видел рост и усугублением проблем потому, что команда просто не хотела приложить каких-либо усилий к настройке своей инсталяции Solr. "Никто так не слеп, как тот, кто не смотрит".
- Использование настроек по-умолчанию в файлах schema.xml и/или solrconfig.xml. Если бы я имел по одному доллару за каждую продакшн-инсталяцию Solr, в которой статически "разогревается" запрос "Solr rocks", я бы мог себе позволить оплатить годовую поддержку от любого коммерческого поставщика поисковых решений. Файлы конфигурации по-умолчанию являются, конечно же, примерами, и шаблонами < рабочей конфигурации>. Потратьте время на изучение настроек конфигурации и типов полей, и используйте их наилучшим образом для вашего случая. Удалите все, что не используется (сколько раз вы действительно вызывали этот "распределенный" обработчик запросов...) Держите ваши файлы конфигурации в строгости и без излишеств, и в хорошо читаемом состоянии, и в конечном счете это окупится.
- Игнорирование парсера запросов dismax. Я наблюдал случаи, когда самостоятельно писался собственный парсер запросов, хотя то, что необходимо было сделать, легко могло быть реализовано с парсером запросов dismax. Существуют две различные крайности, по которым люди иногда избегают dismax. С одной стороны, есть ощущение, что он является "сильно упрощенным" парсером. Я полагаю, частично эта проблема вызвана первой строчкой в вики DismaxRequestHandler (и, кстати, мы по-прежнему испытываем неудобства от наследия неудачных наименований - это парсер запросов, а не обработчик запросов), которая гласит, что dismax "предназначен для обработки простых пользовательских запросов". Иногда складывается ощущение, что это всего лишь очень простой инструмент для тех, кто не хочет прилагать усилий по обработке своих запросов. Наоборот! Dismax обладает огромной мощью и гибкостью. Что ведет ко второй стороне "избегания dismax", а именно, что он "слишком сложный". И действительно, он несколько сложноват. Но время, затраченное на его изучение, возмещается сторицей.
- Недостаточное внимание настройкам JVM и сбору мусора. Не нужно становиться джедаем JVM чтобы запустить хорошо налаженную инсталяцию Solr, но стоит потратить некоторое время на изучение основ по различным типам сборщиков мусора и мониторингу JVM такими инструментами, как JConsole. Хорошей отправной точкой является блог моего коллеги Марка Миллера (Mark Miller) из Lucid Imagination. Еще одним хорошим ресурсом является этот документ, выпущенный Sun.
Грех № 2: Скупость
Умен на пенни, глуп на фунт (т.е. рискует большим ради малого). Это ловушка, в которую на удивление очень часто попадают. Естественно, далеко не каждый имеет неограниченный бюджет, но иногда ради ограничения ресурсов принимаются ужасные решения, решения, которые со временем окажутся более дорогостоящими. Например:
- Отказ в добавлении на сервер надлежащего объема оперативной памяти. Бывали случаи, когда у меня на маковском ноутбуке было больше оперативной памяти (4 Гб), чем на тех продакшн-инсталяциях Solr, которые я смотрел. Иногда даже в крупных компаниях проекты, связанные с Solr, были недофинансированы. Бывают бизнес-требования, которые влекут большие запросы по памяти (сортировка по длинному строковому полю, большое число фасет по полям с огромным числом различных значений, и т.д.), но при этом будут ожидания, что все это "заработает" на недостаточном объеме памяти каким-то волшебным образом. У моего друга есть поговорка: "Нельзя поместить 15 фунтов риса в 10 фунтовый пакет." Во что бы то ни стало настаивайте на приобретении по крайней мере минимально достаточного количества ресурсов.
- Требование запуска индексирования и поиска на одном и том же хосте. Одна из первейших рекомендаций, которую мы в Lucid Imagination зачастую даем клиентам, заключается в разделении процессов индексации и поиска на (по крайней мере) два отдельных узла. В этом есть несколько преимуществ. Во-первых, процессы индексирования и поиска не будут конкурировать за ресурсы (процессор, память и т.д.). Во-вторых, для оптимальной производительности главный и вспомогательный (-ые) сервера могут быть настроены немного по-разному. Обеспечьте бюджет для "железа", адекватного вашему числу документов, размеру индекса и ожидаемому объему запросов.
Грех № 3: Гордыня
Гордыня (в нашем случае): Не признание хорошей работы других. Чрезмерное самолюбие.
Инженеры любят писать код. Иногда до такой степени, что создают собственную разработку вместо уже существующей только потому, что: а) они верят, что могут сделать это лучше; b) считают, что могут изучить это, пройдя через этот процесс; c) это "будет забавно". Это не призыв против создания нового в помощь проекту с открытым исходным текстом, отправки исправлений багов, или, конечно же, улучшения существующей функциональности. Но будьте осторожны, чтобы не поспешить и не начать кодирование прежде, чем узнаете, какие варианты уже существуют. Семь раз отмерь, один раз отрежь.
- Не изобретайте колесо. Я видел разработчиков фактически ищущих оправдания написанию своего собственного анализатора запросов или другого компонента. Иногда такие усилия необходимы, и, к счастью, ПО с открытыми исходными текстом делает это реализуемым таким образом, который никогда не будет возможен с коммерческим программным обеспечением поиска. Но, прежде чем писать собственный код, убедитесь, что у вас есть реальная потребность, - по крайней мере писать за счет компании. Необходимы дополнительные усилия для поддержки самописного кода и для его синхронизации с Solr, поэтому убедитесь, что это действительно является единственной возможностью решения конкретной задачи.
- Используйте списки рассылки и архивы списков. Это должно быть очевидно, но многие все еще думают, что это принизит их в некотором роде, как если бы просьба о помощи была бы каким-то изъяном. С другой стороны, при отправке сообщений в почтовые рассылки, эффективно используйте время каждого её участника. Хорошенько поищите в архиве рассылки перед тем, как постить. (LucidFind облегчает это предоставляя в одном месте возможность поиска по соответствующим почтовым рассылкам, вики, блогам, документациям javadoc и другим ресурсам.) Если и когда вы постите вопрос, представьте краткое описание проблемы и дайте понять другим, что вам нужно. Не отвлекайтесь от темы на протяжении всего диалога. Комиттеры Lucene и Solr и сотрудники Lucid Imagination регулярно участвуют в списках рассылки, поэтому пользуйтесь этим ресурсом, когда у вас есть реальная необходимость.
Грех № 4: Вожделение
... Итак, давайте определим вожделение как "неестественную жажду чего-нибудь до степени потворства своим желаниям или безумия". OK.
- Настройка слишком большого размера кучи JVM, не оставляя достаточно оперативной памяти для операционной системы. Итак, мы, наконец, получили столько памяти, сколько мечтали (см.: жадность), а теперь что мы делаем? Мы получили 16 Гб ОЗУ на нашей машине и выделили 15Гб для кучи, где запускается Solr. Стоп! Время для холодного душа! Solr возможно единственный объект вашего внимания, но не пренебрегайте операционной системой. Терпение и внимание вступают здесь в игру. Промониторьте JVM под нагрузкой и определите, какой реальный объем памяти Solr использует. Вы захотите, чтобы операционная система смогла кэшировать данные файловой системы (особенно индексы Lucene), поэтому не забудьте оставить достаточный объем оперативной памяти для операционной системы.
- Слишком много внимания JVM и сбору мусора. С другой стороны (и в прямом противоречии с нашим первым пунктом в разделе Жадность), не переусердствуйте с JVM. Есть, казалось бы, бесконечно много путей подстройки и подгонки JVM. Не попадитесь в ловушку попробовать абсолютно каждую настройку JVM или сборщика мусора, если вы нея являетесь экспертом JVM. После того как вы овладели основами JVM и поняли различия между различными типами сборщика мусора, по большей части вы не должны быть слишком креативны. Не выставляйте "-XX:CMSIncrementalDutyCycleMin=10" просто из любопытсива.
- Пытаться "выжать еще немного" за счет числа предварительно "разогреваемых" запросов. ... Мы все хотим максимально короткого времени ответа поиска, по возможности, и средства авто-"разогрева" в Solr queryResultCache и filterCache являются важным инструментом, помогающим сохранять ответы на самые популярные запросы как можно более быстрыми. Но давайте не будем заблуждаться. Чрезмерное число авто-"разогреваемых" запросов может вести к чрезмерному времени подготовки кэшей, что в свою очередь влияет на время подготовки нового IndexSearcher после каждого обновления <индекса>. Спросите себя, а действительно ли вам нужно авто-"разогревать" 5000 самых популярных запросов всякий раз, когда вносится изменение в индекс. Очень легко увлечься этим процессом и придти к тому, что время подготовки нового IndexSearcher превысит период обновления вашего индекса, что может привести ко всякого рода неприятностям, включая исключения OutOfMemory. Убедитесь, что вы знаете каково среднее время разогрева ваших кэшей и подготовки нового IndexSearcher. Лучше всего начать с весьма скромного числа авто-"разогреваемых" запросов и увеличивать его по необходимости, нежели сразу начинать с большого. Записывайте отдельно или в базу запросы пользователей из логов вашей продакшн-инсталяции. Используйте эти данные для определения, а какие запросы действительно наиболее популярны. Иногда задания всего лишь 100 авто-"разогреваемых" запросов вполне достаточно. Но требуется время и усилия для нахождения золотой середины между "холодными" кэшами и "обжигающими" кэшами.
Грех № 5: Зависть
- Желание фич, как на других сайтах, но которые вам в действительности не нужны. Сосредоточьтесь на ваших бизнес-потребностях. Убедитесь, что вы знаете, что вам действительно нужно от поиска. Распространенным сценарием в списках рассылки является то, что Крис Хостеттер (Chris Hostetter), один из комиттеров Lucene/Solr, называет "проблемой XY": "Вы работаете с 'X', и вы думаете, что 'Y' также будет вам полезна, вы спрашиваете о 'Y', не давая более подробной информации о 'X', чтобы мы могли в полной мере понять проблему. Возможно, лучшим решением будет не включать 'Y' совсем". Определите, что вам нужно, и всегда придерживайтесь этих потребностей.
- Желание иметь больший индекс, чем у кого бы то ни было. Это антитеза вопросу о выделении недостаточных ресурсов (см. "скупость"). "Достать Луну" и пытаться обеспечить возможность роста на ближайшие 20 лет. Ловушка для тех, кто верит, будто их статус определяется размером их серверной. Конечно же планируйте наперед, но не ожидайте, что сможете заглянуть в будущее и предусмотреть все возможные сценарии. Планируйте энергично но не переусердствуйте в этом.
Грех № 6: Обжорство
"Быть подтянутым и в форме" - как правило хорошая практика при разработке и реализации Solr приложений. Многое из этого перекликается с разделом "Лень", и, как правило, являются случаями, когда дополнительные усилия по сохранению ваших конфигурации и данных в эффективном состоянии не считаются важными.
- Недостаточное внимание к конфигурации полей в схеме. Хранение полей, которые никогда не будут запрашиваться. Индексирование полей, по которым никгда не будут искать. Хранение координат, позиций и фасет, которые никогда не будут использованы. Ненужное раздувание <индексной базы>. Изучите ваши данные и потребности ваших пользователей и спроектируйте вашу схему и поля в соответствии с ними.
- Невнимание к неэффективным и излишним запросам. Я наблюдал случаи, когда запросы генерировались программно с большой избыточностью и с бессмысленной логикой. Пользуйтесь преимуществами фильтров запросов когда только возможно. Например, если у нас есть запрос, вроде такого - &q=content:solr AND datasource:wiki AND category:search AND language:en - используем фильтры запросов по полям, где это имеет смысл: &q=content:solr&fq=datasource:wiki&fq=category:search&fq=language:en.
Грех номер 7: Ярость
Хотя ярость обычно считается синонимом гнева, давайте здесь придерживаться старого определения: "неистовое отрицание истины, как по отношению к другим, так и самого себя, нетерпение".
- Предполагать, что никогда не придется переиндексировать всё. Легко можно увлечься дизайном схемы, составлением конфигурации, развертыванием системы, вопросами масштабирования и эффективности, а также настройкой релевантности, и при этом игнорировать рассмотрение вопросов восстановления индекса в случае аварии, будь то большой или малой. Один из пунктов, который никогда не следует упускать при планировании, это рассмотрение вопроса о восстановлении индекса в случае аппаратных сбоев. Если вы реплицируете данные от мастера к ведомому или ведомым, рассмотрите вопрос о дополнительном ведомом, который не будет использоваться для обработки запросов поиска, но будет получать реплики индекса и служить в качестве резервной копии мастера. Если возможно создавайте резервную копию данных индекса на других носителях информации. И наконец, если у вас небольшой индекс, который может быть создан заново без особых усилий в случае его удаления или потери, убедитесь, что у вас есть план и процедура действий по подготовке к быстрой переиндексации.
- Поспешность выхода в продакшн. Конечно, у всех нас есть крайние сроки, но вы получаете всего один шанс произвести первое впечатление. Несколько лет назад я участвовал в проекте, в котором мы выпустили наш поиск преждевременно (досрочно) потому, что компания решила, что лучше бы иметь хоть что-то запущенное, чем не иметь возможности поиска вовсе. Мы, разработчики, чувствовали, что имея еще четыре недели для работы, мы могли бы подготовить систему полностью, и она бы была отличным приложением для поиска данных. Но мы поспешили выйти в продакшн с некоторыми существенными недоработками. Покупатели наших заказчиков приходили в негодование, когда искали свою продукцию и не могли её найти. Мы заработали плохую репутацию, возмущение некоторых партнеров по бизнесу и потеряли деньги просто потому, что было сочтено необходимым выпустить поисковое приложение на четыре недели раньше.
Итак, не усложняйте, действуйте разумно, своевреммно вносите обновления и поддерживайте ваше приложение поиска в "здоровом" состоянии. Ищите (разумно), и вы найдете.