OLTP vs OLAP vs HTAP - tenji/ks GitHub Wiki

OLTP vs OLAP vs HTAP

一、基本概念

  • OLTP (OnLine Transaction Processing): 联机事务处理，OLTP 是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLTP 主要重点是记录当前事务的更新、插入和删除。
  • OLAP (OnLine Analytical Processing): 联机分析处理，OLAP 是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。OLAP 主要重点是复杂的查询。
  • HTAP (Hybrid Transaction Analytical Processing): 混合事务/分析处理，是数据库技术领域的新名词，是 OLTP 和 OLAP 合称简写，即（HTAP = OLAP + OLTP）, HTAP 既可以在线交易事务，又可以在线实时分析。

二、OLTP

2.1 OLTP 系统的要求

使用事务数据的 OLTP 系统最常见的架构是三层架构，通常由表示层、业务逻辑层和数据存储层组成。表示层是前端，其中事务通过人工交互产生或由系统生成。逻辑层由验证交易并确保完成交易所需的所有数据可用的规则组成。数据存储层存储事务以及与之相关的所有数据。在线交易处理系统的主要特点如下：

  • 酸合规性：OLTP 系统必须确保正确记录整个事务。事务通常是可能需要执行多个步骤或操作的程序的执行。当所有相关方都确认交易时，或者当产品/服务交付时，或者当对数据库中的特定表进行一定数量的更新时，它可能是完成的。只有执行并记录了所有涉及的步骤，才能正确记录事务。如果任何一个步骤有任何错误，则必须中止整个事务，并且必须从系统中删除所有步骤。因此 OLTP 系统必须符合原子性、一致性、隔离性和持久性 (ACID) 属性，以确保系统中数据的准确性。
  • 并发性： OLTP 系统可能拥有非常庞大的用户群，许多用户试图同时访问相同的数据。系统必须确保所有这些试图读取或写入系统的用户可以同时进行。并发控制保证两个用户同时访问数据库系统中的相同数据将无法更改该数据，或者一个用户必须等到另一个用户完成处理才能更改该数据。
  • 扩展： OLTP 系统必须能够即时扩展和缩减，以实时管理事务量并同时执行事务，而与尝试访问系统的用户数量无关。
  • 可用性： OLTP 系统必须始终可用并随时准备接受事务。交易失败可能导致收入损失或可能产生法律影响。因为交易可以在世界任何地方和任何时间执行，系统必须 24/7 全天候可用。
  • 高吞吐量和短响应时间： OLTP 系统需要纳秒甚至更短的响应时间来保持企业用户的生产力并满足客户不断增长的期望。
  • 可靠性： OLTP 系统通常读取和操作高度选择性的少量数据。最重要的是，在任何给定时间点，数据库中的数据对于访问该数据的用户和应用程序来说都是可靠且值得信赖的。
  • 安全性： 由于这些系统存储高度敏感的客户交易数据，因此数据安全性至关重要。任何违规行为对公司来说都是非常昂贵的。
  • 可恢复性： OLTP 系统必须具有在任何硬件或软件故障时恢复的能力。

三、OLAP

3.1 OLTP vs OLAP

OLTP 系统 OLAP 系统
支持大量人员实时执行大量数据库事务 通常涉及查询数据库中的许多记录（甚至所有记录）以进行分析
需要闪电般快速的响应时间 需要比 OLTP 要求的响应时间慢几个数量级的响应时间
频繁修改少量数据，通常涉及读写平衡 完全不修改数据；工作负载通常是读取密集型的
使用索引数据来缩短响应时间 以列格式存储数据，以便轻松访问大量记录
需要频繁或并发的数据库备份 需要少得多的数据库备份频率
需要相对较少的存储空间 通常需要大量存储空间，因为它们存储大量历史数据
通常运行仅涉及一条或几条记录的简单查询 运行涉及大量记录的复杂查询

四、HTAP

2014年 Gartner 的一份报告中使用混合事务分析处理（HTAP）一词描述新型的应用程序框架，以打破 OLTP 和 OLAP 之间的隔阂，既可以应用于事务型数据库场景，亦可以应用于分析型数据库场景，实现实时业务决策。这种架构具有显而易见的优势：不但避免了繁琐且昂贵的 ETL 操作，而且可以更快地对最新数据进行分析。这种快速分析数据的能力将成为未来企业的核心竞争力之一。

4.1 HTAP 的合理性

  • 数据刚进入数据库的时，可称之为“热数据”；热数据在 OLTP 场景下会被频繁修改。此时数据宜行存储。
  • 随着数据慢慢变久，数据越来越“冷”；这个时候数据不太可能被频繁的修改，对数据的查询和分析越来越多。此时数据宜列存储。

4.2 TiDB

TiDB 是 PingCAP 公司基于 Google Spanner / F1 论文实现的开源分布式 NewSQL 数据库。

TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景。

TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力。

4.2.1 TiDB 核心特性

  1. 高度兼容 MySQL

    大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。

  2. 水平弹性扩展

    通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。

  3. 分布式事务

    TiDB 100% 支持标准的 ACID 事务。

  4. 高可用

    相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。

  5. 一站式 HTAP 解决方案

    TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解决方案，一份存储同时处理 OLTP & OLAP，无需传统繁琐的 ETL 过程。

  6. 云原生 SQL 数据库

    TiDB 是为云而设计的数据库，同 Kubernetes 深度耦合，支持公有云、私有云和混合云，使部署、配置和维护变得十分简单。

TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解决方案，一份存储同时处理 OLTP & OLAP，无需传统繁琐的 ETL 过程。

五、Amazon RDS vs Redshift

5.1 相似点

5.2 不同点

结构。RDS 和 Redshift 之间最重要的区别在于它们的数据处理设计。RDS 遵循 OLTP 设计，而 Redshift 遵循 OLAP 设计。

RDS 旨在为需要立即响应的实时交易提供在线服务。 Redshift 适用于可以异步执行的具有更长和更繁重数据分析的作业。

配置和扩容。

数据访问。RDS 数据库并不允许访问存储在其本地存储系统和预定义格式之外的数据。 Redshift 可以访问存储在集群本地或外部数据源中的数据。

对于外部存储的数据，Redshift 支持多种格式，例如 ORC、Parquet、JSON 和 CSV。 Redshift 经过设计和优化，可以存储和访问比 RDS 大得多的数据集。每个节点的容量最高可达 128 TB，在集群中可以存储数 PB 的数据。相比较而言，对于大多数数据库引擎，RDS 达到 100 GB 到 64 TB。

费用。

参考链接