1樓：MQ4096
拆分的方式有兩種。一是分割槽，二是分庫分表。 分割槽的代表有Oracle 12c的sharding，OceanBase，TiDB（是比分區更細粒度的Range）。
分庫分表的代表有DRDS，TDSQL，MyCat。本質上就是分布式中介軟體去實現分庫分表路由。 無論哪種都說自己是分布式資料庫。
下面假設你說的是第二種，其分析思路同樣也適合第一種。由於市場上絕大部分OLTP型分布式資料庫通過分布式中介軟體做的，底層資料都是mysql。所以下面分析時是以mysql分布式資料庫例項拆分為例。
2. 拆分要決定按什麼維度拆、以及拆成多少片。這裡假設拆分維度不是你的問題，拆成多少片就是說總的業務資料要拆分到多少個分表裡面。
這個可以根據資料量、訪問量去自己設定乙個值。然後在業務使用過程中總結經驗。發現拆少了，那下次拆多點；發現拆多了，那下次拆少點。
並沒有準確的公式說明應該拆成多少個分表。在阿里電商業務裡，經驗是分表數維持為乙個2的冪。如16，32，64，128，256，512，1024，2048，4096等。
分表數越多，對中介軟體的元資料管理和效能挑戰都越大。根據業務資料規模和訪問規模，選擇乙個值，用久了就有經驗選哪個值了。分表的總數之所以是2的冪，是方便資料庫集群的合併或者進一步拆分（拆分就是對半開）。
你也可以不這樣來（比如說用DRDS），這樣選擇餘地就很大了，比如說16-1024之間任意乙個數都可以。缺乏標準選擇太多有時候也是很頭痛的事情。
3. 分表的數量定了後，還要定分庫的數量。這些分表並不是放在乙個分庫里。
同樣阿里電商的經驗，分庫的數量有8，16，32，64，128，256。這樣總分表數除以總分庫數，每個分庫下的分表數就定了。這個題目問的就是總的分庫的數量是否越多越好。
分庫的數量影響的是拆分場景的運維操作。以mysql為例，把乙個mysql例項拆分為2個，最快捷的操作就是搭建2個新的從庫（A(主)->B(備）->C(備)->D(備)。然後把 B->C同步斷開，C變為主，然後把A裡一半的分庫刪掉，同時把C裡另外一半的分庫刪掉。
這種拆分方式就是對半拆，實現擴容2倍。如果要擴容4備，無非就是1個例項變4個例項，然後每個例項裡只保留1/4的分庫數。這就是為什麼分庫的數量也是2的冪的原因。
乙個例項裡的分庫數量決定了還能繼續擴容的最大倍數。比如說例項有4個分庫，那意味著還能拆2次，實現4倍擴容；如果有16個分庫，還能拆4次，實現16倍擴容。
4. 有很多分庫後，這些分庫也不一定全部放在乙個例項裡。所以還有個例項數的概念。
一樣，阿里電商的經驗，例項數量常有1，2，4，8，16，32，64，128等。乙個業務資料庫到底是用1個mysql例項還是用4個mysql例項，主要取決於業務對資料庫的效能需求，以及空間需求。如果效能毫無問題，只要乙個機器能放得下乙個業務的所有資料，1個例項也是ok；如果放不下，就分多個例項存放，因為多個例項可以放到多個機器上。
這是空間標準。 實際工作中常常是根據效能評估。每個特定規格的mysql例項能提供的qps和tps，以及rt是有個範圍的，需要實際測試知道。
然後用業務對db的總qps要求去除以單個例項的能力，就是要拆分多少個例項的參考值。 業務初期，壓力小，為了節省機器資源，可以少用一些例項；業務規模和壓力上去後，可以對mysql分布式資料庫集群進行拆分，如從4例項拆分為16例項等等。 只是前面說了，單個例項裡的分庫數很重要，決定了能擴容的倍數。
5. 以上理論的第3點有個不嚴密的地方。有人會說即使例項裡只有1個分庫的時候，由於有多個分表或者只有乙個表，依然可以把資料對半分。
是的，只不過這個就要借助外在的資料同步工具去拆分了，需要把資料讀出來然後對半掰開，這種效率相比搭建mysql主從同步要低很多，切不能絕對保證資料不丟。聰明人會從一開始就規避這種場景。
6. 上面分析的過程就是拆分設計的思考過程。 不過DRDS這個產品實際使用的思路跟上面這個過程並不完全一致。
DRDS的例項個數由你選擇的RDS例項個數決定（選幾個就是幾個），每個例項裡的分庫數限制死了是8個，所以總的分庫數就由選的RDS例項個數乘以8決定。至於總分表的個數，DRDS建表時會指定每個分庫下的分表數，可以隨意定，比如3個。那麼總的分表個數為總例項數*8*單個分庫下的分表數。
這個決策過程個人覺得是蠻彆扭的。
2樓：陳廣勝
可以想像一種極端的情況，每個庫上只有一條記錄會如何？
分了太多庫會有（包括但不限於）以下缺點，
1.資源浪費
2.維護成本高昂
3.大量分布事務
1，2顯而易見，我只說下3，
分布式事務的代價較大。主要問題是，分布式事務使用的兩階段提交，要經過多次通訊（如果是互動SQL，那麼通訊次數會更多），相應的延遲較高。這造成鎖的持有時間要跨越節點間的通訊，衝突的機率變大了。
如果事務的協調者掛掉，事務就被阻塞住了。分布式事務被認為是難以擴充套件，而分庫的主要目的就是就是解決擴充套件性問題，這本身就是個矛盾。
關於分庫，乙個經驗之談是盡可能的減小分布式事務的數量。拿TPCC裡的表為例，把item表做成全域性複製，按warehouse分割槽後，就會產生很少的分布式事務。
所以，分庫並不是越多越好，合適就好。
3樓：husterindg
我沒有這方面的DBA經驗，以上介紹僅供參考。
根據資料量選擇合適的物理庫數量是最好的。我看了下華為雲分布式資料庫DDM的幫助中心材料，專門有乙個最佳實踐講了分片數（物理庫）該怎樣分，該分多少。
分布式資料庫，如hadoop cassandra mysql集群，主流是採用什麼儲存技術，DAS NAS還是SAN？
如果簡單的回答題主的問題，那麼答案是DAS。除了MySQL以外，其他的都是經典的分布式系統。這些分布式系統通常假定任何裝置都是不可靠的，演算法上會對資料做冗餘儲存，因此對介質本身的要求相對較低，DAS即可。MySQL相對特殊。一般而言，如果用MySQL，題主要用的是關聯式資料庫，且資料一般是比較重要...
分布式資料庫計算引擎對分布式儲存系統底座提出了哪些新的技術挑戰？
lemon wonder 我說一下HTAP情況，對於資料庫，TP主要是事務相關，一般底層儲存引擎使用行存，對於AP是分析性，對事務要求沒那麼高，一般用列存，要處理HTAP，那要做到行列混合儲存就很困難。對於儲存引擎，一種是外掛程式型，向MySQL中，SQL和儲存約定好介面，實現介面並直接使用。但是要...
分布式資料庫如何解決儲存過程？
xchliu 這是個好問題。事實上，太多的系統使用儲存過程來實現業務場景了，雖然在網際網路不多，畢竟網際網路系統沒有歷史包袱。在傳統企業系統中，儲存過程改造問題是非常艱鉅的任務。於是才有了這個問題，也就是說分布式資料支援儲存過程，改造代價就會小很多。而從分布式資料庫實現的角度，變成了乙個選擇題 要不...