我們?cè)谶x擇數(shù)據(jù)庫(kù)時(shí)應(yīng)該考慮哪些問(wèn)題？ 你有什么需求？ 所選擇的數(shù)據(jù)庫(kù)是否符合要求？ 可以直接用嗎？ 需要一些額外的開(kāi)發(fā)？ 這個(gè)在本文的分享中會(huì)提到。

一、數(shù)據(jù)庫(kù)技術(shù)選型的思考維度

當(dāng)我們進(jìn)行選擇時(shí)，我們首先會(huì)問(wèn)：

誰(shuí)選擇？ 是負(fù)責(zé)采購(gòu)的朋友，DBA還是業(yè)務(wù)開(kāi)發(fā)的？

如果是采購(gòu)的朋友，他們更看重成本，包括存儲(chǔ)方式、網(wǎng)絡(luò)要求等。

如果你選擇一個(gè) DBA 朋友，他們關(guān)心的是：

①運(yùn)維成本

首先是運(yùn)維成本，包括監(jiān)控告警是否健全，是否有備份恢復(fù)機(jī)制，升級(jí)遷移成本是否高，社區(qū)是否穩(wěn)定，調(diào)優(yōu)是否方便，是否容易排錯(cuò)；

②穩(wěn)定性

其次，DBA會(huì)關(guān)注穩(wěn)定性，包括是否支持?jǐn)?shù)據(jù)多副本、服務(wù)的高可用、多寫(xiě)多活等；

③性能

第三是性能，包括延遲、QPS、是否支持更多的中間分層存儲(chǔ)功能等；

④ 擴(kuò)展性

第四個(gè)是可擴(kuò)展性。 如果業(yè)務(wù)需求不確定，是否容易縱向橫向擴(kuò)展；

⑤安全

最后是安全性，必須滿(mǎn)足審計(jì)要求，不容易出現(xiàn)SQL注入或者數(shù)據(jù)庫(kù)拖拽。

⑥其他

除了采購(gòu)和DBA，開(kāi)發(fā)后臺(tái)應(yīng)用的朋友也會(huì)關(guān)注穩(wěn)定性、性能、擴(kuò)展性等問(wèn)題。 同時(shí)，他們也很關(guān)心數(shù)據(jù)庫(kù)是否好開(kāi)發(fā)，是否容易改數(shù)據(jù)庫(kù)。

接下來(lái)我們看一下愛(ài)奇藝使用的數(shù)據(jù)庫(kù)類(lèi)型：

由此可見(jiàn)，愛(ài)奇藝的數(shù)據(jù)庫(kù)種類(lèi)還是比較多的，這可能會(huì)導(dǎo)致業(yè)務(wù)開(kāi)發(fā)的朋友不清楚在自己的業(yè)務(wù)場(chǎng)景中應(yīng)該選擇哪種數(shù)據(jù)庫(kù)系統(tǒng)。

那么，我們先按照（SQL、NoSQL）和業(yè)務(wù)場(chǎng)景（OLTP、OLAP）兩個(gè)維度，對(duì)這類(lèi)數(shù)據(jù)庫(kù)做一個(gè)簡(jiǎn)單的、不嚴(yán)謹(jǐn)?shù)姆诸?lèi)。

右圖中，左上角是一類(lèi)面向OLTP，支持SQL的系統(tǒng)，比如MySQL，通常對(duì)事務(wù)支持不同的隔離級(jí)別，對(duì)QPS要求比較高，延遲也比較低，主要用于交易信息和關(guān)鍵數(shù)據(jù)的存儲(chǔ)。 比如訂單、VIP信息等。

左下角是NoSQL數(shù)據(jù)庫(kù)，是針對(duì)特殊場(chǎng)景優(yōu)化的一類(lèi)系統(tǒng)。 它通常比較簡(jiǎn)單，具有高吞吐量和低延遲。 它通常用作緩存或 KV 數(shù)據(jù)庫(kù)。

整個(gè)右側(cè)是OLAP大數(shù)據(jù)分析系統(tǒng)，包括等，通常支持SQL，不支持事務(wù)，擴(kuò)展性較好。 可以通過(guò)增加機(jī)器來(lái)減少數(shù)據(jù)存儲(chǔ)量，響應(yīng)延遲更長(zhǎng)。

