Pascal Desmarets 谈 NoSQL 数据建模最佳实践

关键结论

• 了解在 NoSQL 数据库中建模与在关系型数据库中建模有哪些不同。
• 理解一个典型的 NoSQL 数据建模有哪些步骤。
• NoSQL 数据建模过程中的可交付物与制件。
• 多模（multi-model）NoSQL 数据建模的最佳实践。
• 怎样对 NoSQL 数据库中的事务和分析用例进行数据模型。

NoSQL 数据库被设计用来专门存储不同类型的数据，像 KV 数据、文档、列存储、时间序列、图形以及物联网数据。Pascal Desmarets 在访谈中讲述了跟关系型数据库相比，应该怎样在 NoSQL 数据库中建模。

InfoQ：NoSQL 数据库中的数据建模与关系数据库的数据建模为什么不一样？

Pascal Desmarets：多年来，“schemaless”、“schema-on-read”和“non-relational”这些术语给人们造成了一种假象，那就是 NoSQL 数据库没有建模的必要。随着情况变得复杂起来，人们很快发现 NoSQL 的数据建模不仅必要，而且事实上比关系型数据库还重要。事实上，灵活和功能强大的 JSON（用于在 NoSQL 文档数据库中存储数据）一不小心或者管理不善，就会给你造成很多数据不一致和无法查询的麻烦。没有严格的使用方法，数据甚至可能都不准确。NoSQL 基于 JSON 的动态模型的特点对于应用程序开发人员来说是一个非常好的机会：能够以最小的学习成本开始存储和访问数据、非常灵活、快速并易于演化。但是，灵活性虽然带来了强大的功能，也为 NoSQL 的新手和经验不足的开发者、设计师带来了危险。这也是为什么 NoSQL 供应商为了弥补他们市场部门简单的宣传而不得不将大量的网页、博客、视频等资源投入到 schema 设计中去（即， MongoDB 、 DynamoDB 、 Couchbase 、 Cassandra 等等）。在 NoSQL 数据库进行数据建模与在关系型数据库中进行数据建模有两个不同：首先是因为它不符合 NoSQL 开发人员的习惯，其次是因为在 JSON 中嵌套对象的建模并不是一个简单的实现。

InfoQ：一个典型的 NoSQL 数据建模有哪些步骤？

Desmarets：谈到 NoSQL 数据建模的时候，最大的不同是标准化规则不再适用。相反地，现在鼓励使用便宜的存储空间，实现信息的反规范化（denormalize），并且保存尽可能多的重复数据以满足性能和环境的需求。鉴于 NoSQL 允许数据在“写入时（on write）”时连接（joined），数据建模需要考虑数据的访问和查询方式。至于数据建模的过程，取决于团队在严谨程度上达成的一致，如果采用敏捷的方式，数据库模式可以按需快速演化。有些人头脑里有清晰的认知时会心情愉悦，能直接进入数据库的物理设计，然后基于试错的模式快速迭代。在开始启动新应用时，基于用户的需求，更为正式的过程会与关系型数据库类似，只不过物理模型将会与特定的数据存储技术相关。这些步骤通常始于某种概念设计（或领域驱动），然后演变为逻辑建模，最后是物理存储模型设计，这由物理存储模型所使用的特定技术来决定。这就是 NoSQL 与传统的关系型数据库区别较大的地方。

InfoQ：NoSQL 数据库被设计用来专门存储不同类型的数据，像 KV 数据、文档、列存储、时间序列、图形以及物联网数据。对不同的数据库应该怎样进行数据建模？

Desmarets：不同种类的 NoSQL 数据库正在迅速地向多模（multi-model）数据库演进。键值存储现在会将 JSON 数据存储在值的部分，有些数据能够对深度嵌套的属性进行索引；文档数据库正在增加图形功能，图形数据库则将每个属性都建模为关系；物联网的数据能够得到很好的处理，根据数据的复杂性，可以采用键值数据库或文档数据库。尽管越来越趋同，但是每个供应商的产品都有其特定的优点和缺点，最重要的是为正确的工作选择正确的工具。在数据建模方面，唯一存在不同方法的是图形类的数据库。这是因为其关系的数量会迅速生成一个不可读的视觉、图形模型。不过，一些数据建模方面的供应商已经开始解决这个问题，相信很快会给市场带来可用的新工具，从而解放开发人员。

InfoQ: NoSQL 数据库用在了事务型和分析型的用户场景中。为这些多样且不兼容的用户场景进行建模的最佳方式是什么？

