大量資料

通常在破百萬筆資料時
SQL的搜尋就需要做最佳化了
搜尋有兩件難事要做
一是比對關鍵字
二是資料排序

在蛋的想法裡
大量並非指某個數量
而是指單台機器無法負荷時
就叫做大量
(有時機器差一點,可能50萬筆資料就叫大量了)
在這個時候就需要做資料分散的管理
例如1~50萬筆資料在A機器
50~100萬筆資料在B機器
這樣一來,只要機器多就好辦事

當資料分散在各個機器時
如何將資料取出來,就變成是一個很大的學問
這個學問,我也不懂,還在思考中..

話再說回到排序
排序除了一般程式的演算法之外
其實在SQL裡的INDEX也是一個方法
常常在說,INDEX很重要
但INDEX也有其極限
如同一般的資料,INDEX其實也只是另一個資料檔
它的差別在於,這個資料有被排序過


serial PK #流水號
user_no char(10) #編號(UNIQUE)
user_name char(20) #名稱
user_birthday date() #生日

serial,user_no,user_name,user_birthday
1,a123456781,王大明,1977-08-01
2,a123456782,王二明,1978-08-01
3,a123456783,王二明,1968-08-01
.......

以上這個資料表如果是在戶政事所就有2300筆
如果沒有INDEX,當我要依生日排序時
就得每一筆資料都叫出來並做比對排大小
2000筆資料還好2000萬筆資料,可能就瘋了
所以INDEX就會建另一個檔

serial-user_birthday
3
1
2

就是一個已排好序的serial
這只是INDEX的基本,它其實還做了更多事
在此就不多說(蛋也不是很清楚,也無法多說)
當資料有所異動時,INDEX也會跟著異動
我們就會發現到INDEX的兩個問題
1.當異動時,會變動到的檔案增多
2.當資料量大的時候,INDEX也會隨著增大

這兩點都是無可避免的問題,也關係到程式效能
這些都是在大量時會遇到的問題
如同蛋剛開始說的
當資料量大時,我們就必需要分散到各機器去
當INDEX大時,我們也可以分散到各機器去

分散的方法,依需求來去分散
可能依資料來分散
serial 1~50 serial1_50.index
serial 50~100 serial1_100.index
也可能依排序來分散
user_birthday 1~50 birthday_50.index
user_birthday 50~100 birthday_100.index

類似這樣的分散
也許在連結機器所耗的效能增多了
但平均機器會有的負荷也相對減少

後記
依排序來分散,會造成一些效能的問題
當我新增一筆資料時,生日的排序可能在這birthday_50.index
原本birthday_50.index排最後一名的,會被改到birthday_100.index
birthday_100.index排最後一名的,會被改到birthday_150.index
類似這樣的情況
所以蛋才會說依需求來分散
有時雖然在變動資料時會花上一些效能
但在排序資料時就會快很多