Хранение визуализации и анализа в базе данных

Question

В настоящее время я работаю над веб-приложением, которое позволит пользователям анализировать & визуализировать данные. Например, одним из вариантов использования является то, что пользователь выполнит анализ основных компонентов и сохранит его. Может быть другой такой анализ, как график вулкана, тепловая карта и т. Д.

Я хотел бы сохранить эти анализы и визуализации в базе данных в фоновом режиме. Перед нами стоит задача разработать схему реляционной базы данных, которая будет делать это эффективно. Вот некоторые из моих проблем:

• Данные, связанные с проектом, уже будут храниться в нормализованном порядке, чтобы их можно было вызвать. Я бы не хотел хранить его снова с визуализацией.
• В то же время пользователь должен иметь возможность видеть, каковы исходные данные за визуализацией. Напр. какие данные были поданы в алгоритм PCA? Пользователь может не использовать все данные, связанные с проектом для PCA. Он может просто делать это на подмножестве данных в проекте.
• Количество визуализаций, связанных с webapp, будет расти со временем. Если мне нужно каждый раз придумывать новую схему, добавляя новую визуализацию, это может привести к замедлению общего развития.

Имея это в виду, мне интересно, попытаться ли я решить эту проблему с помощью реляционной базы данных, такой как MySQL. Или я должен посмотреть на MongoDB? В целом, как я могу думать об этой проблеме? Я попытался найти несколько блогов/учебников в Интернете, но не смог найти много полезного.

Answer 1

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

• Как визуализируется связанная с объектами данных, которую он визуализирует? Когда визуализация просто отображает данные по типу объекта (скажем, количество продаж в месяц), это тривиально. Но если он охватывает более одного типа объекта (количество продаж в месяц, категорию продукта и страну), вам нужно будет решить, к какому из них нужно связать его. Для этого нет единого правильного решения, но оно зависит от требований пользователей: от каких истоков они найдут эту визуализацию? Если они всегда происходят из одного и того же происхождения (скажем, страны), будет достаточно связать визуальные эффекты с этим типом объекта.

• Как вы будете обрабатывать вставки, удаления и обновления основных данных с момента создания визуализации? Если такие операции, связанные с визуальными эффектами, невозможны, то это легко: просто сохраните критерии выбора (страна = «Австрия», категория продукта = «Игрушки») с визуальным, и каждый будет знать его значение. Если, однако, основные данные могут быть изменены, вам следует внедрить модель данных, которая охватывает историзацию этих данных, то есть возможность восстановить значения данных, на которых основывался исходный визуал. Конечно, прежде чем принимать решение по этому вопросу, вам необходимо уточнить требования: будет ли в случае изменения базовых данных исходный визуал интересным или его нужно будет сгенерировать, чтобы отразить изменения?

Оба вопроса не упрощаются и не осложняются с помощью базы данных NOSQL.

Независимо от того, каков результат этих требований и данных усилий моделирования, я бы придерживаться следующих принципов:

• Отдельные визуальными из основных данных, даже если визуально тесно связано только один набор базовых данных. Причина. Визуальные эффекты являются следствием базовых данных, которые могут быть пересчитаны в случае их утери. Таким образом, требования, например, для резервного копирования данных будет более строго для основных данных, чем для визуальных.

• Не храните основные данные избыточно, чтобы показать основу для каждого отдельного визуального. Логика метки времени с каждой записью основных данных вместе с меткой времени созданного визуального изображения будет служить той же цели с меньшим усилием и объемом памяти.