c# - 如何使用 MongoDB 建模数据

Question

我们有一个使用关系数据库 (MSSQL) 的相对大型应用程序。大量阅读之后，我决定使用 MongoDB 而不是 MSSQL 进行检查，主要是因为性能和规模问题。

我阅读和研究了有关 Mongo 的内容，但无法找出以下问题的答案:

1. 我们应该这样做吗？记住我们有时间投资，唯一的问题是“这对我们有好处吗？”
2. 如何为我们的数据建模？

我对 mongo 的问题是我们的数据库中有很多一对多的关系。在阅读 this great post(以及 second part)之后，我意识到一个好的做法是将决策分为 3 个场景:

1. 1 到几个
2. 1对多
3. 1 到 squillions。

在我们的数据库中，大多数时候我们使用一对多，但问题是大多数时候都是同一个“一”。

例如，我们有用户和交易表。每个用户都可以执行交易，所以基本上我应该做的是按如下方式对用户建模:

{“名字”:“约翰”，...,“事务”:[ObjectId("..."), ObjectId("..."),...]

到目前为止还不错，问题是我们有很多不仅仅是事务，例如我们可以有:帖子、请求和更多功能，如事务，然后，我的用户集合变得庞大(超过 25"列”)。而且，当我想要检索数据集时，我必须执行多个查询，这与我仅使用 Join 语句的 MSSQL 不同。

另一个问题是我必须保存很多额外的数据，例如，对于每笔交易我必须保存终端 ID，并且在报告中我必须显示终端名称，在那种情况下(就我的理解而言)我有两个选择，一个是做两个查询，另一个是也保存终端名称。在关系数据库中，这是一个简单的连接。

所以也许对于像我们这样的方案，Mongo(或任何其他基于文档的数据库)不是最佳选择？

• 我知道这些是新手问题:)
• 我们在服务器端使用 c# (ASP.Net Web API)

提前致谢!

Answer 1

在使用 2 和 3 方法对数据建模时，您可能会遇到一些严重的问题:

1. 对于一对多，您可能会面临数据不一致或/和最终一致性的问题。在这里，您在文档内部存储外部文档的索引(引用数组)。因此，对于添加新事务的示例，您需要两个请求:创建事务并将其引用添加到用户(更新文档)。 Mongo DB 仅在文档​​级别具有 ACID 事务，因此对于您的案例应用程序，出于某种原因可以创建一个事务，但不会将其引用添加到用户。可能是应用程序故障、网络问题、错误等。当然，你可以在app中模拟db事务，用try/catch block 在出错时进行数据清理。它会有所帮助，但不会完全帮助，因为应用程序可能会在请求之间掉落。因此，如果您的应用程序在一段时间后负载很高，您可能会有一些未链接到任何用户的“爸爸”交易。如果您的应用程序不直接查询交易，这不会是一个大问题——仅通过用户，您在数据库中将只有无用的数据。否则会出现数据不一致。要解决这个问题，您需要创建后台作业来进行适当的清理。因此，在一段时间内您的数据可能会不一致——最终一致性。对于某些应用程序，它可能没问题，但对于其他应用程序则不行。删除交易时可能会遇到同样的问题。我同意，包含 25 个引用数组(列)的文档看起来不太好。手动处理此类对象会更加困难(测试、手动数据修复等)。

2. One to squillions 没有这种影响，但您需要索引才能高效查询。对于大型和共享数据库，您的性能可能会很差。

总的来说，如果您的应用程序主要使用一个文档(聚合)并且没有太多对另一个文档的引用并且您不需要文档之间的事务，那么我想说文档数据库非常好。非规范化也可能是不一致的根源。

键值数据非常容易扩展。文档数据库——它离键值数据存储更近了一步。面向列的数据库更接近键值，因此它们可以更好地扩展。

另外，我建议您考虑接下来的措施来提高您的 SQL Server 数据库性能:

1. 缓存——也许您可以缓存一些应用程序聚合，而不是一直在 SQL 数据库中收集(进行连接)它们。例如，Stack Overflow uses SQL Server db and Redis用于缓存聚合(带有答案、评论等的问题)。

2. 在索引、数据库结构、士气低落等方面调整查询性能。

3. 如果您的数据库托管在本地 SQL Server 中，那么额外的内存、SSD 磁盘、表分区、数据压缩、复制都可以提供帮助。通常，对于高达 1 TB 的数据库，SQL Server 通过这些方法提供了良好的性能。

4. CQRS approach .

5. 考虑将您的应用数据存储在不同的数据库中。每种类型的数据库都有自己的强项和弱项。 Document DB 适用于存储聚合，SQL db – 用于关系数据等等。复杂的应用程序通常使用几种数据库类型。