Все зависит от двух вещей - какой объем данных (количество объектов со значимыми полями) и какого рода анализ необходимо делать на основе данных. Так же вопрос, как много потребителей этих данных? Возможен ли конкурентный доступ на чтение и запись (так как когда вступает в дело параллелизм и одновременный доступ, все становится сложнее на порядки)
Второе определит, хватит ли тебе sql баз данных (они лучше подходят для фильтраций и анализа чем документоориентированные) либо придется искать узкоспециализированные решения, в т.ч. графовые бд.
Первое же определит, особенно если данных очень мало, может ли самостоятельная работа в оперативной памяти в своем приложении, быть более эффективной? Дело в том что 99% причин, почему в мире люди наработали столько не простых инструментов - это большое количество данных и высокие требования по многопользовательскому доступу к ним, если оба этих пункта исключить, то гораздо удобнее нетипичный анализ проводить в своей программе, удерживая данные в оперативной памяти (а база данных используется исключительно как отказоустойчивое хранилище).
Лично мне больше нравится комбинация самописных инструментов в совокупности с классическими хранилищами (надежность, хранение и многопоточный доступ). К примеру когда из-за особенностей задачи анализа, sql запросы становятся неподъемно сложными, в ход вступает их генерация, в конце концов многие так и поступают и готовые решения строятся на основе уже готовых эффективных решений. sql хорошо масштабируются, просты в использовании и не вносят заметных дополнительных расходов.
p.s. json это значит для контроля над целостностью, индексации и поиска придется городить свои надстройки, с другой стороны это освобождает руки от непреднамеренного усложнения хранилища там где это не требуется, в общем осторожностью нужно подходить к этому, это не плохо и не хорошо, это просто еще один способ со своими плюсами и минусами
Средний
