MongoDB + Elasticsearch или только Elasticsearch?

Ответ 1

Говоря о аргументах использования Mongo вместо/вместе с ES:

• Управление пользователями/ролями.

  • Встроенный в MongoDB. Может не соответствовать всем вашим потребностям, может быть неуклюжим где-то, но он существует, и он был реализован довольно давно.
  • Единственное, что для безопасности в ES - shield. Но он поставляется только для подписки Gold/Platinum для использования в целях производства.

• Схема

  • ES схематично, но построена поверх Lucene и написана в Java. Основная идея этого инструмента - индексные и поисковые документы, и работающий таким образом, требует согласованности индексов. На задней панели все документы должны быть установлены в плоском индексе Lucene, что требует некоторого понимания того, как ES должен иметь дело с вашими вложенными документами и значениями, и как вам следует упорядочивать индексы для поддержания баланса между скоростью и полнотой/согласованностью данных. Работа с ES требует, чтобы вы постоянно храните некоторые вещи в схеме. Т.е.: поскольку вы можете индексировать почти что-либо в ES, не помещая соответствующее сопоставление заранее, ES может "угадывать" сопоставление "на лету", но иногда делает это неправильно, а иногда неявное сопоставление является злым, потому что, как только оно ставится, оно не может быть изменено w/o переиндексация всего индекса. Таким образом, лучше не рассматривать ES как хранилище схем, потому что вы можете на некоторое время наступить на грабли (и это будет боль:)), а скорее рассматривать его как интенсивно для схемы, по крайней мере, когда вы работаете с документами, что может нарезать на конкретные поля.
  • Mongo, с другой стороны, может "пережевывать и оставлять без крошек" из всего, что вы вкладываете в него. И большинство ваших запросов будут хорошо работать, пока вы не вспомните, как Mongo будет обрабатывать ваши данные с точки зрения JavaScript. И поскольку JS слабо типизирован, вы можете работать с действительно схематичным рабочим процессом (конечно, если вам это нужно)

• Обработка нестатистических данных.

  • ES ограничивается обработкой данных, не помещая их в индекс поиска. И это решение достаточно хорошо, когда вам нужно хранить и извлекать дополнительные данные (по сравнению с данными, которые вы хотите выполнить).
  • MongoDB поддерживает gridFS. Это дает вам возможность обрабатывать большие куски данных за одним и тем же интерфейсом. I.e., вы можете хранить двоичные данные в Mongo и извлекать их в пределах одного и того же интерфейса с точки зрения вашего кода.

Ответ 2

Хорошо, выберите правильный инструмент для правильной работы. Если вам нужны возможности поиска, такие как полнотекстовый поиск, огранка и т.д., Тогда ничто не может победить полноценную поисковую систему. ElasticSearch (ES) или Solr - это только вопрос выбора.

Фактически вы можете загружать (индексировать) документы в ES для поиска, а затем извлекать полные данные для конкретной записи из MongoDB или любой другой базы данных.

Я могу сделать вашу задачу проще, взгляните на мою работу с открытым исходным кодом, которая использует MongoDB, ES, Redis и RabbitMQ, все интегрированные в одном месте, здесь, на github

Обратите внимание, что приложение встроено в .Net С#.

Ответ 3

Недавно я разработал функцию в своей компании,

мы хотели выполнить некоторые поиски и ранжировать результат в соответствии с его релевантностью по нескольким факторам и условиям.

Поэтому в моем приложении мы уже использовали MongoDB в качестве Db,

Итак, по индексу ElasticSearch я экспортировал некоторые поля из MongoDB, по которым я хочу выполнить поиск и фильтры. Таким образом, в соответствии с необходимыми условиями, я подготовил свой запрос на монго и запрос на поиск и выполнил поиск. Затем я отфильтровал и отсортировал результат в соответствии с моими потребностями. Весь поток будет разработан таким образом, чтобы даже если в ES произошла ошибка, mongo получит записи. Если я получу результат от ES, то результат монго будет зависеть от результата ES. Вот как я использовал монго и ES в комбинации.

Кроме того, не забудьте правильно обрабатывать все обновления, удаления и вставки новых записей.

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

Ответ 4

После использования Elasticsearch на производстве я могу добавить к этой теме несколько заметок:

• Мы изолировали нашу кластеризацию Elasticsearch через обратный прокси-сервер, который проверяет подлинность клиентского сертификата во время запроса, прежде чем разрешить запрос: это доказывает, что в любом случае существует несколько способов добавления аутентификации. (Если вам нужна большая точность в безопасности, например, при использовании ролей, для управления разрешениями можно добавить несколько плагинов)
• Elasticsearch mapping и настройки (настройка) являются действительно важными понятиями, которые нужно полностью понять, прежде чем приступить к работе с ним, и что не так просто понять, как все работает быстро.
• Кластеризация и горизонтальное масштабирование очень гибки и просты в настройке
• Набор инструментов (Kibana, ритмы и т.д.) - очень удобный способ сбора логов, раскрытия ключевых данных и т.д....
• Функции поиска чрезвычайно продвинуты, вы действительно можете делать удивительные вещи, когда немного освоите работу полнотекстового поиска (нечеткость, повышение, оценка, остановка, токенизатор, анализаторы и т.д.).
• API немного разбросан, и нет уникальных способов чего-то достичь. И некоторые API действительно WTF для использования, такие как API массовой вставки: вам нужно передавать двоичные данные в формате JSON (ofc не забудьте символы конца строки) и повторять некоторые поля несколько раз. Это очень многословно, и я думаю, что это унаследованный код, как у всех нас в наших проектах;).
• И последнее: если вы разрабатываете проект Java, не используйте Hibernate Search для дублирования данных из источника данных в ваш кластер ES, у нас было очень много проблем с Hibernate Search, если бы нам пришлось сделать это снова, мы бы сделали это вручную.

Теперь о реальном вопросе:

На мой взгляд, достаточно использовать только Elasticsearch, что может снизить сложность использования нескольких систем хранения NoSQL.

Я думаю, что это достойно, когда вы делаете дуэт Реляционная и транзакционная база данных + поисковая система NoSQL, но иметь две системы, которые примерно служат для тех же целей, немного излишне