Web開發系列(十一):資料庫擴充套件
- 讀寫分離:這種情況適用於讀遠大於寫的情況,讀越多,就可以分出越多的從庫。從庫是隻讀的,主則負責所有的寫入。主和從之間 通過同步binlog完成資料同步。
-
分表:
- 當一張表的資料量非常大時,我們可以採取對時間,id等進行分表,對錶進行瘦身,從而達到提高讀取/寫入速度的目的,原理 是因為,表更小了,系統維護成本更低,此外對索引的維護成本也會隨之降低,但是缺點是很明顯的,即當需要對所有資料進行查詢時, 查詢的邏輯會變得複雜。這種方案適用於並不需要所有資料的情況,例如使用者的訊息,只需要儲存最近三個月的資料,則可以把三個月 以前的資料從當前表中抽走到其他備份表中。
- 此外分表還有一種方式,例如使用者可能有很多資訊,但是常用的資訊卻只有那麼多,我們可以把常用的資訊放在使用者表,其他的資訊 放在其他表,通過關係把兩個表關聯起來,這樣能加快查詢的原因是可以減少很多不必要的資料查詢,尤其是使用ORM的情況下,ORM 一般都會把所有的資料都拿出來以便進行對映,通過這種方式可以減少資料傳輸量和資料庫維護表的成本。
-
分庫:設想,當一個數據庫的寫入不堪重負時,我們該要如何處理?答案便是將一部分資料搬到另外一個數據庫去,這種方案帶來的好處 是顯而易見的:把對其中一部分的資料的讀和寫都帶走了,可以大大的降低資料庫的負載,但是缺點便是,增加了應用程式的邏輯複雜度, 原本只要在一個數據庫中連表就可以查出來的資料,現在要在不同的資料庫中查詢。
以上三種方案的難度依次遞增,對未來的預測和預留能力要求也是依次遞增。
現在出現了一些新的分散式方案,但是我還沒有試過,所以沒有寫上去,例如MySQL Cluster
和TiDB
。
但是一般來說,合理的安排資料庫的關係,合理的安排索引,合理的安排主從,在業務還沒有達到那個量級之前,根本就不需要使用 更加高階的方案,目前我使用的一張表,合理的安排索引和表的關係,已經達到1.6億行,讀寫分離1帶3,仍然能在10ms內完成查詢。