Google Spanner 是一個什麼樣東西？對未來會產生什麼樣的影響？

01-14

聽起來是一個全球分散式資料庫，到底他對 google 和行業帶來什麼樣的推動和啟發呢？
http://gigaom.com/data/googles-spanner-a-database-that-knows-what-time-it-is/

spanner作為一個分散式資料庫的實現本身有一個最大的創新是 true time 的引入。這個東西讓分散式事務從原來最傳統的讀寫鎖方案進化為可擴展的分散式MVCC的方案了。MVCC方案的優勢是寫讀、讀寫不相互阻塞。並發度更好。

Part3_事務與分散式事務原理與實現具體可以見這個視頻中單機mvcc的說明。

在分散式事務實現中，之前之所以使用讀寫鎖方案，而不用MVCC方案，主要原因是傳統mvcc擴展方案裡面的自增id分配是個單點瓶頸。

spanner解決問題的方法是，放棄邏輯時間，改用真實時間-___-

不過從實踐中可以看到（paper裡面有些數據我們也問過相關的同事），他能解決部分問題，但是最核心的分散式事務的性能問題其實解決的也並不是很好，尤其在熱點更新的情況下，鎖延遲太高的問題也沒能解決。

整體來看，工程實現上讓人眼亮的點要多於理論上的。

sql兼容性上我覺得DRDS比目前的spanner強不少，畢竟DRDS是個給外部提供的產品，spanner目前主要是給內部使用。

要明白spanner，先要看看傳統資料庫是什麼樣子的。

傳統資料庫說白了就一張表格，就跟小時候班級值日用的表格是一樣的，上面有不同的項，項下面填著不同的值。

想想看，現在小明要填表，小紅要讀表，這怎麼辦呢？

正常情況下，要麼小明等小紅看完了表再填表，要麼小紅等小明填完了再看。這樣就存在一個「」等待「」的過程，傳統資料庫就是這樣，在讀寫的時候加一把鎖。

可是，如果我們有一萬個小紅小明，一百萬個，一億個呢？

想想看那一張紙面前人山人海排隊的壯觀場面。

那麼怎麼解決這個問題呢？

動用一下勞動人民的智慧！

讓小明填很多份表！每一個小明都可以填一份！，這樣小紅看的時候，小明也可以填，就不需要這個等待的過程了，所以小明可以隨便寫，小紅可以隨便看，我們不需要鎖了。

然而，怎麼保證小紅拿的是最新的數據呢？我們可以通過一個版本號來標識不同的小明填的不同的表，版本號最大的那個就是最新的。

然而這個版本號計算的時候就又會有等待的問題，小明a和小明b同時寫，那麼小明a的版本號大還是小明b的版本號大呢？沒辦法，排隊吧，於是這個策略在這裡又出現了性能瓶頸。

這可怎麼辦呢。

谷歌的辦法是，用時間戳！

用一個時間戳來當版本號！時間一直是在走的，自然也就比出了大小。自然，這就勢必要求小明a和小明b的時間是完全同步的，這個地方，谷歌利用了GPS和原子鐘來做超級精確的時間同步。如果小明a和小明b的寫時間戳連一毫秒都不差可怎麼辦？那時候再退化成排隊。這種情況很少見，自然性能就要比以前一直排隊的效率要高多了。

所以spinner的理論還是老理論，創新點就在這個時間戳當做版本號上面，基於這個原子鐘的時間同步，可以大大提高資料庫的並發效率。

因為用的比較淺顯的語言，各路大神還請輕噴。

分散式資料庫suffer了很久的consistency問題被解決了。