从 SQL 迁移到 NoSQL Databases

将数据从关系数据库迁移到 NoSQL

在您的 .NET 应用程序中使用关系数据库并非没有一些限制，例如它无法在不更换现有硬件（扩展）的情况下处理更多负载以及无法更新其刚性数据模型（即行和列）。如果您面临这些挑战，那么您可能已经决定将数据库转移到 NoSQL. 如果您仍然不相信，那么您可能需要阅读为什么 NoSQL?

考虑到您无法扩展数据库层并且选择将数据移动到 NoSQL，迁移的艰巨任务可能使您无法实现这一飞跃。

虽然迁移是一项艰巨的任务，但如果分成几个步骤，它可以以非常有条理的方式进行，让您的生活变得轻松。本白皮书旨在帮助您按照 6 个逻辑步骤组织迁移过程。

如果您遵循这些简单的步骤，它们一定会在您的迁移过程中为您提供帮助。本文认为您已经了解了 NosDB, .NET NoSQL 文档数据库。如果没有，请前往官网. 下面我向您介绍上述过程的详细信息。

第 1 步：确定范围

第一步也是最重要的一步是了解您的业务模型和数据库架构。您还需要完全了解应用程序如何访问这些数据以及进出数据库的数据流。这有助于识别两个关键信息：

访问次数最多的数据库架构部分（读取、写入或两者兼有）
分组在一起的数据，即始终一起访问以进行读取和写入。

拥有这些信息可以帮助您确定剩余步骤中的关键决策。因此，这也是最关键的一步。

步骤2：找出 NoSQL 设置要求

一旦您了解了您的业务模型和数据流，您就可以很好地就如何部署您的业务做出一些粗略的决定。 NoSQL 集群，基于您的业务需求。例如，记录当前运行的应用程序数量、用户数量和访问率是一些重要的指标。注意您的数据的哪一部分是高度敏感的，即您需要不惜一切代价进行备份，这也有助于您确定副本节点的部署策略。

既然一个 NoSQL database 是一个分布式数据库，您可以利用分布式特性来发挥自己的优势，并根据您的业务需求进行部署。除了可扩展性之外，您获得的最大优势是分发/部署您的 NosDB 跨不同 GEO 位置的集群分片。这允许您在应用程序的地理位置附近部署分片，并避免昂贵的网络旅行。它提高了应用程序的性能。

请记住，我们在这里所做的只是勾勒出需求。在我们确定、创建和优化我们的收藏后，我们一定会重新审视这些设置。

第 3 步：转换和优化 JSON 集合

现在您已经有了部署集群的基本要求，您的“草图”将决定您的优化策略。

将表转换为集合

首先，只需将关系数据库中的表转换为集合，然后将列转换为属性。这是 标准化 来自关系数据库的数据。

通过嵌入文档对数据进行反规范化

接下来，你需要 去规范化 孤立的表，即除非与另一个表相关，否则没有任何意义的表。在关系方面，孤立的表是 连接表。例如，订单详细信息在 Northwind 数据库中提及 Order 时更有意义。因此，正确的选择是将 OrderDetails 嵌入到订购产品文档。

转换关系

现在，您剩下的是那些包含文档的集合，这些文档具有各自的 连接表 嵌入其中。但是多对多、一对多和其他关系呢？这就是您对自然分组数据和一起访问数据的了解派上用场的地方。

在 NorthWind 数据库示例的迁移是，对客户的和订购产品表是相关的，但并不总是一起访问。所以，嵌入是没有意义的客户对象里面的订单文件. 此外，嵌入客户文件将不必要地重复数据，我们希望尽可能避免这种情况。否则，客户资料中的单个更改将要求应用程序在所有订单.客户文件。不必要的计算成本。

另一方面，每当获取 Product 时，应用程序总是需要类别；因此，这是一个很好的嵌入候选者。而且，不要忘记 JSON 文档的美妙之处在于它们还可以支持数组和 JSON 文档数组，以丰富您的对象。

混合模型 - 最佳归一化和反归一化

既然一个 NoSQL 模式基于应用程序的数据流，如果集合具有保持嵌入和非嵌入的优点，则采用混合模型。

在上一页引用的示例 Northwind 数据库中，可以在产品类别和产品表。场景是，每当一个产品被访问时，应用程序需要知道它的产品类别. 但应用程序还需要找出热销产品 by 产品类别.

