Я работаю над переносом поисковой системы из базы данных sql наasticsearch.
Основная причина для этого - возможность легко вычислять фасеты.
В настоящее время у нас есть аспекты в SQL, генерирующие предкальциевые таблицы. Это хорошо работает, но поддерживать его сложно, и фасеты поддерживаются только в подмножестве данных.
Теперь прототип ES работает, я сравниваю два решения, и кажется, что версия ES немного ниже версии sql с точки зрения производительности (с точки зрения удобства сопровождения, она намного лучше).
Я использовал точно такие же конфигурации компьютеров, 64-битную платформу, 32 гигабайта оперативной памяти, ssd-диск и четырехъядерный процессор Intel Xeon с тактовой частотой 3 ГГц для сравнения sql и ES.
Документ не маленький, в нем около 200 полей, в зависимости от запроса, используется сортировка на основе сценариев, а фасеты всегда вычисляются на 8 полях документа.
Индекс содержит 3 миллиона документов, если я не ошибаюсь, он сравнительно мал для того, что может обработать ES.
В терминах запроса я использую фильтрованный запрос, а для некоторых запросов - запрос custom_filters_score, чтобы вычислить оценку и использовать ее для сортировки.
Некоторые из фильтров являются глобальными из-за фасетов, но в отфильтрованном запросе всегда есть некоторые фильтры, поэтому количество проверенных документов следует уменьшить (не весь индекс сканируется).
Я использую в своих тестах две меры: время, проведенное на сервере для выполнения поиска, и количество запросов в секунду, выполняемых клиентом, выполняющим 100 потоков параллельно.
Для эластичного поиска среднее время, затрачиваемое на сервер, составляет около 500 мс для каждого запроса (для 100 параллельных запросов), а среднее количество запросов в секунду на клиенте составляет около 160 (некоторые мс теряются при построении запроса, отправка, получение результатов и их анализ).
И это при индексе с 1 шардом и 0 репликами, когда я увеличиваю количество шардов / реплик, производительность значительно снижается.
Для sql среднее время, затрачиваемое на выполнение запроса, составляет около 360 мс (в том числе 100 параллельных запросов), а среднее количество запросов в секунду на клиенте - около 200.
Я знаю, что это трудно сравнивать, но, поскольку я понятия не имею о результатах, которые я могу ожидать, я задаюсь вопросом, может ли кто-нибудь прокомментировать эти меры.
Может быть, я что-то упустил, и это должно быть на порядок быстрее, или, может быть, это типичные результаты для подобных мне сред, не знаю.
Чего мне ожидать в моем случае?
Что вы наблюдали при похожих обстоятельствах с ES?
Хорошо ли он поддерживает параллельные запросы?
Должно ли время выполнения запроса быть в диапазоне 500 мс при одновременном выполнении 100 запросов?
Есть ли способы улучшить производительность поиска?
Любая информация или комментарии приветствуются, это важная часть для решения о промышленном внедрении прототипа или нет.
Спасибо.