一觉醒来,就发现有人给我微信上发消息,通知我说数据库创业圈子里,又出来一件牛逼大了的事情。
我一看,原来是PingCAP放大招了,PingCAP在美国加州硅谷从甲骨文公司挖了Sunny Bains入职。
这位Sunny Bains的背景,大体上就是在印度上完了中学,在澳大利亚墨尔本上完了本科,然后在澳洲的CTI工作了一段时间,之后就来到美国的甲骨文公司了。
他在甲骨文公司从2006年一直干到现在,最近加盟PingCAP。之前在甲骨文负责的就是InnoDB。坦白讲,我对这位Sunny Bains大神不熟。恕我孤陋寡闻了。
InnoDB是MySQL的一个存储引擎,最初由在芬兰赫尔辛基的Innobase公司开发。该公司2005年被Oracle给买了。MySQL被Sun公司买了之后,2009年Oracle公司又收购了Sun,最终InnoDB和MySQL又合并在了一起。
PingCAP公司是国内TiDB的数据库初创公司。无论是在资本市场,还是在数据库的初创市场上,都是当之无愧的国内当红炸子鸡。公司融资无数,既不缺钱,也不缺人。
根据该公司说法,TiDB是该公司研发的兼容MySQL的,按照谷歌Spanner的论文研发的新一代分布式数据库,自称NewSQL。下面的存储是通过Key-Value Store TiKV实现的。
有关TiKV是如何本地通过RocksDB实现存储,如何实现MVCC,以及如何通过Raft协议进行多拷贝一致性同步等等,TiDB出了很多文章了。大家有兴趣的可以自己去读一下。我就不赘述了。
但是我若干年前读TiDB这方面文章的时候,对其中的一个东西完全无法理解。这里主要讲讲这个东西。TiKV在本地用RocksDB来存储数据的时候,采用了一种和BigTable非常类似的编码方式。
简单来说,就是不管数据类型是什么,所有的实际的列值都会被组合编码成为STRING类型,而Key则由表的id和行的id的组合字符串构成。当然,还可以针对一个表做二级索引,但是还是离不开对一堆STRING的访问。
这样子一来,一个单机节点上存储的数据,在实际计算的时候,需要从STRING转换成为实际的类型,这种编码方式,其成本是很大的。

当然,并不是只有TiKV这样做,苹果的开源系统Foundation DB也差不多是底层用KV来存数据。
只不过很有意思的是,没有人真的拿Foundation DB去存实际的数据,通常大家都是用Foundation DB存元数据。因为对元数据的访问来说,这种KV的方式配合上层灵活的数据模型,有天然的优势。比如Snowflake的元数据就是这样存的。
这种天然的优势,如果存的是数据,而不是元数据,那就意味着有无数条记录要被访问,被解码。我大概是脑袋被驴踢过,智商受损了,实在无法理解一个先进的NewSQL里会有这种实现。
我想,但凡有点DB经验的开发者,都会抵制这种存储选择。当时我想,也许这群人,都是野路子出身,根本不懂数据库?可是也不对啊,人家都是做NewSQL,buff拉满的那种。所以也只可能我自己脑袋被驴踢过,我才是那个那个毫无开发经验的人,所以才完全不能理解对方英明神武的选择。
PingCAP这次挖了一个数据库存储引擎的大拿过来,大概率是要好好的重新写一写这个基于TiKV的底层存储了。不知道新写出来的东西,是不是能让我这个毫无开发经验的人也能看明白呢?所以还是要衷心祝愿PingCAP在挖来的老印牛人Sunny Bains的带领下,好好做个存储层。
继续阅读
阅读原文