還有一類(lèi)數(shù)據(jù)庫(kù)相對(duì)中性。 它在數(shù)據(jù)量比較小的時(shí)候表現(xiàn)比較好，在數(shù)據(jù)量大或者復(fù)雜查詢(xún)的時(shí)候表現(xiàn)也不錯(cuò)。 通常，使用不同的存儲(chǔ)引擎和查詢(xún)引擎來(lái)滿(mǎn)足不同的需求。 業(yè)務(wù)需求，我們稱(chēng)之為HTAP，TiDB就是這樣一個(gè)數(shù)據(jù)庫(kù)。

2.愛(ài)奇藝優(yōu)化建立數(shù)據(jù)庫(kù)

后面我們講了很多種數(shù)據(jù)庫(kù)，我給大家介紹一下我們?cè)趷?ài)奇藝是怎么使用這種數(shù)據(jù)庫(kù)的。

一、MySQL在愛(ài)奇藝的使用

①M(fèi)ySQL

首先是MySQL。 MySQL的基本使用方式是-slave+半同步，支持每周全量備份+每天增量備份。 我們進(jìn)行了一些基本的功能增強(qiáng)，首先是提高數(shù)據(jù)恢復(fù)工具的性能。

我之前遇到過(guò)一個(gè)情況。 我們有一個(gè)300G數(shù)據(jù)的全量數(shù)據(jù)庫(kù)，一個(gè)每晚70G數(shù)據(jù)的增量數(shù)據(jù)庫(kù)，總數(shù)據(jù)量大約700G。 當(dāng)時(shí)我們只需要恢復(fù)一張表的數(shù)據(jù)，但是工具不支持單表恢復(fù)，整個(gè)數(shù)據(jù)庫(kù)恢復(fù)需要5個(gè)小時(shí)。

針對(duì)這種情況，我們?cè)敿?xì)排查了原因，發(fā)現(xiàn)在數(shù)據(jù)恢復(fù)的過(guò)程中，需要進(jìn)行多次寫(xiě)磁盤(pán)的IO操作和大量的串行操作，所以我們做了一些優(yōu)化。 比如剪枝過(guò)程中的一些磁盤(pán)寫(xiě)操作，可以減少磁盤(pán)數(shù)量，并行處理數(shù)據(jù)。 優(yōu)化后全庫(kù)恢復(fù)時(shí)間縮短至100分鐘，單表數(shù)據(jù)可直接恢復(fù)。

然后在內(nèi)部系統(tǒng)適配DDL和DML工具，gh-ostt和oak--alter-table在數(shù)據(jù)量大的時(shí)候會(huì)造成-slave延遲，所以我們?cè)谑褂霉ぞ叩臅r(shí)候也要減少延遲考慮實(shí)時(shí)檢測(cè)Slave庫(kù)之間的延遲，如果延遲大于使用會(huì)議掛起工具，恢復(fù)到正常水平再繼續(xù)。

②MySQL高可用

二是MySQL高可用。 -slave加半同步等高可用的方式不好建立，所以我們參考MHA做改動(dòng)，采用+agent的形式。 Agent部署在每臺(tái)數(shù)學(xué)機(jī)上，可以監(jiān)控?cái)?shù)學(xué)機(jī)上所有實(shí)例的狀態(tài)，定期向服務(wù)器發(fā)送脈沖，實(shí)時(shí)檢測(cè)每個(gè)Agent的狀態(tài)。

如果MySQL出現(xiàn)故障，將啟動(dòng)補(bǔ)償機(jī)制，完成訪問(wèn)域名的切換。 考慮到數(shù)據(jù)庫(kù)跨機(jī)房、跨區(qū)域的部署，我們也對(duì)MHA做了高可用的設(shè)計(jì)，其中很多會(huì)通過(guò)raft組成一個(gè)，類(lèi)似于TiDB的PD模塊。 目前MySQL策略支持三種形式：同機(jī)房、同地域跨機(jī)房、跨地域。

③MySQL擴(kuò)展能力

三是增強(qiáng)MySQL的擴(kuò)展能力，提供更大容量的數(shù)據(jù)存儲(chǔ)。 擴(kuò)展方式有SDK，比如開(kāi)源的，在愛(ài)奇藝也有廣泛使用。 另一個(gè)是Proxy，開(kāi)源的比較多。 而且使用SDK和Proxy的問(wèn)題是支持的SQL語(yǔ)句簡(jiǎn)單，擴(kuò)展困難，依賴(lài)多，運(yùn)維復(fù)雜，所以部分業(yè)務(wù)已經(jīng)遷移到TiDB。

