Мы использовали solr для поиска/потока/автоматических предложений/персонализации в электронной коммерции.

Проблемы с solr кластером

• Управление solr-инфраструктурой (zookeeper, JVM, анализ GC и т. д.) — непростая задача. В общем, для этого нам нужен выделенный разработчик (SRE/SDE-3).
• Обновление до более новой стабильной версии. Меньше поддержки сообщества по любым критическим вопросам.

ELK теперь поставляется с эластичной премиальной лицензией. Поэтому мы выбрали открытый поиск, так как это открытый исходный код. Он основан на версии elasticsearch 7.10. Есть лицензия апача.

Основные проблемы

• Существующий код имел проблемы с дизайном. Тесно связанный с solr. Микросервисная архитектура и зависимость от нескольких сервисов.
• Большой размер кластера в некоторых регионах и запусках по странам.

1. Мы использовали terraform для формирования кластера opensearch во всех регионах.
2. Для кода мы использовали шаблон проектирования factory и шаблон проектирования Adapter.
3. Параллельный прием данных как в opensearch, так и в solr.
4. Миграция дельта-данных opensearch & solr с помощью нашей службы переиндексации.
5. Один за другим запуск сервиса с поддержкой как opensearch, так и solr
6. После того, как шаги с 1 по 5 были готовы. Мы планировали запуск и мониторинг newRelic с учетом страны.

Основное узкое место : это было связано с выбором машины AWS типа узла c5. Мы исправили это с помощью бенчмаркинга и выбрали c6g.

Результат

Мы успешно перенесли более 100 миллионов документов с solr на opensearch без простоев. В миграции участвовало более 100 узлов на solr и opensearch. Нам также удалось сэкономить около 0,8 млн долларов США.

Ссылка

1. Заводской шаблон дизайна
2. Терраформ
3. Открытый поиск
4. Солр
5. Шаблон проектирования адаптера