读书笔记。
设计数据密集型应用 Designing Data-Intensive Application
第一章：可靠性 可拓展性 可维护性
Data System
可靠性 Reliability
系统在adversity中任然可以正常工作。
可靠性的总结：
- 程序表现出用户所期望的功能
- 允许用户犯错，允许用户以出乎意料的方式使用软件
- 在预期的负载和数据量下，性能满足要求
- 系统能防止未经授权的访问和滥用
故障（fault） 容错（fault-tolerant） 韧性（resilient）
硬件故障、软件错误、人为错误
可拓展性 Scalability
有合理的办法应对系统的增长（数据量 流量复杂性）
描述负载 tw为例
描述性能
对于hadoop 关心吞吐（throughput）
对于在线系统，关心响应时间（response time）对响应时间的比较良好的数据：百分位点（percentiles）和中位数（median）而不是算术平均值（arithmetic mean）
尾部延迟（tail latecies）在某些场景下非常重要，比如亚马逊–用户掏钱了
应对负载
纵向拓展 scaling up 垂直拓展 vertival scaling 转向更强大的机器
横向拓展 scaling out 水平拓展 horizontal scaling 将负载分不到多台小机器上
有些系统是弹性的（elastic），但是会造成额外的复杂度，手动扩容会简单很多 如果系统是极难预测的，则弹性扩容可能会很有用（highly unpredictable）
跨多台机器部署无状态服务（stateless service）非常简单。
没有通用的可拓展框架（万金油 magic scaling sauce）
一个适配良好的可拓展框架，是围绕假设（assumption）建立的
可维护性 Maintainability
许多不同的人在不同的声明周期，都高效的在系统中工作
在设计软件指出就尽量考虑尽可能减少维护期间的痛苦，从而避免自己的软件系统编程遗留系统。
为此，我们将特别关注软件系统的三个设计原则：
可操作性
便于运维团队保持系统平稳运行
简单性
从系统中消除尽可能多的复杂度（complexity）
可演化性
可拓展性（extensibility） 可修改性（modifiability）可塑性（plasticity）
数据模型与查询语言
数据模型不仅仅影响着软件编写方式，而且影响着我们的解题思路。
数据模型种类繁多，每个数据模型都带有如何使用的设想，有些用法很容易，有些则不支持如此。
掌握一个数据模型需要花费很多精力，所以选择一个适合的数据模型是非常重要的。
关系模型与文档模型
SQL
现在最著名的数据模型可能是SQL，它基于Edgar Codd在1970年提出的关系模型：数据被组织称关系（SQL中称作表），每个关系是元组的无需集合。
NoSQL
NoSQL被追溯性的重新解释为不仅是SQL（Not Only SQL）
驱动NoSQL诞生的原因是：
- 需要比关系型数据库更好的可拓展性，包括非常大的数据集或非常高的写入吞吐量
- 相比商业数据库产品，免费和开源更手滑你用
- 关系模型不能很好地支持一些特殊查询
- 受挫与关系模型的限制性，渴望一种更多动态性与表现力的数据模型
在可预见的未来，关系型数据库似乎可能会继续与各种非关系型数据库一起使用，这种想法有时被称为混合持久化(polyglot persistence)
对象关系不匹配