資料庫的可伸縮性的探索
author
：skate
time
：2009-5-30
資料庫在當今社會越來越重要，尤其對於乙個發展迅速的企業，其資料是**式的發展，為了適應其資料的發展，對資料庫的架構體系設計要求也越來越高，它要可以方便的線形擴充套件
對於資料庫的一般優化思路：
1.優化前端的邏輯，把一些不必要的產品功能去掉，並加上一些限制，從而可以空值不必要的資料增長
2.通過在資料庫層面觀察
sql，可有優化一些效能低效的
sql，以達到減少對
iops
的衝擊3.
對適當的業務點加上
cache
，以減少對資料庫訪問
4.如果以上三種方式還不能解決，那就要考慮資料庫的並行，例如
oracle rac
，可能通過增加硬體伺服器來進一步解決資料庫的壓力問題。但這種方式有個特點，就是採用共享儲存，不是無限制的增加伺服器就可以緩解資料庫的壓力（資料庫的儲存也是有限制的）
通過以上方式的修改，可以緩解資料庫的壓力，其實所謂資料庫的壓力，主要是在磁碟讀取上（磁碟的效能發展要比
cpu，記憶體等慢很多）
當資料庫的儲存成為瓶頸的時候，就要考慮進一步的優化方法: 1.
更換更快的儲存（最好用記憶體支撐
iops
），以達到提高磁碟
iops
效能2.
庫的讀寫分離，可能讓我們可以有針對性的優化，因為寫操作會對資料產生排他鎖阻塞其他回話的讀；我可以在讀操作前端加上
cache
，這樣使用者的讀操作的響應時間會大大提高
3.採用分庫的方法，可以把乙個庫的壓力分擔在若干不同的庫上；這種方法很適用資料爆增的系統，只需要增加硬體就可以線性的解決效能和儲存的問題；如果考慮以後增長會很快，可在在分庫中增加分表；在分庫的基礎上可以在按功能或其他方式在分庫
分庫的幾個原則：
#1：按功能分割
#2：水平切分
#3：避免分布式事務
#4：用非同步策略解耦程式
#5：將過程轉變為非同步的流
#6：虛擬化所有層次
#7：適當地使用快取
分庫有個問題
1.如何分庫，按這什麼規則什麼標準分
2.分庫之間如何保證資料的一致性
3.如何跨庫
merage
和sort 4.
如何做資料修正
5.如何保證分庫之間的資料唯一
拿blog
為例要把資料庫表按著
public
和private
區分，按使用者說，哪個是使用者私有的，哪些是使用者共享的
方法一：
1.如果
public
的表單獨放在乙個庫里2.把
private
按使用者id
分，如每
100萬使用者為乙個分庫
優點：對於
public
的相關資料的修正維護很方便，
缺點：會增加分布式的事務，增加跨庫操作，而且庫之間的耦合度也會增加
方法二：
把
public
和private
和表都分別放在分庫中，
public
的表通過觸發器等方法同步
有單獨的乙個庫用於觸發維護其他的分庫；假如有個分庫的
public
資料變化，就會觸發維護庫來更新其他所有的庫，這就可以保證資料的一致性
還要有乙個配置庫（路由庫）：用以判斷選在哪個庫的哪個表，配置庫要有配置表，用於配置分庫，分表的規則和查詢路由；這個也可以放在中介軟體裡，讓中介軟體判斷選擇使用哪個庫，哪個表
以上是個人的一點看法，希望能和這方面大師請教！！
參考文件：
ZooKeeper的伸縮性
經過前面的介紹，我想大家都已經知道了在zookeeper集群當中有兩種角色leader和follower。leader可以接受client 請求，也接收其他server 的寫請求，負責更新系統狀態。follower也可以接收client請求，如果是寫請求將 給leader來更新系統狀態，讀請求則由f...
資料系統的可靠性，可伸縮性，可維護性
資料密集型應用設計讀書筆記第一章。現在的資料密集型應用，趨勢是元件化。乙個系統裡，快取，資料庫，索引，和訊息佇列等都解耦開來，每個部分再針對需求選擇對應的元件。而應用業務 則負責維護元件之間的一致性。而乙個資料系統，非功能性需求的基礎目標有三個，可靠性，可伸縮性，可維護性。可靠性 reliabili...
系統設計 後台系統的伸縮性
1 軟體分層 分層思想很普及，把資料流拆成幾段，比如接入層 load balancer webserver 應用服務層 platformserver 資料儲存層 資料庫database nosql 2 伸縮性定義 2.1 接入層 loadbalancer webserver 請參考乙個客戶端請求到後...