一、單機數據庫
1、數據庫的基本組成
（1）K-V存儲
（2）事務引擎、關係代數和
（3）用戶API
2、K-V存儲
（1）本質來說，就是“映射”，按照key找打value
（2）所有數據存儲的最基本和最底層的結構
（3）不文件系統找指定的數據的作用相同，也是根據指定的key查找到對應的數據
（4）映射的關鍵特性
是否支持範圍查找？是否能夠處理更新？讀寫性能指標？是否面向磁盤結構？並行指標？內存佔用？
（5）按照key找到對應的數據
（6）二級索引：分級key-value-key-value等
（7）組合索引：兩個key
3、事務
（1）事務的核心就是鎖與併發
（2）查詢加鎖，保證數據不會被獨佔
（3）單個事務單元：建立索引、讀取記錄、寫入記錄、刪除。。。
（4）一組事務單元
4、SQL引擎
（1）AST
抽象語法樹，標記SQL的組成方式
（2）執行計劃
告知執行器如何高效的利用K-V
二、分佈式數據庫
1、多機Key-Value存儲
（1）可運維、高性能、可以比較容易地擴容
（2）核心數據結構還是hash和樹，部分case針對多機做了一點點優化
（3）代表組件
mongoDB->mongos服務器
Hbase->region server + client jar包
DRDS(TDDL)->tddl規則引擎組件
2、路由
（1）規則引擎
有狀態數據應按照什麼規則進行寫入和讀取
（2）本質來說還是查找的過程
Hash：O(1)效率，不支持範圍查詢（按時間這樣的查詢條件就比較困難），不需要頻繁調整數據分佈
Tree：主要是B-Tree，O(logN)效率，支持範圍查詢，需要頻繁分裂和合並
3、Hash
（1）Id%n最普通的hash
（2）如果id%3 -> id%4總會有80%的數據發生移動，最好情況下是倍分id%3 -> id%6，這時候會有50%的數據發生移動，數據移動本身過於複雜
（3）一致性hash：主要解決數據擴容和縮容
Def idmod=id%100
If(id>=0 and id<250) return db1;
Else if(id >= 250 and id < 500) return db2;
Else if(id >= 500 and id < 750) return db3;
Else return db4；
（4）虛擬節點
解決熱點問題，只需要調整對應關係即可
解決n到n+1問題，規則可以規定只移動需要移動的數據
方案相對的複雜一些
一般推薦使用簡單方案開始，使用n到2n方案擴容
只有需要的情況下，再考慮平滑的擴展到虛擬節點方案即可
4、B樹
Hbase使用的切分方法
支持範圍查詢，對於大部分場景來說，引導列都是pk.userid一類的單值查詢，用樹相對複雜
需要頻繁的進行切分和合並操作，region server的噩夢
固定節點情況下，跨度相對較大，查找效率可能會進一步降低
5、一致性問題C（順序）A（安全）P
（1）無主機方案Dynamo/cassandra/Paxos:gossip
W+R>N，所有節點可寫，不存在單點故障
讀數據的最新版本，需要將所有可寫節點的數據都讀出來合併一次
（2）有主機方案（Raft）
Mysql MongoDB Oracle+firbreChannel
只有一個節點可寫，切換時存在短暫leader election過程，會出現短暫不可寫
數據一致性比較好控制，讀最新數據只需要讀主機就可以，一致性讀性能較好
6、考慮問題
（1）有些機器負擔寫任務，因此讀壓力可能不均衡，因此必須有權重設置
（2）單個節點掛掉的時候，TCP超時會導致業務APP的線程花費更多的時間來處理單個請求，這樣會降低APP的處理能力，導致雪崩
（3）因爲突發情況，導致數據庫請求數增加，數據庫響應變慢，導致雪崩
三、數據庫時間
1、單機優化原則
（1）二分查找效率》全表遍歷，選擇合適的索引
（2）內存讀寫》SSD讀寫》磁盤讀寫，將物理讀（磁盤讀）換成邏輯讀（內存讀）
（3）減少鎖衝突，儘可能通過業務設計，將更新變成插入
（4）減少臨時表使用，減少多維護排序
2、分佈式系統優化原則
（1）減少跨機網絡交互，儘可能帶sharding key，分頁優化
（2）減少數據讀寫熱點，切分顆粒度儘可能細，用戶顆粒度好於省份
（3）減少鎖開銷，儘可能規避分佈式事務
3、原則
（1）盡一切可能利用單機資源：單機事務、單機join
（2）儘可能走內存，儘可能將一次要查詢到數據物理的放在一起
（3）通過合理的數據冗餘，減少走網絡的次數
（4）合理並行提升響應時間
（5）讀取數據瓶頸，可以通過加slave節點解決
（6）寫入瓶頸，用規則sharding和擴容來解決