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

254

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

  • 8
    См. Stackoverflow.com/questions/2546494/…
  • 4
    Спасибо, но это не отвечает на мой вопрос: зачем мне использовать MongoDB вместо Lucene для моей базы данных? Они оба обрабатывают документы, но у Lucene есть несколько очень мощных опций поиска. +1, хотя на самом деле найти связанный вопрос. Я искал несколько раз на Stackoverflow, и не нашел близкого сравнения.
Показать ещё 2 комментария
Теги:
solr
lucene
nosql
memcached

10 ответов

212
Лучший ответ

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

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

  • MongoDB и т.д., похоже, служат целям, в которых нет необходимости искать и/или делать огранку. Это, по-видимому, более простой и, возможно, более простой переход для дезинтеграции программистов из мира РСУБД. Если бы никто не привык к этому, у Lucene и Solr была бы более крутая кривая обучения.

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

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

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

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

Поделиться
  • 9
    Solr не имеет карты для уменьшения функциональности. Поэтому отчеты, статистика, подсчет очков и т. Д. Невозможны! Используйте Solr, только если у вас есть / может угрожать ваши данные в виде текстовых данных
  • 7
    Solr не имеет встроенного map-Reduction, но вы можете комбинировать его с Hadoop. architects.dzone.com/articles/solr-hadoop-big-data-love
Показать ещё 4 комментария
34

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

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

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

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

Поделиться
  • 13
    MongoDB также не имеет транзакций.
  • 1
    У Solr или Lucene есть поиск в реальном времени, поэтому фиксация не является проблемой.
Показать ещё 3 комментария
24

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

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

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

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

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

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

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

Поделиться
  • 3
    Хороший пост в блоге. Да, именно так я и использовал Lucene в прошлом со старыми хранилищами данных SQL и MySql (хранение идентификаторов в Lucene и извлечение сложных типов из хранилища данных). Технически, однако, этот вопрос заключался в том, чтобы исследовать различия между этими двумя понятиями, а не как использовать «лучшее из обоих миров». +1 за использование этого способа, так как это действительно единственный реальный способ использования огромных объемов данных.
  • 0
    Спасибо за ваш ответ. Я знаю, что вопрос в том, чтобы выбрать Nosql вместо Lucene, но здесь я хочу показать, что вместо того, чтобы выбирать один из других, гибридное использование их даст лучший результат.
Показать ещё 4 комментария
13

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

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

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

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

Поделиться
4

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

Поделиться
1

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

Поделиться
0

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

Поделиться
0

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

  • 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
Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню