架構- 數據庫的優化

一、增長了數據庫等鏈接池後，架構發生了變化，進行了必定的性能提高

 

主從讀寫分離：

大部分系統時讀多，寫少，讀寫的數據量可能會有幾個數量級

 

刷朋友圈的確定比發朋友圈的多太多了。

因此這時候的優化要考慮到主從讀寫分離

 

主從就要涉及到主從的數據複製過程：

一、主從複製， mysql的主從複製所有依賴於binlog ， mysql的全部變化以二進制的形式存在磁盤上的二進制日誌文件中，

binlog從主庫傳輸到了從庫上，通常這個過程時異步的，主庫操做不等待binlog同步完成

 

從庫鏈接到主節點，會建立一個io線程， 請求binlog的信息，並寫入relay_log中，而後在從庫進行回放，最終從庫一致性

 

能夠進行一主多從多配置，最多掛3-5個從庫，由於從庫多了，主庫須要log dump線程來處理複製的請求，對主庫資源消耗大

，主庫的網絡帶寬也是限制

 

問題點：主從延遲問題，解決辦法：

一、儘可能不去從庫查詢數據，能夠進行數據的冗餘。

二、使用緩存，寫入庫的同時在緩存中進行記錄     緩存的方案比較適用於新增數據

三、查詢走主庫（明確查詢的量不是很大）

四、運維加強保證對主從延遲的一些監控和報警

 

緩存，若是是更新數據的操做，可能會致使庫裏和數據庫不一致的問題

 

如何訪問數據庫：

數據庫中間件，來解決數據庫的訪問問題

 

 

業務繼續擴張，單表的數據量太大了

數據量大了：佔用磁盤空間，恢復和備份時間長，索引也佔用很大的空間，查詢也會很慢

分庫分表， 對數據庫進行垂直拆分和水平拆分

依照策略將數據儘可能平均地分配到多個數據庫節點或者多個表中

 

垂直拆分： 分庫，專庫專用，好處：

一、業務影響解耦，單獨存儲對應的業務

二、垂直拆分通常是按照業務來進行拆分的

當單個庫數據量也很大的狀況下，分表 - 水平拆分：

水平拆分表，按照某些字段來進行拆分

一、某個字段的hash值進行拆分

二、根據時間長度來進行拆分 - 數據不平均，表須要按時提早建好

三、查詢的時候比較難肯定是哪一個庫哪一個表，數據庫中間件來解決問題

 

假如是用user_id來進行水平區分，那以後的查詢必須帶user_id才能肯定表地址並進行查詢

若是不帶user_id怎麼辦？難道所有都查一遍嗎？ 思路：能夠引入幾個簡單的映射表，好比user_id和哪幾個字段的

映射關係

 

分庫分表後的id的全局惟一：

Twitter. Snowflake 算法，生成惟一id 

 

Nosql的區分：

Redis ，base，MongoDB

傳統的數據庫都是機械磁盤， 對於磁盤的訪問有兩種方式： 一種是隨機IO，一種是順序IO, 隨機IO須要

話費時間去作昂貴的磁盤尋道， 讀寫效率要比順序IO 小兩到三個數量級，因此儘可能減小隨機IO

LSM樹， 犧牲了必定的讀性能換取了寫入數據的高性能，