TiDB学习之路

【是否原创】是
【首发渠道】TiDB 社区
【首发渠道链接】其他平台首发请附上对应链接
【正文】

首先分库分表不是一个最优的解决方案。做过数据库的朋友应该知道关系型数据库有ACID的四大要素。其中一致性,尤其是强一致性是和NoSQL的区别之一。我们通常说一个计算机如何厉害,会说这是军用级别,因为要求高。而数据库最高的级别不是军事级别,而是金融级别。金融级别对一致性的要求可以说是苛刻的。通常关系型数据库在单机或者集群下比如Oracle的RAC就是强一致性的。因为在一个数据库或者集群下是数据库利用事务来保证一致性的。而多个独立的数据库(分库)是无法保障的。

我们举例而说:有的系统原来是一个Oracle库,运行稳定。随着微服务和中台概念出现,采用了将数据库分成几十个数据库来建设。比如会员、订单、合同、结算、资金等等。

分库的痛点:

当订单发生改变的条件下,单机和分库的处理差别是这样的(订单变了和订单强依赖的一系列必然会发生连锁变化,是非常合理的):

在原始Oracle中,在一个事务中订单表发起变更,同步更新了合同表、资金表和会员表最终的余额。如果遇到超时或者锁定异常则回退,重新再次执行。

在分库的系统中,需要更新订单数据库,合同数据库、资金数据库和会员数据库。如果采用同步方案系,统之间的调用时间不可控制,效率低下。如果采用异步的方案,每个数据库独立工作,一旦一个没有写成功,那么整个环节和流程上都存在了不一致的问题。以哪个为准?

分表的痛点:

无论用什么维度对表进行切分,那么意味着如果不按照这个维度查询,那么必然要遍历所有表才能得到结果。比如一般按照userid进行分表,查询一个userid的所有订单,是没有问题的。
image
但是如果查询当天所有数据库的订单,要遍历所有数据库去查。
image
不仅如此,数据还涉及到合并和排序(数据合并好理解,为什么要排序?)
image
image
那是因为一般用户都是希望拿到的数据是有序的,即使数据库不自带,也要考虑到应用开发的SQL会带Order by的输入。
image
这里就引申出另外一个问题,分库分表是不是分布式数据库?答案是否定的。只有支持分布式事务才是分布式数据库。

TiDB设计之处就秉承了云原生的分布式数据库。TiDB是一个不需要分库分表的MySQL。而云原生是说产品是依托于云可以发挥出弹性优势,为了云而设计的,在云的场景下发挥的最好。

在学习TiDB的过程,其实可以发现一个不用分库分表的数据库才是解决问题的根本。因为当分库分表以后带来的问题非常大,大到我不愿意去分甚至宁可不分。在亿级别的数据库场景下,B-tree的层级最多也就3-4层。即使冷数据4次IO也可以找到数据,无需分库分表完成。所以没有分库分表的分布式数据库才是解决问题的王道。
OLAP 的痛点

什么是分析?用简练的话来说就是对少量列的聚合。如果说在数据库里面有几条数据,请问你觉得应该是下面这种形式存储的吗?一行从A到J是一条数据,一共13行。而我们只要统计蓝色的C列。
image
图1

还是像下图一样的存储?一种颜色代表一行,收尾相连的存储?
image
图2

以上两个图都是用excel表达。可能大多数人一开始都觉得是第一个excel。因为她就是一个excel。但是实际上看过图2的人基本会否定图1.图2才是数据库真实存储的样子。所以即使统计C的sum,也要把各个颜色(每条记录)遍历一下才能得到结果。所以列越长,行越多的表统计分析就越慢。而我们熟悉的excel是在内存中进行列的统计,而且数据量不大才显得快。

关系型数据库是行存的,而分析系统是列存比较有优势。怎么才能做到HATP既能满足交易又能满足分析。答案只有一个就是行列混存。

Oracle采用了磁盘行存,内存列存的方式解决。而TiKV是行存,TiFLash列存。
image
虽然做的方式方法不一样,但是原理大致一样。在MySQL的HeatWave也是类似的实现原理。
image
这张图引用黄东旭老师一次分享的图片。
当你真的做过把Oracle和MySQL的数据往CDH中送的项目就知道,坑实在太多了。首先ETL解决不了实时问题,其次Hive不支持修改,HBase不支持关联。对于源端数据的update和delete来说,Hive处理非常复杂。
HATP的意义就在于对应用透明,不再需要hadoop生态圈的十几种技术栈来完成BI、数仓和报表,大大节约了企业设备成本、人力成本。

21赞

格局:+1:

数据链路越长,风险越高,维护难度越大,有同感。

1赞

心路历程:+1:

坚持写下去:call_me_hand:

老师是实力派:+1:

1赞

学习:+1:

1赞

厉害:+1:t2:

1赞

真棒。

加油。

感谢分享,学习了