Использование поискового индекса Solr в качестве базы данных - это «неправильно»?

Question

Моя команда работает со сторонней CMS, которая использует Solr в качестве поискового индекса. Я заметил, что, похоже, авторы используют Solr в качестве базы данных, в которой каждый возвращаемый документ содержит два поля:

1. Идентификатор документа Solr (в основном имя класса и идентификатор базы данных)
2. XML-представление всего объекта

Таким образом, в основном он выполняет поиск в Solr, загружает XML-представление объекта, а затем создает экземпляр объекта из XML, а не ищет его в базе данных с помощью идентификатора.

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

Является ли текущая реализация совершенно обоснованной, или есть данные, подтверждающие идею о том, что она готова для рефакторинга?

РЕДАКТИРОВАТЬ: Когда я говорю «представление XML» - я имею в виду одно сохраненное поле, которое содержит строку XML всех свойств объекта, а не несколько сохраненных полей.

Answer 1

Да, вы можете использовать SOLR в качестве базы данных, но есть несколько очень серьезных предостережений:

1. Наиболее распространенный шаблон доступа SOLR, который работает по протоколу http, не особенно хорошо реагирует на пакетные запросы. Кроме того, SOLR НЕ выполняет потоковую передачу данных, поэтому вы не можете лениво повторять миллионы записей одновременно. Это означает, что вы должны быть очень внимательны при разработке крупномасштабных шаблонов доступа к данным с помощью SOLR.

2. Хотя производительность SOLR масштабируется как по горизонтали (больше машин, больше ядер и т. Д.), Так и по вертикали (больше оперативной памяти, более качественные машины и т. Д.), его возможности запросов сильно ограничены по сравнению с зрелая РСУБД . Тем не менее, есть несколько превосходных функций, таких как запросы статистики поля, которые довольно удобны.

3. Разработчики, которые привыкли использовать реляционные базы данных, часто сталкиваются с проблемами, когда они используют одни и те же шаблоны проектирования DAO в парадигме SOLR, поскольку SOLR использует фильтры в запросах. Будет кривой обучения для разработки правильного подхода к созданию приложения, которое использует SOLR для части его больших запросов или полных изменений .

4. "предприимчивые" инструменты, которые позволяют расширенное управление сеансами и полные сущности, которые предлагают многие расширенные веб-фреймворки (Ruby, Hibernate, ...), должны быть полностью выброшены из окна .

5. Реляционные базы данных предназначены для работы со сложными данными и взаимосвязями, и поэтому они сопровождаются современными метриками и инструментами автоматического анализа. В SOLR я обнаружил, что пишу такие инструменты и много вручную тестирую нагрузку, что может отнять время .

6. Присоединение: это большой убийца. Реляционные базы данных поддерживают методы для создания и оптимизации представлений и запросов, которые объединяют кортежи на основе простых предикатов. В SOLR нет надежных методов объединения данных между индексами.

7. Отказоустойчивость: для обеспечения высокой доступности SolrCloud использует распределенную файловую систему (то есть HCFS). Эта модель сильно отличается от модели реляционной базы данных, которая обычно обеспечивает отказоустойчивость, используя ведомые и ведущие, или RAID, и так далее. Таким образом, вы должны быть готовы предоставить инфраструктуру отказоустойчивости, необходимую для SOLR, если вы хотите, чтобы она была облачной, масштабируемой и устойчивой.

Тем не менее, у SOLR есть множество очевидных преимуществ для определенных задач: (см. http://wiki.apache.org/solr/WhyUseSolr) - бесполезные запросы намного проще выполнять и возвращать значимые результаты. Индексирование выполняется по умолчанию, поэтому большинство произвольных запросов выполняются довольно эффективно (в отличие от СУБД, где вам часто приходится оптимизировать и отменять нормализацию после факта).

Вывод: Даже если вы МОЖЕТЕ использовать SOLR в качестве СУБД, вы можете обнаружить (как и я), что в конечном счете «нет бесплатного обеда» - и экономия затрат на супер-крутой текст на лусене - поиск и высокопроизводительная индексация в памяти часто оплачиваются за счет меньшей гибкости и принятия новых рабочих процессов доступа к данным.

Answer 2

Совершенно разумно использовать Solr в качестве базы данных, в зависимости от вашего приложения.На самом деле, именно это и делает guardian.co.uk .

Это определенно не плохая практика как таковая.Это плохо, если вы используете его неправильно, как любой другой инструмент любого уровня, даже GOTO.

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

Answer 3

Я видел похожие вещи, потому что это позволяет очень быстро искать. Мы перемещаем данные из наших индексов Lucene в быстрое хранилище значений ключей, чтобы следовать принципам DRY, а также уменьшить размер индекса. Для такого рода вещей нет жестких правил.

Answer 4

Вероятно, это было сделано из соображений производительности, если бы не возникало проблем, я бы оставил это в покое.Существует большая серая область того, что должно быть в традиционной базе данных по сравнению с индексом Solr.Мне кажется, что люди делают подобные вещи (обычно пары ключ-значение или json вместо xml) для представления пользовательского интерфейса и получают реальный объект из базы данных только при необходимости для обновления / удаления.Но все чтения просто идут к Solr.