作者：郭磊濤截亦，愛奇藝數(shù)據(jù)庫和中間件負(fù)責(zé)人爬泥，TiDB User Group Ambassador。本文系 TUG 北京區(qū) 9 月線下活動 “不同業(yè)務(wù)場景下的數(shù)據(jù)庫技術(shù)選型思路” 分享實錄崩瓤。
我是愛奇藝的數(shù)據(jù)庫和中間件負(fù)責(zé)人郭磊濤袍啡，今天主要向大家分享數(shù)據(jù)庫選型方面的思路，供大家參考和學(xué)習(xí)却桶。我們進(jìn)行數(shù)據(jù)庫選型的時候要考慮哪些問題葬馋？有哪些需求？待選用的數(shù)據(jù)庫是否和需求對的上肾扰？是不是直接就可以拿來用畴嘶？需不需要一些額外的開發(fā)？這些都會在今天的分享中提及集晚。
我們做選型的時候首先要問：
誰選型窗悯？是負(fù)責(zé)采購的同學(xué)、 DBA 還是業(yè)務(wù)研發(fā)偷拔？
如果選型的是采購的同學(xué)蒋院，他們更注重成本，包括存儲方式莲绰、網(wǎng)絡(luò)需求等欺旧。
如果選型的是 DBA 同學(xué)，他們關(guān)心的：
- 首先是運維成本蛤签，包括監(jiān)控告警是否完善辞友、是否有備份恢復(fù)機(jī)制、升級和遷移的成本是否高震肮、社區(qū)是否穩(wěn)定称龙、是否方便調(diào)優(yōu)、排障是否簡易等戳晌；
- 其次DBA會關(guān)注穩(wěn)定性鲫尊，包括是否支持?jǐn)?shù)據(jù)多副本、服務(wù)高可用沦偎、多寫多活等疫向；
- 第三是性能咳蔚，包括延遲、QPS 以及是否支持更高級的分級存儲功能等搔驼；
- 第四是擴(kuò)展性谈火，如果業(yè)務(wù)的需求不確定，是否容易橫向擴(kuò)展和縱向擴(kuò)容匙奴；最后是安全，需要符合審計要求妄荔，不容易出現(xiàn) SQL 注入或拖庫情況泼菌。
除了采購和 DBA之外，后臺應(yīng)用研發(fā)的同學(xué)同樣會關(guān)注穩(wěn)定性啦租、性能哗伯、擴(kuò)展性等問題，同時也非常關(guān)注數(shù)據(jù)庫接口是否便于開發(fā)篷角，是否便于修改數(shù)據(jù)庫 schema 等問題焊刹。
接下來我們來看一下愛奇藝使用的數(shù)據(jù)庫類型。
- MySQL恳蹲， 互聯(lián)網(wǎng)業(yè)務(wù)必備系統(tǒng)虐块；
- TiDB；愛奇藝的 TiDB 實踐會有另外的具體介紹嘉蕾；
- Redis, KV 數(shù)據(jù)庫贺奠，互聯(lián)網(wǎng)公司標(biāo)配；
- Couchbase错忱，這個在愛奇藝用的比較多儡率，但國內(nèi)互聯(lián)網(wǎng)公司用的比較少，接下來的部分會詳細(xì)說明以清；
- 其他儿普，比如 MongoDB、圖數(shù)據(jù)庫掷倔、自研 KV 數(shù)據(jù)庫 HiKV 等眉孩；
- 大數(shù)據(jù)分析相關(guān)系統(tǒng)，比如 Hive勒葱、Impala 等等勺像。
可以看到愛奇藝的數(shù)據(jù)庫種類還是很多的，這會造成業(yè)務(wù)開發(fā)的同學(xué)可能不太清楚在他的業(yè)務(wù)場景下應(yīng)該選用哪種數(shù)據(jù)庫系統(tǒng)错森。那么吟宦，我們先對這些數(shù)據(jù)庫按照接口（SQL，NoSQL）和面向的業(yè)務(wù)場景（OLTP, OLAP）這兩位維度進(jìn)行一個簡單非嚴(yán)謹(jǐn)?shù)姆诸悺?/p>
左上角是面向 OLTP涩维、支持 SQL 的這樣一類系統(tǒng)殃姓，例如 MySQL袁波，一般支持事務(wù)不同的隔離級別， QPS 要求比較高蜗侈，延時比較低篷牌，主要用于交易信息和關(guān)鍵數(shù)據(jù)的存儲，比如訂單踏幻、VIP 信息等枷颊。
左下角是 NoSQL 數(shù)據(jù)庫，是一類針對特殊場景做優(yōu)化的系統(tǒng)该面，schema 一般比較簡單夭苗，吞吐量較高、延遲較低隔缀，一般用作緩存或者 KV 數(shù)據(jù)庫题造。
整個右側(cè)都是 OLAP 的大數(shù)據(jù)分析系統(tǒng)，包括 Clickhouse猾瘸、Impala等界赔，一般支持SQL、不支持事務(wù)牵触，擴(kuò)展性比較好淮悼，可以通過加機(jī)器增加數(shù)據(jù)的存儲量，響應(yīng)延遲較長揽思。
還有一類數(shù)據(jù)庫是比較中立的敛惊，在數(shù)據(jù)量比較小的時候性能比較好，在數(shù)據(jù)量較大或復(fù)雜查詢的時候性能也不差绰更，一般通過不同的存儲引擎和查詢引擎來滿足不同的業(yè)務(wù)需求瞧挤，我們把它叫做 HTAP，TiDB 就是這樣一種數(shù)據(jù)庫儡湾。
前面我們提到了很多種的數(shù)據(jù)庫特恬，那么接下來就和大家介紹一下在愛奇藝我們是怎么使用這些數(shù)據(jù)庫的。
MySQL 在愛奇藝的使用
首先是 MySQL徐钠。MySQL 基本使用方式是 master-slave + 半同步癌刽，支持每周全備+每日增量備份。我們做了一些基本功能的增強(qiáng)尝丐，首先是增強(qiáng)了數(shù)據(jù)恢復(fù)工具 Xtrabackup 的性能显拜。之前遇到一個情況，我們有一個全量庫是 300G 數(shù)據(jù)爹袁，增量庫每天 70G 數(shù)據(jù)远荠，總數(shù)據(jù)量 700G 左右。我們當(dāng)時只需要恢復(fù)一個表的數(shù)據(jù)失息，但該工具不支持單表恢復(fù)譬淳，且整庫恢復(fù)需要 5 個小時档址。針對這個情況我們具體排查了原因，發(fā)現(xiàn)在數(shù)據(jù)恢復(fù)的過程中需要進(jìn)行多次寫盤的 IO 操作并且有很多串行操作邻梆，所以我們做了一些優(yōu)化守伸，例如刪減過程中的一些寫盤操作，減少落盤并將數(shù)據(jù)處理并行化浦妄，優(yōu)化后整庫恢復(fù)耗時減少到 100 分鐘尼摹，而且可以直接恢復(fù)單表數(shù)據(jù)。
第二是適配 DDL 和 DML 工具到內(nèi)部系統(tǒng)剂娄，gh-ostt 和 oak-online-alter-table 在數(shù)據(jù)量大的時候會造成 master-slave 延時蠢涝，所以我們在使用工具的時候也增加了延時上的考慮，實時探測Master-Slave 庫之間延時的情況宜咒，如果延時較大會暫停工具的使用惠赫，恢復(fù)到正常水平再繼續(xù)把鉴。
第二是 MySQL 高可用故黑。Master-slave 加上半同步這種高可用方式不太完善，所以我們參照了 MHA 并進(jìn)行了改動庭砍，采用 master + agent 的方式场晶。Agent 在每一個物理機(jī)上部署，可以監(jiān)控這個物理機(jī)上的所有實例的狀態(tài)怠缸，周期性地向 master 發(fā)送心跳诗轻，Master 會實時監(jiān)測各個Agent的狀態(tài)。如果 MySQL故障揭北，會啟動 Binlog 補(bǔ)償機(jī)制扳炬，并切換訪問域名完成 failover∩μ澹考慮到數(shù)據(jù)庫跨機(jī)房跨地區(qū)部署的情況恨樟，MHA 的 master 我們也做了高可用設(shè)計，眾多 master 會通過 raft 組成一個 raft group句喜，類似 TiDB 的 PD 模塊牲览。目前 MySQL failover 策略支持三種方式：同機(jī)房灰伟、同地域跨機(jī)房以及跨地域。
第三是提高M(jìn)ySQL擴(kuò)展能力养晋，以提供更大容量的數(shù)據(jù)存儲。擴(kuò)展方式有 SDK梁钾，例如開源的 ShardingSphere绳泉，在愛奇藝的使用也比較廣泛。另外就是 Proxy姆泻，開源的就更多了圈纺。但是 SDK 和 Proxy 使用的問題是支持的 SQL 語句簡單秦忿，擴(kuò)容難度大，依賴較多且運維復(fù)雜蛾娶，所以部分業(yè)務(wù)已經(jīng)遷移至 TiDB灯谣。
第四是審計。我們在 MySQL 上做了一個插件獲取全量 SQL 操作蛔琅，后端打到 Kafka胎许，下游再接入包括 Clickhouse 等目標(biāo)端進(jìn)行 SQL 統(tǒng)計分析。除此之外還有安全策略罗售，包括主動探索是否有 SQL 注入及是否存在拖庫情況等辜窑，并觸發(fā)對應(yīng)的告警。 MySQL 審計插件最大的問題是如何降低對 MySQL 性能的影響寨躁，對此我們進(jìn)行了一些測試穆碎，發(fā)現(xiàn)使用 General Log 對性能損耗較大，有 10%~20% 的降低职恳。于是我們通過接口來獲取 MySQL 插件里的監(jiān)控項所禀，再把監(jiān)控項放到 buffer 里邊，用兩級的 RingBuffer 來保證數(shù)據(jù)的寫入不會有鎖資源競爭放钦。在這個插件里再啟動一個線程色徘，從 RingBuffer 里讀取數(shù)據(jù)并把數(shù)據(jù)打包寫到 FIFO 管道里。我們在每臺 MySQL 的物理機(jī)里再啟動一個 Agent操禀，從管道里阻塞地讀取數(shù)據(jù)發(fā)至 Kafka褂策。優(yōu)化后我們再次進(jìn)行壓測，在每臺機(jī)器上有 15 萬的更新颓屑、刪除或插入操作下不會丟失數(shù)據(jù)斤寂，性能損耗一般情況下小于 2%。目前已經(jīng)在公司內(nèi)部的集群上線了一年時間揪惦，運行比較穩(wěn)定遍搞，上線和下線對業(yè)務(wù)沒有影響。
第五是分級存儲丹擎。MySQL 里會存一些過程性的數(shù)據(jù)尾抑，即只需要讀寫最近一段時間存入的數(shù)據(jù)，過段時間這些數(shù)據(jù)就不需要了蒂培，需要進(jìn)行定時清理再愈。分級存儲就是在 MySQL 之上又用了其他存儲方式，例如 TiDB 或其他 TokuDB护戳，兩者之間可以進(jìn)行數(shù)據(jù)自動搬遷和自動歸檔翎冲，同時前端通過 SDK + Proxy 來做統(tǒng)一的訪問入口。這樣一來媳荒，業(yè)務(wù)的開發(fā)同學(xué)只需要將數(shù)據(jù)存入 MySQL 里抗悍，讀取時可能從后端接入的任意數(shù)據(jù)庫讀出驹饺。這種方式目前只是過渡使用，之后會根據(jù) TiDB 的特性進(jìn)行逐步遷移缴渊。
Redis 在愛奇藝的使用
接下來是 Redis赏壹。Redis 也是使用 master - slave 這種方式，由于網(wǎng)絡(luò)的復(fù)雜性我們對 Sentinel 的部署進(jìn)行了一些特殊配置衔沼，在多機(jī)房的情況下每個機(jī)房配置一定數(shù)量 Sentinel 來避免腦裂蝌借。
備份恢復(fù)方面介紹一個我們的特殊場景，雖然 Redis 是一個緩存指蚁，但我們發(fā)現(xiàn)不少的業(yè)務(wù)同學(xué)會把它當(dāng)做一個 KVDB 來使用菩佑，在某些情況下會造成數(shù)據(jù)的丟失。所以我們做了一個 Redis 實時備份功能凝化，啟動一個進(jìn)程偽裝成 Redis 的 Slave 實時獲取數(shù)據(jù)稍坯，再放到后端的 KV 存儲里，例如 ScyllaDB搓劫，如果要恢復(fù)就可以從 ScyllaDB 里把數(shù)據(jù)拉出來瞧哟。我們在用 Redis 時最大的痛點就是它對網(wǎng)絡(luò)的延遲或抖動非常敏感。如有抖動造成 Redis Master 超時糟把，會由 Sentinel 重新選出一個新的節(jié)點成為 Master绢涡，再把該節(jié)點上的數(shù)據(jù)同步到所有 Slave 上牲剃，此過程中數(shù)據(jù)會放在 Master 節(jié)點的 Buffer 里遣疯，如果寫入的 QPS 很高會造成 Buffer 滿溢。如果 Buffer 滿后 RDB 文件還沒有拷貝過去凿傅，重建過程就會失敗缠犀。
基于這種情況，我們對 Redis 告警做了自動化優(yōu)化聪舒，如有大量 master - slave 重建失敗辨液，我們會動態(tài)調(diào)整一些參數(shù)，例如把 Buffer 臨時調(diào)大等箱残， 此外我們還做了 Redis 集群的自動擴(kuò)縮容功能滔迈。
我們在做 Redis 開發(fā)時如果是 Java 語言都會用到 Jedis。用 Jedis 訪問客戶端分片的 Redis 集群被辑，如果某個分片發(fā)生了故障或者 failover燎悍，Jedis 就會對所有后端的分片重建連接。如果某一分片發(fā)生問題盼理，整個 Redis 的訪問性能和 QPS 會大幅降低谈山。針對這個情況我們優(yōu)化了 Jedis，如果某個分片發(fā)生故障宏怔，就只針對這個分片進(jìn)行重建奏路。
在業(yè)務(wù)訪問 Redis 時我們會對 Master 綁定一個讀寫域名畴椰，多個從庫綁定讀域名。但如果我們進(jìn)行 Master failover鸽粉，會將讀寫域名從某舊 Master 解綁斜脂，再綁定到新 Master 節(jié)點上。DNS 本身有一個超時時間触机，所以數(shù)據(jù)庫做完 failover 后業(yè)務(wù)程序里沒有立刻獲取到新的 Master 節(jié)點的 IP的話秽褒，有可能還會連到原來的機(jī)器上，造成訪問失敗威兜。我們的解決方法是把 DNS 的 TTL 縮短销斟，但對 DNS 服務(wù)又會造成很大的壓力，所以我們在 SDK 上提供 Redis 的名字服務(wù) RNS椒舵，RNS 從 Sentinel 里獲取集群的拓?fù)浜屯負(fù)涞淖兓闆r蚂踊，如果集群 failover，Sentinel 會接到通知笔宿，客戶端就可以通過 RNS 來獲取新的 Master 節(jié)點的 IP 地址犁钟。我們?nèi)サ粲蛎ㄟ^ IP 地址來訪問整個集群泼橘，屏蔽了 DNS 的超時涝动，縮短了故障的恢復(fù)時間。SDK 上還做了一些功能炬灭，例如 Load Balance 以及故障檢測醋粟，比如某個節(jié)點延時較高的話會被臨時熔斷等。
客戶端分片的方式會造成 Redis 的擴(kuò)容非常痛苦重归，如果客戶端已經(jīng)進(jìn)行了一定量的分片米愿，之后再增加就會非常艱難。Redis 在 3.0 版本后會提供 Redis Cluster鼻吮，因為功能受限在愛奇藝應(yīng)用的不是很多育苟，例如不支持顯示跨 DC 部署和訪問，讀寫只在主庫上等椎木。我們某些業(yè)務(wù)場景下會使用 Redis 集群违柏，例如數(shù)據(jù)庫訪問只發(fā)生在本 DC，我們會在 DC 內(nèi)部進(jìn)行 Cluster 部署香椎。但有些業(yè)務(wù)在使用的過程中還是想做 failover漱竖，如果集群故障可以切換到其他集群。根據(jù)這種情況我們做了一個 Proxy士鸥，讀寫都通過它來進(jìn)行闲孤。寫入數(shù)據(jù)時 Proxy 會做一個旁路，把新增的數(shù)據(jù)寫在 Kafka 里，后臺啟用同步程序再把 Kafka 里的數(shù)據(jù)同步到其他集群讼积，但存在一些限制肥照，比如我們沒有做沖突檢測，所以集群間數(shù)據(jù)需要業(yè)務(wù)的同學(xué)做單元化勤众。線上環(huán)境的Redis Cluster 集群間場景跨 DC 同步 需要 50 毫秒左右的時間舆绎。
Couchbase 在愛奇藝的使用
Redis 雖然提供 Cluster 這種部署方式，但存在一些問題们颜。所以數(shù)據(jù)量較大的時候（經(jīng)驗是 160G）吕朵，就不推薦 Redis 了，而是采用另一種存儲方式 Couchbase窥突。
Couchbase 在國內(nèi)互聯(lián)網(wǎng)公司用的比較少努溃，一開始我們是把他當(dāng)做一個 Memcached 來使用的，即純粹的緩存系統(tǒng)阻问。但其實它性能還是比較強(qiáng)大的梧税，是一個分布式高性能的 KV 系統(tǒng)，支持多種存儲引擎 (bucket)称近。第一種是 Memcached bucket第队，使用方式和 Memcached 一樣為 KV 存儲，不支持?jǐn)?shù)據(jù)持久化也沒有數(shù)據(jù)副本刨秆，如果節(jié)點故障會丟失數(shù)據(jù)凳谦；第二種是 Couchbase bucket，支持?jǐn)?shù)據(jù)持久化衡未，使用 Json 寫入尸执，有副本，我們一般會在線上配置兩個副本眠屎，如果新加節(jié)點會對數(shù)據(jù)進(jìn)行 rebalance剔交，愛奇藝使用的一般是 Couchbase bucket 這種配置肆饶。Couchbase 數(shù)據(jù)的分布如右圖改衩，數(shù)據(jù)寫入時在客戶端上會先進(jìn)行一次哈希運算，運算完后會定位 Key 在哪一個 vBucket （相當(dāng)于數(shù)據(jù)庫里的某個分片）驯镊。之后客戶端會根據(jù) Cluster Map 發(fā)送信息至對應(yīng)的服務(wù)端葫督，客戶端的 Cluster Map 保存的是 vBucket 和服務(wù)器的映射關(guān)系，在服務(wù)端數(shù)據(jù)遷移的過程中客戶端的 Cluster Map 映射關(guān)系會動態(tài)更新板惑，因此客戶端對于 服務(wù)端的 failover 操作不需要做特殊處理橄镜，但可能在 rebalance 過程中會有短暫的超時，導(dǎo)致的告警對業(yè)務(wù)影響不大冯乘。
Couchbase 在愛奇藝應(yīng)用比較早洽胶，2012 年還沒有 Redis Cluster 的時候就開始使用了。集群管理使用 erlang 語言開發(fā)裆馒，最大功能是進(jìn)行集群間的復(fù)制姊氓，提供多種復(fù)制方式：單向丐怯、雙向、星型翔横、環(huán)式读跷、鏈?zhǔn)降取燮嫠噺淖畛醯?1.8 版本使用到如今的 5.0 版本禾唁，正在調(diào)研 6.0效览。中間也遇到了很多坑，例如 NTP 時間配置出錯會導(dǎo)致崩潰荡短，如果每個集群對外 XDCR 并發(fā)過高導(dǎo)致不穩(wěn)定丐枉，同步方向變更會導(dǎo)致數(shù)據(jù)丟失等等，我們通過運維和一些外部工具來進(jìn)行規(guī)避掘托。
Couchbase 的集群是獨立集群矛洞，集群間的數(shù)據(jù)同步通過 XDCR，我們一般配置為雙向同步烫映。對于業(yè)務(wù)來說沼本，如果 Cluster 1 寫入， Cluster 2 不寫入锭沟，正常情況下客戶端會寫 Cluster 1抽兆。如果 Cluster 1 有故障，我們提供了一個 Java SDK族淮，可以在配置中心把寫入更改到 Cluster 2辫红，把原來到 Cluster 1 的連接逐步斷掉再與Cluster 2 新建連接。這種集群 failover 的過程對于客戶端來說是相對透明和無感的祝辣。
愛奇藝自研數(shù)據(jù)庫 HiKV 的使用
Couchbase 雖然性能非常高贴妻，并且數(shù)據(jù)的存儲可以超過內(nèi)存。但是蝙斜，如果數(shù)據(jù)量超過內(nèi)存 75% 這個閾值名惩，性能就會下降地特別快。在愛奇藝孕荠，我們會把數(shù)據(jù)量控制在可用內(nèi)存的范圍之內(nèi)娩鹉，當(dāng)做內(nèi)存數(shù)據(jù)庫使用。但是它的成本非常高稚伍，所以我們后面又開發(fā)了一個新的數(shù)據(jù)庫—— HiKV弯予。
開發(fā) HiKV 的目的是為了把一些對性能要求沒那么高的 Couchbase 應(yīng)用遷移到 HiKV 上。HiKV 基于開源系統(tǒng) ScyllaDB个曙，主要使用了其分布式數(shù)據(jù)庫的管理功能锈嫩，增加了單機(jī)存儲引擎 HiKV。 ScyllaDB 比較吸引人的是它宣稱性能高于 Cassandra 十倍，又完全兼容 Cassandra 接口呼寸，設(shè)計基本一致那槽，可以視為 C++ 版 Cassandra 系統(tǒng)。 ScyllaDB 性能的提升主要是使用了一些新的技術(shù)框架等舔，例如 C++ 異步框架 seastar骚灸，主要原理是在j每臺物理機(jī)的核上會 attach 一個應(yīng)用線程，每個核上有自己獨立的內(nèi)存慌植、網(wǎng)絡(luò)甚牲、IO 資源，核與核之間沒有數(shù)據(jù)共享但可以通信蝶柿，其最大的好處是內(nèi)存訪問無鎖丈钙，沒有沖突過程。當(dāng)一個數(shù)據(jù)讀或?qū)懙竭_(dá) ScyllaDB 的 server 時交汤，會按照哈希算法來判斷請求的 Key 是否是該線程需要處理的雏赦，如果是則本線程處理，否則會轉(zhuǎn)發(fā)到對應(yīng)線程上去芙扎。除此之外星岗，它還支持多副本、多數(shù)據(jù)中心戒洼、多寫多活俏橘，功能比較強(qiáng)大。
在愛奇藝圈浇，我們基于 SSD 做了一個 KV 存儲引擎寥掐。Key 放在內(nèi)存里，Value 放在盤上的文件里磷蜀，我們在讀和寫文件時召耘，只需要在內(nèi)存索引里定位，再進(jìn)行一次盤的 IO 開銷就可以把數(shù)據(jù)讀出來褐隆，相比 ScyllaDB 原本基于 LSM Tree 的存儲引擎方式對 IO 的開銷較少污它。索引數(shù)據(jù)全部放在內(nèi)存中，如果索引長度較長會限制單機(jī)可存儲的數(shù)據(jù)量妓灌，于是我們通過開發(fā)定長的內(nèi)存分布器轨蛤，對于比較長的 Key 做摘要縮短長度至 20 字節(jié)，采用紅黑樹索引虫埂，限制每條記錄在內(nèi)存里的索引長度至為 64 字節(jié)。內(nèi)存數(shù)據(jù)要定期做 checkpoint圃验，客戶端要做限流掉伏、熔斷等。
HiKV 目前在愛奇藝應(yīng)用范圍比較大，截至目前已經(jīng)替換了 30% 的 Couchbase斧散，有效地降低了存儲成本供常。
愛奇藝的數(shù)據(jù)庫運維管理
愛奇藝數(shù)據(jù)庫種類較多，如何高效地運維和管理這些數(shù)據(jù)庫也是經(jīng)歷了不同的階段鸡捐。
最初我們通過 DBA 寫腳本的方式管理栈暇，如果腳本出問題就找 DBA，導(dǎo)致了 DBA 特別忙碌箍镜。
第二個階段我們考慮讓大家自己去查問題的答案源祈，于是在內(nèi)部構(gòu)建了一個私有云，通過 Web 的方式展示數(shù)據(jù)庫運行狀態(tài)色迂，讓業(yè)務(wù)的同學(xué)可以自己去申請集群香缺，一些簡單地操作也可以通過自服務(wù)平臺實現(xiàn)，解放了 DBA歇僧。一些需要人工處理的大型運維操作經(jīng)常會造成一些人為故障图张，敲錯參數(shù)造成數(shù)據(jù)丟失等。
于是在第三個階段我們把運維操作 Web 化诈悍，通過網(wǎng)頁點擊可以進(jìn)行 90% 的操作祸轮。
第四個階段讓經(jīng)驗豐富的 DBA 把自身經(jīng)驗變成一些工具，比如有業(yè)務(wù)同學(xué)說 MySQL master-slave 延時了侥钳，DBA 會通過一系列操作排查問題【笞玻現(xiàn)在我們把這些操作串起來形成一套工具，出問題時業(yè)務(wù)的同學(xué)可以自己通過網(wǎng)頁上的一鍵診斷工具去排查慕趴，自助進(jìn)行處理痪蝇。除此之外我們還會定期做預(yù)警檢查，對業(yè)務(wù)集群里潛在的問題進(jìn)行預(yù)警報告冕房；開發(fā)智能客服躏啰，回答問題；通過監(jiān)控的數(shù)據(jù)對實例打標(biāo)簽耙册，進(jìn)行削峰填谷地智能調(diào)度给僵，提高資源利用率。
實用數(shù)據(jù)庫選型樹：快速進(jìn)行數(shù)據(jù)庫選型
最后來說一些具體數(shù)據(jù)庫選型建議详拙。這是 DBA 和業(yè)務(wù)一起帝际，通過經(jīng)驗得出來的一些結(jié)論。對于關(guān)系型數(shù)據(jù)庫的選型來說饶辙，可以從數(shù)據(jù)量和擴(kuò)展性兩個維度考慮蹲诀，再根據(jù)數(shù)據(jù)庫有沒有冷備、要不要使用 Toku 存儲引擎弃揽，要不要使用 Proxy 等等進(jìn)行抉擇脯爪。
NoSQL 也是什么情況下使用 master-slave则北，什么情況下使用客戶端分片、集群痕慢、Couchbase尚揣、HiKV 等，我們內(nèi)部自服務(wù)平臺上都有這個選型樹信息掖举。
一些思考
我們在選形時先思考需求快骗，判斷需求是否真實。你可以從數(shù)據(jù)量塔次、QPS方篮、延時等方面考慮需求，但這些都是真實需求嗎俺叭？是否可以通過其他方式把這個需求消耗掉恭取，例如在數(shù)據(jù)量大的情況下可以先做數(shù)據(jù)編碼或者壓縮，數(shù)據(jù)量可能就降下來了熄守。不要把所有需求都推到數(shù)據(jù)庫層面蜈垮，它其實是一個兜底的系統(tǒng)。
第二個思考的點是對于某個數(shù)據(jù)庫系統(tǒng)或是某個技術(shù)選型我們應(yīng)該考慮什么裕照？是因為熱門嗎攒发？還是因為技術(shù)上比較先進(jìn)？但是不是能真正地解決你的問題晋南？如果你數(shù)據(jù)量不是很大的話就不需要選擇可以存儲大數(shù)據(jù)量的系統(tǒng)惠猿。
第三是放棄，當(dāng)你放棄一個系統(tǒng)時真的是因為不好用嗎负间？還是沒有用好偶妖？放棄一個東西很難，但在放棄時最好有一個充分的理由政溃，包括實測的結(jié)果趾访。
第四是自研，在需要自己開發(fā)數(shù)據(jù)庫時可以參考和使用一些成熟的產(chǎn)品董虱，但不要盲目自研扼鞋。
最后是開源，要有擁抱開源的態(tài)度愤诱。
文章首發(fā)于 TiDB User Group (TUG) 線上問答社區(qū) AskTUG：https://asktug.com/t/topic/1396
