代码改变世界

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

2021-06-01 17:52  AlfredZhao  阅读(899)  评论(0编辑  收藏  举报

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

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对不同负载的卓越表现,迁移之后应用也无需重新适配改造。

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