DDIA-CN

设计数据密集型应用总结

• 总结：本书深入讲解数据密集型应用的设计，从数据结构到架构，助力成为优秀的架构师。涵盖可靠性、扩展性、维护性等核心要素。
• 你能获得：掌握数据系统设计的精髓，轻松应对技术挑战，打造高效、稳定的数据密集型应用。

核心内容：

1. 数据密集型应用构建：

• 应用分层构建：从现实世界建模到硬件层面的字节表示，每一层都通过数据模型隐藏复杂性。
• 复合数据系统：通过组合通用组件创建，可能需要应用代码负责维护同步。

详细解释：

• 现代应用多为数据密集型，数据是主要挑战。
• 需要工程师和架构师理解各种技术的利弊权衡。

2. 可靠性、可扩展性、可维护性：

• 可靠性：系统在各种困境中仍能正常工作。
• 可扩展性：系统能合理应对增长。
• 可维护性：不同的人员在不同时期都能高效地在系统上工作。

详细解释：

• 是数据系统设计需要关注的重要问题。

3. 可靠性实现：

• 容错机制：应对硬件故障、软件故障、人为错误。
• 错误预防：最小化犯错机会，解耦易错环节。
• 错误恢复：提供快速回滚，分批发布，数据重算等。

详细解释：

• 硬件冗余是减少系统故障率的方法。
• 软件容错机制是在硬件冗余的基础上进一步引入的。

4. 可扩展性策略：

• 描述负载：使用负载参数，如请求数、读写比率等。
• 描述性能：关注吞吐量、响应时间，以及百分位点。
• 纵向与横向扩展：根据需求选择合适的扩展方式。

详细解释：

• 评估不同情况下，系统性能将受到什么影响。

5. 可维护性原则：

• 可操作性：便于运维团队保持系统平稳运行。
• 简单性：消除复杂度，使新工程师易于理解。
• 可演化性：易于修改，适应新的应用场景。

详细解释：

• 实现这些目标没有简单的解决方案。

6. 数据模型选择：

• 关系模型：适用于传统业务数据处理。
• 文档模型：适用于文档结构的数据。
• 图模型：适用于多对多关系复杂的数据。

详细解释：

• 选择合适的数据模型非常重要。

7. 查询语言：

• 声明式查询：如SQL，指定结果的模式，由查询优化器自动选择执行细节。
• 命令式查询：需要手动编写访问路径，较为繁琐。

详细解释：

• 声明式语言为查询优化器提供了更多机会来提高查询的性能。

8. 数据模型演变：

• 读时模式：数据结构隐含，读取时才被解释。
• 写时模式：模式明确，数据库确保所有数据都符合其模式。

详细解释：

• 模式变更的速度很慢，而且要求停运。

9. 一致性模型：

• 最终一致性：数据最终会同步，但可能存在短暂的不一致。
• 读己之写：用户总是能看到自己提交的数据。
• 单调读：用户不会看到时间倒退。

详细解释：

• 要根据业务场景选择一致性模型。

10. 属性图与三元组存储：

• 属性图：顶点和边都包含属性。
• 三元组存储：以主语、谓语、宾语的形式存储信息。

详细解释：

• 属性图模型更加灵活。

11. MapReduce：

• MapReduce 既不是一个声明式的查询语言，也不是一个完全命令式的查询 API ，而是处于两者之间：查询的逻辑用代码片断来表示，这些代码片段会被处理框架重复性调用。

详细解释：

• 提供了在多台机器上批量处理大规模数据的能力，但编程模型相对底层。

12. NoSQL 数据库：

• 需要更好的可扩展性、免费和开源软件、更具多动态性与表现力的数据模型。
• 每个NoSQL 数据库都存在一定的局限性，难以满足所有的数据处理和存储需求

详细解释：

• MongoDB，RethinkDB，CouchDB 和 Espresso等数据存储技术，都属于该范畴

13. 可扩展架构

• 可扩展的架构通常也是从通用的积木块搭建而成的，并以常见的模式排列。
• 一个良好适配应用的可扩展架构，是围绕着假设建立的。

详细解释：

• 没有一招鲜吃遍天的通用可扩展架构。

问答

Q: 什么是数据密集型应用？

A: 数据密集型应用是指数据是其主要挑战（数据量、数据复杂度或数据变化速度）的应用，与计算密集型应用相对。

Q: NoSQL 数据库的出现有哪些驱动因素？

A: 包括需要更好的可扩展性、免费和开源软件更受欢迎、关系模型不能很好地支持一些特殊的查询操作、渴望一种更具多动态性与表现力的数据模型等。

Q: 什么是可维护性？

A: 可维护性是指许多不同的人（工程师、运维）在不同的生命周期，都能高效地在系统上工作（使系统保持现有行为，并适应新的应用场景）。