sql-server - 将网上商店存储迁移到 NoSQL 解决方案

Question

如果您有一个基于 SQL Server 关系数据库的网上商店解决方案，那么迁移到 NoSQL 存储的原因是什么？将严重依赖关系的数据存储迁移到 NoSQL 是否有意义？如果从头开始，您会为网上商店项目选择 NoSQL 解决方案而不是关系型解决方案吗，一段时间后，该项目将再次以一堆表格结束，例如文章、分类、税率、价目表等，以及它们之间的大量关系？

.NET (4.0) 对 MongoDB 的支持或 MongoDB 对 .NET 4.0 的支持是什么？我可以指望 MongoDB 的 EF 向导、L2SQL 向导等丰富的代码生成工具吗？

因为据我目前所读，NoSQL 主要适用于文档存储、更简单的对象模型。

您对这个问题的回答将帮助我做出正确的基础架构设计决策。

更新:如果我围绕 ASP.NET MVC 开发我的解决方案并且严重依赖模型类，选择 DB4o 来简单地将我的对象序列化和反序列化到数据存储区或从数据存储区序列化和反序列化是否是最简单的方法？

Answer 1

好吧，这是一个开放式的问题。

Migration to a NoSQL-datastore for an existing software

对于现有的关系技术，通常有很多经验和知识。当您的应用程序运行良好时，它可能不值得付出努力。但是，当您遇到当前解决方案无法解决的问题时，这是一个选择。

Does it even make sense to migrate datastores that rely on relations heavily to NoSQL?

您必须考虑到这三种技术(文档数据库、关系数据库管理系统、对象数据库)彼此之间有很大的不同。

• 在关系世界中，您规范化数据并在运行时将它们连接在一起。这工作正常，只要数据大小不是很大。问题通常从这里开始:当您有大量规范化数据时，您需要进行大量连接，这会消耗大量性能。当然，对象和表之间的映射可能非常棘手。
• 在对象数据库中，每个对象都是单独存储的，“关系”以指针的形式存储。因此，当对象 A 具有对对象 B 的引用时，对象数据库会存储此引用。所以要检索“关系”，不需要连接操作。因此，“关系”是廉价的。总之，对象数据库非常擅长处理关系。
• 在像 MongoDB 这样的文档数据库中，完整的对象图存储为文档。文档数据库与文档级别一起工作。所以这里没有真正的“关系”。您通常只是存储/加载文档。因此，当您可以对场景进行建模以便您的大部分操作仅适用于单个文档时，它会非常高效且简单。

这是一个很好的blog-post比较了MongoDB(文档数据库)和db4o(对象数据库)的设计差异

最后，您的模型应该适合您的数据库。例如，不要尝试将模型用于关系数据库并将其 1:1 存储在文档数据库中。另见 Ayende's blog about modeling for a object-database .

What's the support like in .NET (4.0) for MongoDB or MongoDB's support for .NET 4.0?

Gates VP has already answered this for MongoDB . .NET 4.0 版的 db4o 正在开发中。同时 3.5 版本在 4.0 框架上也能正常工作。

Can I count on rich code generation tools similar to EF wizard, L2SQL wizard etc. for MongoDB?

对于 MongoDB 和 db4o，您不需要生成代码。您的类(class)就是模式。您只需存储对象，数据库会处理其余部分。另见 Gates VP answer

Because as what I have read so far, NoSQL's are mostly suited for document storage, simpler object models.

嗯，范围很大。从真正简单的键值存储，到更高级的文档数据库、面向列的数据库、图形数据库和对象数据库。

当然，当您存储了类似文档的数据(例如博客软件)时，文档数据库工作得很好。而图数据库和对象数据库擅长处理极端复杂的数据结构。