內存數據庫索引

　　記得早前第一份工做的時候，很得意本身能寫很是龐大的存儲過程，聊起天來就是怎樣引用索引、怎麼寫sql快；想一想那時候多好，容易知足，容易開心，開懷大笑！

　　仍是在前年的時候，忙完一個大項目以後！恰好有點時間研究fastdb，由於早期沒用商用數據庫以前就是用的這個。後來發現併發能力的問題，才切換到商用數據庫。

　　若是單從數據讀寫能力來看，fastdb無疑具備很是強的競爭力；我記得幾年前測試fastdb查詢能力就比timesten的速度快很是多，可是關鍵在於fastdb在進程併發的時候就變的很慢。由於fastdb並非行級鎖，而是表鎖+庫鎖，多進程時候衝突增長的狀況下性能跟不上。

　　fastdb有兩種索引，hash索引和T-tree索引。

　　hash索引採用分桶的方式，數據和分桶數達到必定比例就重新分配桶，以保證hash結果能獲得一個比較精確匹配的值，這樣才能保證hash索引的效率。他的實現其實和stl裏面的hash實現基本同樣，我以爲它的缺點和優勢都很明顯：

　　a、若是數據不能保證key是惟一的，那麼大量的重複key將會致使hash性能直線降低

　　b、上述缺點其實也是優勢，若是能保證key惟一。那麼hash效率無疑比較好的算法選擇

　　c、hash重新分配桶的時候，性能明顯變慢。並且其佔用空間也比較大

　　我今天主要是要記錄關於T-tree索引的理解。11年的時候剛開始接觸內存數據庫，開始在網上搜相關資料，很驚奇的發現大量的文章在論證爲什麼內存數據庫用的是T-tree而傳統的物理數據庫用的是B+tree。依據主要是如下兩點

　　a、不少的文字在描述T-tree的效率理論上就比B-tree要高，雖然時間複雜度都是log2n，但那是基於時間複雜最壞打算來講的；而數據庫索引T-tree查詢只有一半的機率查詢須要到最壞狀況，並且一半狀況下能夠提早查詢到結果。

　　b、物理數據庫選擇B+tree一個重要緣由是磁盤換入換出，而內存數據庫不存在這種需求。

　　不知道是否是基於這個理論，當時我所接觸的幾個數據庫都是採用了T-tree索引，timesten、altibase、fastdb等幾個無一例外。

 

　　等到前年去嘗試改造fastdb的時候，把數據庫改爲行級鎖，其中重要一部分就是T-tree索引的支持。基於上述理論，我開始不斷的coding+test，很長一段時間都沒有獲得理想結果。其中我以爲最難解決的問題是，T-tree索引在插入一個數據以後，節點分裂沒法控制其父節點影響的層次。這種狀況下，我只能無限的遞歸去鎖定上層節點父節點，最終鎖定的你會發現是跟節點，因此我想這就是當時fastdb爲什麼只能作到表鎖的根本緣由。

　　我沒法肯定timesten這些公司的人是怎麼實現這種狀況下的併發，除非他們有大量的鬆耦合邏輯來輔助這顆索引樹來完成互斥的功能。

　　很幸運公司來了一個韓國數據庫的團隊（聽說是大佬從altibase挖出來的核心團隊）來交流產品，更幸運的是領導讓我來接待他們，陪他們測試和交流技術，跟咱們在用的timesten進行了對標。他們總結的優點在於：

　　一、國產的，雖然是棒子作的。可是boss是中國大佬（那時候恰好掀起去IOE的風潮）

　　二、性能高，比市面上的主流數據庫產品性能都高。還有一大批的性能對比測試報告（至關專業）

　　三、複製代理性能高，基於他們高速網絡框架可以實現實時的數據同步。（有接觸太高可用產品的人都知道，這一點相當重要。可是不能肯定他們是否是吹的）

　　另外，他們不否定的一個點是，如今市面上商用少，說國內有一個金融產品的點；主要仍是在韓國用。

　　基於他們說的這些，咱們進行了一些測試。基於這些測試數據，卻是對他們產品有一些瞭解。首先是併發性能好，對比timesten徹底不是一個等級的，在3個進程之內，二者持平，可是進程數越多就越明顯。後來我和他們來的韓國專家（固然有翻譯，徹底裝不起來B）交流，他們用的是B-tree，我問他怎麼不用T-tree。棒子專家說了足有半小時，可是翻譯兄弟給個人結果是：他們原來用的是T-tree，後來改爲B-tree了，他們有從來的測試報告。至於緣由，翻譯兄弟說他翻不過來了。。。後來還叨叨了不少其餘的，通過翻譯兄弟的嘴以後，索引互斥鎖、複製代理啥的。感受收穫很少（語言過重要！！）

　　通過此次交流，開始從新審視兩顆樹的差別，發現其實T-tree在索引更新時搞不定的問題用B-tree徹底能夠解決。由於B-tree在分裂的時候，沒有旋轉的概念，並且他能夠肯定分裂節點的父節點以上就不須要變動，基於這點就能夠實現B-tree的互斥索引了。

　　因而我另外有一個發現，timesten11版本已經把T-tree索引改爲了B-tree索引，並且新的內存數據庫像sqlite也用的是B-tree。可是網上很難找到相關的論證文章。

　　不過無論如何，那時候已經決定從T-tree改爲B-tree了，又開始了一個週期的coding+test。不斷的修改和測試，這個小小的B-tree已經爲我搞定了行級索引鎖的問題測試了幾百萬數據，幾個進程併發的狀況下，3w/s的插入，查詢20w+/s。。問題仍然存在，性能太差了。可是能幫我驗證寫的其它數據庫管理代碼，索引確實是個問題，但願後面能找到其它靈感吧