数据密集型系统的设计

总结：

可靠性，扩展性和可维护性

这一章我们探索了数据密集型应用的一些基本方法，这些原则会指导我们这本书里剩下的部分，深入技术细节。

应用程序满足各种各样的需求：

包括功能性需求（数据存储，retrieved，数据查询，数据处理）

非功能性需求： 安全性，可靠性，complinace，compatibility，伸缩性，可维护性。

本章重点讨论可靠性，伸缩性，可维护性。

可靠性：意思是是系统正常运行，尤其是当错误发生时。

        错误包括硬件问题（通常随机但不相干），软件问题（问题一般具有系统性且不容易修复），人为问题（不可避免的时不时发生）。

Fault-tolerance（容错）技术可以隐藏部分问题不被终端用户知晓。

伸缩性：表示当负载增加的时候，能够保证性能继续良好的策略集。

        为了讨论伸缩性，先得定量的描述下负载和性能。我们简单的看了一下Twtter首页的时间线来作为一个例子： 用反应时间的百分比来计算性能。

在可伸缩系统中，你可以增加处理能力（可插拔）来保证高负载下的可靠性。

可维护性：意味着很多特性，关键一点在于是的使用系统的工程和运维团队活的更轻松。

        好的抽象可以坚守复杂度并且是的系统容易更改和适配新的使用场景。好的运维意味着系统健康度的良好可见性，并且有高效的管理方法。

不幸的是，同时达成这三个目标很难。然而，一些确定的模式和技术在不通的应用中重现。在线的几张我们可以看一下数据系统的例子和分析他们怎样工作来达成这些目标。

在本书的第三部分，我们会看到组成一个系统的多个组件一同工作的模式。参看图1-1

数据模型和查询语言

不通的应用场景有不同的数据模型与之匹配，本书不能一一穷举。

历史上，数据被表现为一颗巨大的树（层次模型），但是不好表示多对多关系，所以关系型模型被发明来解决这个问题。但是最近，开发人员发现一些应用也不能很好的适配关系型模型，所以出现了非关系型数据库，简称“NoSQL”，主要向两个方向发展：

        文档型数据库：  目标用例是来自于自包含的文档，  并且一个文档和另外一个关系很少。

        图型数据库：正好相反，目标用例是那些可以可以潜在关联所有事情的任一事务。

关系型，文档型，图形数据库三大类。今天都在各自业务域广泛使用，并且一种模型可以被另一种模型模拟。举例子图库可以用关系型数据库模拟--尽管结果很蛋疼。那就是为什么不通系统要有不同模型，不存在“一招鲜”的解决方案。

        文档型和图库有一个共通的特点他们通常不会对数据存储实施模式？，这使得应用程序修改需求很容易。然而你的应用程序更喜欢假设数据有特定结构，这只是一个显示的模式（写入强制执行）和隐式模式（在读取处理）。

每种数据库对应自己的查询语言。

除了三道数据库之外，根据具体用途，还有其他的的数据模型，我简单说说：

1，研究基因数据研究员：需要做序列相似的研究，所以需要很长的字节流，表现DNAmolecule分子， 并且和一个很大的字符串数据库，他们为此编写了专门的基因数据库，GenBank

GenBank数据库格式的说明 | Public Library of Bioinformaticshttps://www.plob.org/article/3704.html

2，粒子科学家：大数据类型的大规模数据分析,大型强子对撞机需要处理几百个PB的数据规模，需要定制的解决方案来控制硬件成本失控。

3，全文本搜索：是一个经常与数据库一起使用的数据模型。信息检索是一个专业的大的主题领域我们一般不会涉及，，但是我们第三章会谈一下搜索索引。

下一章我们讨论一些本章的数据模型的实现时的取舍（分布式系统的弊端）。

存储和检索

这一章我们到达数据库处理和检索数据的底层逻辑：

        你存储数据的时候数据库发生了什么；

        你查询数据的时候数据库干了啥；

来到高阶一点，查询引擎的两个比较大的分类：

为事务处理优化的OLTP操作（optimized for transcation processing）

为分析处理优化的OLAP操作（optimized for analysis processing）

他们在用例上有巨大的不同。

OLTP：1，面向用户，要处理大量查询。

             2，为了处理负载，应用每次查询一般只会查询少量记录。

             3，应用请求记录时使用一些关键字，存储引擎使用索引来找到key所对应的数据，

             4，磁盘查询时间通常是这类型的瓶颈；

OLAP：

        1，数仓和类似分析系统不那么出名，他们不直接面对用户，而面对商业分析学家。

        2，查询量不如OLTP，但是每次查询非常苛刻，需要在短时间内扫描上百万条数据。

        4，磁盘带宽（非查询时间）通常是这类型的瓶颈。

        5，面向列的存储是这类工作负载一个增长的流行方案。

详细介绍：

        就OLTP而言，我们看到存储引擎主要有两个学派（schools of thought）

        log-structured 日志结构化学派，只允许追加文件和删除过期文件，但是从不更新已经写入的文件。例如：Bitcask，SSTables，Hbase，Lucene等等；

        *日志结构化是最近存储引擎的趋势。

        他们关键在于： 它们系统地将磁盘上的随机写转换为顺序写。 磁盘和SSD的特点以此来获得更高的写吞吐量。

update-in-place 就地更新学派， 将磁盘当做一个固定大小的页面，可以被覆盖。B-tree（包括mysql）就是这种理论的最大例子。大部分关系型数据库和芬关系型都是使用这种。

完成了这些关于OLTP的介绍后，我们简单了解一下更多复杂索引结构，和将所有数据存储于内存的优化方向的数据库。

接下来我们从存储引擎的内部观察了像数据仓库的高级架构。这个背景解释了分析型工作负载和OLTP的区别：

        如果你的查询需要书序扫描数量巨大的行，索引就起不了作用了。取