如果产品类别被保存在一个单独的表中，单个产品获取将意味着两个数据库调用，一个用于获取产品另一个获取相应的产品类别，因此额外的网络成本。如果只有产品类别已嵌入，然后要找出所有类别，您必须运行以下 SQL 语句：

SELECT DISTINCT product.Category.CategoryName FROM Products;

一个简单的 SQL 查询，但不是一个非常有效的查询吗？所以答案是保持产品类别文档在单独的集合中，但仅嵌入产品必需的部分。这被称为 混合模型.

例如，在我们的场景中，当应用程序获取 Product 文档时，它只需要知道产品类别名称和产品类别描述。因此，完全没有必要嵌入产品类别每个产品文档中的图片。事实上，如果重复，它将占用大量不必要的存储空间并增加文档大小，从而造成代价高昂的网络旅行。

这是混合模型的完美用例，因此集合的形状如下：

"Product" {
   "name": "string",
   "category": {
      "name": "string",
      "description": "string",
   }
}

和存储产品类别也分别：

"Category" {
   "name": "string",
   "description": "string",
   "picture": byte[]
   }
}

决定您的分销策略

接下来要决定的是您的收藏品可能的分发策略。您的设置要求的初始草图直接影响到这一点。

您的分销策略有三种选择：

基于范围的分布： 此策略允许您根据为每个分片指定的范围定义数据在节点之间的分布方式。例如，如果您的 NosDB 集群是 GEO 分布，一个分片在纽约，另一个分片在伦敦，那么纽约现有应用程序生成和需要的数据应该在同一个 GEO 位置，从而优化网络成本。这种策略主要用于 GEO 分布式集群，但也有其他用例。
基于哈希的分布： 散列允许您在分片之间均匀分布数据，从而也均匀分布负载。此策略不是 GEO 分布式集群的最佳选择，但非常适合 NosDB 单个数据中心内的集群。
单一分片集合（禁用分发）： 这完全禁用了对集合的分发。如果您的数据集很小或者您特别希望它位于单台机器中，请使用此选项。

在确定您的分发策略后，您可能需要重新审视您的集合优化和部署策略，看看它们是否可以进一步优化。几次迭代通常足以做出决定。

第 4 步：迁移数据

最后，经过一番激烈的头脑风暴，这里是相对容易的部分，即将数据从关系数据库迁移到 NoSQL database.

首先创建代表您的集合和 JSON 文档的 .NET 对象。是的！插入数据不需要 ORM，因为 .NET API 会自动将您的 .NET 对象转换为 JSON 文档。（不过请注意，您也可以选择使用随附的 ADO.NET 集成 NosDB).

接下来，访问您的关系数据库并填充这些 .NET 对象，然后将它们插入到 NoSQL database. 您还可以使用由提供的 CLR 触发器和 CLR UDF NosDB 协助您的迁移。

迁移数据后，现在是迁移应用程序以采用集合和文档方面的数据的时候了。没有 NosDB 您没有使用 ADO.NET 或 CLR 触发器和 UDF 的选项，但您仍然可以使用 API。

第 5 步：迁移应用程序

有多种方法可以将工作中的 .NET 应用程序迁移到 NosDB. NosDB 支持 SELECT、INSERT、UPDATE 和 DELETE 等 SQL 操作。使用 SQL 操作大大减少了迁移应用程序的学习曲线，即您可以使用您习惯的语法。您甚至可以在 NosDB 使用 SQL。

NosDB 支持 SQL 以多种方式访问数据库，即：

.NET API
- ADO.NET
- LINQ
Java API
REST API

您还可以使用服务器端 API 来提高应用程序性能，通过使用 MapReduce 等框架来利用分布的力量。如果你不使用 NosDB 您只能选择直接调用 API。 SQL 和 ADO.NET 仅由 NosDB.

第 6 步：验证迁移

迁移后，验证是整个过程的最后一步：验证所有测试，验证迁移的数据和应用程序。此步骤完全取决于您和您的业务流程。板凳新成立的 NoSQL database. 检查当前集群配置的限制（尽管您可以随时扩展）并为自己配备正确的工具，例如 NosDB Management Studio 从一个位置管理和监控整个集群。

就是这样！如果您遵循这些步骤，您可以组织从关系数据库到 NoSQL database 在一个合乎逻辑的 6 步过程中。