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

С ростом 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. Создайте новый документ, создайте идентификатор и сохраните его. Готово. Легко и приятно.

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

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

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

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

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

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

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

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

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

Там нет транзакции в Solr.

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

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

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

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

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

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

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

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

И здесь, где Lucene / Solr преобладает, особенно с кэшированием FilterQuery, производительность является выдающейся.

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

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

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

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

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

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

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

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