java - это - solr документация на русском




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

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

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

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

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

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

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


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


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

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

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

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


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

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

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

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

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

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

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

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

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

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





solr