asticsearch и MongoDB для фильтрации приложений [закрыто]

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

Гипотетически оба хранят объекты данных, которые имеют поля и значения, и позволяют запрашивать это тело объектов. Таким образом, предположительно, фильтрация подмножеств объектов в соответствии с выбранными полями ad-hoc подходит для обеих сторон.

Мое приложение будет вращаться вокруг выбора объектов в соответствии с критериями. Он будет выбирать объекты путем одновременной фильтрации по более чем одному полю, иначе говоря, его критерии фильтрации запросов обычно содержат от 1 до 5 полей, а в некоторых случаях может быть больше. Принимая во внимание, что поля, выбранные в качестве фильтров, будут подмножеством гораздо большего количества полей. Представьте себе, что существует около 20 имен полей, и каждый запрос представляет собой попытку отфильтровать объекты по нескольким полям из этих общих 20 полей. поля к полям, используемым в качестве фильтров в каждом отдельном запросе). Фильтрация может осуществляться по наличию выбранных полей, а также по значениям полей, например, отфильтровывать объекты, которые имеют поле A, и их поле B находится между x и y,

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

Что касается данных, поступающих в хранилище, то никаких особых подробностей об этом нет ... объекты почти никогда не изменятся после вставки. Возможно, старые объекты нужно будет удалить, я хотел бы предположить, что оба хранилища данных поддерживают удаление файлов с истекшим сроком действия внутренне или по запросу приложения. (Реже, объекты, которые соответствуют определенному запросу, должны были бы также быть отброшены).

Что вы думаете? И вы экспериментировали с этим аспектом?

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

Спасибо!

Прежде всего, здесь необходимо сделать важное различие: MongoDB - это база данных общего назначения, Elasticsearch - это система распределенного текстового поиска, поддерживаемая Lucene. Люди говорили об использовании Elasticsearch в качестве базы данных общего назначения, но знают, что это не был ее оригинальный дизайн. Я думаю, что базы данных и поисковые системы общего назначения NoSQL движутся к консолидации, но в настоящее время они происходят из двух совершенно разных лагерей.

Мы используем MongoDB и Elasticsearch в моей компании. Мы храним наши данные в MongoDB и используем Elasticsearch исключительно для его полнотекстового поиска. Мы отправляем только подмножество полей данных Монго, которые нам нужно запросить, в эластичный. Наш вариант использования отличается от вашего тем, что наши данные Mongo все время меняются: запись или подмножество полей записи могут обновляться несколько раз в день, и это может потребовать повторной индексации этой записи до эластичного. Только по этой причине использование эластичного хранилища данных в качестве единственного хранилища данных не является хорошим вариантом для нас, поскольку мы не можем обновить выбранные поля; нам нужно будет переиндексировать документ целиком. Это не эластичное ограничение, это то, как работает Lucene, основная поисковая система, стоящая за эластичной. В вашем случае тот факт, что записи выиграли Изменение после сохранения избавит вас от необходимости делать этот выбор. Сказав это, если безопасность данных является проблемой, я бы дважды подумал об использовании Elasticsearch в качестве единственного механизма хранения ваших данных. Может быть, это произойдет в какой-то момент, но я не уверен, что это там еще.

С точки зрения скорости, Elastic / Lucene не только соответствует скорости запросов Mongo, в вашем случае, когда «очень мало постоянных с точки зрения того, какие поля используются для фильтрации в любой момент», это могут быть порядки на величину быстрее, особенно когда наборы данных становятся больше. Разница заключается в базовых реализациях запросов:

• Elastic / Lucene используют Модель векторного пространства и инвертированные индексы для поиска информации , которые являются высокоэффективными способами сравнения сходства записей с запросом. Когда вы запрашиваете Elastic / Lucene, он уже знает ответ; большая часть его работы заключается в ранжировании результатов для вас по наиболее вероятным из них, чтобы соответствовать условиям вашего запроса. Это важный момент: поисковые системы, в отличие от баз данных, не могут гарантировать вам точные результаты; они ранжируют результаты по степени их близости к вашему запросу. Так уж получилось, что в большинстве случаев результаты близки к точным.
• Монго - это подход к хранилищу данных более общего назначения; он сравнивает документы JSON друг с другом. Вы можете получить из этого отличную производительность, но вам нужно тщательно обработать свои индексы, чтобы соответствовать запросам, которые вы будете выполнять. В частности, если у вас есть несколько полей, по которым вы будете запрашивать, вам нужно тщательно составить составные ключи.так что они уменьшают набор данных, который будет запрашиваться как можно быстрее. Например, ваш первый ключ должен фильтровать большую часть вашего набора данных, ваш второй ключ должен дополнительно фильтровать то, что осталось, и так далее, и так далее. Если ваши запросы не соответствуют ключам и порядку этих ключей в определенных индексах, ваша производительность значительно снизится. С другой стороны, Mongo - это настоящая база данных, поэтому, если вам нужна точность, ответы на нее будут точны.

Для устаревания старых записей Elastic имеет встроенную функцию TTL. Монго только что представил его с версии 2.2, я думаю.

Поскольку я не знаю других ваших требований, таких как ожидаемый размер данных, транзакции, точность или то, как будут выглядеть ваши фильтры, трудно дать какие-либо конкретные рекомендации. Надеюсь, здесь достаточно, чтобы вы начали.