Ответ 1
Во-первых, существует важное различие: MongoDB - это база данных общего назначения, Elasticsearch - это распределенная текстовая поисковая система, поддерживаемая Lucene. Люди говорили об использовании Elasticsearch в качестве базы данных общего назначения, но знают, что это не был ее "оригинальный дизайн". Я думаю, что базы данных NoSQL общего назначения и поисковые системы нацелены на консолидацию, но, поскольку это происходит, они происходят из двух совершенно разных лагерей.
Мы используем MongoDB и Elasticsearch в моей компании. Мы храним наши данные в MongoDB и используем Elasticsearch исключительно для своих возможностей полнотекстового поиска. Мы отправляем только подмножество полей данных монго, которые нам нужно запросить на эластичность. Наш случай использования отличается от вашего, так как наши данные Mongo постоянно меняются: запись или подмножество полей записи может обновляться несколько раз в день, и это может потребовать повторной индексации этой записи до эластичной. По этой причине использование эластичных материалов в качестве единственного хранилища данных для нас не является хорошим вариантом, поскольку мы не можем обновлять поля выбора; нам нужно будет переиндексировать документ в его полном объеме. Это не эластичное ограничение, так работает Луцен, основной поисковый движок за эластичным. В вашем случае тот факт, что записи не будут изменены после сохранения, избавит вас от необходимости делать этот выбор. Сказав, что, если безопасность данных вызывает беспокойство, я бы дважды подумал об использовании Elasticsearch в качестве единственного механизма хранения ваших данных. Он может попасть туда в какой-то момент, но я еще не уверен, что он там.
В плане скорости не только Elastic/Lucene наравне с скоростью запросов Mongo, в вашем случае, когда "очень мало констант, с помощью которого поля используются для фильтрации в любой момент", это может на порядок быстрее, тем более, что наборы данных становятся больше. Разница заключается в базовых реализациях запросов:
- Эластик /Lucene используют векторную космическую модель и инвертированные индексы для Информационный поиск, которые являются высокоэффективными способами сравнения сходства записей с запросом. Когда вы запрашиваете Elastic/Lucene, он уже знает ответ; большая часть его работы заключается в ранжировании результатов для вас наиболее вероятными для соответствия вашим условиям запроса. Это важный момент: поисковые системы, в отличие от баз данных, не могут гарантировать вам точные результаты; они ранжируют результаты по тому, насколько близко они добираются до вашего запроса. Так получилось, что в большинстве случаев результаты близки к точным.
- Монгольский подход относится к хранилищу данных общего назначения; он сравнивает документы JSON друг против друга. Вы можете получить отличную производительность из него, но вам нужно тщательно обработать свои индексы в соответствии с запросами, которые вы будете запускать. В частности, если у вас есть несколько полей, по которым вы будете запрашивать, вам необходимо тщательно обработать ваши составные ключи, чтобы они уменьшали набор данных, который будет запрашиваться как можно быстрее. Например. ваш первый ключ должен отфильтровать большую часть вашего набора данных, а вторая должна дополнительно отфильтровать оставшиеся и т.д. и т.д. Если ваши запросы не совпадают с ключами и порядком этих ключей в определенных индексах, производительность будет падать совсем немного. С другой стороны, Mongo - это настоящая база данных, поэтому, если точность - это то, что вам нужно, ответы, которые она даст, будут на месте.
Для устаревания старых записей Elastic имеет встроенную функцию TTL. Монго только что представил его с версии 2.2, я думаю.
Так как я не знаю ваших других требований, таких как ожидаемый размер данных, транзакции, точность или то, как будут выглядеть ваши фильтры, трудно сделать какие-либо конкретные рекомендации. Надеюсь, этого достаточно, чтобы вы начали.