本文最后更新于 4 天前，文中所描述的信息可能已发生改变。
DDIA 第二版，第一章：可靠性、可扩展性和可维护性。
数据系统的标准构件
这类应用通常由若干标准构件搭建而成，每个构件负责一种常见能力。例如，很多应用都需要：
- 存储数据，以便它们或其他应用程序以后能再次找到（数据库）
- 记住昂贵操作的结果，以加快读取速度（缓存）
- 允许用户按关键字搜索数据或以各种方式过滤数据（搜索索引）
- 一旦事件和数据变更发生就立即处理（流处理）
- 定期处理累积的大量数据（批处理）
讨论：
Q：流处理这里是不是不够全面？API 接口和流式数据的生产消费还是有区别的吧，API 接口算流处理吗？
A：原文说的"流处理"（Stream Processing）是指异步的事件驱动处理——比如 Kafka 消费消息、CDC 监听数据变更。API 接口（请求/响应模式）严格来说不算流处理，它是同步的在线服务（Online Service）。DDIA 第一版在后面区分了三种系统类型：
- 在线服务（Online Service）：等待请求、响应请求，关注响应时间。API 接口属于这类
- 批处理系统（Batch Processing）：处理大量累积数据，关注吞吐量
- 流处理系统（Stream Processing）：介于两者之间，近实时地消费事件
所以这段列举的是数据系统的构件，不是系统类型的完整分类。API/在线服务层没有被单独列出来，因为它更多是应用本身而非"数据基础设施"组件。作者这里关注的是数据怎么被存、被缓存、被索引、被异步处理，而不是请求怎么进来。
事务（Transaction）的由来
在商业数据处理的早期，对数据库的写入通常对应于发生的商业交易（commercial transaction）：进行销售、向供应商下订单、支付员工工资等。随着数据库扩展到不涉及金钱交换的领域，事务（transaction）这个术语仍然保留了下来，指的是形成逻辑单元的一组读取和写入。
事务这个概念的词源来自真实的商业交易。关键点在于"逻辑单元"——事务的本质不是"和钱有关"，而是一组操作要么全部成功、要么全部失败，不可分割。
OLTP 与 OLAP
尽管数据库开始用于许多不同类型的数据——社交媒体上的帖子、游戏中的移动、地址簿中的联系人等等——但是基本的访问模式仍然类似于处理商业交易。事务型系统通常通过某个键查找少量记录（这称为点查询）。基于用户的输入插入、更新或删除记录。因为这些应用程序是交互式的，这种访问模式被称为联机事务处理（OLTP）。
然而，数据库也越来越多地用于分析，与 OLTP 相比，分析具有非常不同的访问模式。通常，分析查询会扫描大量记录，并计算聚合统计信息（如计数、求和或平均值），而不是将单个记录返回给用户。为了将这种使用数据库的模式与事务处理区分开来，它被称为联机分析处理（OLAP）。
讨论：
Q：OLTP 是单纯的读写系统，OLAP 是对大量数据进行聚合。聚合的数据来源可能是物理表，也可能是物化视图、视图，或者其他广义的数据库存在形式，对吗？
A：大方向对，但可以更精确一些。OLTP 不是"单纯的读写"，而是小范围、高频率的点读写——按主键查一条记录、插入一笔订单，强调低延迟。OLAP 则是大范围扫描 + 聚合计算，强调吞吐量。
至于数据来源，确实不局限于物理表。OLAP 场景下常见的形式包括：
- 物理表：数据仓库中的事实表和维度表（星型/雪花模型）
- 物化视图：预计算好的聚合结果，用空间换时间
- 普通视图：逻辑上的查询封装，实际执行时还是扫描底层表
- 列式存储：同样是物理表，但按列而非按行存储，天然适合聚合扫描
- 数据湖 / 外部表：Parquet、ORC 等文件格式，通过引擎（如 Spark、Presto）直接查询
所以"广义的数据库存在形式"这个说法是对的，OLAP 的数据来源比传统关系表要宽泛得多。
