5

我有一个想要转换为 NoSQL 的 SQL 数据库（目前我正在使用 RavenDB）

这是我的表：

痕迹： 

ID (PK, bigint, not null)
DeploymentID (FK, int, not null)
AppCode (int, not null)

部署：

DeploymentID (PK, int, not null)
DeploymentVersion (varchar(10), not null)
DeploymentName (nvarchar(max), not null)

应用：

AppID (PK, int, not null)
AppName (nvarchar(max), not null)

目前我的表中有这些行：

痕迹：

ID: 1 , DeploymentID: 1, AppCode: 1
ID: 2 , DeploymentID: 1, AppCode: 2 
ID: 3 , DeploymentID: 1, AppCode: 3 
ID: 3 , DeploymentID: 2, AppCode: 1

部署：

DeploymentID: 1 , DeploymentVersion: 1.0, DeploymentName: "Test1"
DeploymentID: 2 , DeploymentVersion: 1.0, DeploymentName: "Test2"

应用：

AppID: 1 , AppName: "Test1"
AppID: 2 , AppName: "Test2"
AppID: 3 , AppName: "Test3"

我的问题是：我应该如何构建我的 NoSQL 文档模型？

它应该看起来像：

trace/1
{
 "Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test1" } ],
 "Application": "Test1"
}

trace/2
{
 "Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test1" } ],
 "Application": "Test2"
}

trace/3
{
 "Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test1" } ],
 "Application": "Test3"
}

trace/4    
{
 "Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test2" } ],
 "Application": "Test1"
}

如果部署 1 发生变化怎么办？我应该浏览每个文档并更改数据吗？

什么时候应该在 NoSQL 中使用引用？

4

2 回答 2

8

Raven 等文档数据库不是关系数据库。您不能先构建数据库模型，然后再决定各种有趣的查询方式。相反，您应该首先确定要支持的访问模式，然后相应地设计文档模式。

因此，为了回答您的问题，我们真正需要知道的是您打算如何使用这些数据。例如，显示按时间排序的所有跟踪与显示与特定部署或应用程序相关联的跟踪明显不同。这些要求中的每一个都将决定不同的设计，同时支持它们。

这本身对您来说可能是有用的信息（？），但我怀疑您想要更具体的答案:) 所以请添加一些关于您的预期用途的额外细节。

在决定策略时，有一些“做”和“不做”：

DO：针对常见用例进行优化。通常有 20/80 的细分，其中 20% 的 UX 驱动 80% 的负载——Web 应用程序的主页/登录页面就是一个典型的例子。首要任务是确保这些尽可能高效。确保您的数据模型允许 A) 在单个 IO 请求中加载它们或 B) 对缓存友好

不要：不要落入可怕的“N+1”陷阱。当您的数据模型强制您进行 N 次调用以加载 N 个实体时，就会出现这种模式，通常在此之前还有一个额外的调用以获取 N 个 ID 的列表。这是一个杀手，尤其是与#3...

做：总是限制（通过用户体验）你愿意获取的数据量。如果用户有 3729 条评论，您显然不会一次获取所有评论。即使从数据库的角度来看它是可行的，用户体验也会很糟糕。这就是搜索引擎使用“下一个 20 个结果”范式的原因。因此，您可以（例如）将数据库结构与 UX 对齐并将评论保存为 20 块。然后每次页面刷新都涉及一个 DB 获取。

DO：平衡读取和写入要求。某些类型的系统是读取繁重的，您可以假设每次写入都会有很多读取（StackOverflow 就是一个很好的例子）。因此，为了提高读取性能，提高写入成本是有意义的。例如，数据非规范化和复制。其他系统均衡甚至写入繁重，需要其他方法

做：利用时间维度来发挥你的优势。Twitter 是一个典型的例子：99.99% 的推文在第一个小时/天/周/任何时间之后将永远不会被访问。这在您的数据模式中打开了各种有趣的优化可能性。

这只是冰山一角。我建议阅读一下基于列的 NoSQL 系统（例如 Cassandra）

于 2013-05-02T21:25:34.177 回答
1

您如何为文档建模主要取决于您的应用程序及其域。从那里，可以通过了解您的数据访问模式来完善文档模型。

盲目地尝试将关系数据模型映射到非关系模型可能不是一个好主意。

更新：我认为马特在这里得到了我的主要观点。我想说的是，没有规定的方法（无论如何我都知道）可以在不理解和考虑应用程序的领域。让我在这里详细说明一下...

查看您的 SQL 架构后，我不知道除了似乎加入应用程序和部署的表之外的跟踪是什么。我也不知道您的应用程序通常如何查询数据。了解这一点会在您对文档进行建模时有所不同，就像它会对您对应用程序对象（或域对象）建模的方式产生影响一样。

因此，您的问题中建议的文档模型可能适用于您的应用程序，也可能不适用于您的应用程序。

于 2013-04-30T17:00:37.160 回答