我們進行數據庫選型的時候要考慮哪些問題？有哪些需求？待選用的數據庫是否和需求對得上？是不是直接可以拿來用？需不需要一些額外的開發？一起來看看~
轉自：阿飛的博客
一、數據庫技術選型的思考維度
我們做選型的時候首先要問：
誰選型？是負責採購的同學、 DBA 還是業務研發？
如果選型的是採購的同學，他們更注重成本，包括存儲方式、網絡需求等。
如果選型的是 DBA 同學，他們關心的：
① 運維成本
首先是運維成本，包括監控告警是否完善、是否有備份恢復機制、升級和遷移的成本是否高、社區是否穩定、是否方便調優、排障是否簡易等；
② 穩定性
其次，DBA會關注穩定性，包括是否支持數據多副本、服務高可用、多寫多活等；
③ 性能
第三是性能，包括延遲、QPS 以及是否支持更高級的分級存儲功能等；
④ 拓展性
第四是擴展性，如果業務的需求不確定，是否容易橫向擴展和縱向擴容；
⑤ 安全
最後是安全，需要符合審計要求，不容易出現 SQL 注入或拖庫情況。
⑥ 其他
除了採購和 DBA之外，後臺應用研發的同學同樣會關注穩定性、性能、擴展性等問題，同時也非常關注數據庫接口是否便於開發，是否便於修改數據庫 schema 等問題。
接下來我們來看一下愛奇藝使用的數據庫類型：
- MySQL，互聯網業務必備系統；
- TiDB，愛奇藝的 TiDB 實踐會有另外的具體介紹；
- Redis，KV 數據庫，互聯網公司標配；
- Couchbase，這個在愛奇藝用得比較多，但國內互聯網公司用得比較少，接下來的部分會詳細說明；
- 其他，比如 MongoDB、圖數據庫、自研 KV 數據庫 HiKV 等；
- 大數據分析相關係統，比如 Hive、Impala 等等。
可以看到愛奇藝的數據庫種類還是很多的，這會造成業務開發的同學可能不太清楚在他的業務場景下應該選用哪種數據庫系統。
那麼，我們先對這些數據庫按照接口（SQL、NoSQL）和麪向的業務場景（OLTP、OLAP）這兩位維度進行一個簡單非嚴謹的分類。
下圖中，左上角是面向 OLTP、支持 SQL 的這樣一類系統，例如 MySQL，一般支持事務不同的隔離級別， QPS 要求比較高，延時比較低，主要用於交易信息和關鍵數據的存儲，比如訂單、VIP 信息等。
左下角是 NoSQL 數據庫，是一類針對特殊場景做優化的系統，schema 一般比較簡單，吞吐量較高、延遲較低，一般用作緩存或者 KV 數據庫。
整個右側都是 OLAP 的大數據分析系統，包括 Clickhouse、Impala等，一般支持SQL、不支持事務，擴展性比較好，可以通過加機器增加數據的存儲量，響應延遲較長。
還有一類數據庫是比較中立的，在數據量比較小的時候性能比較好，在數據量較大或複雜查詢的時候性能也不差，一般通過不同的存儲引擎和查詢引擎來滿足不同的業務需求，我們把它叫做 HTAP，TiDB 就是這樣一種數據庫。