我是如何低效的看TiKV代碼的（序）

為什麼要看TiKV

空間和時間-----魚和熊掌

我們一致在為空白間和時間的平衡而在做妥協。在時間昂貴的情境，就使用空間來換時間，在空間昂貴的時候，就用時間來換空間。
當我們開始分布式、大資料、高並發的情境時候，資料量大到一定的程度，時間開始變的昂貴。而追溯所有的問題根源，似乎都是IO的問題。
在一個業務剛剛起步的時候，一個簡單的資料庫加一個Web應用似乎就可以解決問題。但是當使用者開始增多，資料量變大的時候，
似乎所有人都在考慮使用分庫分表的策略。

當然，這裡我還是保持一點點的懷疑態度，為什麼要分庫分表？單機效能到底受限於什麼，這個我還是沒有弄明白。
無論是說資料表大的話，索引表會很大，會佔用很多記憶體，同時索引在缺頁的情況下頻繁的做LRU頁替換，效能有很大的損失;
還是資料庫的單表過大會引起單點問題。。。
理性的分析一下，資料庫的索引應該不會佔用太多的記憶體導致記憶體一直在切換、同時現在的資料庫都在使用SSD，尋道等問題已經消失;
還有人說MySQL在百萬層級的數量的時候效能還行，千萬的時候效能衰減嚴重，但立刻有人說現在跑這大幾千萬的單表應用也沒有關係。。
諸多理由似乎都沒有解釋清楚為什麼在現在一定要使用分庫分表策略來拆解大應用。

我能想到的是在偏離線的資料分析情境下，對group by, order, count 以及一些子查詢有更多的需求，在這種情境下，
IO的問題就被凸顯出來了。IO的極限很容易理解。

拿空間換取點時間！！

這種情況下樸素的想法也是做歸併嘛，拆解問題嘛，當然就是資料備份好幾份，每個上面處理一個子任務，然後在合并起來唄。
這裡最佳化的空間可就大了（水深），當然可以不備份多份資料，而是根據一定的規則將資料分散的儲存在不同的機器上。
子任務處理完成之後合并結果。

複雜度守恒定律

複雜度不會減少，只會轉移。

在我們面對有大量的資料需要做處理的時候，基本是兩個套路：

1. 分庫分表，資料在什麼地方業務自己來做處理
2. 全部採用分布式的方案來解決。比如Google的全家桶， BigTable、Spanner、F1

SQL的查詢語言在設計初衷其實是為了屏蔽資料存放區資訊，使用者只管去倉庫中找資料就可以了。當我們開始注意如何建立索引，如何最佳化SQL
的時候，這個事情本身就跟初衷背道而馳。現在還需要關心分庫分表，手動的寫兩階段事務，心智負擔的確非常重。

那麼分布式的資料庫，特別是一個全特性支援SQL的分散式資料庫是一個什麼樣子呢，引起了我的好奇心。
TiDB/TiKV 恰好是一個工業層級的開源產品，Talk is cheap , show me the code.

在分散式資料庫中一個Insert 語句會怎麼執行呢?

帶著這個問題，我們來一起看看TiDB是如何做到

準備工作

Windows 使用者要不就用個虛擬機器？（微笑）

TiDB 依賴的幾個工程

https://github.com/pingcap/tidbhttps://github.com/pingcap/tikvhttps://github.com/pingcap/pdhttps://github.com/pingcap/kvprotohttps://github.com/pingcap/raft-rshttps://github.com/pingcap/rust-rocksdb

安裝golang && rust

1. 可以使用Linux 的包管理工具下載，或者去官網下載相應的發行包
2. 使用make編譯tikv
3. 推薦使用emacs(spacemacs) + playground外掛程式，在遇到語言層不理解的地方，用playground寫一點小程式，看看結果

PS: 當然也可以使用IntelliJ全家桶，已經發布了golang, rust的版本，或者使用VS code.

公欲善其事必先利其器。準備好趁手的工具，就開始看代碼啦～～