2023年，p o'neil等提出的 lsm-tree 是乙個重大 突 破。lsm-tree主要有兩種變形，最簡單的lsm-tree，是乙個記憶體中的小索引加上外存中的大索引，更新先快取在小索引中，再批量更新到大索引， 這樣就有望合併對屬性同一頁面的多次更新的io。複雜的lsm-tree，是劃分為多個level的很多的小索引，每個level的大小，近似的是前乙個 level大小的r倍，如果乙個level有r個小索引，則合併形成乙個下一level的較大的索引，這樣隨機插入或刪除的平均io開銷可以降低到 log（n）/b次，是乙個很大的提公升。但帶來的問題是，搜尋的時候，就要搜尋這麼多個小索引，而這樣的索引會有o（log（n/b））個，那是可能有幾 十個，搜尋的效能就可能下降幾十倍，這往往也帶來問題。lsm-tree已經有不少的現實應用，bigtable、cassandra、lucene等這 些用的是複雜的那種lsm-tree，innodb的change buffer可以說是那種一大一小的簡單lsm-tree。ntse想在做多版本事務的時候順便實現change buffer。
2023年，ma bender等提出的cache oblivious b-tree 是第二個重大突破。這個跟lsm-tree有些類似，也是索引從小到大分成相鄰大小翻倍的多個索引，因此隨機插入或刪除的平均io開銷也是log（n）/b次，但它用了fractional cascading 的技術，使得搜尋的效能較傳統b+樹相關不多。雖然**發表了10年了，這種索引似乎現在只有tokudb 一家實現，它是稱之為fractal tree。我們拿來試了試，效果果然出奇的好。
有沒有可能將來搞出乙個比fractal tree更好的東西呢，遺憾的是如果硬體不發生根本改變，已經證明fractal tree已經是最理想的了。
但lsm-tree或fractal tree，其實只是消除索引的隨機插入和刪除帶來的隨機io，對隨機搜尋沒什麼幫助。這個剩下的索引的隨機搜尋問題比較複雜，要分解來看。一種是真正的來自於應用需求的搜尋，另一種是檢查唯一性帶來的搜尋。這兩種處理方法是不同的。
對於真正的來自於應用需求的搜尋，處理還得借助於記錄級快取類似的技術，但這時變成索引項的快取了。innodb中的adaptive hash index就是這個東西。但對檢查唯一性帶來的搜尋，bloomfilter是個好方法，經常可以消除98%以上不必要的檢查。所以bigtable裡就 用。但對傳統b+樹由於索引是實時更新的，bloomfilter不好用，對fractal tree，索引是在merge的時候再批量更新的，可以用bloomfilter。我們試了tokudb，根據效能表明看，它對索引性索引的隨機插入，也 能輕鬆對付，估計也是用了bloomfilter類似的技術。
因此，我們可以看到，隨機io這個老大難的問題，其實還是有不少的技術可以 解決的。然而，現實是悲摧的，我們經常在用的主流資料庫，無論是商業的oracle、db2、sql server，還是開源的mysql、postgresql，都基本上還在用最老土的技術，innodb裡搞了一點change buffer，就能讓人津津樂道半天。nosql系統走在前面，用上了lsm-tree，但也並不是最先進的，搜尋的效能經常令人擔憂。在索引這方 面，tokudb走在前面，但還沒為大眾接受。記錄方面，不清楚為什麼大家不作記錄級快取，這不是很難的事，莫非認為用memcached就可以了，「因 為善小而不為」？
從資料庫層面理解 隨機 I O 順序 I O
在 談這倆概念前 先來說說 大i o vs.小i o 通常 我們把 16kb的i o認為是小i o 而 32kb的i o認為是大i o 了解i o的大小 影響到後期對快取 raid型別 lun的一些屬性的調優 當前大多數資料庫使用的都是傳統的機械磁碟 因此 整個系統設計要盡可能順序i o 避免昂貴的...
ASP讀取ACCESS資料庫隨機記錄的方法
檢查了一些貼子對於mssql資料庫一般可以採用這樣的語句 select top 50 from sometable order by newid 但是如果是access資料庫的話似乎沒有什麼好的解決方法。方法一 有人用如下 以記錄總數為極大值來首先提取出指定數量的隨機數，然後以這些隨機數做為記錄id...
關於資料庫的隨機查詢
隨機查詢資訊 select from table where id select floor rand select max id from table order by id limit 1 最後，再把語句完善一下，加上min id 的判斷。我在最開始測試的時候，就是因為沒有加上min id 的判...