④審計(jì)

四是審計(jì)。 我們?cè)贛ySQL上做了一個(gè)插件，獲取完整的SQL操作，前端打Kafka，下游訪問(wèn)包括等待目標(biāo)端進(jìn)行SQL統(tǒng)計(jì)分析。 此外還有安全策略，包括主動(dòng)探索是否存在SQL注入和數(shù)據(jù)庫(kù)拖拽，并觸發(fā)相應(yīng)的告警。

MySQL審計(jì)插件最大的問(wèn)題是如何增加對(duì)MySQL性能的影響。 我們對(duì)此進(jìn)行了一些測(cè)試，發(fā)現(xiàn)使用Log有很大的性能損失，有10%到20%的提升。

所以我們?cè)贛ySQL插件中使用獲取監(jiān)控項(xiàng)，然后將監(jiān)控項(xiàng)放入其中，使用兩級(jí)保證數(shù)據(jù)寫(xiě)入不會(huì)出現(xiàn)鎖資源競(jìng)爭(zhēng)。 在這個(gè)插件中啟動(dòng)另一個(gè)線程，從中讀取數(shù)據(jù)并將數(shù)據(jù)打包到 FIFO 管道中。

我們?cè)诿颗_(tái)MySQL化學(xué)機(jī)中啟動(dòng)一個(gè)Agent，從管道中讀取數(shù)據(jù)并發(fā)送給Kafka。 優(yōu)化后，我們?cè)俅芜M(jìn)行了壓力測(cè)試。 每臺(tái)機(jī)器15萬(wàn)次、、操作下沒(méi)有數(shù)據(jù)丟失，性能損失通常大于2%。

目前公司集群已經(jīng)上線一年，運(yùn)行比較穩(wěn)定。 線上線下對(duì)業(yè)務(wù)沒(méi)有影響。

⑤ 分級(jí)存儲(chǔ)

五是分層存儲(chǔ)。 MySQL會(huì)存儲(chǔ)一些過(guò)程性的數(shù)據(jù)，即只需要讀寫(xiě)最近一段時(shí)間存儲(chǔ)的數(shù)據(jù)，一段時(shí)間后就不需要這種數(shù)據(jù)了，需要定時(shí)清除。

分層存儲(chǔ)是指在 MySQL 之上使用其他存儲(chǔ)方式，比如 TiDB 等。 兩者之間可以手動(dòng)移動(dòng)和歸檔數(shù)據(jù)，后臺(tái)使用SDK+Proxy作為統(tǒng)一的訪問(wèn)入口。 這樣業(yè)務(wù)開(kāi)發(fā)的朋友只需要將數(shù)據(jù)存儲(chǔ)在MySQL中，讀取時(shí)可以從前端連接的任意數(shù)據(jù)庫(kù)中讀取。 這些方法目前只是過(guò)渡使用，之后會(huì)根據(jù) TiDB 的特點(diǎn)逐步遷移。

二、Redis在愛(ài)奇藝的使用

連接是Redis。 Redis也使用了-slave的方法。 由于網(wǎng)絡(luò)的復(fù)雜性，我們針對(duì)部署做了一些特殊的配置。 在多個(gè)機(jī)房的情況下，每個(gè)機(jī)房配置一定的編號(hào)，以防止腦裂。

在備份和恢復(fù)方面，我們介紹一個(gè)特殊的場(chǎng)景。 Redis其實(shí)就是一個(gè)緩存，但是我們發(fā)現(xiàn)很多業(yè)務(wù)同學(xué)把它當(dāng)作KVDB來(lái)使用，在某些情況下可能會(huì)導(dǎo)致數(shù)據(jù)丟失。

于是我們做了一個(gè)Redis實(shí)時(shí)備份的功能，啟動(dòng)一個(gè)偽裝成Redis Slave的進(jìn)程實(shí)時(shí)獲取數(shù)據(jù)，然后放到前端的KV存儲(chǔ)中。 例如，如果你想恢復(fù)，你可以從中拉取數(shù)據(jù)。

