分散式資料系統的兩個問題根源：partition 和 replication。

先談partition。當資料放不進一台機器，或是對資料的運算太過耗時，單台機器無法負荷時，就是考慮partition的時候。

partition就是把資料切割放到多台機器上，首先要考量的，就是要怎麼切資料。

資料有幾種常見的切法：

• Round-Robin: 資料輪流進多台機器。好處是load balance，壞處是不適合有session或資料相依性(need join)的應用。變型是可以用thread pool，每個機器固定配幾個thread，這可以避免某個運算耗時過久，而檔到後面運算的問題。
• Range: 事先定好每台機器的防守範圍，如key在1~1000到A機器。優點是簡單，只需要維護一些metadata。問題是彈性較差，且會有hotspot的問題 (大量資料數值都集中在某個範圍)。MongoDB在早期版本只支援這種切割方式。
• Hash: 用Hash來決定資料要在哪台機器上。簡單的Hash像是取餘數，但取餘數在新增機器時會有資料遷移的問題，所以現在大家比較常用Consistent Hashing來避免這個問題。Hash可以很平均的分佈，且只需要非常少的metadata。但Hash規則不好掌握，比方說我們就很難透過自定Hash規則讓某幾筆資料一定要在一起。大部分的Data Store都是採用Consistent Hashing。
• Manual: 手動建一個對照表，優點是想要怎麼分配都可以，缺點是要自己控制資料和負載的均衡，且會有大量metadata要維護。

除了切法之外，還要決定用哪個欄位當做切割的key。

資料切割是非常應用導向的問題，因為有一好沒兩好，某個切法可能能讓某種運算很有效率，但會害到其他種運算。

有一個tradeoff在讀寫之間，優化寫可能會害到讀。比方說Round-Robin可以平均寫入負載，但Range Query就要到所有機器上查詢。而如果用流水號的Range來切，有利於流水號的Range Query，但寫入會擠在同一台機器上。

另一個tradeoff在application之間，比方說一個用戶表格資料如果用地區來切割，那就有利於常帶地區條件的應用，因為這些應用可以只鎖定幾個partition進行查詢，而不用把query灑到所有機器上。

為什麼我們不要把query灑到所有機器上，這就下次再講好了。