系统设计基础——第二部分

原文：https://medium.com/hackernoon/fundamentals-of-system-design-part-2-abbe437ce2dd

你可以在这里阅读本系列的上一篇帖子。

应用程序需要永久存储用户或应用程序特定的数据。在像链表这样的内存数据结构中，数组是为 CPU 通过指针访问而优化的。永久存储针对连接到数据库服务器的客户端/进程的读/写访问进行了优化。永久持久性的一个非常重要的方面是数据建模。我将在这篇文章中讨论如何为您的应用程序选择一个好的数据模型。

关系数据库

最著名和最流行的数据建模技术是使用关系表。在关系表中，数据被组织成一个表的记录。表使用主键外键相互关联。你应该选择关系表的原因有很多。

您刚刚构建出应用程序的 v1，数据访问模式还不太清楚。关系模式总是一个不错的首选。所有应用程序的 v1 通常都很糟糕(这是我办公室的一位高级后端开发人员告诉我的:)，没有人会指责你从关系表开始，而不是更好的 NoSQL 或 Graph DB。
您需要对写约束实施严格的模式。
您希望保持零数据冗余。关系模型中模式的规范化具有将信息分解到许多表中的效果
您的数据模型有多对一和多对多的关系。换句话说，你事先就知道哪些连接将被执行。使用 SQL 这样的声明性语言连接和查询关系数据库是关系数据库最大的秘密武器之一。许多研究和努力都是为了让关系查询变得超快。应用程序开发人员只需指定查询的预期数据模式。查询引擎会将 SQL 查询转换成优化的代码来读取/写入数据。

NoSQL 数据库

应用程序开发是使用面向对象编程完成的。然而，当使用表进行数据存储时，需要从对象到“分解的”关系表的转换。ORM 框架提供了样板代码来减少翻译所需的工作量，但是仍然有工作要做。

NoSQL 通过将记录表示为自包含的 JSON 文档来解决这个问题。例如，假设我们需要存储患者的人口统计信息以及他的当前状况。在 NoSQL 数据库中表示该记录的一种方法是:

{ "名字": "约翰"，"姓氏":"多伊"，"条件":[ { "名字":" T2DM "，"发病":" 12–12–1990 " }]}

如果您需要在应用程序中读取患者的个人资料数据，您不需要发出多个连接，因为所有数据都在一个 NoSQL 文档中。通常，如果您的数据模型表现为一对多关系的树状结构，使用 NoSQL 数据库可能更有意义。

在上面的患者示例中，如果我们想存储条件的 ICD10 标准代码而不是条件的名称，该怎么办？这在基于文档的 NoSQL 数据库中有点麻烦，因为它们很少支持连接。您仍然可以在应用程序层进行连接，但是与在典型的关系数据库层进行的连接相比，这总是次优的。在这种情况下，NoSQL 数据库变得不太理想。

最后，如果您的数据模型没有固定的模式，走 NoSQL 路线可能更有意义。考虑上面的病人例子，我们还需要存储病人的出生日期。在 NoSQL 的情况下，我们可以在新文档中添加一个新字段“dob”。在应用程序级别，我们还可以添加代码来处理读取没有 dob 字段的旧文档。在关系数据库中，处理 dob 的解决方案是改变模式并进行数据迁移。数据迁移速度很慢，需要停机，因此通常会避免。

图形数据库

当您的应用程序的数据模型需要支持许多“多对多”关系时，图形数据库很有意义。关系模型可以处理一些多对多的关系，但是超过一定程度后，所有的关系连接都会变得混乱而缓慢。使用图形数据库还提供了一个额外的优势，即很容易扩展异构对象之间的关系。

图由两种对象组成——节点和边。节点包含对象或实体的描述。边包含节点之间关系的描述。例如，假设一个人因接触某种物质而出现过敏反应。您可以将人、过敏反应和物质建模为节点。您还可以在图形数据库中对节点之间的关系进行建模。例如，人和过敏之间的关系可以是从人节点到过敏节点的单向关系“人有过敏”。过敏和物质之间的关系可以是从过敏到物质的“暴露触发”的单向关系。

为什么不在关系表中这样做呢？你可以的。您可以创建三个表——人员、过敏和物质，并设置适当的 Pk-FK 约束。就像我前面说的，当我们有很多多对多关系时，使用图数据库是有意义的。例如，假设您在总体方案中引入了一个位置对象，这样您就可以捕获发生过敏反应的人的位置。位置可以是邻居、城市、州、国家、大陆或半球。基本上，位置信息可以在不同的粒度级别上获得。使用 SQL 创建声明性查询将会很麻烦。 SQL 需要预先知道哪些连接将是查询的一部分。另一方面，在图数据库中，您可以在到达目标节点之前遍历许多节点和边。对于 Neo4j 图形数据库，您可以使用像 Cypher 这样的图形数据库声明性查询语言非常简洁地表达一次或多次遍历图形的事实。

点击此处链接阅读系统设计基础——第三部分。