设计数据密集型应用（1-2）

假期宅家，这两天在看一本书：Designing Data-Intensive Application，书名翻译成中文是设计数据密集型应用 —— 大部分互联网应用都属于数据密集型应用。

通读下来，这本书并没有教怎么设计一个应用（Application），而是介绍各种数据系统（Data System）背后的设计思想和技术 —— The Big Ideas Behind Reliable, Scalable and Maintainable Systems.

这本书的内容很“丰富”，写得算是通俗易懂，推荐对数据系统内部实现原理了解比较少的人阅读，有助于在做技术选型时进行合理的判断和取舍。

本文是这本书前两章的笔记。

Reliable, Scalable, and Maintainable Applications

书的第一章围绕书名副标题中的三个关键词展开介绍：Reliability、Scalability 和 Maintainability。

Reliability（可靠性）要求系统持续正确地运行，即使出现部分软硬件故障或人为失误。
Scalability（可扩展性）描述的是系统应对负载上涨的方式和能力。一般有两种 scale 的方式：scale up（垂直扩展）和 scale out（水平扩展）。
- Scale up 这种方式比较简单——通过提高硬件配置来提高系统的处理能力。大部分多线程程序都可以通过 scale up 来提升性能。但是如果业务的增长速度超过了硬件处理能力的增长速度，这条路就走不下去了。这种方式在大规模业务场景下是走不通的。
- Scale out 则意味着系统可以通过增加机器数量来提升系统的处理能力。这也是现代分布式系统的扩展方式。
书中将 maintainability（可维护性）分解成三个维度：
- 从运维角度看的 operability（可操作性）—— 系统运营起来要简单，至少不能太难。系统的升级、回退、扩容、缩容在系统设计的时候都要考虑在内，最好是能自动化解决。
- 从开发角度看的 simplicity 和 evolvability。Simplicity 要求要控制软件的复杂度，让新人可以快速上手。Evolvability 是为了让迭代升级更加简单。 Simplicity 和 evolvability 在很多方面都是相通的。代码简单（simplicity）好上手，迭代（evolvability）起来自然没那么困难。代码之间进行抽象、解耦是实现 simplicity 和 evolvability 的常见方式。

第二章介绍数据库提供的数据模型和查询语言（接口）。

目前主流的数据模型主要有：

远古的层级模型、网络模型这里就不说了。（文档模型和层级模型，图模型和网络模型看起来都挺像的。）

其实还有一种非常简单的数据模型 —— Key-Value 模型，书中没有提到。可能作者认为这个连数据模型都算不上吧~或者说 Key-Value 模型其实是关系模型或文档模型的子集/基础。

Key-Value 在互联网的应用是非常广的，这里的 value 可以是 string、list、set 等，代表作是 redis。

书中有一部分内容讨论关系模型和文档模型这两种数据模型孰优孰劣。

短期看，这两种各有优劣。文档模型的好处是 scheme-less 在大部分情况下显得比较灵活，但是过于“灵活”往往容易导致“混乱”。而且大部分文档数据库不支持 join，事务（ACID）能力也比关系数据库弱不少。

长期看，这两种数据模型的数据库正在相互融合，汲取对方的优点来弥补自己的不足。MySQL、PostgreSQL 等关系数据库也已经支持 JSON 数据类型，并逐渐完善各种能力。一些文档数据库也开始支持 join 操作（虽然名字不一定叫 join）并开始在事务领域发力。

关系模型和文档模型并不是对立的关系，长期看，它们应该会走向融合。

数据系统提供的接口多种多样。应用最广的应该是 SQL。虽然都叫 SQL ，但是每个数据库的 SQL 可能都不太一样。图数据库领域有 GQL（Graph Query Language）。Cassendra 有自己的 CQL。各种 NoSQL 数据都有自己特殊的“语言”或“接口”。

SQL 是一个强大、灵活的工具。但是，要支持完整的 SQL 并且做到各种场景下都很强大，就没那么简单了。并且，灵活的东西总是容易被误用，随便写个 SQL，如果没做好保护，可能就会把整个数据库拖死。

长期看来，应该还是 SQL 家族独大，各种特殊接口/语言共存的局面。

总的来说，前两章都是一些概念上的东西。对于不了解数据系统的人，可以通过这两章的内容快速形成对数据系统的认知。如果对一些数据系统已经有所了解，可以快速略过。

0 人点赞