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

280

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

mongodb solr lucene memcached nosql eduncan911
источник
8
См stackoverflow.com/questions/2546494/...
bajafresh4life
4
Спасибо, но это не отвечает на мой вопрос: зачем мне использовать MongoDB вместо Lucene для моей базы данных? Они оба обрабатывают документы, но у Lucene есть несколько очень мощных опций поиска. +1, хотя на самом деле найти связанный вопрос. Я искал несколько раз на Stackoverflow, и не нашел близкого сравнения.
eduncan911
Как вы используете Lucene, который обеспечивает функциональность, аналогичную MongoDB? Вы привязываете его к реляционной БД для хранения?
Филипп Тинни
1
@Philip: это гипотетический вопрос. Почему бы не использовать Lucene в качестве хранилища документов? Вы получаете гораздо больше возможностей поиска и масштабируемости (при смешивании с Solr сделать Lucene еще проще в использовании).
eduncan911

Ответы:

250

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

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

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

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

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

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

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

Микос
источник
10
Solr не имеет карты, уменьшающей функциональность. Поэтому отчеты, статистика, подсчет очков и т. Д. Невозможны! Используйте Solr, только если у вас есть / может угрожать вашим данным в виде текстовых данных
Роланд Кофлер
8
Solr не имеет встроенного map-Reduction, но вы можете комбинировать его с Hadoop. architects.dzone.com/articles/solr-hadoop-big-data-love
Микос
6
Map-Reduce нет, но он имеет возможность выполнять запрос параллельно на нескольких серверах Solr и агрегировать эти результаты. Так что, хотя у него нет общего назначения карты-сокращения, оно уже написало то, что вы написали бы с помощью карты-сокращения, то есть параллельных поисковых запросов.
chubbsondubs
@Roo: Будет ли возможность использовать Lucene в качестве основной БД и каким-либо образом создавать сводные индексы с MongoDB? Или это не имеет смысла? И Микос: отличный ответ и +1 за реальный опыт упоминания.
Гримаса Отчаяния
2
из solr6 он поддерживает функциональность сокращения карт с параллельными выражениями
Дивьянг Шах
36

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

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

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

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

Питер Лонг
источник
13
MongoDB также не имеет транзакций.
user183037
1
У Solr или Lucene есть поиск в реальном времени, поэтому фиксация не является проблемой.
mihaicc
1
@ user183037 в MongoDB любые обновления в документе являются атомными. И к вашему сведению, в Lucene также нет транзакций (в вашем смысле)
Аравинд Яррам
48
Этот ответ стал неверным. Solr 4+ поддерживает частичные обновления, а мягкие фиксации / почти в реальном времени устраняют большинство проблем «старого стиля» фиксаций Solr.
Маурисио Шеффер
1
Они добавили поддержку транзакций на MongoDB 4.
Йонас
26

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

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

Парвин Гасымзаде
источник
3
Хороший пост в блоге. Да, именно так я и использовал Lucene в прошлом со старыми хранилищами данных SQL и MySql (хранение идентификаторов в Lucene и извлечение сложных типов из хранилища данных). Технически, однако, этот вопрос состоял в том, чтобы исследовать различия между этими двумя понятиями, а не точно, как использовать «лучшее из обоих миров». +1 за использование этого способа, так как это действительно единственный реальный способ использования огромных объемов данных.
eduncan911
Спасибо за ваш ответ. Я знаю, что вопрос состоит в том, чтобы выбрать Nosql вместо Lucene, но здесь я хочу показать, что вместо того, чтобы выбирать одно из другого, гибридное их использование даст лучший результат.
Парвин Гасымзаде
2
Вы помните (сейчас 1,5 года спустя) примерно размер базы данных Solr, когда производительность запросов настолько снизилась, что вы начали задумываться о добавлении MongoDB? (Было ли это 10 000 документов или 10 000 000 документов?)
KajMagnus
Очень полезно. Я работаю в ГИС, и поэтому возможность комбинировать полнотекстовый и пространственный поиск таким образом очень интригует. Мы уже используем MongoDB и Postgres, и я некоторое время думал о Solr.
Джон Пауэлл
2
@ParvinGasimzade ссылка на сообщение в блоге не работает. Не могли бы вы предоставить другую ссылку или источник?
забвение
24

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

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

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

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

Празит Говин
источник
Если я вас правильно понял, причина, по которой вы используете MongoDB (в дополнение к Solr), заключается в том, что MongoDB имеет более быструю вставку + скорость чтения? Вы также указали, что MongoDB имеет более надежное хранилище данных? (Или вы имели в виду Solr?) - С чего вы начали изначально? Только MongoDB, только Solr или оба Mongo + Solr?
КаджМагнус
12

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

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

mjalajel
источник
10

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

акварель
источник
6
что ИМХО не совсем верно. У Solr есть схема, как определено в schema.xml, но у нее также есть «динамические поля», то есть поля, типы которых определяются с помощью подстановочных знаков, так что вы можете иметь все поля, соответствующие, скажем, *_iиндексированным как целочисленные поля. при добавлении документов, вы можете иметь документы conaining поля , такие как count_i, foo_i, bar_iчто все понятные , как целые поля без появления в schema.xmlбуквальном смысле. я бы сказал, довольно без схемы см. youtube.com/watch?v=WYVM6Wz-XTw для получения дополнительной информации.
поток
Я должен вернуться и увеличить это с +1, потому что это правда - изменения схемы в Solr всегда были в PITA, чтобы синхронизироваться с другими хранилищами данных.
eduncan911
4
Solr имеет функцию, которая поддерживает схему или без схемы!
Крунал
5

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

в промежутке
источник
1

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

张洪岩
источник
1

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

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

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

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

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

Гари Руссо
источник