Solr только против решения Solr / MySQL

Question

В настоящее время у меня есть система, которая основана исключительно на Solr.Это означает, что я храню все данные в Solr (используя SolrJ) без какого-либо другого хранилища данных.Проблема в том, что у меня возникли проблемы с производительностью.Я подумал, что, возможно, имеет смысл сохранить в MySQL и затем синхронизировать данные с Solr, например, с DataImportHandler .Так что у меня есть операции чтения индекса Solr и основные операции записи в MySQL, а затем иногда только операции Solr-Writing при синхронизации с Solr.

Дело в том, что я ожидаю сотни миллионов документов, которые должны бытьхранится, и я не знаю, если MySQL / Solr имеет смысл.

Есть ли другое лучшее решение?Может быть, Master-Solr для записи и Solr-slaves для чтения?

Обновление : я забыл сказать, что в случае изменения schema.xml «хранение данных вMySQL "решение может быть полезным, на мой взгляд, потому что тогда я могу повторно зафиксировать все данные, не заботясь о самих данных Solr.

Answer 1

Не желательно использовать один и тот же экземпляр Solr для чтения и записи, поскольку действия (с фиксацией и оптимизацией) в Solr во время записи сильно влияют на операции чтения.

Master - более подходящим является конфигурирование Slave, причем master в основном предназначен для записи, а ведомые - только для чтения.
Рабы периодически пополняются содержимым от Мастера. (Так что будет некоторая задержка)
Вы всегда можете масштабировать, добавив несколько рабов.

Лучше всего использовать MySQL в качестве постоянного хранилища с Master-Slave Solr.
MySQL обеспечивает стабильное хранилище данных и защитит вас от повреждения индекса или некоторых других проблем, которые могут привести к потере данных.
Используя обработчик dataimport, вы можете легко сделать это с инкрементными обновлениями, но будет больше метки времени для появления последних данных на ведомых устройствах.
При этом вы также можете использовать обмен индексами для полного обновления.

В случае, если индекс растет, чтобы его можно было поддерживать и он оказывал влияние на производительность, вы можете проверить осколки сольра.

Answer 2

Я тоже думал о той же проблеме: хранить все в solr или stor в mySql и index в Solr.

Я решил пойти по второму пути: хранить с MySQL и индексировать в solr.

Причина: обработка данных (чтение и запись данных) в MySql намного лучше, чем в Solr. Также импорт / экспорт данных из / в MySql поддерживается / возможен многими инструментами, из коробки. Следующий пункт: Резервное копирование. Существует гораздо более надежные способы резервного копирования базы данных MySql, чем индекс Solr.

Конечно, для полнотекстового поиска Solr намного лучше, чем MySql. Поэтому я решил, что каждый должен работать там, где он знает лучше всего. Для вашей информации: я имею в виду средний индекс: 4 ГБ для нескольких миллионов документов.

// Редактировать: не забывайте, что некоторые функции требуют отображения данных в lucene (не только проиндексированы), например, выделения. Если вам это нужно, вы должны хранить документы в Solr (дополнительно). Альтернативным способом может быть реализация этих функций на стороне клиента. (Я так и сделал)