OLTP（Online Transaction Processing）联机事务处理

OLAP（Online Analytical Processing）联机分析处理

非实时OLAP

实时OLAP

HTAP（Hybrid Transactional/Analytical Processing）

OLAP 和 OLTP 数据库该怎么选

紧贴核心业务需求

场景举例

在互联网高速发展的今天，大量数据的复杂分析和高并发事务处理不可兼得，不同场景对各自需求的性能要求使得数据库的处理模式被分为两类，OLTP和OLAP，后来还衍生了两者兼顾的HTAP。

OLTP（Online Transaction Processing）联机事务处理

这指的是我们最熟悉的处理模式，也就是绝大多数的实时CRUD的数据库应用场景。

特点：高并发短事务、快速响应、强一致性
典型场景：订单创建、支付交易、账户余额变更
代表数据库：MySQL、Oracle、PostgreSQL

在OLTP方面，除了大家熟知的关系型数据库意外，云原生的发展也出现一些性能更强大的数据库产品，例如阿里云的 PolarDB，华为云的 GaussDB，这些产品相比MySQL具体更高的TPS和QPS性能，又能很好的兼容MySQL协议。

OLAP（Online Analytical Processing）联机分析处理

与OLTP不同，OLAP模式主要注重数据查询分析，可以说是专门为分析而生的架构。

特点：低并发（几百或几十QPS）批量处理、复杂查询、列式存储
典型场景：销售报表、用户行为分析、BI看板
代表数据库：ClickHouse、Apache Doris，selectDB、Greenplum

OLAP从时效上来讲又分为实时OLAP和非实时OLAP（批量OLAP）两类，两者的技术实现和适用场景有显著差异。

非实时OLAP

数据延迟:小时级或天级
代表技术：Hive + Presto，Oracle Exadata
适用场景：财务报表月结，年度销售趋势分析等决策分析场景

实时OLAP

数据延迟：秒级或分钟级，通过CDC(Change Data Capture)数据同步实现
代表技术：Apache Doris，selectDB，ClickHouse
适用场景：运营大屏，物流轨迹实时追踪等近实时查询场景

HTAP（Hybrid Transactional/Analytical Processing）

这种架构同时支持在线事务处理与在线分析处理，但俗话说鱼与熊掌不可兼得，这种架构虽然兼容两种场景，但也是两方面平衡后的选择。

特点：事务处理+分析查询一体化，主打一站式服务
典型场景：需要实时分析的交易系统
代表数据库：TiDB

OLAP 和 OLTP 数据库该怎么选

紧贴核心业务需求

如果你的业务需要的是高并发，稳定，延迟小的处理数据的CRUD，例如订单交易场景，那OLTP系统就是你的首选。如果你的业务场景是从千万上亿的数据中查询，分析，统计相关的指标，为决策提供参考，那OLAP更适合你的场景。

那即使是在OLTP方面，市面上的数据库产品多种多样，具体选哪个也需要根据你业务数据的特点来决定。总之，在系统建设过程中，应该综合考虑选用当下最合适的方案。

场景举例

场景1：B端的交易业务库用的是MySQL，由于数据增速不快累计增量也少，业务库可以使用定期归档的方式来维持。但是两年后归档的数据量也非常大了，在一些历史数据查询分析场景MySQL已经不能支撑了，需要考虑新的数据源选型。
基于方案切换成本考虑，最终选用了实时OLAP的数据库selectDB,通过把业务库数据通过CDC同步到selectDB，基于selectDB来支持大数据量下的复杂查询功能。

场景2：营销活动业务库用的是MySQL，数据增量少但是查询更新量较大，对tps要求较高，在做了异步写入优化和升级MySQL配置等方案后，还是会出现抖动的情况。
针对这个场景，问题点主要在tps上，经过了解后在GaussDB 和 PolarDB两款云原生数据库产品中选了一个，同OLTP模式下这两个相比MySQL在tps和qps性能上都有较大的提升。