读书笔记《数据密集型应用系统设计》- 高可靠性、高可展性、可维护性 & 数据模型与查询语言

第一章、高可靠性、高可展性、可维护性

笔者按：我们总是讲述系统的设计，其实大部分在可维护性上缺乏建设，导致后期系统难以维护，又不得不重新造轮子，把前人的推翻。在高可靠性上由于直接关系生而死，一般来还是做了一定的冗余建设，在扩展性上大部分由于中间件的建设及分布式理论的成熟基本没有太大的问题，就是在性价比上可以掰扯掰扯。

大部分的数据类系统设计如此，有 数据库、缓存、全文，再加一个消息队列推出消息。其实在数据库内部也是如此，有磁盘、有cache、有CDC可以订阅log，现在不少数据库也支持全文的检索，包括local的全文以及global的。

1.1 可靠性：容忍硬件、软件失败、认为错误

【硬件故障、软件故障、人为失误】

1.2 扩展性：评测负载与性能、百分位数、吞吐量

• 如果系统以某种速度增长，我们该怎么办？

• 什么是负载？ 不同系统有不同的定义。
• 讲述了一个以Feeds流的例子，是写放大，还是读放大？ 有一些用户被关注的人有数亿，其采取写放大不显示，最后采取混合模式。大户是读放大。

• 描述性能？ SLA

• 离线批处理更加关心 吞吐量，在线关注的是 响应时间。
• 平均xx 往往不能衡量 真是的情况，一般采取99分为等来度量。 直接影响到体检，一般采取99.9%的时间是多少？

• 如果解决可扩展性问题？

• 自动检测，手工拟合
• 未来分布式系统会成为标配
• 对于早期创业的产品，功能快速迭代比性能的扩展性更加重要

1.3、可维护性：可运维、简单与可演化性

大部分人并不喜欢维护老的系统；但软件的生命周期里面大部分处于维护状态；

可运维性、简单性、可演化性；

• 可运维性：良好的操作性经常可以化解软件的局限，不规范的操作最终会击垮软件。
• 简单性：一个复杂的软件最终是一个大泥潭。降低复杂性，可以大大提高软件的可维护性。
• 可演化性：一成不变的的系统需求基本没有。

第二章：数据模型与查询语言

笔者按：笔者在16~19年，在阿里带了3年多的HBase多模系统，后续演化为LIndorm多模，由于之前一直是范式论，在接触NoSQL后，第一的思维转变就是反范式。而今，数据库种类也日益丰富，各有侧重；从趋势看在NoSQL、NewSQL等各种边界也在融合。

1.1、关系型、文档型、图类型

1. 关系从Edgar Codd于1970年提出，一直发展至今。进入21世纪，NoSQL兴起；
2. NoSQL：【扩展性、开源软件、特定查询，自由的Scheme】；
3. 对象关系不匹配：ORM  => JSON可能更加合适； JSON减少了应用程序代码和存储层之间的阻抗失配；
4. 使用ID的好处是ID对于人类没有任何意义，所以永远都不需要更改；
5. 关系型数据库与文档数据库也在渐渐融合；
6. 一些其他的 全文检索、针对对撞机设计的存储查询（数白PB）、GenBank基因库软件、时序的OpenTSDB；

1.2、数据查询语言

命令式查询语言，声明式查询语言。

MapReduce是一种编程模型，不是命令式，也不是声明式，是介于两者之间的编程模型。