Этот вопрос касается выбора архитектуры, прежде чем углубляться в детали экспериментов и реализации. Речь идет о пригодности, с точки зрения масштабируемости и производительности, эластичного поиска по сравнению с MongoDB для определенной цели.
Гипотетически оба хранят объекты данных, которые имеют поля и значения, и позволяют запрашивать это тело объектов. Таким образом, предположительно, фильтрация подмножеств объектов в соответствии с выбранными полями ad-hoc подходит для обеих сторон.
Мое приложение будет вращаться вокруг выбора объектов в соответствии с критериями. Он будет выбирать объекты путем одновременной фильтрации по более чем одному полю, иначе говоря, его критерии фильтрации запросов обычно содержат от 1 до 5 полей, а в некоторых случаях может быть больше. Принимая во внимание, что поля, выбранные в качестве фильтров, будут подмножеством гораздо большего количества полей. Представьте себе, что существует около 20 имен полей, и каждый запрос представляет собой попытку отфильтровать объекты по нескольким полям из этих общих 20 полей. поля к полям, используемым в качестве фильтров в каждом отдельном запросе). Фильтрация может осуществляться по наличию выбранных полей, а также по значениям полей, например, отфильтровывать объекты, которые имеют поле A, и их поле B находится между x и y,
Мое приложение будет постоянно выполнять такую фильтрацию, в то время как не будет ничего или очень мало констант с точки зрения того, какие поля используются для фильтрации в любой момент. Возможно, в эластичном поиске необходимо определить индексы, но, возможно, даже без индексов скорость находится на одном уровне с MongoDB.
Что касается данных, поступающих в хранилище, то никаких особых подробностей об этом нет ... объекты почти никогда не изменятся после вставки. Возможно, старые объекты нужно будет удалить, я хотел бы предположить, что оба хранилища данных поддерживают удаление файлов с истекшим сроком действия внутренне или по запросу приложения. (Реже, объекты, которые соответствуют определенному запросу, должны были бы также быть отброшены).
Что вы думаете? И вы экспериментировали с этим аспектом?
Меня интересует производительность и масштабируемость каждого из двух хранилищ данных для такого рода задач. Это своего рода архитектурно-конструкторский вопрос, и подробности конкретных параметров магазина или краеугольных камней запроса, которые должны сделать его хорошо спроектированным, приветствуются в качестве демонстрации полностью продуманного предложения.
Спасибо!