我們?cè)谑褂?Redis 時(shí)最大的痛點(diǎn)是它對(duì)網(wǎng)絡(luò)延遲或者抖動(dòng)非常敏感。 如果有任何抖動(dòng)導(dǎo)致Redis超時(shí)，就會(huì)重新選舉一個(gè)新的節(jié)點(diǎn)，然后把這個(gè)節(jié)點(diǎn)上的數(shù)據(jù)同步到所有的slave上。 在這個(gè)過(guò)程中，數(shù)據(jù)會(huì)被放置在節(jié)點(diǎn)中。 如果寫(xiě)入的QPS很高，就會(huì)造成溢出。 如果RDB文件寫(xiě)滿(mǎn)后還沒(méi)有復(fù)制，重建過(guò)程就會(huì)失敗。

基于這些情況，我們對(duì)Redis告警進(jìn)行了手動(dòng)優(yōu)化。 如果有大量-slave重構(gòu)失敗，我們會(huì)動(dòng)態(tài)調(diào)整一些參數(shù)，比如臨時(shí)增加size等，我們也實(shí)現(xiàn)了Redis集群的手動(dòng)擴(kuò)縮容功能。 .

我們?cè)谧鯮edis開(kāi)發(fā)的時(shí)候，如果是Java語(yǔ)言，就會(huì)用到Jedis。 使用 Jedis 訪問(wèn)客戶(hù)端分片的 Redis 集群。 如果一個(gè)分片發(fā)生故障，Jedis 將重新連接所有前端分片。 如果某個(gè)分片出現(xiàn)問(wèn)題，整個(gè)Redis的訪問(wèn)性能和QPS都會(huì)急劇下降。 我們針對(duì)這種情況優(yōu)化了 Jedis。 如果一個(gè)分片失敗，它只會(huì)為這個(gè)分片重建。

當(dāng)業(yè)務(wù)訪問(wèn)Redis時(shí)，我們會(huì)綁定一個(gè)讀寫(xiě)域名，從庫(kù)中綁定多個(gè)讀寫(xiě)域名。 但是如果繼續(xù)的話，讀寫(xiě)域名會(huì)從一個(gè)舊的節(jié)點(diǎn)上解綁，然后綁定到一個(gè)新的節(jié)點(diǎn)上。

DNS本身有超時(shí)時(shí)間，所以如果業(yè)務(wù)程序在建庫(kù)完成后沒(méi)有立即獲取到新節(jié)點(diǎn)的IP，可能會(huì)連上原機(jī)，導(dǎo)致訪問(wèn)失敗。

我們的解決方案是縮短DNS的TTL，但是會(huì)對(duì)DNS服務(wù)造成很大的壓力，所以我們?cè)赟DK上提供了Redis名稱(chēng)服務(wù)RNS，RNS可以從中獲取集群拓?fù)浜屯負(fù)渥兓?如果是集群的話會(huì)通知，客戶(hù)端可以通過(guò)RNS獲取新節(jié)點(diǎn)的IP地址。 我們?nèi)サ粲蛎ㄟ^(guò)IP訪問(wèn)整個(gè)集群，屏蔽DNS超時(shí)，縮短故障恢復(fù)時(shí)間。

SDK上還有一些功能，比如Load，故障檢測(cè)等。 例如intellij idea 數(shù)據(jù)庫(kù)關(guān)系圖，如果一個(gè)節(jié)點(diǎn)延遲很高，它會(huì)被暫時(shí)吹滅。

客戶(hù)端分片的形式會(huì)導(dǎo)致Redis的擴(kuò)容非常痛苦。 如果客戶(hù)端已經(jīng)完成了一定量的分片，再減少就非常困難了。

Redis將在3.0版本之后提供Redis。 由于功能有限，愛(ài)奇藝?yán)锩娴膽?yīng)用并不多。 比如不支持跨DC部署訪問(wèn)，讀寫(xiě)只在主庫(kù)上。

我們?cè)趥€(gè)別業(yè)務(wù)場(chǎng)景中使用 Redis 集群。 比如數(shù)據(jù)庫(kù)訪問(wèn)只發(fā)生在這個(gè)DC，我們就部署在DC內(nèi)部。

但是，有些商家在使用過(guò)程中還是想做。 如果集群出現(xiàn)故障，可以切換到其他集群。 基于這些情況，我們做了一個(gè)Proxy，通過(guò)它進(jìn)行讀寫(xiě)。 Proxy在寫(xiě)數(shù)據(jù)的時(shí)候會(huì)做一個(gè)旁路，把新添加的數(shù)據(jù)寫(xiě)到Kafka里面，后臺(tái)開(kāi)啟同步程序，然后把Kafka里面的數(shù)據(jù)同步到其他集群，但是有一些限制，比如我們不做沖突檢查，所以集群的數(shù)據(jù)需要業(yè)務(wù)友們聯(lián)合起來(lái)。 有線環(huán)境Redis跨集群場(chǎng)景跨DC同步需要50微秒左右。

