@beduin01

Можно ли хранить в графовых базах данных JSON?

Думаю над тем как спроектировать систему.
Система выглядит следующим образом -- есть массив данных в виде JSON, который постоянно дополняется.
Нужно:
1. Иметь возможность работать с ним (поиск значений, синонимов, отдача пользователю найденных JSON)
2. Данные очень похожи на те которые можно анализировать через графовые БД т.е. искать взаимосвязи и тд.
3. Полноценная аналитика (не знаю можно ли считать отдельным пунктом или он к 1/2 относится)

Я так и не понял в каком виде хранят данные графовые БД. Чем они отличаются от документоориентированных. Могут ли графовые БД выполнять то что я написал в пункте 1?

На сколько перпендикулярны эти две задачи? Если нужно и то и другое можно ли одной БД обойтись или нужно две использовать?
  • Вопрос задан
  • 47 просмотров
Решения вопроса 1
@rPman
Все зависит от двух вещей - какой объем данных (количество объектов со значимыми полями) и какого рода анализ необходимо делать на основе данных. Так же вопрос, как много потребителей этих данных? Возможен ли конкурентный доступ на чтение и запись (так как когда вступает в дело параллелизм и одновременный доступ, все становится сложнее на порядки)

Второе определит, хватит ли тебе sql баз данных (они лучше подходят для фильтраций и анализа чем документоориентированные) либо придется искать узкоспециализированные решения, в т.ч. графовые бд.

Первое же определит, особенно если данных очень мало, может ли самостоятельная работа в оперативной памяти в своем приложении, быть более эффективной? Дело в том что 99% причин, почему в мире люди наработали столько не простых инструментов - это большое количество данных и высокие требования по многопользовательскому доступу к ним, если оба этих пункта исключить, то гораздо удобнее нетипичный анализ проводить в своей программе, удерживая данные в оперативной памяти (а база данных используется исключительно как отказоустойчивое хранилище).

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

p.s. json это значит для контроля над целостностью, индексации и поиска придется городить свои надстройки, с другой стороны это освобождает руки от непреднамеренного усложнения хранилища там где это не требуется, в общем осторожностью нужно подходить к этому, это не плохо и не хорошо, это просто еще один способ со своими плюсами и минусами
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы