Использование индекса поиска Solr в качестве базы данных - это "неправильно"?
моя команда работает со сторонней CMS, которая использует Solr в качестве поискового индекса. Я заметил, что похоже, что авторы используют Solr в качестве базы данных в том, что каждый возвращаемый документ содержит два поля:
- идентификатор документа Solr (в основном имя класса и идентификатор базы данных)
- XML-представление всего объекта
поэтому в основном он запускает поиск по Solr, загружает XML-представление объекта, а затем создать экземпляр объекта из XML, а не искать его в базе данных, используя идентификатор.
моя интуиция подсказывает мне, что это плохая практика. Solr-это индекс поиска, а не база данных... поэтому для меня имеет смысл выполнить наш сложный поиск по Solr, получить идентификаторы документов, а затем вытащить соответствующие строки из базы данных.
является ли текущая реализация совершенно здравой, или есть данные для поддержки идеи, что это созрело для рефакторинг?
EDIT: когда я говорю "представление XML" - я имею в виду одно сохраненное поле, которое содержит строку XML всех свойств объекта, а не несколько сохраненных полей.
4 ответа:
Да, вы можете использовать SOLR в качестве базы данных, но есть некоторые действительно серьезные предостережения:
наиболее распространенный шаблон доступа SOLR, который находится над http, не особенно хорошо отвечает на пакетные запросы. Кроме того, SOLR не передает данные --- поэтому вы не можете лениво перебирать миллионы записей за раз. Это означает, что вы должны быть очень внимательны при разработке крупномасштабных шаблонов доступа к данным с помощью СОЛР.
хотя производительность SOLR масштабируется горизонтально (больше машин, больше ядер и т. д..) а также по вертикали (больше оперативной памяти, лучшие машины и т. д.),его возможности запроса сильно ограничены по сравнению с возможностями зрелой СУБД. Тем не менее, есть некоторые отличные функции, такие как запросы статистики поля, которые довольно удобны.
разработчики, которые привыкли использовать реляционные базы данных, часто сталкиваются проблемы, когда они используют одни и те же шаблоны проектирования DAO в парадигме SOLR, из-за того, как SOLR использует фильтры в запросах. там будет кривая обучения для разработки правильного подхода к созданию приложения, которое использует SOLR для части своих больших запросов или statefull модификаций.
инструменты "предприимчивость", которые позволяют advanced session management и statefull сущности, которые многие передовые веб-фреймворки (Ruby, Hibernate, ...) предлагать придется выкинуть полностью из окна.
реляционные базы данных предназначены для работы со сложными данными и отношениями - и поэтому они сопровождаются современными метриками и автоматизированными инструментами анализа. в SOLR я обнаружил, что пишу такие инструменты и вручную стресс-тестирование много, что может быть временным потоком.
присоединение: это большой убийца. Реляционные базы данных поддерживают методы построения и оптимизация представлений и запросов, которые соединяют Кортежи на основе простых предикатов. в SOLR нет надежных методов для объединения данных по индексам.
отказоустойчивость: для высокой доступности SolrCloud использует распределенную файловую систему внизу (т. е. HCFS). Эта модель сильно отличается от реляционной базы данных, которая обычно делает отказоустойчивость с использованием ведомых и главных устройств или RAID и т. д. Так что вы должны быть готовы обеспечить отказоустойчивость инфраструктура SOLR требуется, если вы хотите, чтобы она была масштабируемой и устойчивой к облаку.
тем не менее-есть много очевидных преимуществ для SOLR для определенных задач : (см. http://wiki.apache.org/solr/WhyUseSolr) -- свободные запросы гораздо проще запускать и возвращать значимые результаты. Индексирование выполняется по умолчанию, поэтому большинство произвольных запросов выполняются довольно эффективно (в отличие от СУБД, где вам часто приходится оптимизировать и де-нормализовать после факт.)
вывод: несмотря на то, что вы можете использовать SOLR в качестве СУБД, вы можете обнаружить (как и я), что в конечном итоге "нет бесплатного обеда" - и экономия затрат на супер-крутой текстовый поиск lucene и высокопроизводительное индексирование в памяти часто оплачиваются за счет меньшей гибкости и принятия новых рабочих процессов доступа к данным.
вполне разумно использовать Solr в качестве базы данных, в зависимости от код приложение. На самом деле, это в значительной степени то, что guardian.co.uk делает.
Это точно не плохая практика как таковая. Это только плохо, если вы используете его неправильно, как и любой другой инструмент на любом уровне, даже Гото.
когда вы говорите " представление XML..."Я предполагаю, что вы говорите о наличии нескольких сохраненных полей Solr и получении этого используя XML-формат Solr, а не только одно большое поле XML-контента (что было бы ужасным использованием Solr). Тот факт, что Solr использует XML в качестве формата ответа по умолчанию, в значительной степени не имеет значения, вы также можете использовать бинарный протокол, так что это вполне сравнимо с традиционными реляционными базами данных в этой области.
в конечном счете, это зависит от потребностей вашего приложения. Солр и в первую очередь текстовый поисковик, но также может выступать в качестве базы данных NoSQL для многих приложения.
Это, вероятно, было сделано по соображениям производительности, если это не вызывает никаких проблем, я бы оставил его в покое. Существует большая серая область того, что должно быть в традиционной базе данных против индекса solr. Ive кажется, что люди делают подобные вещи (обычно пары значений ключей или json вместо xml) для представления пользовательского интерфейса и получают только реальный объект из базы данных, если это необходимо для обновлений/удалений. Но все читает просто перейти к Solr.