作者：李浩
责编：宇亭
当我们选择一款 HTAP 数据库时，总是先被其相关文档里所描述的优异性能所吸引。卓越的性能是我们选择一款产品的出发点，因为我们希望该款产品能够解决我们业务中的痛点。而大家使用 HTAP 产品的出发点就是希望该款数据库能够解决我们在事务处理过程中的实时分析痛点。不过，性能优势只能算作我们选择一款产品的考量因素之一，实际上，公司层级去选择一款HTAP产品时，还需要额外考量一些其他的因素，本篇文章，StoneDB首席架构师李浩给大家分享一下选择 HTAP 产品的六大关键考量因素。
在 TP 产品非常成熟的今天，各类 TP 类型数据库早已在各行各业中支撑着业务系统的高速发展。随着业务系统越来越复杂，所产生的数据量也在飞速增长。同时，对于这些数据的实时分析需求也日益迫切。然而，当前的解决方案却无法满足实时分析的需求。例如：如果直接在TP数据库上进行分析，虽然可以满足实时性要求，但其分析的性能基本无法满足要求，并且在进行分析时会占用大量的计算资源和 IO 资源，从而影响到 TP 性能。因此，传统的做法是将分析任务放在业务低峰时候（通常是半夜进行，因此大家经常会看见 T+1的说明情况）。
HTAP 的出现则解决了这个实时数据分析的痛点。HTAP，即Hybrid Transaction/Analytical Processing，一套系统可以同时解决 TP 需求和 AP需要。如果你的业务对于 TP 业务所产生的数据需要进行实时的 AP 分析，那么 HTAP 将会是你很好的选择。
Gartner 预计在 2024 年左右，HTAP 市场将会走向成熟。从最早 2014 年概念的提出到最近这几年，国内外对于 HTAP 已经从概念走向具体的产品落地。早期大家炒炒概念还可以接受，但显而易见，现在的市场越来越明确地走向产品质量和方案落地的竞争。
无论国内外的 SnowFlake（Unistore）、Google（AlloyDB）、Oracle（HeatWave）还是国内的 TiDB、OceanBase、StoneDB 等都推出了其各自的 HTAP 产品并且在积极的落地到生产系统。那么面对越来越多的 HTAP 产品，我们该如何选择一款适合自己业务的 HTAP 数据库产品呢？我们选择一款 HTAP 数据库又需要从那些方面进行考察呢？本篇文章中，StoneDB将给出一些自己的思考，需要说明的是，本篇作为产品选择篇，我们不从技术架构和具体的实现上进行讨论，而是主要从业务需求端的角度来作分析。对于硬核的技术实现角度，我们将在《什么是真正的 HTAP？实践篇》的下一章进行讨论。
业务场景
首先，我们从业务场景的角度来讨论如何选择一款HTAP数据库，主要有以下四个维度：
1.1、业务类型
业务所在的领域决定了产品底层技术栈的选择。这个很好理解，比如电商这个业务场景所需要的技术栈和产品特点与传统制造、CRM 等所关注的侧重点就完全不一样——电商关注高并发、低延时、数据一致性和秒杀场景等等，而传统制造商则对海量多样化数据的处理和如何有效挖掘数据价值这些方面更加关注。
在不同的业务类型下，选择一款 HTAP 产品需要重点考察的是——这个业务类型需要哪一部分能力为主：TP 能力为主亦或是 AP 能力为主。
对于电商系统需要更加注重其在 TP 方面的关键能力，例如：事务、数据一致性等等；而对于CRM系统，经销存等等对TP能力则不会那么严苛，其可能更加看重AP的能力，在 TP 能力满足其基本业务需求的情况下，哪款产品的 AP 能力更强，业务侧可能会更倾向于选择该款产品。
而现有 HTAP 产品从技术实现路线上，基本可以分为这么两类路线，其决定产品的基因：即侧重于 TP 还是 AP？
路线1：以成熟的TP系统为基础，在其上进行AP能力的扩展。现有大部分 HTAP 数据库产品均采用该种策略。为什么采用该种策略？其原因是显而易见的，TP 系统发展到现在其相较于 AP 系统，更加成熟。例如：国内外的 OB，StoneDB，TiDB，Oracle MySQL Heatwave 和 Google AlloyDB 等；
路线2：在 AP 系统的基础上扩展其处理 TP 的能力。例如：Snowflake 等。这种路线，比较困难，但是成熟的科技公司会有更多的资源去做这个事儿，难度大，但是做出来了，也会是一大利器。
1.2、端到端的解决方案能力：
对于业务开发相关人员，一个新产品或者解决方案的引入，自然希望不会给其带来额外的工作负担，并且最好能够与其原有的技术栈相兼容，这样对于原有业务系统的改动要求最少。但也不完全就是为了让干的活儿更轻松一些，因为，对于一个在线运行的系统，其对于稳定性的要求非常高，而新组件的引入往往会让整个业务的不稳定因素增大。因此，如果不能够保持原有的技术栈，则需要提供端到端的解决方案。例如：原系统采用的 ClickHouse 或者 ElasticSearch，如果需要替换为 OB 或者StoneDB，那么需要考虑原系统 ClickHouse 或者 ElasticSearch 上下游相关模块接口兼容性，数据同步到 CK 或者 ES 的方式等等，这些解决方案都要提供出来。
1.3、数据实时性要求：
数据实时性的高低同样也会影响到产品的选择。当前现有的 HTAP 数据库在 TP和 AP 之间的数据同步策略实现机制不尽相同。例如：有些云厂商通过 MySQL+Binlog+ClickHouse 的组合方式提供 HTAP 服务，从用户的角度看似乎该服务具备了HTAP的能力，但实际上完全不是那么回事儿——因为通过 Binlog 这种方式会有很多弊端，这里可以参考我们之前的两篇文章；又如有厂商通过 TP+Redo+Raft+AP 这样的组合构成 HTAP 产品，其相较于前一种在数据的实时性上有了较大的提升，但也只是提供数据的最终一致性，同样数据的实时性还是得不到保证；有的厂商则采用了基于 LSM-tree 实现的行列混存，这种可以基本保证对于数据实时性的要求；而像 MySQL Heatwave 和 StoneDB 则提供了基于内存计算的强实时性的方案。
HTAP 数据库在产品具体实现的时候，其选择的存储方案会直接到影响架构的选择：是一体化的架构？还是 TP 系统叠加 AP 系统的方案？架构的选择则会直接决定数据同步策略和数据实时性的高低。
1.4、技术能力：
产品背后其公司所代表的技术实力也是业务方选择一款产品的考量因素，例如：我们在下文第六点中给出的观点。
性能
考量完业务场景相关的因素后，接下来需要考量的一个重要因素就是性能。不同于TP系的 Benchmark TPC-C 或者 AP 系统的 Benchmark TPC-H，对于HTAP 的性能测评一般不再使用这两个传统的方式来进行衡量。
当前大家更多地使用 TPC-H 来对其 AP 的能力进行评估，该种方法可以对其系统有一定的评价作用，但也存在着一定的弊端，那就是 TPC-H 无法全面地衡量一款 HTAP——因为 HTAP 数据库的系统中会同时存在两类负载：TP负载和AP负载。两类负载需要同时使用系统的CPU资源、IO 资源和网络资源等等。对资源的竞争会导致两类负载的相互干扰。因此，为了更好的衡量 HTAP 数据库，无论是学术界还是工业界，都逐渐提出了一些适用于HTAP数据库的 Benchmark 系统，具体可以参考我们之前的文章：《如何给一个 HTAP 数据库做基准测试？》
这里也简单提一下，除了具体的性能指标，例如：TPS、QPS、吞吐量等等，资源隔离性也是我们的重要考量。而资源隔离通常有两种方式：
（1）通过系统手段（软件）隔离。例如，通过 Cgroup 的方式进行资源的管理；
（2）通过物理手段进行隔离。例如，依据不同的负载类型 Route 到不同引擎上，将 AP 查询路由到列存引擎节点上，这样可将 TP 负载和 AP 负载运行于不同的节点上，从而做到真正的物理隔离。
运维
运维的难度也需要我们认真考量。数据库的运维不同于其它基础系统，其对于 DBA 的综合素质有比较高的要求。在系统长时间运行的过程中会遇到各种数据库的使用、功能、性能等等问题。解决这些问题除了需要数据库、操作系统和业务等多方面的知识，同样也需要相关运维工具的支持。运维手段和运维工具可以高效的支持 DBA 的运维工作。复杂的系统形态，会导致 DBA 的运维工作量增大，最直接的影响就是难以快速定位问题，增加了解决问题的耗时。
生态
生态是选择一款 HTAP 数据库的一个重要因素。当前有两类生态：PostgreSQL 和 MySQL。选择哪一种生态，会直接影响到后续围绕数据库所构成的整个技术栈。同时，业务也会从其自身的特点选择相应的技术路线。例如：如果业务系统是基于 JSON 和 GIS 能力的话，那么多数的业务开发者可能更倾向于选择 PostgreSQL 生态；如果是电商业务则更多的会选择 MySQL 生态。
具体来讲，生态中的周边工具、中间件和解决方案的完整性和丰富性非常重要。除工具、方案外，社区参与的人数（不管是对开源的 HTAP 数据库，还是对于商业或云上的 HTAP 服务，都需要考量该使用该服务的人群数量），更多的社区参与人数往往意味着社区比较活跃，那么，我们使用者遇到的一些问题就可以得到快速的响应。
生态的繁荣也从另外一个侧面反映出该技术路线获得了相当多的上下游厂商的支持。
成本是一个无法绕过的话题，一般企业/组织内的管理者对于成本的关注度往往是多于其他项的。如果想要使用一款 HTAP，需要考量的成本主要包括以下几个方面：硬件成本、替换（迁移）成本、运维成本等：
5.1、硬件成本：
其中最主要包括：计算成本和存储成本。在 StoneDB 实际的产品 POC 过程中，遇到很多客户实际的业务数据量在 100GB-1TB 内。如果采用一些现有的其他国产 HTAP 产品，由于这些产品对最小集群有要求，从而使得这些小厂商在使用 HTAP 服务时，必须付出比较高的集群硬件成本，这个是他们不愿意接受的。特别地，当需要替换现有MySQL数据库的时候，目前的一些国产 HTAP 数据库，基本都存在 MySQL 语法兼容性的问题，这导致迁移到新的业务系统上需要进行大量的修改，从而造成整体成本的飙升。如果厂商比较在乎这一部分的成本的话，StoneDB 就是很好的选择了。
5.2、替换成本：
需要能够提供对于原系统的平滑迁移能力。对于业务侵入改动最小，业务无需做修改即可平滑迁移到新的数据库平台。
5.3、运维成本：
在第三点中我们讨论运维问题，这里就不再详细讨论了。运维成本将会是系统稳定后，最主要的支出成本。
LTS 支持性
对于LTS（Long Term Support，长期支持版）支持性，这里又可以从两个方面来讨论。
（1）商业 HTAP 数据库
（2）开源 HTAP 数据库
无论对于商业数据库还是开源数据库都面临某个版本的生命周期问题。
商业数据库相对来说，其售后服务有保障，但同时商业数据库又面临闭源和售后服务需要支付昂贵的服务费用等问题。而开源数据库，其 LTS 的支持除了需要社区支持以外，也需要由其背后的公司来进行保证。我们也很容易发现，一个成功的开源数据库项目背后，通常都有一个成功的商业公司支撑。
因此，无论是选择哪类 HTAP 数据库，都需要注意所选择的产品的 LTS 支持性的问题。
好了，以上就是我们总结的选择一款 HTAP 数据库需要考量的六大因素，也即：业务场景、性能、运维、生态、成本和 LTS 支持性，希望对于这六点的分析能给大家在做 HTAP 产品选型时提供帮助。
StoneDB 的 2.0 架构完全对标 Oracle MySQL MDS（HeatWave），目前，我们的架构设计方案的RFC文档也完全公布在了 Github 上：
https://github.com/stoneatom/stonedb/issues/436
如果您想了解更多，也可以关注我们的 Github 仓库：
https://github.com/stoneatom/stonedb
本周五（12月9号）下午，StoneDB 开源社区PMC、StoneDB 首席架构师李浩老师也将参与由 ITPUB 社区举办的开源小秀场线上 Meetup 活动，欢迎大家前往官网 http://os.itpub.net/ 关注：
StoneDB 2.0 云原生分布式实时 HTAP 架构详细设计以 RFC 形式持续进行，欢迎大家关注我们最新进展，更欢迎给我们开源协作的模式和方法提出改进意见，一起通过开源的方式共建 StoneDB ~
https://github.com/stoneatom/stonedb/issues/436
- StoneDB 代码已完全在 Github 开源：
https://github.com/stoneatom/stonedb
- StoneDB 官网：