Elasticsearch v.s. MongoDB для фильтрации приложений

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

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

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

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

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

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

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

Спасибо!

Ответ 1

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

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

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

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

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

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