如何选择适合你的HTAP数据库？

Posted 2021-06-01

最近，在数据库行业对HTAP（混合事务/分析处理，Hybrid Transactional/Analytical Processing）这个概念宣传的非常火爆，也衍生出 Real-Time HTAP的说法，主要是因为随着IT行业的发展，很多用户的复杂业务已不再是单纯的OLTP或者OLAP场景，而是二者皆有的混合场景。很多数据库厂商为了响应这样的需求，同时也为了更好的宣传旗下数据库的适用性足够广泛，就纷纷打出可同时支持OLTP和OLAP的混合负载，即支持HTAP的宣传语。
当我们在网络上去搜索“HTAP”关键字，相关信息很多会提到分布式/集中式架构、传统数据库/新型数据库等等概念，本文就从这些相关概念来切入，抛砖引玉，试着理清面临如今众多的数据库，对于有HTAP需求的用户，究竟该如何理性的选择。

• 1.分布式还是集中式？
• 2.传统数据库还是新型数据库？
• 3.水平扩展问题
• 4.Exadata对OLAP的表现
• 5.Exadata对OLTP的表现
• 总结

1.分布式还是集中式？

首先这是一个非常值得深入思考的问题。由于现在“分布式”的概念很热点，导致很多人会误认为分布式数据库也会是数据库行业的唯一出路，似乎可以解决所有问题。 事实上，分布式也的确可以解决一些问题，比如接近线性的水平扩展；但是同样分布式也会带来一些麻烦，比如在互联网行业最初兴起的分库分表方案（其实并不能算作真正的分布式）通常对应用有很大的侵入性，后来顺势发展起来的原生分布式数据库也都逃不出CAP理论的制约、事务2PC的考虑、RPC的代价等等。 当然无论哪种方案，复杂还是简单，都有其适用的场景，最终如何理性选择，还是要依据具体需求，但有一个基本原则：大道至简，能用集中式解决的就无需考虑分布式。如果您的业务系统集中式架构就可以完全满足，却选择了分布式架构，那无形中就会多投入很多服务器资源，同时面临许多分布式架构下独有的挑战。

2.传统数据库还是新型数据库？

好像如今一谈到HTAP，都是各种新型的数据库，那么，传统的数据库不能支持HTAP场景吗？ 实际上并非如此，就以传统数据库中公认的老大哥Oracle为例，其本身的产品定位就是一款融合型的数据库，无论是关系型数据、图数据、空间数据、文本、XML、JSON、AP、TP等各种类型甚至包括区块链相关数据，都能实时性解决。也就是说Oracle不但支持HTAP场景，而且能更好更全面的支持，就单拿它在支持多种数据类型这点，大多新型数据库目前都还是做不到的。 那既然这样，为什么会有很多人说Oracle承载OLAP表现不佳呢？其实这是一个历史发展问题。就拿笔者之前负责运维过的项目举例，大型运营商项目，典型HTAP场景，用户最终设计还是将OLTP和OLAP分开的：使用Oracle去承担典型的OLTP业务，另外采用Vertica这类MPP架构的数据库去承担OLAP；不得不说，这个专门跑分析类应用的数据库，在执行大查询的效率的确是非常高，实际进一步去对比发现，其中一点最本质的区别是行存还是列存的选择问题，为了对OLAP有更好的效率表现，这类偏向于分析型的数据库都是采用列存的设计。 起初这样分开运行也能满足业务需求，但随着时代发展，用户对分析类业务的实时性要求也越来越高，这种混合架构就不能很好保证了，而且期间大量ETL的维护工作也很让人头疼。幸运的是，技术也在不断发展，Oracle在12c以后就推出了In-Memory列存，相当于解决了OLAP的效率问题同时又不影响OLTP的稳定运行。后续很多厂商声称支持的HTAP，基本也是参考了这样的思路，用各种技术手段最终实现的核心都是行列混合存储，从而更好的支撑HTAP场景，因为所有处理操作都是在同一套环境中，过去那种ETL/数据同步都不再需要，所以自然就实现了 Real-Time HTAP。

3.水平扩展问题

通过上面两节的讨论，我们看到，HTAP本身和分布式/集中式、传统数据库/新型数据库是没什么直接的对应关系的。那为什么提到HTAP就总爱扯上分布式呢？ 这是因为随着近些年来互联网行业的蓬勃发展，一些用户数据有了爆发性增长，传统的架构下，通过scale-up扩容的方式已经不能很好的满足这类需求，所以就演变成了分布式架构下scale-out扩容的方式，也就是我们说的水平扩展方式。 举个例子，现在某产品，当前业务集中式完全可以承担，但是考虑到未来会有爆发性增长（嗯..很多业务沾上一点互联网属性就变得这么有自信^_^），怕采用集中式架构后，以后扩容会遇到瓶颈。比如如今很多非常核心关键的应用对应的主数据库都是由Oracle RAC来支撑的，但有人会说RAC这项技术的确很好，可当部署在传统架构下遇到扩容需求时，在计算层，扩展RAC节点得不到接近线性的提升，如果使用不当还会出现严重的gc等待之类；在存储层，虽然是高端存储但总会有上限和I/O瓶颈。 其实早在Oracle Exadata一体机发布以后，这些问题就都被很好的解决掉了，Exadata 平台对数据库服务器和存储服务器均采用了一种可横向扩展的架构，下图展示了Exadata X8M-2的水平扩展能力：1/8 Rack -> 1/4 Rack -> 灵活配置 -> Multi Rack：

