利诱聚小人，狸猫换太子
数月后，在一次数据库技术大会上，老朋友们又相聚了。
W：L兄，上次聊完后，我就对选型测评留了个心眼，果然发现有厂商在写入性能测评中做了关日志、删索引等操作。于是毫不犹豫地将他们拉进黑名单。L：干得漂亮！不过测评作弊的手段可是会不断升级哦，要擦亮眼睛。举一个近期的例子，某数据库厂商靠关系入围了，但是数据库产品的功能或性能不满足客户需求，之前说种种手段也无法奏效，你猜他们怎么办？W：不满足就等到能满足时再上，如果时间紧迫就只有放弃，还能咋样？L：正经厂商确实就是这么做，不过无良厂商可就不是这么想了，他们觉得一定不能错过这样的机会，就开始想办法了，比如发现别家数据库产品能符合客户需求，就拿来应对测评，通过了再用自家数据库产品来上线。Q：还有这种操作？测试和上线是不同的数据库，上线的数据库还不满足需求，能不出问题吗？L：这就是厂商的精明之处了，有不少项目尤其是新上线的场景，客户往往对运营的性能和功能给予过高的预测，实际情况可能并不高。即便最终会达到预期的高要求，也可能需要长时间推广才能做到，这样也有足够的缓冲时间应对。L：有利益分配自会有合作可能，甚至还出现拉拢厂商员工进行私下合作的情况......上演了狸猫换太子的套壳大戏。L：用别人的数据库冒充自家的，这和将开源数据库改Logo说是自家的有区别吗？
L：有一种VIE模式，把公司注册在海外，本质是一个空壳，而真正的业务和资产在国内，然后通过复杂的协议安排，将境内实体的利益"套"进这个"壳"里，就这样将风险留给国内，把收益留给了海外。W：哦，这也是套壳。这类企业的实际控制权是海外主导，如果是科技企业，其技术就很难为国家兜底吧。L：是的，比如提供数据库技术，在使用中就存在一定风险。L：我再举个例子，继续拓宽大家对套壳的认知。某厂商的数据库产品功能有缺失，于是厂商想了这样一个办法，去寻找能实现对应特定功能的免费开源插件、工具，再通过数据库的接口改造，将其缝合在一起来解决问题。怎么样，是不是又一个隐蔽的套壳？W：开眼界了，如此的数据库必然是粗糙松散，谁用谁惨！
L：更可气的是，当他们被抓现形后，居然说能解决问题就行，不必在意细节。L：数据库本质就是对数据的存、查、改，不过为了更好的存、查、改就会延伸非常多的功能。比如数据的加解密、权限管理、分片、分区、压缩、复杂分析、快速响应等等。此时正经厂商就是脚踏实地的去实现这些功能，而无良厂商就把目标放在寻找现成的东西拼凑在一起，来满足客户需求，这种套壳方式会让数据库的兼容性、可维护性都堪忧，带来极大风险。W：L兄，不管是直接的还是隐蔽的套壳方式，最终都要在生产系统真刀真枪的干，套壳者不担心吗，不会出大问题吗？L：W兄问到精髓了，其实套壳者并不太担心，不过一定会出大问题！L：我来说说其中的逻辑。套壳者不管是用什么忽悠手段，一旦数据库上线，客户就休想将其轻易撤换或者回退，因为变动的代价实在太大了。所以也只能容忍套壳厂商修修补补的解决方案，实在靠不住就在自己应用层想办法，让数据库少干活来减少风险。久而久之客户就慢慢将苦难变成习惯，甚至看成自己的岗位护城河。所以数据库套壳者基本不太担心。
L：嗯，顺着人性看，精彩又来了。话说数据库的客户当中，不乏大型央企和行业巨头，他们内部无论是O记替换还是新项目的数据库需求都很大，是各数据库厂商眼中的大金主。当这些大企业了解到数据库开源套壳乱象后，免不了打起小算盘。心想你不就是基于开源改一改，凭什么要让你割韭菜。我有钱有人懂业务，你能做我更能做。而且做成了可以节省采购经费；可以自主实现一些特殊功能；甚至还可以从自用转为他用，创造新的经济增长点；最最重要的是还能出政绩....于是，企业自研数据库登上舞台。M：啊，还有这层逻辑。大企业看不上套壳公司可以找原创数据库公司合作啊，我觉得术业有专攻，把有限的精力投入到主营业务才是正道。W：是啊！不过L兄刚才说的小算盘，听起来似乎也有点道理。L：那是他们想的太简单了，其实研发及实施需要大量投入，成本远超节省的采购经费；而自主可控也不容易，不以数据库为主营业务的企业，是难以提供打磨一流数据库的土壤；至于卖数据库就更难了，毕竟从满足内部需求出发的数据库，通用性的优先级并不高。最后说政绩，这和领导任期相关，实际很可能是一个大雷。
Q：太真实了，我就有过因领导离任而导致数据库项目最终打水漂的经历。L：此类企业自研数据库大多都是实现了一个调度分配的统一接口，将P记或者M记的开源数据库管理起来协同工作，以提供更好的性能和更高的并发，甚至可以说这只是一个数据库调度管理工具，而非数据库产品。
W：一针见血啊。不过他们敢用这种方式支撑各种核心业务，不担心吗？
L：和套壳数据库厂商一样，企业自研数据库团队也不担心。因为即便是一地鸡毛，他们也有解决方案。即通过舍弃，断臂求生。L：数据库好坏的评估有功能、安全、稳定、 性能、易用、生态、成本、服务等诸多方面。不过数据库安全、稳定对于核心系统来说是重中之重，这个必须保障。而数据库的响应速度往往直接决定项目成败，此外数据库竞品PK也主要看性能，毕竟功能看起来都差不多。至于易用、生态、成本、服务等都难以及时有效的验证，就先靠边。
L：是的，有此铺垫，接下来聊聊企业自研数据库的生存四部曲。先说第一曲——限制。要求所有访问必须通过界面或接口完成，禁止后台直连，同时设置访问权限、分配访问时段，并详细记录日志以便审计。W：要求这么苛刻！不过这一通操作下来，访问量会减少、峰值压力会被分摊、误操作也会被避免，这对提升数据库的稳定性和安全性很有帮助哦。
L：是的，接着是对SQL的限制，让SQL是通过界面操作自动生成，同时设有SQL审核，如此壳大幅规避低效SQL进数据库的风险。
W：厉害，大部分性能问题都和烂SQL相关，这操作对提升性能很有用！
L：还有对资源的限制，如规定了数据库所在主机资源不能超过30%，否则要限制访问或增加节点。如此数据库的稳定性就会得到进一步保障。L：是的，有得就有失。我再说第二曲——转移。即数据处理逻辑能转移到应用端就尽量转移出去，让数据库干的活越少越好。
W：明白了，不过压力从数据库侧转移出去，那应用侧压力不就大了吗？L：这要你自己品了。接下来是第三曲——扩容。即存储、内存、CPU、网络带宽等尽量高端，让服务器数量充裕.....
L：最后说第四曲——人海。大企业自研数据库诞生的主要目的就是替换O记，而这两种数据库理念相差巨大。O记是能在数据库完成的事就尽量在数据库完成，而自研数据库是能不在数据库内完成的事就尽量不在数据库完成，这种差异导致替换投入数百人年的惊人工作量；此外自研数据库的分布式节点众多，需要大量运维人员；再有非原生分布式架构难以有效应对分布式事务，需投入多方力量随时修复问题......W：人海战术啊。看这样四部曲下来，安全、稳定、性能看似有保障了，但是易用性差到极致，成本高到吓人，功能转嫁的干干净净....
L：是的，被迫如此折腾的根本原因在于缺乏数据库内核掌控能力，不得不采取曲线救国方式绕开技术解决问题。试想每个头部企业都怀着这样的小心思入局，那原创厂商的生存空间就会受到严重挤压，是不是最终形成多输的局面。Q：确实是多输！不过，话说深入数据库内核有那么难吗？
L：是的，目前主流的开源数据库无论是P记还是M记，代码主要贡献者都鲜有中国人，这意味着什么？
W：我也听说了咱们主要在内核之外的周边，有一些代码提交，这从侧面说明国内基于开源的数据库厂商在内核自主研发方面，基础是很薄弱的！L：是的，不过也并非中国人不愿意或没能力贡献，而是我们基于内核的代码提交难以被采纳。原因不展开，从P记管理团队罕见中国人这点或许能察觉一二。
W：我觉得，基于开源改造的数据库厂商上手容易深入难，走的是一条先甜后苦的路，而原创的数据库厂商上手困难深入易，走的是一条先苦后甜的路。
L：W兄，你这句总结得精彩啊！我这里补充一下，其实走先甜后苦路的厂商往往都是大型企业、互联网巨头等，他们根本不担心自研数据库坐冷板凳，因为仅靠内部消化，市场就大的惊人。他们要的是速度，先整出产品占到坑位再说，后续再优化，反正结合自家业务有的是办法，所以开源数据库就是他们的不二选择。其实用开源数据库最大的问题还不在于受限于他人框架而技术难革新，而是有更可怕的后果。L：数据库的内核是别人的，你只做数据库的周边及业务改造，要是人家在内核里嵌入别有用心的后门代码，或击毁数据库，或盗取数据，后果不堪设想！
M：L兄说的是，某家基于P记的数据库厂商大干数百天，将P记内核升级到新版本后，性能和稳定性都大幅提升，在PK中击败了未升级内核的同类厂商。L：这个案例很典型，平时少动内核多动周边，等着社区新版本稳定后直接拿来主义，居然取得了不错的效果。如果大家都效仿这种方式，把命运掌握在别人手中，且不说触雷风险，这样未来还有希望吗？
W：确实如此！
L：此外，基于开源自研的数据库除了内核难把控外，还存在知识产权的法律风险，比如基于M记开源数据库的国产数据库，需要遵循很多严格的协议，比如需要开源回馈社区，可现实中许多基于M记开源数据库的厂商并未这么做，这就是把客户往火坑里推。L：这又是体现人性的一面。数据库厂商明明是基于开源数据库修改的，对外却说明自己是自研的，甚至还有某基于开源数据库的厂商对外宣传代码自研率为百分百，成为数据库圈内经久不衰的笑料。W：这还遮遮掩掩，也难怪不遵守协议了，这该死的虚荣心啊。L：也不全是虚荣心作祟，说自己自研更有机会取得客户的信任，更有机会卖个好价钱，更有机会获奖......这里是有商业利益的，也产生了不少黑操作。不过也并非每家厂商都是只索取不回报的，也有大大方方承认自己就是基于M记开源数据库改造的，并遵守协议将其开源的厂商，他们这样做至少消除了知识产权法律风险，还是值得肯定的。
L：当然了，我刚说的基于M记开源数据库却未遵守协议的厂商，已经在金融领域落地了不少关键项目，知识产权的法律风险大概率在某天爆发，非常危险！
L：你忘了，之前不是说过大型央企和行业巨头自己搞个套壳数据库都撑住了自家业务。那厂商支撑金融领域的关键业务有何不行？思路其实大同小异，都是技术不行就在业务层面走曲线救国路线呗。和不掌握内核能力的套壳厂商合作还有被绑架风险，因为此类厂商为适应业务可能会展开一波非内核层面的魔改，但是无法标准化和通用化，有的还会让你绑定一些特定硬件，至此将数据库整成了一个四不像，等客户忍无可忍要将其替换时，发现几乎是不可能完成的任务，被坑惨了！Q：啊，如此看来如果都是套壳，真还不如自己套壳靠谱，好歹不会被绑架。
L：你说的是，不过我还是旗帜鲜明的反对企业自己下场做套壳数据库。当然，如果有企业能在主营业务外做出一款世界级的原创数据库产品，那也是好事。L：有差距没关系，努力追赶总能看到希望。可让人揪心的是，别人的技术在持续进步，而我们却在加速倒退，这导致数据库技术代差被越拉越大。不止是数据库，其实各种技术都有存在相同的问题，这些年卡脖子的新闻听得还少吗？Q：确实不少。芯片、GPU、工业软件、AI....L：最近这十多年，咱们国家各行各业发展出现了欣欣向荣的景象，很多进步比如越来越便捷的衣食出行等，都是老百姓实实在在能感受到的，不过误打误撞，业务繁荣的背后却带来了技术的倒退。因为业务发展太快了，技术跟不上业务发展，而等技术的进步就会错失市场机会，因此我们除了没耐心来研究技术外，其他的一切手段都用上了，如能投入人力就尽量投入、能改造业务也就就尽量改造、能购买现成产品就购买、能抄开源就抄.....总之就是要快，资本就是如此引导是市场的，就这样在急功近利中，我们一点点丧失了核心竞争力，包括数据库。
Q：L兄说的太深刻了，受教了！对了，我觉得开源就是海外科技巨头挥向我们的武器，让大家免费使用并对其产生依赖，以消磨我们锐意进取的决心，进而拉大了和他们商用产品之间的差距，为后续的各种卡脖子铺路。W：L兄，数据库具体是如何一步一步丧失核心竞争力呢？L：比如用堆砌机器暂缓解性能问题，而这本可以通过优化器和存储引擎的优化解决的，可惜就这样错过了；比如投入大量人力去改造业务，而这本可以在数据库中融入AI能力来解决问题，可惜就这样错过了.....Q：L兄，数据库不进步可以理解，你刚说的加速倒退，这我就不明白了？L：本该在数据库内核、算法层面实现的关键技术没耐心去好好实现，反而不适合在数据库实现的功浅层需求，却通过堆砌的方式在非内核层面实现了，这导致数据库变的不再标准、不再通用、性能受到影响、稳定性下降......请问这算不算倒退？再有这种急功近利挤兑了市场，使掌握核心技术的原创数据库厂商没了生存空间，请问这算不算倒退？L：国家已经注意到这个问题，倡导不要只聚焦于业务繁荣，而是要注重发展新质生产力，宣扬科学家精神，不追求短期效果，将目光放长远。这种思想具体落到数据库层面，就是鼓励原创数据库，消除知识产权法律风险、杜绝后门风险，提升技术，为企业和国家兜底。W：希望原创的数据库能得到更多的支持和更好的发展，消灭套壳，不断提升我们的自主可控能力。
L：这里说明一下，基于开源数据库的厂商也不见得都是套壳。有基于开源P记数据库的厂商尝试对P记进行内核改造，比如将多进程模式改为多线程，将MVCC改为UNDO模式等。L：其实不同架构本来就各有利弊，其主要意义可能并不在于创新本身，而是打响了掌控开源内核的第一枪，迈出与P记分道扬镳的第一步。L：是的，希望他们以此为基础，一步一步能最终走向完全自主原创。否则在人家设定的技术框架中，不仅技术上的革新会受限，安全保障上也可能面临挑战。相比之下，最为彻底的是一开始就选择原创之路的数据库厂商，他们选择了最艰辛的路，坚持做难而正确的事，不以眼前利益为目标，以情怀、信念为支撑，在不被人理解中、在嘲笑声中、在压力下奋力拼搏，负重前行。国家需要原创数据库，有原创才有未来！不管他们未来发展如何，都必将名垂青史！
梁敬彬约 13 分钟