1.2 為什麼作業系統操作磁碟的最小單位是簇紅黑樹資料結構1.3 尋道時間
1.4 讀取乙個簇的時間 `ta`
1.5 磁碟讀取時間總結:
2. 資料庫儲存 資料結構選擇
2.2 有序資料結構
2.2.2 btree
2.2.3 b+tree
3.總結
btree資料結構
b+tree資料結構
建議稍微了解一下這三種資料結構,不然下文可能看不懂
這段主要目的是讓大家對機械硬碟讀取速度有個感性的認識!!!
這裡介紹一下常用的最廉價的儲存介質機械硬碟
下面我們要對磁碟儲存區域進行一下劃分
什麼是尋道時間?
非常重要總結: 機械硬碟讀寫乙個簇是乙個毫秒級的操作
毫無疑問如果沒有排序和範圍查詢的需求雜湊表效能最好o(1),但是很多情況下排序是非常強的需求,所以我們暫時不討論
優點:
缺點:
1. 假設n=1000,那麼樹高假設為h=lg1000=9.967=10,這個樹高增長的趨勢還是非常快得
2. 假設平均每次讀取的節點高度為10(二叉樹很容易就達到),那麼就意味著平均每次讀取,需要磁碟10次io才能找到目標
3. 那麼如果一次硬碟讀取為10ms,讀取10次就需要100ms來找到期望的節點
4. 綜上,紅黑樹其實不太適合在磁碟這種載體上使用,記憶體讀取一次耗時100ns級別,而硬碟讀取一次耗時是10ms這個級別的慢了100倍
btree為我們提供了一些思路
設btree子節點個數為t,t為常數
樹高<=logt((n+1) /2) 以t為底的log函式
設t=2^x,x為常數
查詢複雜度=o(logt((n+1) /2))=o((1/n)lg((n+1)/2))=o(lgn)
查詢複雜度還是o(lgn)
這裡有個非常形象的btree結構的操作,建議大家都去看看
舉個例子,看看查詢效率
例子不嚴謹
設我們有1000個結點,設t=1000(假設每個結點可以有1000個關鍵資料)
設1000個鍵資料,佔據磁碟空間<=4kb,乙個簇(塊)可以容納得下
根據公式h<= logt((n+1) /2) = 1.00045 = 2,樹高為2
即我們查到指定的資料只需要讀取兩個簇
而1000條資料讀入記憶體之後,進行比較操作,耗時跟磁碟io相比耗時可以忽略不計,不是乙個數量級的
設每個結點比較耗時100ns,如果進行了1000次比較來找到指定結點.1,000,000納秒=1毫秒,那麼耗時為0.001ms
也就是說,我們查到指定資料,最多隻需要兩次磁碟io,查詢時間約等於20ms
順序讀寫速度
4k隨機讀寫速度
機械硬碟
2500000ns
100mb/s
1mb/s
固態硬碟
15000ns
1000mb/s
10mb/s
記憶體100ns
10000mb/s
500mb/s
l3 cache
1ns>100000mb/s
>100000mb/s
(1,000,000納秒=1毫秒)
b+tree優點:
上面分析了紅黑樹和btree之間的比較
那麼為什麼mysql要用b+tree呢?與b+tree相比還有什麼優勢呢?
b+tree缺點:
因為結點中只儲存了關鍵資料,想要獲取完整的資料,就一定要查到葉節點,
但其實也可以認為,每次都要查到葉節點,是讓查詢速度更加穩定了
空間占用相對btree多一些,因為除了葉節點,其他父節點全部是為了排序冗餘的
通過以上分析,我們可以看出
b+tree的設計,正好適合資料庫通過作業系統讀取操作硬碟的特性
mysql就是各方權衡,最終選擇b+tree來作為儲存的資料結構
為什麼mysql索引要用B Tree資料結構
二叉樹 不適合自增長索引，失去索引效率，樹單邊增長，成煉錶狀。從1插入到4 紅黑樹 平衡二叉樹 不適合資料量大，樹太高。如果查詢資料在葉子節點，則需要查樹高次數。從1插入到5 hash表 hash衝突，並且不支援範圍查詢，大於小於區間查詢。mysql支援，等於查詢能快速定位，只適合資料量特別大，範圍...
為什麼要用 enable shared from
樓主 hma if you think you can,you can.panrainbow 憂鬱淡藍 於 tue nov 9 11 48 38 2010 提到 引入enable shared from this的原因是可以實現返回值為指向該類本身的 shared ptr，為什麼以this為拷貝構造...
為什麼要用補碼
在探求為何機器要使用補碼之前,讓我們先了解原碼,反碼和補碼的概念.對於乙個數,計算機要使用一定的編碼方式進行儲存.原碼,反碼,補碼是機器儲存乙個具體數字的編碼方式.原碼就是符號位加上真值的絕對值,即用第一位表示符號,其餘位表示值.比如如果是8位二進位制 1 原 0000 0001 1 原 1000 ...