数据库国产化需要知道的几件事

　　本文存在反转，有兴趣的请看完。如果观点不太，请见谅。
　　大概是十年前吧，一个朋友突然打电话来说，他们公司有一个数据库，性能超过Oracle 50倍，希望我帮着看看，能不能在一些客户里推广推广。当时我就没把这话当回事，如果你说你们的数据库性能已经快赶上Oracle了，那我可能还会认真的去考虑考虑。后来他觉得我对这件事不上心，亲自飞到深圳，一定要给我上上课。在一个餐馆里，几杯酒下肚后，他拿出了电脑给我介绍他们的十分牛逼的数据库系统。当我看到第一页上的Mysql语法完全兼容的时候，我就说咱们接着喝酒吧，大概我清楚了。
　　为什么我这么有把握呢？实际上数据库发展了几十年，其核心技术是十分清晰的，SQL引擎、优化器、资源管理、并发控制、存储架构这几个方面的核心技术决定了数据库最终能够达到什么样的高度。而在这些方面，Oracle无疑是最为优秀的。
　　数据库的优化器是决定某条SQL语句最快能跑多快的一个最为关键的因素，十分遗憾的是，目前的所有国产化数据库，甚至加上所有的商用数据库，没有一个优化器能够和Oracle相媲美。作为一个通用数据库，将会面临各种复杂甚至变态的SQL语句，而优化器都能够找到最好的执行计划，这是高性能的数据库产品必须具备的能力。可惜的是，在这方面，Oracle一骑绝尘，具有绝对的统治力。可能有朋友会觉得我在瞎说了，现在霸榜TPCC测试第一名的不已经是我们的国产数据库了吗？TPCC实际上是一种十分理想化的交易型场景，针对TPCC去做相关的数据库产品优化并不难，但是其价值并不大，这也是近些年美国的数据库厂商大多数都已经不再送测TPCC的主要原因，我们的数据库产品击败的也是十多年前的Oracle数据库。TPCC测试对于优化器的要求其实并不高，甚至很多国产数据库TPCC测试时都要求关闭HASH JOIN，以达到更高的测试效果。而HASH JION正是大数据量下表连接的十分高效的执行方式。十年前的Mysql尚不支持Hash Join，用这个引擎去做一个数据仓库的SQL引擎，那么这个数仓在处理复杂的OLAP分析的时候，效率会如何了，所以我当时就对那个产品不感兴趣了。所以在做数据库国产化的时候，第一个需要了解的真相是，我们的国产数据库在最为核心的优化器，以及资源管理器、并发控制算法方面仍然与Oracle存在巨大的差距。虽然我们不太情愿承认这一点，但是我们必须承认。就像一个国产数据库的核心研发人员所说的：＂我们开始以为我们的优化器已经和Oracle水平相当，但是在很多用户实际应用上我们才发现，我们还差的太远＂，这句话只有真正懂数据库的人才说得出来，尽管不是十分情愿。
　　在数据库国产化领域还有另外一种说法是弯道超车，和Oracle一样玩集中式数据库我们不行，那我们就玩NewSQL,玩MPP架构，SHARE NOTHING。确实，分布式数据库可以从很大程度上解决国产集中数据库无法避开的SQL引擎及优化器能力不足、资源管理并发管理方面算法效率较低的问题。就像几年前一位领导在数据库国产化相关的研讨中说的：＂一个人干不过你，咱们一群人还干不过你吗？＂。通过多节点，并发处理的能力来实现对有限节点的集中式数据库实现超越，也是一条不错的路线。不过，这条路走起来也不顺利。首先是服务器的计算能力发展太快，存储技术发展也太快了。集中式数据库配上高性能的X86服务器，再加上闪存技术的加持，让集中式数据库的处理能力一下子增长了数十倍，我们追赶的难度又增加了。再加上分布式数据库仍然避不开SQL引擎和优化器的问题，在一个分布式环境中，优化器开发的难度更大了，连一个单机的优化器都做不好的研发团队，就更难做好分布式环境下的优化器了。目前我们的大多数分布式国产数据库，在某个特定领域的能力确实很强，比如在一些简单的交易场景，针对银行、证券甚至运营商的业务逻辑较为简单的，以数据写入与不太复杂的查询分析的场景，已经支持的很好了。目前也有不少金融企业逐渐完成国产数据库替代的案例，这是极为正常的。不过很多国产分布式数据库都对开发人员提出了更高的要求，肆意编写SQL语句是绝对不允许的，必须按照数据库提出的要求来编写SQL。如果我们的应用开发商能够掌握这些技巧，在这些分布式数据库上，完全可以写出十分优秀的系统。不幸的是，我们的IT决策人员大多数并不知道这个真相。所以说，我们今天讲的第二个真相是，分布式数据库并没有大多数人想象的那么强大，起码对某些常用应用场景是如此的。
　　看到这里，似乎本文是在宣扬数据库国产化无望的文章，其实不是的。因为下面我们要讲的真相都是支持数据库国产化的。我们总是在谈国产数据库在很多关键技术方面与Oracle相比有着巨大的差距。但是我们往往忽略了一个十分朴素的现实，那就是其实实际上我们的绝大多数系统并不需要如此高的并发处理能力，数据量也并没有大到无法处理的地步，真正需要Oracle的大多数高性能，高并发能力的系统并不多。在国产化数据库替代的时候，并不一定要选择必须能够与Oracle相匹敌的产品。甚至在大多数应用系统从Oracle数据库迁移到国产化数据库的时候，我们最总要的考虑因素并不是性能，而是更应该考虑兼容性、稳定性、运维便捷性、总体使用成本等方面的因素。退一万步说，一个企业里的至少80%以上的系统，是可以通过最为简单的方式用国产化数据库替代的。这一点已经可以让我们的数据库国产化工作启动起来了，随着国产数据库应用的日益深入，我想，国产数据库的技术提升也会加速。所以说，这个令人鼓舞的真相就是，我们的绝大多数应用系统不需要Oracle那么强的能力。
　　鼓舞之后打击又来了，因为在信息系统中任何短板都是需要在应用开发上去弥补的，因此如果我们不使用Oracle这样强大的商用数据库，而改用国产数据库的话，我们的应用开发人员必须去解决数据库性能不足的问题，这对于信息系统的开发团队是一个巨大的考验。曾经有一个企业在把应用系统向阿里云迁移的时候发现，原有的应用开发团队能力不足，无法驾驭RDS/DRDS上的研发工作，于是只能重组整个队伍，提升队伍的技术水平，仅此一点，每年在研发方面的投入要增加2000万。事实上，不仅仅是研发，在系统上线后的运维、优化等方面都需要有一定的投入，才能支撑数据库国产化的工作。而事实上，我们的很多IT部门的决策者并不了解这方面，他们觉得只要选择好一款国产化数据库，把Oracle替换了，就万事大吉了。如果我们在数据库国产化工作中仅仅如此简单操作，那么数据库国产化的过程中肯定会遇到一地鸡毛的。第四个真相是，数据库国产化是一个复杂的生态建设工程，而不仅仅是一次商业采购的产品替换，在这个问题上我们远没有准备好，必须花大力气在应用研发、系统优化、运维支撑等全领域都构建起针对国产化数据库的能力，才能把这项工作做好。
　　今天要讲的最后一个真相是，Oracle确实太昂贵了，我们真的用不起。可能很多朋友都觉得Oracle应该是使用成本最低的数据库了，我们花100万买一套数据库，可以节约更多的研发、运维方面的成本，不是很划算吗？实际上讲数据库成本的时候确实要算总账，不能仅仅算买数据库的钱。但是我们的计算过程出问题了。Oracle数据库对于一般企业的许可证是一个核20万左右（如果加上RAC/PARTITION/甚至我们常用的AWR都是要另外加钱都的），对于一台16核的四路服务器来说，哪怕按照1/2的核数来计算许可证的话，购买Oracle的合法许可证费用是640万，再加上每面22%的标准服务费（这个费用最主要是要合法的下载补丁），这绝对不是一般企业能够承受的起的。可能有朋友不服气了，我们就是花了几十万买了一套正版的Oracle。没错你花钱买了一套正版的Oracle，但是你在使用的时候超范围使用了，这在法律上也构成了盗版。这也是为什么很多美国的大公司大量的在使用SQL SERVER,MYSQL等数据库的一个主要的原有。十多年前，去IOE浪潮兴起的时候，我就和一位美国的DBA交流过为什么美国没有去IOE浪潮。他说：＂我们用不起那么多的ORACLE，只是在必须使用的场景使用Oracle，其他的地方能用不花钱的MYSQL就用MYSQL,或者用便宜点的SQL SERVER＂。既然如此，我们趁着数据库国产化的机会，把以前那么多存在盗版法律风险的问题解决掉，不也是一件好事吗。
　　其实在这里我也要说一个不得不说的残酷真相，那就是某些系统，目前还真的很难找到Oracle的替代品，那么我们也不必要纠结，继续使用就行了。条件不成熟时候就强行换掉Oracle也是不符合科学的事情。可能有些朋友不相信这种场景的存在，我也没办法让每个人都相信我的观点，观点并不等于事实，任何时候事实只有一个，观点可能各不相同，没必要每个人的观点都相同。