3.在愛(ài)奇藝中使用

Redis似乎提供了這些部署形式，但是存在一些問(wèn)題。 因此，當(dāng)數(shù)據(jù)量較大時(shí)（經(jīng)驗(yàn)是160G），不推薦使用Redis，而是采用另一種存儲(chǔ)方式。

國(guó)外的互聯(lián)網(wǎng)公司很少用。 一開(kāi)始我們把它當(dāng)成一個(gè)，也就是一個(gè)純緩存系統(tǒng)。

但是可能它的性能比較強(qiáng)，是一個(gè)分布式的高性能KV系統(tǒng)，支持多種存儲(chǔ)引擎（）。 第一種是使用和KV存儲(chǔ)一樣的方式，不支持?jǐn)?shù)據(jù)持久化，沒(méi)有數(shù)據(jù)副本。 如果節(jié)點(diǎn)發(fā)生故障，數(shù)據(jù)將丟失；

二是支持?jǐn)?shù)據(jù)持久化，用Json寫(xiě)，有副本。 我們一般在線配置兩份。 如果增加一個(gè)新的節(jié)點(diǎn)來(lái)進(jìn)行數(shù)據(jù)處理，愛(ài)奇藝通常會(huì)使用這些配置。

數(shù)據(jù)分布如右圖所示。 寫(xiě)入數(shù)據(jù)時(shí)，會(huì)先在客戶(hù)端進(jìn)行哈希運(yùn)算。 運(yùn)行后會(huì)定位到key（相當(dāng)于數(shù)據(jù)庫(kù)中的某個(gè)分片）。 以后會(huì)根據(jù)Map向?qū)?yīng)的發(fā)送信息。 客戶(hù)端的Map存儲(chǔ)著與服務(wù)端的映射關(guān)系。 在服務(wù)端數(shù)據(jù)遷移過(guò)程中，客戶(hù)端的Map映射關(guān)系會(huì)動(dòng)態(tài)更新。 因此，客戶(hù)端對(duì)服務(wù)端的操作無(wú)需特殊處理，但過(guò)程中可能會(huì)出現(xiàn)短暫的超時(shí)，由此產(chǎn)生的告警對(duì)業(yè)務(wù)影響不大。

愛(ài)奇藝的應(yīng)用比較早，2012年開(kāi)始用，當(dāng)時(shí)還沒(méi)有Redis。 集群管理是使用語(yǔ)言開(kāi)發(fā)的，其最大的功能是進(jìn)行集群間的復(fù)制，提供多種復(fù)制方式：雙向、雙向、星型、環(huán)型、鏈型等。

愛(ài)奇藝一直在用原來(lái)的1.8版本到現(xiàn)在的5.0版本，在監(jiān)管下的6.0，中間也遇到了很多坑，比如NTP時(shí)間配置錯(cuò)誤會(huì)導(dǎo)致死機(jī)，如果每個(gè)集群的外部XDCR并發(fā)是低，造成不穩(wěn)定，同步方向改變會(huì)造成數(shù)據(jù)丟失等，我們使用運(yùn)維和一些外部工具來(lái)避免。

集群是一個(gè)獨(dú)立的集群，集群之間的數(shù)據(jù)同步是通過(guò)XDCR進(jìn)行的intellij idea 數(shù)據(jù)庫(kù)關(guān)系圖，通常配置為單向同步。 對(duì)于業(yè)務(wù)來(lái)說(shuō)，寫(xiě)1不寫(xiě)2，一般情況下客戶(hù)端會(huì)寫(xiě)1。 如果1出現(xiàn)故障，我們提供了一個(gè)，可以在配置中心修改對(duì)2的寫(xiě)入，逐漸斷開(kāi)原來(lái)與1的連接，然后再與2建立新的連接。這些集群的過(guò)程相對(duì)透明，不敏感客戶(hù)。

4.愛(ài)奇藝自研數(shù)據(jù)庫(kù)HiKV的使用

