这个故事得从这个招聘说起
先说明我倒不是 PR 你们赶紧投一投这个岗位，人(bu)少钱(bu)多速(bie)来，在我看来这个岗位就是个深坑，深不见底。这也是大师兄和他的空降们拍脑子下又一个失败的项目，当然了看猴戏看了 2 年，也不奇怪这项目怎么做着做着就要招负责人了。
先说下这个项目背景，大体上是 2021 克劳德空降后要求 CC/RedisKV 团队满足介于离线和在线中间，实现一套有一定持久化能力并且满足高性能的 KKV 存储系统。其实对当时的我们来说，讲实话很鸡肋的。于是在招了一位阿里存储方面 P9 在深圳之后，这个项目就顺理成章「移交」到了这位大佬手中，这便是 mmdb 的开始。就我所知的来说，因为这位大佬和我的一个洗脚好基友比较熟，就选用了好基友出去创业搞的 NebulaGraph 作为底层存储。mmdb 本质就是对 NebulaGraph 封装了一层「兼容各协议」的 Proxy，美名其曰大一统通用存储。
我倒是不是说这个 P9 菜，只不过做这一系列决策的大师兄，在当时来说确实没人看得懂他的骚操作，我和这位 P9 也聊过，人家觉得也挺…鸡肋的。不过熬到现在才跑，也…挺抖的讲实话。
在这之后的故事简略的来说就是无形的大手叫停了当时我们已经初具规模验证过的 RedisKV，排挤走了负责人。再后来这无形的大手一巴掌又拍死 CC 之后甚至传出缓存也要并入 mmdb 之中，不过那时候我已经颐养天年，两耳不闻窗外事了。
那么回到为什么我断言这个项目一定会死，这里说说我对存储系统的理解吧。首先咱们不要考虑强一致还是最终一致，这都不重要，本质上分布式存储看的是最终业务，就两种离线和在线。
讨论在线的话很简单，Redis 几乎统一了 KV/NoSQL 这个方向所有在线系统，你可以列举 memcache 或者其他，但没有一个能撼动 Redis 的地位。这个地位的表现就是，不管是谁搞了个「增强」的 KV/NoSQL 大体上总会补上一句 Redis Protocol Compatible。因此你做 mmdb 先不管你要不要搞自己协议，你一个 Compatible 就必然打不过 Native，更何况一开始 mmdb 就决定自己搞一套协议，自己搞 SDK自己搞框架然后在全司推开。从底层实现来说，NebulaGraph 我记得也是基于 Raft 的玩意，你性能上也跑不过 Redis。现在你是客户，无形的大手一巴掌呼过来跟你说，你来用咱们这个新系统，来来来把这个我们写的客户端集成下，哦对了数据 migrate 得麻烦你自己写下，性能嘛差点就差点了，但咱们持久化啊。你作为技术负责人，又只拿了 0.5 个月年终奖，会不会很抵触？
至于持久化，本身我们当时就基于原生 Redis 实现了 Rediskv，上层网络层协议层完全就是 Redis 的逻辑，甚至过了 3 年后 Redis 官方商业版也走上了我们当年这条路，客户完全一行代码不改既能享受持久化，又享有高性能分级缓存，mmdb 拿头来碰瓷啊，所以只能……含泪先把 rediskv 项目砍了咯。
而离线就更简单了，纵观大数据历史，无外乎就是传统 Hadoop 玩法，是现在讲究实时性更高的 OLAP 玩法，或者混点 OLTP 直接从源头到决策一条龙解决方案，但是，这些和你 KKV 有啥必然的关系？mmdb 从设计之初最根本的需求来源就是 KKV，只不过是数据分析中一个小得不能再小的数据结构需求罢了。是，传统的离线存储分析实时性差了点，但社区也好商业上也好大把可以选的玩意。至于因为我要吃个饼，想把白芝麻换成黑芝麻，就先去种个芝麻树吗？这种树的钱还老贵了，先不说人力成本当时我知道的都是数百万记，你搞个存储没三五年能行？人人都是头条 adb 啊，再说了人家 adb 之父小锁什么水平，你这还得靠 NebulaGraph 的什么水平，大师兄心里没个 AC 数么？
我要单纯存日志，前有 mfs ceph，花钱还有 juicefs 这类的，挂个 posix 就完事了。我要搞日志检索挂个 es，嫌弃慢换当时已有的 tidb 基础设施又不是不能用（大师兄大手一挥，砍了）。我要搞分析…等等，分析这事也轮不到 mmdb 来决定用什么姿势吧？
所以这项目能立起来就离谱，离谱到只要脑子正常就会觉得肯定不会成功，ROI 不是低，是负分，滚粗的那种。当然了，在大师兄亲自指挥亲自部署虾皮基建的那个年代，一切皆有可能咯，然后你心里就会想，大师兄得道升天，为什么 MIT 的高材生，为什么 Google L6，心里也一点 AC 数都没有。我想这就是菜吧…