无生有，莫强求，方便法门鬼见愁
旁人以为稀罕物，左道旁门不入流
这是黑神话悟空第二章里，无头的灵吉菩萨唱给天命人听的。之所以用这两句开篇，起因是因为和一个国产数据库同行聊到他们之前一个项目，引发了我的一些思考。
方便法门
佛教里有个概念叫方便法门，意思是在修行的过程中，灵活处置，旨在让众生更好地修行理解佛法。
朋友公司做的国产数据库迁移项目，是把他们自己的产品拿去替换Exadata。你没看错，Exadata。我相信所有用过Exadata的朋友，都知道这东西有多恐怖，不仅仅是价格上的恐怖，还有能够通吃各种业务场景的恐怖性能。迄今为止我仍然找不到哪个产品能有它的极限性能。用实力诠释了什么叫做一分钱一分货。朋友公司做的是国产数据库，也是国内各种号称HTAP数据库中的一员。然而在做POC测试的时候，诸多问题就都出来了。
第一个问题，存储过程无解。很多基于Oracle开发的系统，往往都用了存储过程。然而目前为止，国产数据库的存储过程性能，都距离Oracle差距不小。这一点上，他们只能尝试用各种UDF或者其他方式来解决业务逻辑的问题。然而仍然不理想。
第二个问题，ADG同步无解。两地三中心，要求秒级别的数据同步。他们产品虽然号称是分布式，但是并不具备跨不同地域数据中心的能力。所有的节点必须在一个内网里。跨服务器，只能用其他办法来实现。一定程度上还要用第三方工具来实现自己产品的数据同步。
第三个问题，监控无解。Oracle自带的OEM还有市面上各种成熟的监控工具对Oracle的解决方案，都已经很完备。然而新数据库在这方面是个很大短板。客户希望监控到的一些重要项都很难做到，只能通过其他方式来尽可能覆盖，但是精准度还是差了一截。
和他聊起这个项目的过程中，我已经感觉到，他们团队以己经尽可能在用各种办法，去替换去兼容Oracle的各个场景了，有些地方甚至已经超过了之前承诺的产品范围。但是仍然有大量无法满足的需求，而且这三个问题都是刚需，涉及到性能、高可用、监控，哪一样都是要命的东西。
聊到这里，我就不禁劝他，你们产品的成熟程度比起Exadata差太多了，很可能投入到最后结论还是不行，最后项目黄了，人力物力都打水漂，有些项目没这个能力就别强求了，你拿双截棍打装甲车，难度太大。
他苦笑着说，不行啊，这是老板亲自谈下来的项目，要求必须拿下。
旁门左道
聊天的后半段，我们就不再单纯关注这个项目，而是怎么拿到的这个项目。
首先就是，从开发阶段开始，项目团队重点放在了各种Benchmark上，例如TPCH、SSB、Sysbench。然后再找一些市面上主流的产品做对比，多少有点拿手机跑分的玩法。这一套20年前在游戏主机上很常见，每秒多少个多边形。而我们都知道，实际业务中遇到的业务，远远要比这些Benchmark复杂几十上百倍。这些跑分仅仅具有参考价值，并不具备实际指导意义。
然后就是，老板和客户谈的时候，提前画饼了。客户说，我们要兼容Oracle的xxx功能，xxx特性。老板说，我们正在开发，开发完就在你这上。客户那边问，功能是可以上生产的水平吗？老板一口答应下来。前方gogogo，研发nonono。饼是画了，但是这个功能开发难度远远高于预期，而且会严重影响原有的开发计划，很多东西仓促上阵，稳定性和健壮性都差出好几个MySQL。
之所以非要强行去做这个客户的需求，是老板觉得，自己产品需要一个传统行业来背书，证明自己产品能力。说起来也挺搞笑，很多数据库公司一方面总是贬低传统行业的数据库，另一方面还需要他们来提升自己的品牌印象。但是却没想过，传统行业用数据库的年头都不短，很多东西已经形成了行业规范。这些行业规范的壁垒之高，有时候难以想象。这些东西牵一发而动全身，不会为了某个新生的国产数据库妥协，而是要数据库厂商你去适应他们。而这些实打实的东西，不是靠跑分画饼能解决的。在产品能力面前，都是旁门左道。不能解决实际问题，反而会在真实的业务场景面前现出原形。
如同黄风怪，砍下灵吉菩萨的头来炼化大圣根器，不得其法，反而成了投机取巧的方式。在真实的实力面前，立刻就现了原形。外行眼里，TPCH跑分高，什么什么东西很快就能做出来。在资深的数据库从业者面前，都是不入流的东西。
求而不得
这一切的背后，折射的都是四个字：求而不得。
很多初创的数据库品牌，总希望开局就能获得很多客户，忽略了数据库开发需要深厚积累的的客观事实。最后陷入求而不得的怪圈。曾经踌躇满志的黄风大圣，最终黑化成为黄风怪。耳听怒，听到的都是别人吃肉，自己怎么苦苦不得解脱？
小猴子，你听那风里，都是求而不得声音。
