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

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

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

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

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


mysql database performance solr solrj
person H6.    schedule 04.10.2011    source источник
comment
Сколько строк у вас есть сейчас, сколько времени это займет и сколько времени вы хотели бы, чтобы это заняло? Я думаю, что добавление дополнительной сложности и межплатформенных мостов не решит вашу проблему.   -  person Johan    schedule 04.10.2011
comment
в настоящее время у меня есть ок. 50 миллионов документов в тестовой среде Solr. Но иногда у меня бывают тайм-ауты, и я подумал, что, возможно, запись блокирует чтение.   -  person H6.    schedule 04.10.2011
comment
@ Даниэль, пожалуйста, обратите внимание на мое обновление / редактирование. Возможно, вам придется хранить данные в solr, в зависимости от ваших потребностей.   -  person The Bndr    schedule 05.10.2011
comment
@Bndr: Да, я знаю о хранении. В настоящее время я храню много вещей, от которых потом, возможно, смогу избавиться при выборе решения RDB/Solr. Нужно проверить это в ближайшие дни. Спасибо   -  person H6.    schedule 05.10.2011

Ответы (2)


arrow_upward
6
arrow_downward

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

Конфигурации «главный-подчиненный» были бы более подходящим подходом, когда главный в первую очередь предназначен для записи, а подчиненные — только для чтения.
Подчиненные устройства периодически обновляются содержимым от главного. (Поэтому будет некоторая задержка)
Вы всегда можете масштабировать, добавляя несколько ведомых устройств.

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

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

person Jayendra    schedule 04.10.2011
comment
Да, я думаю, вы правы. Сейчас я начал с Solr Master/Slave, а затем добавлю MySQL-Database. Или, может быть, Cassandra вместо MySQL. Мне нужно оценить. Спасибо за ваш отзыв. - person H6.; 06.10.2011

arrow_upward
4
arrow_downward

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

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

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

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

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

person The Bndr    schedule 04.10.2011