建模的NoSQL数据库（从SQL数据库转换时）

Question

我有我想转换到NoSQL的一个（我目前使用RavenDB）

这里是我的表SQL数据库：

跟踪：

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中使用引用？

Answer 1

你如何建模你的文档主要取决于你的应用程序和它的域名。从那里开始，可以通过理解数据访问模式来改进文档模型。

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

更新：我认为马特在这里得到了我的观点的主要想法。我想说的是，没有规定的方法（我知道无论如何）在没有理解的情况下将关系数据模型（如规范化的SQL模式）转换为非关系数据模型（如文档模型）考虑应用程序的领域。让我在这里详细说明一下......

看完您的SQL架构后，我不知道除了似乎加入应用程序和部署的表之外还有什么跟踪。我也不知道你的应用程序通常如何查询数据。稍微了解一下这一点会在您为文档建模时发挥作用，就像在模型化应用程序对象（或域对象）的方式上会产生变化一样。

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

Answer 2

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

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

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

有几个“做”和“注意事项”一项战略决定时：

DO：优化了常见的用例。 20％的用户体验驱动80％的负载时经常出现20/80的崩溃 - 网页应用的主页/着陆页是一个典型的例子。首要任务是确保这些尽可能高效。确保你的数据模型允许A）加载那些在单个IO请求或B）缓存友好

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

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

DO：平衡读写要求。某些类型的系统是重读的，你可以假设每次写入都会有很多读操作（StackOverflow就是一个很好的例子）。因此，为了获得读取性能的好处，使写入更加昂贵是有意义的。例如，数据非规范化和重复。其他系统均衡均衡，甚至写入重量，并要求其他方法

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

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