关系数据 库到MongoDB 迁移指南
本文摘译自MongoDB官方迁移白皮书《RDBMS to MongoDB Migration Guide》。
传统关系数据库被替代
关系数据库作为企业数据管理系统的技术基础已经有四十年了。但是，我们今天构建和运行应用程序的方式，加上新数据源和用户负载的持续增长，正在 将关系数据库推向超出其极限。这会抑制业务敏捷性，限制可扩展性，并使预算紧张，迫使越来越多的组织迁移到替代方案。
迁移的根本是数据模型的设计
从关系数据库迁移到MongoDB过程中最根本的变化是「数据建模」的方式的改变。
与任何数据建模练习一样，每个用例都是不同的，但是对于大多数Schema迁移项目，有一些一般的考虑事项。
从刚性的Tables 到灵活而动态的 BSON 文档
我们今天使用的许多数据都具有复杂的结构，可以使用 JSON文档（而不是二维数据表）进行更高效的建模和表达。
MongoDB 将 JSON 文档存储在称为 BSON（二进制 JSON） 的二进制格式中。BSON 扩展了流行的 JSON 格式，包含其他数据类型，如int, decimal, long, and floating point。
JSON 文档数据记录的优势
通过内嵌子文档（sub-documents ）和 数组，JSON 文档还与应用代码中的对象的结构一一对应，这使得开发人员能够轻松地将应用程序中使用的数据映射到数据库中关联的 JSON 文档。
相比之下，尝试将数据的对象表示映射到 RDBMS 的数据表格式会减慢开发速度。添加对象关系映射器 （ORM） 可以通过降低进化计划和优化查询以满足新应用要求的灵活性来创建额外的复杂性。
关系模型和文档模型设计的区别
项目团队应该从需求分析阶段起就开始 data schema 的设计，它应该以一种能利用 JSON文档模型灵活性 的方式对业务数据进行建模。
在data schema迁移（从 table 到 JSON文档）中，将关系数据库的平面table模式直接镜像到 JSON文档模型可能很容易的。然而，这种方法否定了文档模型丰富的嵌入式数据结构所带来的优势。例如，在MongoDB中，两个RDBMS表中属于父子关系的数据通常会被折叠（嵌入）到单个文档中。
在图4中，RDBMS 使用Pers_ID字段连接Person表和Car表，使应用程序能够报告每辆车的车主。 通过使用文档模型，嵌入的子文档和数组通过将相关字段组合到单个复合数据字段中，有效地预连接数据。 传统的RDBMS被规范化（normalized）并分布在独立表中的行和列，现在可以一起存储在单个文档中，当应用程序必须检索完整记录时，就不需要连接几张单独的表了。
例如，在MongoDB中，我们只使用一个schema 对这个数据进行建模，在该 schema中，我们将每个car的子文档数组直接嵌入到Person文档中。
在这个简单的例子中，关系模型只包含两个表(实际上，大多数应用程序需要数十、数百甚至数千个表。)。基于关系的数据建模方法既不能反映架构师思考数据的方式，也不能反映开发人员编写应用程序的方式。
为了进一步说明关系模型和文档模型之间的区别，考虑一个使用customer对象的稍微复杂一些的示例，如图5所示。
客户数据被分解为多张表进行 normalized，当应用程序需要查询客户综合信息，则依赖于RDBMS连接七个单独的表。使用MongoDB，所有客户数据都包含在一张丰富的文档中，将子表折叠为嵌入的子文档和数组。
文档是描述数据的一种更自然的方式。这允许文档与编程语言中的对象结构紧密对应。因此，开发人员可以更简单、更快地建模应用程序中的数据如何映射到存储在数据库中的数据。
文档模型的其他优点
除了使在数据库级别上更自然地表示数据外，文档模型还提供了性能和可伸缩性方面的优势。
一次读写，性能好
通过对数据库的一次调用就可以访问完整的文档，而不必连接多个表来响应一个查询。MongoDB文档在物理上作为单个对象存储，只需要从内存或磁盘读一次。而RDBMS join需要从多个物理位置进行多次读取。
并行扩展
由于文档是自包含的，跨多个节点分布数据库(一个称为分片的过程)变得更简单，并使它有可能在硬件上实现平行的可伸缩性。
Joining Collections
一般来说，基于JSON文档的反范式（denormalized）数据模型的设计对于偏 「操作式数据应用 」是利好的。所谓「操作式数据应用」是指应用性能侧重于数据的读和写——单次读取或写入一条完整记录——的数据库操作的应用。当然，在一些其他类型的应用中，范式（normalizing data）数据模型也有优势，例如当来自多个来源的数据需要混合分析时。这个需求 MongoDB 也有了新解决方案——聚合框架（Aggregation Framework）。
Document Schema设计原则
应用程序 的数据访问模式（data access patterns）可用来驱动 Schema设计：
- 第一，数据库操作的读／写比例，和这些读写操作和性能优化的重要级别；
- 第二，查询和更新操作的特性；
- 第三，数据格式的生命期，和文档数据的增长率；
参考
- 《50 Tips and Tricks for MongoDB Developers》2011
- 《MongoDB设计模式》2013