民族品牌当自强
近几年随着我对主流开源数据库的了解，再慢慢深入去了解国产数据库后，整个对数据库的想法了有很大的改变。最初只接触Oracle数据库并深度熟悉其博大精深之处，对开源数据库也是满目嫌弃，在更深度的去了解开源数据库后，也看到了其开源的魅力，只要有能力可以真正的从源码级别去研究，现在在工作中接触国产数据库时，仍是满目嫌弃，那么为什么我又会转变思想呢？
从一张表格说起
先用一张表格来分析目前主流国外数据库和国产数据库的一个格局和方向。
从表中可以看到，我们国内数据库几乎都是一个套路，那就是兼容，在兼容关系上都逃不脱Oracle、MySQL、PostgreSQL，为什么会造成这样的局面？最主要的因素在于生态的建设上，这个生态包含了业务系统、开发人员、运维人员、基础设施架构等等。想去另辟一套生态，对于企业来说这是无法承受的，也不是一朝一夕能够完成的。
通过国内的摩天轮社区，我们能看到国产数据库的一个流行度排行，越靠前表明这种数据库越受到大众的关注，热度也越高。今天单说一说华为的GaussDB，其发展是否能在国产数据库中脱颖而出挑战Oracle在金融行业的霸权！
总所周知，金融行业对数据库的要求极为严苛，因为跟钱打交道，所以不能有一丝的马虎，这就要求所使用的数据库具备高稳定性、高可靠性、高并发性。当然这三项能力是最基本的能力。计算机的硬件、软件在运行中，很难做到不出问题，如果没有问题的出现，相信我们也不用较劲脑汁去设计和建设多活架构、灾备架构了，往往我们都会做最坏的打算，比如往大了说因不可抗力一个城市没了，往小了说一台服务器或一个软件故障了，这都会影响到企业应用对外提供连续性服务的能力，尤其是对客的业务上。
GaussDB的材料网上也有不少，并且其内核也开源了，想去深入了解并不难，难的是如何去了解其产品在客户的真正的实战案例，这方面的素材比较匮乏。因此需要一定的经历去搜集整理，如果有华为的朋友是不用太担心这个问题的，对于厂商的话，我们也要保着几分信的态度即可。
基本功能
先从基本功能说起，opengauss作为GaussDB的内核，其基于PostgreSQL 9.2.4版本演进而来，PG有着将近40年的发展历程，其稳定性已经在很多企业检验了，国内较少，国外使用是及其广泛的。因此opengauss并不是从0到1的发展，而是站在了巨人肩膀上发展起来的，这也就有了稳定性、可靠性、并发现的一个基本保证。从某些大型金融企业广泛PG，也能窥探到PG满足金融需求。
话又说回来基本功能也只是满足而已，论实例Oracle仍然天下无敌，这一点至少现今我们还是要正视的。
更高层次的能力
新能源都讲究弯道超车，那么我们国产数据库的思路也是如此，在单打独斗上现在确实技不如人，但如果是分布式呢？
数据库发展到今天这个地步，大部分国产数据库该有的功能都有了，那为什么还很难达到金融级别的要求呢？我想这个问题是值得去思考和努力的。当一个数据库已经具备了基本功能，再去发展，就要走向更精细化的能力上和场景上，这已经不单单是一项技术，而是一项工程，而这样的工程实践，势必要有场所来提供实践，20世纪数据库刚兴起时，是一个时代新鲜的产物，从无到有，能给企业带来的是利大于弊，会有更多的企业愿意加入试吃螃蟹，同时，大量的企业实践也为数据库厂家提供了大量工程实践的机会，就是这样不断的磨练，不断的迭代，才成就了这些最牛B的数据库。21世纪，我们要发展自己的数据库，已经没有这样的舒适的场景提供给我们了，再去走老牌数据库厂商的路已经不现实，贸易战确实是一个机遇，成了国产化的助推器，这也使得国内头部数据库公司在这期间不断突破发展。
GaussDB就是在分布式的能力上找到了突破口，其灵活的拓展能力，弥补了单机并发能力不足的问题，部署多中心多活更加贴切，金融业务多中心容灾指标RTO、RPO也能在性能损耗较小的代价下完成，这在几年前是不可想象的。而随着国内越来越多的金融业加入实践，势必也会让华为的Gauss数据库在工程实践上越发完善，这是一个良性的循环。
我们一直在说去"IOE"，而这其中最难去的非Oracle莫属，难点在于找不到一款可以和Oracle对等的产品。如果是一些小应用可能随便找一个基本能力完善的数据库都能搞得定，对于大型应用，高并发、高吞吐没有几个数据库可以应付过来，从另外一个角度来说，由于Oracle的能力实在出众，导致我们很多业务逻辑都是在数据库层面实现的，典型的就是重存储过程的场景，动辄几千万上亿的存储过程代码，改造难度想想都头皮发麻。
拆分来说，第一点，高并发、高吞吐，分布式架构是可以解决的，这也是GaussDB所主打的，这种解决方案，并不是直接原位替代，架构的变革，也无法满足原为替代即可实现，仍然需要进行业务的改造；第二点，重存储过程，只有两个选择，1，实现原位替代，2，业务重写，去存储过程。按代价来说1是最小代价。GaussDB在这方面做的也足够优秀，通过其UGO迁移工具，可以实现90%以上的Oracle存储过程自动改写为GaussDB的，剩下的一小部分难度也大大降低了。
再说一点，opengauss从PG演进而来，那么相对PG来说，是更好用的，我举两个例子：
例子一：存储引擎变化
存储引擎关乎数据的存取，在数据库界，存储引擎多版本并发控制（MVCC）有以下几种实现方式：
Tempspace Update，典型SQL Server的MVCC机制，把旧版本的数据写入专门的临时表空间，新数据写入日志，然后去更改数据
In-place Update，典型Oracle、MySQL的MVCC机制，把旧版本的数据写入到UNDO空间中，新数据写入到REDO日志，然后去更改数据
Append Only，典型PG的MVCC机制，新版数据和旧版数据都保留在表中，通过标记旧版数据不可见的方式，新数据写入到WAL日志，然后去更新数据。
早期opengauss是继承了PG的MVCC的，因此也难以避免这种机制所带来的弊端，也就是表的膨胀，由于多个版本的数据都存放在表中。当然opengauss在这方面也做了很多优化。而现在也在内核中新增了In-place Update的存储引擎，命名为ustore，也就是opengauss是具备多存储引擎的，可根据实际业务类型进行定制使用。
例子二：高可用的便捷
原生PG在做流复制时时必须借助第三方工具的，手工实现真的很难，要将从库提升为主库，并通过pg_rewind等工具来手工校验数据并建立主从关系，很容易要重新搭建。而opengauss将高可用能力写入了内核，这相当于原生具备高可用，不用借助第三方工具就能实现，在切换效率上、数据一致上都有了更高的保障。如果是使用云环境的GaussDB，都是界面化操作，带来的运维效果更是肉眼可见的。
分布式数据库的方向？
最后再说一下分布式数据库，无论国内还是国外，分布式数据库都在如火如荼的发展，我们可能还心存疑虑，到底最终分布式数据库会演进到何种地步？有人说NEWSQL，那什么才是真正的NEWSQL呢？是NOSQL+SQL么，并没有唯一的答案！
我也可以说GaussDB是NEWSQL，是一款成功的商用分布式数据库，但他并不符合NOSQL+SQL这样的技术架构。
未来的发展是业务精细化发展，场景也会越来越多，而数据库也做不到一招吃遍天下，只要选择最合适业务场景的数据库才是最佳方案。
HTAP这条路只是解决绝大部分场景的通用方案，但绝对不是一揽子承包方案。
