NoSQL (MongoDB) против Lucene (или Solr) в качестве базы данных

Question

С ростом движения NoSQL на основе баз данных на основе документов я недавно обратил внимание на MongoDB.Я заметил поразительное сходство с тем, как относиться к элементам как к «документам», так же, как это делает Lucene (и пользователи Solr).

Итак, вопрос: Почему вы хотите использовать NoSQL (MongoDB, Cassandra, CouchDB и т. Д.) Через Lucene (или Solr) в качестве вашей «базы данных»?

Что я (и я уверен, что другие) ищут в ответе - это некоторые глубокие сравненияиз них.Давайте пропустим все обсуждения реляционных баз данных, поскольку они служат другой цели.

Lucene дает некоторые серьезные преимущества, такие как мощные системы поиска и взвешивания.Не говоря уже о гранях в Solr (который скоро будет добавлен в Lucene, да!).Вы можете использовать документы Lucene для хранения идентификаторов и доступа к документам как к MongoDB.Смешайте его с Solr, и теперь вы получите решение с балансировкой нагрузки на основе WebService.

Вы даже можете добавить сравнение провайдеров кэширования вне процесса, таких как Velocity или MemCached, когда говорите о схожем хранении данных.и масштабируемость MongoDB.

Ограничения, касающиеся MongoDB, напоминают мне об использовании MemCached, но я могу использовать Microsoft Velocity и иметь больше возможностей для группировки и сбора списков по сравнению с MongoDB (я думаю).Не может быть быстрее или масштабируемее, чем кэширование данных в памяти.Даже у Lucene есть поставщик памяти.

MongoDB (и другие) имеют некоторые преимущества, такие как простота использования их API.Создайте документ, создайте идентификатор и сохраните его.Готово.Красиво и просто.

Answer 1

Это отличный вопрос, над которым я довольно долго размышлял.Я обобщу полученные уроки:

1. Вы можете легко использовать Lucene / Solr вместо MongoDB практически во всех ситуациях, но не наоборот.Пост Гранта Ингерсолла подводит итог здесь.

2. MongoDB и т. Д., Кажется, служат цели, где не требуется поиск и / или огранка.Это кажется более простым и, возможно, более легким переходом для программистов, детоксицирующих из мира RDBMS.Если не привыкать к этому, у Lucene & Solr есть более крутая кривая обучения.

3. Существует не так много примеров использования Lucene / Solr в качестве хранилища данных, но Guardian добились определенных успехов и суммируют этов превосходной слайд-колоде , но они также не обязательны для полного прыжка на подножку Solr и «расследования» объединения Solr с CouchDB.

4. Наконец, япредложит наш опыт, к сожалению, мало что может рассказать о бизнес-кейсе.Мы работаем в масштабе нескольких ТБ данных, практически в режиме реального времени.Изучив различные комбинации, решил придерживаться Solr.Пока не жалею (6 месяцев и считая) и не вижу смысла переходить на другие.

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

Мои 2 цента, надеюсь, это помогло.

Answer 2

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

И производительность имеет значение.Если вы не делаете коммит, ваше изменение в solr не вступает в силу, если вы фиксируете каждый раз, производительность снижается.

В solr нет транзакции.

Поскольку у solr есть эти недостатки, некоторыеTimes Nosql - лучший выбор.

Answer 3

Также обратите внимание, что некоторые люди интегрировали Solr / Lucene в Mongo, сохраняя все индексы в Solr, а также отслеживая операции оплогов и каскадно обновляя соответствующие обновления в Solr.

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

Это немного технически для настройки, но есть много оплогов, которые могут интегрироваться вSolr.Посмотрите, что диапазон сделал в этой статье.

http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html

Answer 4

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

[...] Однако мы видим, что производительность запросов Solr уменьшается с увеличением размера индекса.Мы поняли, что лучшим решением является совместное использование Solr и Mongo DB.Затем мы интегрируем Solr с MongoDB, сохраняя содержимое в MongoDB и создавая индекс, используя Solr для полнотекстового поиска.Мы сохраняем уникальный идентификатор для каждого документа в индексе Solr и извлекаем фактическое содержимое из MongoDB после поиска в Solr.Получение документов из MongoDB быстрее, чем в Solr, потому что нет анализаторов, скоринга и т. Д. [...]

Answer 5

Из моего опыта работы с обоими, Mongo отлично подходит для простого и понятного использования.Основным недостатком Mongo, от которого мы пострадали, является низкая производительность по непредвиденным запросам (вы не можете создавать монго-индексы для всех возможных комбинаций фильтров / сортировок, просто вы не можете).отличная производительность, особенно благодаря кешированию FilterQuery.

Answer 6

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

Answer 7

@ mauricio-scheffer упомянул Solr 4 - для тех, кто заинтересован в этом, LucidWorks описывает Solr 4 как «сервер поиска NoSQL», и есть видео на http://www.lucidworks.com/webinar-solr-4-the-nosql-search-server/, где они подробно описывают NoSQL (ish ) функции. (-Ish для их версии без схемы, фактически являющейся динамической схемой.)

Answer 8

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

Answer 9

MongoDB Atlas скоро будет иметь поисковую систему на основе люцена.Большое объявление было сделано на этой неделе на конференции MongoDB World 2019.Это отличный способ стимулировать более широкое использование их продукта MongoDB Atlas с высоким уровнем дохода.

Я надеялся увидеть, что он будет включен в MongoDB Enterprise версии 4.2, но не было никаких новостей о его внедрении в их предварительный продукт.line.

Подробнее здесь: https://www.mongodb.com/atlas/full-text-search

Answer 10

Сторонние решения, такие как Mongo Op-Log, привлекательны. Остаются некоторые мысли или вопросы о том, могут ли решения быть тесно интегрированы с точки зрения развития / архитектуры. Я не ожидаю увидеть тесно интегрированное решение для этих функций по нескольким причинам (несколько спекулятивным и подлежащим уточнению, а не актуальным с усилиями по разработке):

• Монго - это C ++, Lucene / Solr - это Java
  • возможно, Люцен мог бы использовать несколько монго-монго
  • возможно, Монго мог бы переписать некоторые алгоритмы Lucene, см. Также:
    • http://clucene.sourceforge.net/
    • http://lucy.apache.org/
• lucene поддерживает различные форматы документов
  • Монго ориентировано на JSON (BSON)
• Люцен использует неизменные документы
  • обновления для одного поля являются проблемой, если они доступны
• люценовые индексы неизменны при сложных операциях слияния
• Монго-запросы - это JavaScript
• У mongo нет текстовых анализаторов / токенизаторов (AFAIK)
• Размеры документов монго ограничены, что может пойти вразрез с зерном для люцена
• Операции агрегации монго могут не иметь места в люцене
  • В lucene есть опции для хранения полей в разных документах, но это не одно и то же
  • solr каким-то образом предоставляет агрегацию / статистику и запросы SQL / graph