为什么要看TiKV
空间和时间-----鱼和熊掌
我们一致在为空间和时间的平衡而在做妥协。在时间昂贵的场景，就使用空间来换时间，在空间昂贵的时候，就用时间来换空间。
当我们开始分布式、大数据、高并发的场景时候，数据量大到一定的程度，时间开始变的昂贵。而追溯所有的问题根源，似乎都是IO的问题。
在一个业务刚刚起步的时候，一个简单的数据库加一个Web应用似乎就可以解决问题。但是当用户开始增多，数据量变大的时候，
似乎所有人都在考虑使用分库分表的策略。
当然，这里我还是保持一点点的怀疑态度，为什么要分库分表？单机性能到底受限于什么，这个我还是没有弄明白。
无论是说数据表大的话，索引表会很大，会占用很多内存，同时索引在缺页的情况下频繁的做LRU页替换，性能有很大的损失;
还是数据库的单表过大会引起单点问题。。。
理性的分析一下，数据库的索引应该不会占用太多的内存导致内存一直在切换、同时现在的数据库都在使用SSD，寻道等问题已经消失;
还有人说MySQL在百万级别的数量的时候性能还行，千万的时候性能衰减严重，但立刻有人说现在跑这大几千万的单表应用也没有关系。。
诸多理由似乎都没有解释清楚为什么在现在一定要使用分库分表策略来拆解大应用。
我能想到的是在偏离线的数据分析场景下，对group by, order, count 以及一些子查询有更多的需求，在这种场景下，
IO的问题就被凸显出来了。IO的极限很容易理解。
拿空间换取点时间！！
这种情况下朴素的想法也是做归并嘛，拆解问题嘛，当然就是数据备份好几份，每个上面处理一个子任务，然后在合并起来呗。
这里优化的空间可就大了（水深），当然可以不备份多份数据，而是根据一定的规则将数据分散的保存在不同的机器上。
子任务处理完成之后合并结果。
复杂度守恒定律
复杂度不会减少，只会转移。
在我们面对有大量的数据需要做处理的时候，基本是两个套路：
- 分库分表，数据在什么地方业务自己来做处理
- 全部采用分布式的方案来解决。比如Google的全家桶， BigTable、Spanner、F1
SQL的查询语言在设计初衷其实是为了屏蔽数据存储信息，用户只管去仓库中找数据就可以了。当我们开始注意如何建立索引，如何优化SQL
的时候，这个事情本身就跟初衷背道而驰。现在还需要关心分库分表，手动的写两阶段事务，心智负担的确非常重。
那么分布式的数据库，特别是一个全特性支持SQL的分布式数据库是一个什么样子呢，引起了我的好奇心。
TiDB/TiKV 恰好是一个工业级别的开源产品，Talk is cheap , show me the code.
在分布式数据库中一个Insert 语句会怎么执行呢?
带着这个问题，我们来一起看看TiDB是如何做到
准备工作
Windows 用户要不就用个虚拟机？（微笑）
TiDB 依赖的几个工程
https://github.com/pingcap/tidb
https://github.com/pingcap/tikv
https://github.com/pingcap/pd
https://github.com/pingcap/kvproto
https://github.com/pingcap/raft-rs
https://github.com/pingcap/rust-rocksdb
安装golang && rust
- 可以使用Linux 的包管理工具下载，或者去官网下载相应的发行包
- 使用make编译tikv
- 推荐使用emacs(spacemacs) + playground插件，在遇到语言层不理解的地方，用playground写一点小程序，看看结果
PS: 当然也可以使用IntelliJ全家桶，已经发布了golang, rust的版本，或者使用VS code.
公欲善其事必先利其器。准备好趁手的工具，就开始看代码啦～～
