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

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

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

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

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

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

EDIT: Когда я говорю "представление XML" - я имею в виду одно сохраненное поле, которое содержит строку XML всех свойств объекта, а не несколько сохраненных полей.

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

  • Инструменты "enterpriseisy", которые позволяют использовать расширенное управление сеансом и statefull-объекты, которые предлагают множество продвинутых веб-фреймворков (Ruby, Hibernate,...), должны быть полностью выведены из окна.

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

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

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

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

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

Ответ 3

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

Ответ 4

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