数据库系统可以在广义上分为
-
联机事务处理（Online Transaction Process，OLTP）
-
联机分析处理（Online Analyze Process，OLAP）
两种面向不同领域的数据库，OLAP数据库也被称为数据仓库。
从产品上看，有专门面向OLTP的数据库，例如MySQL、PostgreSQL、Oracle等
也有专门面向OLAP的数据库，例如Hive、Greenplum、HBase、ClickHouse等
主要区别就是 T (Transaction) 和 A (Analyze)
| OLAP | OLTP | |
|---|---|---|
| 用途 | 数据仓库 | 事务数据库 |
| 数据容量 | 大, PB级 | 小, GB级, 部分能达到TB级 |
| 事务能力 | 弱/无 | 强 |
| 分析能力 | 强 | 弱, 只能做简单分析 |
| 并发数 | 低 | 高 |
| 数据质量 | 相对低 | 高 |
| 数据来源 | 业务数据库 | 业务系统 |
OLAP和OLTP设计原则
OLTP一般是基于三大范式进行数据库设计，所以查询时候会导致多表join关联查询，产生查询慢，不利于数据分析的问题。所以OLAP在设计时不是基于三大范式设计的，允许一定的冗余，基于数据仓库建模设计，为了更好的进行数据查询分析。
OLAP和OLTP的本质区别在于底层数据模型的不同。OLAP更适合使用低范式的数据表，而OLTP则更适合使用高范式的数据表。无论它们之间的功能是否越来越相似，只要其底层数据模型不同，那么它们之间的区别就永远存在，结构决定功能。
OLAP场景的关键特征
OLAP一般不直接产生数据，一般是存储ETL之后的数据和历史数据进行建模分析。关于数据仓库理论可以参考：数据中台和数据仓库设计
- 绝大多数是读请求
- 数据以相当大的批次(> 1000行)更新，而不是单行更新;或者根本没有更新。
- 已添加到数据库的数据不能修改。
- 对于读取，从数据库中提取相当多的行，但只提取列的一小部分。
- 宽表，即每个表包含着大量的列
- 查询相对较少(通常每台服务器每秒查询数百次或更少)
- 对于简单查询，允许延迟大约50毫秒
- 列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)
- 处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行)
- 事务不是必须的
- 对数据一致性要求低
- 每个查询有一个大表。除了他以外，其他的都很小。
- 查询结果明显小于源数据。换句话说，数据经过过滤或聚合，因此结果适合于单个服务器的RAM中
OLTP场景特征
OLTP一般用作实时系统中，飞机订票、银行出纳、股票交易、超市销售、饭店前后管理等。
- 支持大量并发用户定期添加和修改数据。
- 反映随时变化的单位状态，但不保存其历史记录。
- 包含大量数据，其中包括用于验证事务的大量数据。
- 可以进行优化以对事务活动做出响应。
- 提供用于支持单位日常运营的技术基础结构。
- 个别事务能够很快地完成，并且只需访问相对较少的数据。
- 实时性要求高。
- 交易一般是确定的，所以OLTP是对确定性的数据进行存取。(比如存取款都有一个特定的金额)
- 并发性要求高并且严格的要求事务的完整、安全性。(比如这种情况：有可能你和你的家人同时在不同的银行取同一个帐号的款)。
注意: 本文归作者所有, 未经作者允许, 不得转载. 若有谬误, 欢迎指出