Desmarets：要存储的数据的类型和大小应该是选择解决方案的主要标准。完全非结构化的人为产生的标记文本和索引数据将和机器产生的数据如 Web 日志、物联网数据或者操作记录形成完全不同的需求。由于对写入性能的高要求和查询方法的不确定性，大数据分析数据库将不断推动更多关系型存储方法的演进。所以他们可以使用长期以来的传统数据建模工具，另一方面，事务性大数据存储可以真正地利用 JSON 的多态性，因此可以使用为此设计的新数据建模工具。

InfoQ：你能否聊一下多模（multi-model）NoSQL 数据库及其最佳数据建模实践？

Desmarets：“多模（multi-model）”之于不同供应商而言，“多”的部分不尽相同。当多模（multi-model）是 DB 供应商们在市场营销清单中勾选的防御措施时，多模（multi-model）对数据建模的影响微乎其微，因为数据存储的方式并没有发生多大的变化。但是，一些企业级服务供应商确实有支持多种存储模型的能力，比如人为产生的 XML 索引文档、RDF 图形以及 JSON 文档。显然，每一种存储类型都有自己的要求，并不存在一个通用的方法能满足所有的存储要求。因此，这种多模（multi-model）数据库的数据建模工具需要足够灵活。

InfoQ：在 NoSQL 数据建模过程中的典型交付工具和可交付件是什么？

Desmarets：至少，一个好的 NoSQL 数据库数据建模工具应该输出数据库供应商指定的正向工程处理脚本以及所有实体、属性、限制和关系要求的文档。它还需要能够以原生的方式执行逆向工程，并能够对 JSON 的多态属性进行建模。对于大多数不喜欢查看源代码来了解结构的人（业务分析师、设计师、架构师、数据库管理员和开发人员）来说，文档对于促进一个程序的开发者与维护者不同利益诉求者之间的对话至关重要。正向工程脚本将帮助开发人员根据每个供应商要求的语法规范生成符合精心设计过的模型所需要的代码。所有这些都应该为企业进行正确的数据治理而作出贡献。

InfoQ：在 NoSQL 数据库数据建模方面有哪些最佳实践呢？

Desmarets：特别是拥有几年、甚至几十年的关系型数据库设计经验之后，人们很难忘记正常化的习惯。不仅如此，如果有助于数据的可读性，甚至鼓励非常规的和重复的数据。需要考虑到的一些选项是嵌入（可以被视为在存储时传入的连接）、引用以及双向引用。数据建模者应该多考虑考虑查询的问题而非存储方面：在仅有一个磁盘访问请求的情况下，怎么呈现一个应用程序屏幕显示所必需的全部信息？结构将会决定如何存储数据。而且如果一条数据需要被传送到其他非规范化的地方，后台进程就能够处理这种情况，这样数据库中的数据最终会保持一致。顺便说一下，“最终”这个术语经常被误解，它应该被理解为比例：几毫秒甚至是几秒的延时可能是绝大多数应用程序可以容忍的。想象一下：仅仅只是因为你的数据库在复杂的写入操作时无法响应了，你愿意显示一个 404 页面并且承担电子商务销售订单丢失或者永远地失去一个客户的风险，还是先确保呈现数据，即便它不是 100% 的一致？一个数据建模工具将会帮助你设计更有弹性的 NoSQL 数据库。

InfoQ：在进行数据建模任务时，开发人员应该牢记哪些法则？

Desmarets： NoSQL 数据建模工具的目标不是要限制而是要利用 JSON 的灵活、强大、多态和创新特性。因此，数据建模人员不应该去试图控制开发者，而应该成为中间人，多“假设”一些方案并通过各种尝试来减少别人的重复工作。数据建模的文档应该成为团队协作的良好沟通工具，以便不同利益诉求者之间在满足业务需求、提高质量、降低任何 NoSQL 应用程序的总体开销方面取得更好的成绩。

关于这个采访

Pascal Desmarets是 Hackolade 的创始人兼 CEO。他带领公司全力以赴改进经营策略、产品创新和客户关系，使公司专注于生产用户友好、功能强大的可视化工具，从而将 NoSQL 技术平滑地迁移到企业的 IT 蓝图中。Hackolade 的软件将图形数据建模的舒适性和简单性与 NoSQL 文档数据库的强大功能结合在一起，从而缩短了开发时间，提高了应用程序的质量，降低了运行的风险。在创立 Hackolade 之前，他创办并担任了 IntegrIT SA/NV 公司的 CEO，这是一家为大型组织机构提供信息架构、创新解决方案和可扩展系统集成的 IT 战略与咨询公司。Pascal 同时也是 ARTISTdirect 公司的 CIO，ARTISTdirect 是一家公开募股的创业公司，同时也是在线数字音乐世界和网上贸易的原始拓荒者和早期创新者之一。

查看英文原文：《 Pascal Desmarets on NoSQL Data Modeling Best Practices 》

感谢张卫滨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。