在数据库中存储可视化和分析

Question

我目前正在开发一个允许用户分析和可视化数据的网络应用程序。 例如，用例之一是用户将执行主成分分析并将其存储。 可以有其他这样的分析，如火山图、热图等。

我想将这些分析和可视化存储在后端的数据库中。 我面临的挑战是如何设计一个高效的关系数据库模式。 以下是我的一些担忧：

• 与项目相关的数据已经以规范化的方式存储，以便可以调用。 我不想用可视化再次存储它。
• 同时，用户应该能够看到可视化背后的原始数据是什么。 例如。 什么数据被馈送到 PCA 算法？ 用户可能不会将与项目关联的所有数据用于 PCA。 他/她可能只是在项目中的数据子集上执行此操作。
• 与 webapp 相关的可视化数量会随着时间的推移而增长。 如果每次添加新的可视化时我都需要设计一个调用模式，它可能会使整体开发变慢。

考虑到这些，我想知道我是否应该尝试使用像 MySQL 这样的关系数据库来解决这个问题。 还是我应该看看 MongoDB？ 更一般地说，我如何看待这个问题？ 我尝试在网上寻找一些博客/教程，但找不到太多有用的东西。

Answer 1

在考虑技术设计（包括关系或非 SQL 平台）之前，您应该做的第一步是以独立于平台的方式清楚地描述数据之间的结构和关系的数据模型。 我看到以下有趣的问题需要解决：

• 可视化与它可视化的数据对象有何关联？ 当可视化仅显示一种对象类型的数据时（比如每月的销售数量），这是微不足道的。 但是，如果它涵盖多个对象类型（每月的销售数量、产品类别和国家/地区），您将不得不决定将其链接到其中的哪一个。 对此没有单一的正确解决方案，但这取决于用户的需求：他们将从哪个来源找到这种可视化？ 如果它们总是来自同一个来源（比方说国家），将视觉效果链接到该对象类型就足够了。

• 自生成可视化以来，您将如何处理基本数据的插入、删除和更新？ 如果没有这些与视觉相关的操作，那么很简单：只需将选择标准（国家=“奥地利”，产品类别=“玩具”）与视觉存储在一起，每个人都会知道其含义。 但是，如果基本数据可以更改，则您应该实现一个数据模型来涵盖这些数据的历史记录，即能够重建原始视觉所基于的数据值。 当然，在决定之前，您需要明确要求：如果更改了基础数据，原始视觉是否仍然有趣，还是需要重新生成以反映更改？

使用 NOSQL 数据库既不简化也不复杂。

无论这些需求和数据建模工作的结果如何，我都会坚持以下原则：

• 将视觉对象与基本数据分开，即使视觉对象仅与一组基本数据密切相关。 原因：视觉效果只是基本数据的结果，可以重新计算以防丢失。 因此，对于基本数据的数据备份等要求将比对视觉更严格。

• 不要冗余存储基本数据以显示每个单一视觉的基础。 带有每条基本数据记录的时间戳逻辑，连同生成的视觉对象的时间戳，将达到相同的目的，同时减少工作量和存储量。