点“飞总聊IT”关注，星标
后台回复“666”领资料
作为一个一直在数据库周边打酱油，又没做出什么见得人成绩的伪数据库工作者，每次轮到我写数据库大数据相关的技术文章，或者不说技术，就说科普文章的时候，一个头疼的问题就是我的受众里，懂的人往往会觉得我说的忒简单，而不懂的人又会跳出来，给我留下不知道怎么回应的留言
昨天这篇Oracle的文章Oracle在找死？No Zuo No Die ！有人留言表示TiDB也有同样的梦想。TiDB这个东西诞生到现在也有5年时间了，可能还不止。5年时间可以发生很多事情。譬如说，TiDB终于要发布4.0版本了。
要说对TiDB的技术有多了解，我也真的谈不上多了解。比如说TiDB是不是有大一统的想法，我也不知道。我知道的是，TiDB宣传的理念是用户不用太关心自己的查询到底是OLTP还是OLAP。只要在TiDB上能跑起来，都高效率执行就好。
当然，TiDB的整个架构还是蛮复杂的，从最初的要做开源版的Spanner到现在要成为real-time的HTAP的口号也算是改了很久。
TiDB在今年VLDB发了一篇论文，重点介绍其系统。该论文还没有发表出来，但是知乎上有一个TiDB自家人的解读版本。对我来说，这种论文的事情，还是要自己去读几遍，理解一下才能有自己的判断。
这并不是说我自己对自己蜜汁自信，只相信自己的判断。而是论文这个东西，它有其特殊的解读方式。沈向洋大大今年上半年的一个全球直播里面讲怎么去读论文，是一个很值得每个人都去听听的讲话，泄露天机啊。
一般来说，论文里会展现一个事物最美好的一面，说谎是不会说的，但是不好的你也需要自己去字里行间解读，而那些尝试了却失败了的想法，有可能非常的有价值，但是只有同样工作于这一个领域耕耘多年的人，才能从字里行间心有戚戚然了。
TiDB最初是个在KV store上构建出来的“new SQL”，该团队早年有一系列解读自己架构的公众号文章，有兴趣的都可以去读读。后来的发展是引入了列存的TiFlash，魔改Clickhouse的OLAP引擎，之后又对优化器做了改动。论文里应该会有详细的解释，我看了它们自己家出品的对自己论文的解读，但没看到论文的全文。
谷歌的Spanner上云以后卖的并不好。原因很多，成本高是一方面，事务处理的延时高也是一方面。总之这个大杀器，一会GPS一会原子钟的，其实并没有得到什么实际的好处。
亚马逊的Aurora倒是用了非常经典的单点写入方式。但是这也导致了其事务处理性能的瓶颈。而Aurora的多master测试了很久也没最终发布出来。TiDB据说表现在多点写入上性能和扩展都不错。
但是吧，对于HTAP这个东西，我始终都是有一些怀疑态度的。我并不怀疑在一个事务处理的数据库系统中引入冗余的列存方式，从而提高分析查询的性能这个想法。我持怀疑态度的，还是在一个高并发高流量的环境下，进行AP查询的必要性和可靠性。

所以HTAP到底是TP为主导，还是AP为主导，是让TP更好的支持AP，还是在AP的系统上带点TP，一直争议很大。如果一定要硬凹的话，我觉得Oracle就是一个非常非常好的HTAP系统，它家的TP是不用说了，AP也很强。
所以需要HTAP的时候，多半就是在TP环境下提供一些AP查询的便利，我是深深的怀疑HTAP可以直接把数仓给干掉。因为一个真正有意义的AP系统的话，往往需要从很多数据源进行数据清理，最后才能够让垃圾raw data变成为有价值的数据。而这一系列的东西，其实和TP系统关系不大，最好还是专业的人来做专业的事情。

换个说法，我觉得new SQL就是个炒的概念，HTAP又是另外一个炒作的概念。而喜欢把概念一个接一个炒起来的公司，不一定技术方面没独到的地方，事实上通过在Raft层进行列存和行存之间的数据复制，而非在上层通过binlog来进行，这看起来很惊艳。如果你不知道我上面写的是什么可以略过。但是对炒概念起劲的公司的文宣，保持一点警惕的态度，学会辨别什么是实情，什么是套路，没什么坏处。不要一被概念套路了，就觉得万事大吉今晚吃鸡了。
欢迎加飞总微信号
历史推荐
Oracle在找死？No Zuo No Die ！
苹果的2020:Tim Cook的野望
烂泥为什么扶不上墙
长文：Cloudera难卖身！回顾Hadoop黑历史！
飞总聊IT每天给大家提供互联网的干货。识别下面二维码关注，粉丝可以发送“666”到后台领取一份学习资料。
继续阅读
阅读原文
关键词
数据库
系统
还是
列存
论文