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

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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

Ответ 5

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

И здесь, где Lucene/Solr превалирует большое время, особенно с кешированием FilterQuery, производительность отличная.

Ответ 6

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

Ответ 7

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

Ответ 8

Если вы хотите хранить данные с использованием формата ключевого значения, Lucene не рекомендуется, потому что его инвертированный индекс будет тратить слишком много дисковых пространств. И с сохранением данных на диске его производительность намного медленнее, чем базы данных NoSQL, такие как redis, потому что redis сохраняет данные в ОЗУ. Наиболее выгодным для Lucene является поддержка многих запросов, поэтому могут поддерживаться нечеткие запросы.

Ответ 9

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

  • mongo - С++, lucene/solr - java
    • возможно, lucene может использовать некоторые mongo libs
    • Возможно, монго может переписать некоторые алгоритмы lucene, см. также:
  • lucene поддерживает различные форматы документов
    • mongo фокусируется на JSON (BSON).
  • lucene использует неизменяемые документы
    • обновления одного поля являются проблемой, если они доступны
  • Индексы lucene неизменяемы при сложном слиянии ops
  • mongo - это javascript
  • mongo не имеет текстовых анализаторов/токенизаторов (AFAIK)
  • размеры mongo doc ограничены, что может пойти против зерна для люцена
  • агрегирование mongo может не иметь места в lucene
    • lucene имеет опции для хранения полей в документах, но это не то же самое.
    • solr каким-то образом обеспечивает агрегацию/статистику и запросы SQL/graph

Ответ 10

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

Ответ 11

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

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

Более подробная информация здесь: https://www.mongodb.com/atlas/full-text-search