现在谈数据库，不能不谈分布式，否则大家会感觉你很Low。现在好像出门说自己之前是搞Oracle的，甚至都有一种丢脸的感觉，对于数据库技能而言，现在不掌握3～5种数据库，都开不了口。
各个数据库厂家都有自己的话术进行产品的宣传，我的tpcc多少，tpch性能如何，又是如何应用无感弹性扩容等等。那么我们的国产数据库是不是各方面都远远超越国外商业数据库了呢？是不是真的遥遥领先了。
Oracle真的不行了吗？Are you sure？
实际上Oracle数据库的功能很多，各方面都非常的强大，最近发布的Oracle 23c beta版本又引入了大量创新且实用的功能，这里我举个简单的例子,新引入的sql_transpiler功能：
对于这种带函数的操作，在之前的版本中简直的深恶痛绝，现在完全不必担心了。真正做到了，再烂的业务SQL，都能让你跑的快。
再比如引入的另外一个有意思的特性True Cache，看上去也是非常的不错，虽然还没测试过。官方的标准解释是这样的：
Oracle True Cache is a read-only, in-memory, high performance SQL and key-value cache that is automatically managed and consistent.
Oracle True Cache improves application response time while reducing the load on the database server.
Automatic management and consistency simplify application development—reducing developer effort and cost.
这里引入一张官方的架构图：
从架构图来看，大致上就基于主库维持一个只读副本的true cache实例，直接提供给应用访问，难道要把Redis都给替代了吗？从架构来看，我认为不是替代redis的场景，应该是去解决传统adg 读写分离场景下的延迟问题。当然，至于说 这个新特性有没有什么坑，我想一定是有的。不过国内我想以后应该大概率，不一定能见到有生产环境能跑Oracle 23c吧。
说这么多，我这里想表达的是Oracle仍然在不断前进，不断创新，仍然是值得我们国产数据库厂商学习的榜样。
系统数据量太大，只能选择分布式？
实际上这个也是很多分布式厂商天天忽悠的一个主要论点。集中式数据库无法弹性扩展，无法承载几十TB甚至更大体量的数据库。这里我要说明一点的是，这个观点是大错特错的！之前某MySQL大牛就不断抨击o和pg。我想他大概是没有见过单库超过200TB的环境吧。这里我给大家看一个某客户生产环境的实际例子：
就是如上一个架构的系统，使用我司分布式存储解决方案(zData),没有进行太多调优的情况之下，可以跑接近1726万tpmC：
这里我并非是要炫耀这个压测数据，这没有什么意义。主要是想表达一点：利用分布式解决方案，可以更好地使用传统数据库，同时去承载巨大的业务洪峰。上图这个架构图的用户的数据库(单库)已经超过150TB了。
说到这里，有人会说，你这是用的Oracle RAC集群，如果是传统的主备数据库肯定扛不住呀，还是要分布式才行。。。当然，Oracle很强悍，很多国产数据库还远远达不到Oracle这样的能力；但是我们不要忘了，这些年的硬件发展速度，发展速度实在太快，我们完全是可以利用硬件能力来弥补数据库自身能力的不足的。
你说让某梦数据库去跑一个10TB的单库，可能会有压力，但是如果使用一体机的形式，我想就不一定了。同样的道理，我们之前迁移测试某客户一套30多TB的Oracle到MogDB上，发现也就那么回事儿（单机环境）。
话又说回来，又有多少客户的系统单库有10TB+呢？我们曾经帮助过很多客户做过大量数据库迁移，我们发现实际上用户数十套系统中，真正超过10TB的可能就几套，绝大部分都是几百GB，甚至几个GB。举个真实的例子，前段时间我去调研某医院的系统，一共大概10来套，最大最核心的3套库加起来都不到3Tb。所以我说，99%的系统无需分布式，真的无需分布式！
运维、开发成本太高
今天在一个微信群聊天发现，一朋友发了一个非常烂的应用SQL，然后大家突然有感而发，开始活跃起来了。大家都在想，这开发人员或许真的只知道功能，不会注重效率，或者他们根本不懂数据库，不懂开发规范，不懂索引。
然后我提到，我之前参与到一个项目，把客户数据库从Oracle exadata迁移到了我司zData上，然后我们监控发现部分业务SQL效率很差（这实际上在预料之中)；然后我们在上面创建了数千个Index，最后应用跑的飞快，CPU使用率很快就降低到10%左右了。因为这部分应用之前都在Exadata上运行，客户无感知，因为exadata有Smart scan等功能，任你再烂的SQL似乎都能跑，而且效率还不错。对于类似这样不太好的应用，我有时候在想，连Oracle都用不好，那么你能指望他用好OceanBase、TDSQL、GoldenDB？
至于运维成本就不讲了，懂的都懂。开源国产数据库在可观测性方面还差距较大，需要一段时间的积累，这势必让DBA们排查问题更困难。另外由于文档较少，很多问题，原厂售后根本就hold不住，只能反馈给研发。如果连我们数据库厂商原厂都觉得吃力，我们还能指望客户能运维的更好？从我们的客户群体来看,IT能力强的也就是运营商、银行、券商等，他们有专职DBA(数量也就1-5个不等),很多客户甚至没有专职DBA，用户一人都是身兼数职。我们可以想象，让他们去运维分布式数据库，难度会有多大？此时此刻，脑补一下TDSQL 、GoldenDB复杂的架构......
那么分布式数据库一定是未来吗？
之前也有不少同事经常问我，未来怎么走，选择什么方向。在我们内部的技术体系中，通常大家达到P4-P5就会到达一个技术瓶颈。外面选择很多，尤其是现在百花齐放的时代，让人眼花缭乱。大家都知道CAP理论，几乎没有哪个数据库能逃离CAP魔咒。今天就有人在群里说，某分布式数据库宣称突破CAP，那么事实真是如此吗？我们知道CAP分别代表：一致性、可用性、分区容错性。比如Oceanbase，那么我认为它仅仅是实现了AP+C(最终一致性).
要说分布式是不是未来，我也无法回答。不过从近10年的发展来看，似乎数据库理论的发展要远远落后于硬件的提升。最初引入分布式主要是为了解决单点Scale Up的问题，现在用户的服务器随便一台x86就是4路24线程，不管业务量大小与否，直接就是几块7.68TB SSD堆上去。这性能真的很强了。今天跟某用户聊天，我说你们这存储节点配置太高了，2路24线程，内存512g...我完全无话可说。
有时候我也在想，或许哪天量子服务器面世界了，一台服务器就可以实现现在1万台服务的运算能力，你还需分布式？
没有谁可以预测未来，不管是分布式还是国产其他数据库。我还是非常看好的。总之，对于DBA来讲，之前维护MySQL，以后维护OceanBase，维护达梦，有什么区别吗？身边不少同事之前做Oracle，以后无缝切换到MogDB运维，这不都一样吗？大家的薪资不会变，该加班还是要加班。
各种数据库的替换，最终还拉动了GDP，我看挺好！
专注数据库诊断优化、架构设计、数据恢复！加微信请扫码！