顺便提下，在产品白皮书中也有明确提到，像上面1个Rack（一个满机柜）的X8M-2每秒就可以执行超过1600万次8k数据库读取I/O操作或510万次8k闪存写入I/O操作。而且只要有需要，还可以继续扩展为Multi-Rack，所以对那些可能爆发性增长的业务，如果担心选择传统集中式架构下的Oracle在未来扩展时会有瓶颈，那么完全可以考虑换成Exadata平台，单体性能本身强悍的同时还解决了未来的水平扩展问题，而且因为没有更换数据库，应用也无需重新适配改造。

4.Exadata对OLAP的表现

以前笔者写过一篇文章，把Exadata类比成我们所熟悉的iPhone手机，众所周知都知道它的硬件配置并不如同年其他品牌的旗舰机高，但是给使用者的体验确是最稳定的，这很大程度就是因为iPhone软硬件一体，可以进行针对性的定制优化。 有熟悉Exadata的朋友曾开玩笑的说：在Exadata上的Oracle简直就像个作弊器！这类评价也是得益于Exadata的强悍性能表现。下面来看一个DBA的真实体验：

本来需要对664GB数据的大查询，仅通过storage index特性就消除了527GB无关I/O，又通过smart scan特性让剩下的137GB数据下沉在存储中运行，这样可以减少网络消耗并减少数据库CPU压力，最终只返回符合条件的284MB结果数据给DB层，整个过程在15秒内完成。大家感兴趣可以计算下，若是传统架构下即便配置全闪存储，没有Exadata这些独特的核心特性，直接查询这664GB数据要花多久？

5.Exadata对OLTP的表现

Exadata一体机不但为OLAP带来了卓越性能提升，也可以大幅度提升OLTP类应用效率。 有一定经验的DBA可能会质疑，如果是非常典型的OLTP场景，管理的也非常严格，都是通过合适的索引访问数据，不会出现没有走索引这类情况，那么上面说的优势就没了吧？ 其实不然，以X8M为例，除了那些耳熟能详的软件特性带来的性能提升之外，还充分利用了RoCE（RDMA over Converged Ethernet）+ PMEM（持久性内存） 技术，可以让OLTP应用即便在遇到请求访问的数据块并不在内存中时（需要向存储请求物理I/O），也能进一步加快响应，笔者从Exadata PM的介绍中，提炼出相关的几点：

• 1） 事务处理IO延迟提高10倍（单块读 ~ 19us）；
• 2） 日志写入速度提高了8倍（~ 25us）；
• 3） 同时保证原子数据块写入PMEM；
• 4） 用于集群互连的远程直接内存访问（~ 10us）。

值得一提的是，RoCE + PMEM虽然快，但对于写入操作并不算是一个好的选择，因为PMEM具有的是8字节原子写，而数据库块通常大小是8K，如果写过程中突然断电，如何确保不会导致分裂块（坏块）呢？
其实是由Exadata存储软件中的复杂算法来保证原子数据库块写入PMEM，不会出现坏分裂。
另外，传统架构上，存储是无法感知数据库发出的I/O请求属于什么类型。所以有经验的DBA可能遇到过OLAP占用大量IO资源导致影响了OLTP的效率，但是在Exadata上数据库和存储是可感知的，这就可最大程度避免优先级高的IO（比如log file sync）被其他优先级低的IO阻塞进而影响到业务。所以整体来说Exadata是可以更好的运行HTAP混合负载。

总结

上面我们谈了一些HTAP的相关内容，现在回到最初的问题：如何选择适合你的HTAP数据库？这里笔者总结一些原则和判断标准，算是抛砖引玉吧：

• 1）架构选择方面，分布式和集中式两种架构各有优缺点，因为分布式架构更复杂，所以一般能用集中式解决的就无需考虑分布式，千万不要为了分布式而分布式；
• 2）数据库选择方面，如果是核心类业务，首选Oracle数据库，不但可以直接支持HTAP场景、支持更多数据类型而且更稳定可靠；如果是非核心类业务，轻量级的可以考虑mysql这类开源数据库（通常要配合其他开源产品），压力大- 的则可以考虑分布式数据库（一般不建议分库分表那种实现方式）；
• 3）如果当前核心数据库已经是Oracle，但又担心未来几年业务有爆发式增长，超出scale-up扩容瓶颈，那么最简单的方式就是选择迁移到Exadata平台。这样就能够实现scale-out（水平扩展），上文已经看到Exadata对不同负载的卓越表现，迁移之后应用也无需重新适配改造。

总的来说，当我们面对琳琅满目的数据库产品时，首先自身要有一个清晰的底层逻辑，清楚对应业务要求的到底是什么，而不能盲目跟风选择，否则最后发现选择了并不适合自家业务场景的架构或产品，将会给未来的工作带来本不必要的负担。