雖然性能很高，而且數(shù)據(jù)存儲(chǔ)可以超過(guò)顯存。 而且，如果數(shù)據(jù)量超過(guò)顯存75%的閾值，性能提升會(huì)非?？?。 在愛(ài)奇藝，我們會(huì)把數(shù)據(jù)量控制在顯存可用范圍內(nèi)，作為顯存數(shù)據(jù)庫(kù)使用。 而且它的成本非常高，所以我們開(kāi)發(fā)了一個(gè)新的數(shù)據(jù)庫(kù)——HiKV。

開(kāi)發(fā)HiKV的目的是將一些對(duì)性能要求不高的應(yīng)用遷移到HiKV上。 HiKV基于開(kāi)源系統(tǒng)，主要利用其分布式數(shù)據(jù)庫(kù)的管理功能，減少了單機(jī)存儲(chǔ)引擎HiKV。

更吸引人的是，號(hào)稱(chēng)性能低于十倍，而且完全兼容插座，設(shè)計(jì)基本一致。 可以看作是一個(gè)C++版本系統(tǒng)。

性能的提升主要是由于使用了一些新的技術(shù)框架，比如C++異步框架。 主要原理是每個(gè)化機(jī)的核心上都會(huì)有一個(gè)應(yīng)用線程，每個(gè)核心都有自己獨(dú)立的顯存、網(wǎng)絡(luò)、IO資源。 核心之間沒(méi)有數(shù)據(jù)共享，但它們可以通信。 它最大的用處是顯存訪問(wèn)是無(wú)鎖的，沒(méi)有進(jìn)程沖突。

當(dāng)有數(shù)據(jù)讀寫(xiě)到達(dá)時(shí)，會(huì)根據(jù)哈希算法判斷請(qǐng)求的Key是否需要本線程處理。 如果有，則本線程處理，否則轉(zhuǎn)發(fā)給相應(yīng)的線程。

另外，它還支持多副本、多數(shù)據(jù)中心、多寫(xiě)多活，功能比較強(qiáng)大。

在愛(ài)奇藝，我們構(gòu)建了基于SSD的KV存儲(chǔ)引擎。 鍵放在顯存中，值放在磁盤(pán)上的文件中。 當(dāng)我們讀寫(xiě)一個(gè)文件時(shí)，只需要在顯存索引中定位到它，然后執(zhí)行一次磁盤(pán)IO開(kāi)銷(xiāo)就可以讀取數(shù)據(jù)了。 與原來(lái)基于 的存儲(chǔ)引擎方式相比，在 IO 上的開(kāi)銷(xiāo)更小。

所有索引數(shù)據(jù)都放在顯存中。 如果索引寬度較長(zhǎng)，單機(jī)所能存儲(chǔ)的數(shù)據(jù)量就會(huì)受到限制。 因此，我們開(kāi)發(fā)了一個(gè)定長(zhǎng)的顯存分配器，通過(guò)開(kāi)發(fā)一個(gè)定長(zhǎng)的key來(lái)將寬度縮短到20字節(jié)。 紅樹(shù)林索引，限制顯存中每條記錄的索引寬度為64字節(jié)。 顯存數(shù)據(jù)需要定時(shí)做，客戶(hù)端需要做限流和熔斷。

HiKV目前在愛(ài)奇藝應(yīng)用廣泛，目前已替換30%，有效降低存儲(chǔ)成本。

5.愛(ài)奇藝的數(shù)據(jù)庫(kù)運(yùn)維管理

愛(ài)奇藝數(shù)據(jù)庫(kù)種類(lèi)繁多，如何高效地運(yùn)營(yíng)、維護(hù)和管理這些數(shù)據(jù)庫(kù)經(jīng)歷了不同的階段。

起初，我們由 DBA 編寫(xiě)腳本進(jìn)行管理。 如果腳本有問(wèn)題，我們就聯(lián)系DBA，這讓DBA很忙。

第二階段，我們考慮讓大家自己查題答案，所以我們?cè)趦?nèi)部搭建了一個(gè)私有云，通過(guò)Web展示數(shù)據(jù)庫(kù)的運(yùn)行狀態(tài)，方便業(yè)務(wù)朋友自己申請(qǐng)集群，還有一些簡(jiǎn)單的操作也可以通過(guò)自助平臺(tái)的實(shí)現(xiàn)解放DBA。 一些需要人工處理的小運(yùn)維操作，經(jīng)常會(huì)出現(xiàn)一些人為失誤，輸入錯(cuò)誤的參數(shù)導(dǎo)致數(shù)據(jù)丟失等情況。

所以在第三階段，我們把運(yùn)維操作網(wǎng)頁(yè)化，90%的操作都可以通過(guò)網(wǎng)頁(yè)點(diǎn)擊來(lái)完成。

第四階段讓有經(jīng)驗(yàn)的 DBA 將自己的經(jīng)驗(yàn)轉(zhuǎn)化為一些工具。 比如業(yè)務(wù)上的朋友說(shuō)MySQL-slave延遲了，DBA會(huì)通過(guò)一系列的操作來(lái)排查問(wèn)題。 現(xiàn)在我們把這種操作串起來(lái)生成一套工具。 出現(xiàn)問(wèn)題時(shí)，業(yè)務(wù)朋友可以使用網(wǎng)頁(yè)一鍵診斷工具自行排查處理。

此外，我們會(huì)定期進(jìn)行預(yù)警審查，報(bào)告業(yè)務(wù)集群存在的潛在問(wèn)題； 開(kāi)發(fā)智能客服答疑解惑； 利用監(jiān)控?cái)?shù)據(jù)對(duì)實(shí)例進(jìn)行標(biāo)注，進(jìn)行移峰填谷的智能調(diào)度，提高資源利用率。

3、不同場(chǎng)景下的數(shù)據(jù)庫(kù)選擇建議

1.實(shí)用的數(shù)據(jù)庫(kù)選擇樹(shù)

最后，一些具體的數(shù)據(jù)庫(kù)選擇建議。 這是DBA和業(yè)務(wù)通過(guò)經(jīng)驗(yàn)總結(jié)下來(lái)的一些推論。

對(duì)于關(guān)系型數(shù)據(jù)庫(kù)的選擇，可以考慮數(shù)據(jù)量和擴(kuò)展性?xún)蓚€(gè)維度，然后根據(jù)數(shù)據(jù)庫(kù)是否冷備份、是否使用Toku存儲(chǔ)引擎、是否使用Proxy等進(jìn)行選擇。

NoSQL在什么情況下也使用-slave，在什么情況下它使用客戶(hù)端分片、集群、HiKV等。這個(gè)選擇樹(shù)信息在我們內(nèi)部的自助服務(wù)平臺(tái)上有。

2.一些想法

①需求

在選擇模型時(shí)，我們首先考慮需求，并確定需求是否真實(shí)。

可以考慮數(shù)據(jù)量、QPS、時(shí)延等方面的需求，但是這些都是真實(shí)的需求嗎？ 是否可以使用其他方式來(lái)消費(fèi)這個(gè)需求，比如數(shù)據(jù)量很大，可以先對(duì)數(shù)據(jù)進(jìn)行編碼或者壓縮，可能會(huì)減少數(shù)據(jù)量。

不要把所有的需求都推到數(shù)據(jù)庫(kù)層面，好像是一個(gè)自下而上的系統(tǒng)。

②選擇

第二個(gè)思考點(diǎn)是對(duì)于某個(gè)數(shù)據(jù)庫(kù)系統(tǒng)或者某個(gè)技術(shù)選型我們應(yīng)該考慮什么？ 是因?yàn)槿藲鈫幔?還是因?yàn)楦冗M(jìn)的技術(shù)？ 它真的不能解決你的問(wèn)題嗎？ 如果您的數(shù)據(jù)量不是很大，則不需要選擇能夠存儲(chǔ)大量數(shù)據(jù)的系統(tǒng)。

③放棄

三是放棄。 當(dāng)你放棄一個(gè)系統(tǒng)，真的是因?yàn)樗缓糜脝幔?還是行不通？ 放棄一些東西是很難的，但是放棄的時(shí)候最好有一個(gè)好的理由，包括衡量的結(jié)果。

④自主研發(fā)

四是自主研究。 當(dāng)需要開(kāi)發(fā)自己的數(shù)據(jù)庫(kù)時(shí)，可以參考和使用一些成熟的產(chǎn)品，但不要盲目自研。

⑤開(kāi)源

最后是開(kāi)源，我們要有擁抱開(kāi)源的心態(tài)。

您在選擇數(shù)據(jù)庫(kù)時(shí)考慮了哪些激勵(lì)因素？ 歡迎評(píng)論留言告訴你你的看法~

如有侵權(quán)請(qǐng)聯(lián)系刪除！