經(jīng)常有人問(wèn)，架構(gòu)師的學(xué)習(xí)路線(xiàn)是什么？

我一般推薦架構(gòu)師的基本功，是從「存儲(chǔ)選型」開(kāi)始的。

本文整理了存儲(chǔ)選型的思路和整體框架，主要包括幾個(gè)部分內(nèi)容：

• ?了解目前的存儲(chǔ)技術(shù)趨勢(shì)，以及對(duì)開(kāi)發(fā)人員新的要求
• 存儲(chǔ)選型的原則，避免日常的經(jīng)典誤區(qū)
• 結(jié)合典型數(shù)據(jù)庫(kù)特點(diǎn)，說(shuō)明如何進(jìn)行存儲(chǔ)選型，提高業(yè)務(wù)開(kāi)發(fā)效率
• 常見(jiàn)的場(chǎng)景和解決方案?

1.存儲(chǔ)技術(shù)發(fā)展看存儲(chǔ)選型

1.1 存儲(chǔ)類(lèi)型多元化

DB-Engines數(shù)據(jù)庫(kù)排名并不代表數(shù)據(jù)庫(kù)的安裝數(shù)量，或者使用量。但某數(shù)據(jù)庫(kù)越來(lái)越受歡迎則代表在一定時(shí)間范圍內(nèi)更加廣泛的使用。

這里貼了一張2022年5月份的排行榜（https://db-engines.com/en/ranking）。

我們對(duì)于排名前10的數(shù)據(jù)庫(kù)中，比較熟悉的應(yīng)該是MySQL、Redis和ES，這三個(gè)數(shù)據(jù)庫(kù)在我們?nèi)粘ｉ_(kāi)發(fā)中占據(jù)絕大多數(shù)的比例。

但是，這三個(gè)數(shù)據(jù)庫(kù)只代表了一小部分的數(shù)據(jù)庫(kù)類(lèi)型，我們是不是可以把視野打開(kāi)更多一些，看看沒(méi)有更多的數(shù)據(jù)庫(kù)類(lèi)型，可以適合我們不同的業(yè)務(wù)，包括Relational、Document、Key-value、Search engine、Wide column、Time Series、Graph等等不同數(shù)據(jù)庫(kù)類(lèi)型。

1.2 云原生存儲(chǔ)多元化

除去上面的傳統(tǒng)數(shù)據(jù)庫(kù)之外，云時(shí)代存儲(chǔ)技術(shù)又有了更多的變化。

除了簡(jiǎn)單的把上面的數(shù)據(jù)庫(kù)托管到云上之外，還多了許多充分利用云的基礎(chǔ)設(shè)施產(chǎn)生的云原生數(shù)據(jù)庫(kù)，比如aws的Amazon Aurora、阿里云的PolarDB、騰訊云的TDSQL等。

另外，云時(shí)代還產(chǎn)生了更多類(lèi)型的數(shù)據(jù)庫(kù)，比如阿里云的多模數(shù)據(jù)庫(kù)Lindorm、Pingcap的HTAP數(shù)據(jù)庫(kù)TiDb等。

多類(lèi)型數(shù)據(jù)庫(kù)是各個(gè)云廠(chǎng)商發(fā)展的趨勢(shì)，他們?yōu)槭裁磿?huì)支持越來(lái)越多用途的數(shù)據(jù)庫(kù)呢？

供給側(cè)的改變一定是來(lái)源于需求側(cè)，因?yàn)殡S著互聯(lián)網(wǎng)、物聯(lián)網(wǎng)等場(chǎng)景發(fā)展，有很多業(yè)務(wù)需求不是任何單一的數(shù)據(jù)庫(kù)能解決的了。

1.3 告訴我們什么？

「數(shù)據(jù)庫(kù)類(lèi)型多元化」 & 「云原生數(shù)據(jù)庫(kù)類(lèi)型多元化」 是一個(gè)必然的發(fā)展趨勢(shì)。

我們要解決的場(chǎng)景會(huì)越來(lái)越多，我們需要掌握的數(shù)據(jù)庫(kù)領(lǐng)域也越來(lái)越廣，只有這樣，我們才能面對(duì)在線(xiàn)事務(wù)、離線(xiàn)分析、海量存儲(chǔ)、成本與效率等因素，真正做好存儲(chǔ)選型。

2.存儲(chǔ)選型原則：不要耍流氓存儲(chǔ)

2.1 不講場(chǎng)景的選型都是耍流氓

大家可能都知道，數(shù)據(jù)庫(kù)的選型一定是基于實(shí)際的業(yè)務(wù)場(chǎng)景的。但是，可能也遇到過(guò)類(lèi)似的對(duì)話(huà)：

上面的對(duì)話(huà)可能有些夸張，但是實(shí)際生產(chǎn)中，可能是對(duì)場(chǎng)景的理解有誤，也可能是為了快速完成任務(wù)開(kāi)發(fā)，結(jié)果是在「特定場(chǎng)景」選擇了錯(cuò)誤的數(shù)據(jù)庫(kù)的情況時(shí)有發(fā)生。

常見(jiàn)的特定場(chǎng)景包括：

• 離線(xiàn)業(yè)務(wù)：日志、搜索、統(tǒng)計(jì)等。
• 事務(wù)需求：強(qiáng)事務(wù)型、分析型。
• 數(shù)據(jù)熱度：全熱數(shù)據(jù)、冷熱明顯等。
• 數(shù)據(jù)讀寫(xiě)偏好：多讀、多寫(xiě)。

數(shù)據(jù)增長(zhǎng)方式：按日期、按用戶(hù)、按位置類(lèi)型等。

對(duì)于存儲(chǔ)選型來(lái)說(shuō)，一定需要識(shí)別特定場(chǎng)景的特點(diǎn)，是在線(xiàn)業(yè)務(wù)還是離線(xiàn)業(yè)務(wù)？數(shù)據(jù)冷熱是否明顯？數(shù)據(jù)訪(fǎng)問(wèn)方式特點(diǎn)？數(shù)據(jù)增長(zhǎng)方式等等。

如果沒(méi)有根據(jù)場(chǎng)景特點(diǎn)來(lái)做存儲(chǔ)選型，可能會(huì)帶來(lái)不良后果，包括無(wú)法滿(mǎn)足業(yè)務(wù)需求、存儲(chǔ)成本暴漲等，然后就需要花大代價(jià)做不停機(jī)數(shù)據(jù)遷移和代碼重構(gòu)。

因此，針對(duì)特定業(yè)務(wù)場(chǎng)景的存儲(chǔ)選型一定要仔細(xì)、慎重，并在一開(kāi)始就設(shè)計(jì)好。

2.2 不講數(shù)據(jù)規(guī)模的選型都是耍流氓

除了特定場(chǎng)景外，「數(shù)據(jù)規(guī)模」是存儲(chǔ)選型的另一個(gè)核心要素。

這樣的對(duì)話(huà)非常常見(jiàn)。

雖然在一些新業(yè)務(wù)場(chǎng)景下，確實(shí)很難準(zhǔn)確評(píng)估業(yè)務(wù)的數(shù)據(jù)規(guī)模，但是無(wú)法評(píng)估的數(shù)據(jù)規(guī)模，往往意味著無(wú)法做好正確的存儲(chǔ)選型。

因此，如果有一定的先驗(yàn)知識(shí)，我們需要盡量做好數(shù)據(jù)規(guī)模的評(píng)估。比如，之前有沒(méi)有類(lèi)似的業(yè)務(wù)、其他組有沒(méi)有類(lèi)似的需求或功能，它們目前的數(shù)據(jù)規(guī)模大致如何，然后進(jìn)行評(píng)估。

常見(jiàn)的數(shù)據(jù)規(guī)模指標(biāo)有三個(gè)：

• 數(shù)據(jù)總量
• QPS
• rt

不同的數(shù)據(jù)規(guī)模指標(biāo)，往往意味著不同的存儲(chǔ)選型。

2.3 不講掌控度的選型都是耍流氓

對(duì)于存儲(chǔ)選型，「掌控度」是非常重要的選型原則。

這里其實(shí)包括了兩個(gè)維度，開(kāi)發(fā)同學(xué)對(duì)存儲(chǔ)的掌控度 & DBA對(duì)存儲(chǔ)的掌控度。

1）開(kāi)發(fā)同學(xué)的掌控度

對(duì)開(kāi)發(fā)同學(xué)來(lái)說(shuō)，選擇一個(gè)存儲(chǔ)，一定是基于對(duì)該存儲(chǔ)的基本認(rèn)知&最佳實(shí)踐的了解。

一定不是其他人也這么用所以我這么用。

如果盲目使用一個(gè)自己不了解的存儲(chǔ)，很容易帶來(lái)不良后果，輕則造成資源浪費(fèi)，重則引起線(xiàn)上故障（比如Mysql的慢sql、HBase的熱點(diǎn)訪(fǎng)問(wèn)等）。

2）DBA對(duì)存儲(chǔ)的掌控度

對(duì)DBA來(lái)說(shuō)，對(duì)一個(gè)存儲(chǔ)的基本認(rèn)知&最佳實(shí)踐是基礎(chǔ)要求了。在此之上，還有其他更多的要求。

一個(gè)是社區(qū)活躍度。社區(qū)活躍度決定著你獲取信息的難易程度，也決定到出現(xiàn)了故障后的定位速度甚至是能不能定位出來(lái)，如果社區(qū)很活躍，自然就能得到更多的幫助。

第二個(gè)是有沒(méi)有案例背書(shū)。最好是一些中廠(chǎng)、大廠(chǎng)最新的案例實(shí)踐（千萬(wàn)不要被大廠(chǎng)多年前的案例迷惑，技術(shù)發(fā)展往往意味著更新更合適的解決方案）。如果案例與存儲(chǔ)不匹配，或者沒(méi)有什么案例來(lái)支持你的存儲(chǔ)選型，那么這個(gè)選型可能就是不合適的。

第三個(gè)是存儲(chǔ)組件的上手成本。團(tuán)隊(duì)具備了什么樣的技術(shù)儲(chǔ)備？選擇的是自研還是云產(chǎn)品？云產(chǎn)品是全托管的還是半托管的？畢竟每一種數(shù)據(jù)庫(kù)都不是這么簡(jiǎn)單，如果人力有限而上手難度又很大，那么這個(gè)存儲(chǔ)組件目前可能不是一個(gè)好的選擇。

3.選型路線(xiàn)圖

結(jié)合上面的原則，我們來(lái)做一個(gè)存儲(chǔ)選型路線(xiàn)圖供大家參考。

進(jìn)一步，針對(duì)各個(gè)類(lèi)型數(shù)據(jù)庫(kù)，我們都需要了解它們的優(yōu)點(diǎn)、缺點(diǎn)、最佳實(shí)踐等，來(lái)結(jié)合業(yè)務(wù)場(chǎng)景因地制宜。

3.1 Relational

以MySQL為代表的關(guān)系型數(shù)據(jù)庫(kù)。常用于在線(xiàn)業(yè)務(wù)（OLTP)場(chǎng)景，對(duì)于強(qiáng)事務(wù)有較好支持。

優(yōu)點(diǎn)：

• 容易理解，大家基本上都用得比較熟
• 事務(wù)特性
• 配套成熟（備份恢復(fù)、數(shù)據(jù)訂閱、數(shù)據(jù)同步等）
• 服務(wù)極度穩(wěn)定

缺點(diǎn)：

• 不易水平擴(kuò)展
• 大表表結(jié)構(gòu)變更復(fù)雜
• 全文檢索能力弱
• 復(fù)雜分析、統(tǒng)計(jì)能力弱

最佳實(shí)踐：

• 索引設(shè)計(jì)
• 避免n+1輪訓(xùn)
• 避免深分頁(yè)
• 單表千萬(wàn)考慮分庫(kù)分表，或者使用云數(shù)據(jù)庫(kù)（polarDB或者TDSQL)
• 冷熱數(shù)據(jù)注意歸檔
• 不直接處理統(tǒng)計(jì)、分析型操作

3.2 Key-value

KV型NoSql顧名思義就是以鍵值對(duì)形式存儲(chǔ)的非關(guān)系型數(shù)據(jù)庫(kù)，是最簡(jiǎn)單、最容易理解也是大家最熟悉的一種 NoSql。

Redis是其中的代表，典型用于緩存場(chǎng)景。

優(yōu)點(diǎn)：

• 數(shù)據(jù)基于內(nèi)存，讀寫(xiě)效率高
• KV型數(shù)據(jù)，時(shí)間復(fù)雜度為O(1)，查詢(xún)速度快

缺點(diǎn)：

• 查詢(xún)方式單一
• 內(nèi)存有限，且非常昂貴
• 由于存儲(chǔ)是基于內(nèi)存的，會(huì)有丟失數(shù)據(jù)的風(fēng)險(xiǎn)（有持久化存儲(chǔ)方案）

最佳實(shí)踐：

• 合理控制kv大小，避免大key
• 避免熱點(diǎn)key
• 設(shè)置合理的TTL
• 注意緩存雪崩、穿透、擊穿、兼容問(wèn)題
• 不要用于消息隊(duì)列，異常情況無(wú)法堆積消息
• 不要將redis作為數(shù)據(jù)庫(kù)使用，可能會(huì)丟數(shù)據(jù)

3.3 Search engine

搜索型NoSql顧名思義主要是用在搜索場(chǎng)景下的。

盡管MySQL可以通過(guò)索引來(lái)加速查詢(xún)，但是對(duì)于全文搜索、模糊搜索等場(chǎng)景就比較無(wú)力，搜索型NoSql正是為了補(bǔ)足這個(gè)場(chǎng)景誕生的。

ElasticSearch是其中的代表產(chǎn)品。

優(yōu)點(diǎn)：

• 支持分詞場(chǎng)景、全文搜索，這是區(qū)別于關(guān)系型數(shù)據(jù)庫(kù)最大特點(diǎn)
• 支持條件查詢(xún)，支持聚合操作，適合數(shù)據(jù)分析
• 在集群環(huán)境下可以方便橫向擴(kuò)展，可承載PB級(jí)別的數(shù)據(jù)

缺點(diǎn)：

• 讀寫(xiě)之間有延遲，寫(xiě)入的數(shù)據(jù)不一定能馬上讀到
• 硬件性能要求高

最佳實(shí)踐：

• 核心在線(xiàn)應(yīng)用強(qiáng)依賴(lài)ES需要考慮可行的降級(jí)方案
• 禁止使用單索引多type
• ES成本較高，因此建議僅數(shù)據(jù)庫(kù)加速、全文檢索情況下使用es
• ES中僅存儲(chǔ)索引字段，通過(guò)id回查數(shù)據(jù)庫(kù)，不要全量數(shù)據(jù)存儲(chǔ)ES
• 根據(jù)節(jié)點(diǎn)數(shù)量設(shè)置合理的分片數(shù)量、分片大小

3.4 Document

文檔型 NoSql 指的是將半結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)為文檔的一種 NoSql，通常以 JSON 或者 XML 格式存儲(chǔ)數(shù)據(jù)。

Mongo是其中的代表產(chǎn)品。

優(yōu)點(diǎn)：

• 沒(méi)有預(yù)定義的字段，擴(kuò)展字段容易
• 相較于關(guān)系型數(shù)據(jù)庫(kù)，讀寫(xiě)性能優(yōu)越
• 分片集群易水平擴(kuò)展

缺點(diǎn)：

• 文檔結(jié)構(gòu)過(guò)于靈活，可能導(dǎo)致不易維護(hù)
• 客戶(hù)端控制力強(qiáng)，對(duì)開(kāi)發(fā)、優(yōu)化上有一定要求

最佳實(shí)踐：

• 選擇合理的片鍵
• 建立合適的索引
• 正確使用寫(xiě)關(guān)注設(shè)置（Write Concern）
• 正確使用讀選項(xiàng)設(shè)置（Read Preference）
• 正確使用更新語(yǔ)句（局部更新、防止大量更新集中在一條數(shù)據(jù)內(nèi)）

3.5 Wide column

一般用于可靠性要求不高的海量存儲(chǔ)場(chǎng)景。

HBase是代表產(chǎn)品（國(guó)外cassandra用得多，國(guó)內(nèi)HBase用得多）。

優(yōu)點(diǎn)：

• 動(dòng)態(tài)列調(diào)整，不受表結(jié)構(gòu)困擾
• 海量數(shù)據(jù)存儲(chǔ)，PB 級(jí)別數(shù)據(jù)
• 橫向擴(kuò)展方便，且支持廉價(jià)存儲(chǔ)擴(kuò)展，成本低，適用于無(wú)法預(yù)估存儲(chǔ)量的海量數(shù)據(jù)

缺點(diǎn)：

• Hadoop生態(tài)產(chǎn)品，組件依賴(lài)多，沒(méi)有云托管產(chǎn)品，運(yùn)維能力要求比較高
• Rowkey設(shè)計(jì)需要一定經(jīng)驗(yàn)，避免熱點(diǎn)
• 單集群SLA一般3個(gè)9，如果用于在線(xiàn)核心業(yè)務(wù)，一定需要考慮降級(jí)和容災(zāi)
• 只支持行級(jí)事務(wù)

最佳實(shí)踐：

• 適用于行數(shù)多，但單個(gè)kv數(shù)據(jù)量小（1M以下）
• 特別注意Rowkey設(shè)計(jì)，避免熱點(diǎn)
• 大value（10M以上)禁止存入HBase，考慮對(duì)象存儲(chǔ)
• 表創(chuàng)建時(shí)必須預(yù)分區(qū)
• 表的列族數(shù)量不得超過(guò) 2 個(gè)
• HBase是CP型系統(tǒng)，SLA一般是3個(gè)9，一般建議離線(xiàn)業(yè)務(wù)使用。如果核心在線(xiàn)業(yè)務(wù)使用，必須做好降級(jí)、容災(zāi)

4.常見(jiàn)場(chǎng)景和選型方案

上文提出了 三條選型原則 和 常見(jiàn)數(shù)據(jù)庫(kù)的選型依據(jù)，下面結(jié)合不同場(chǎng)景做一下常規(guī)選型方案參考。

4.1 主要場(chǎng)景和方案

毋庸置疑，互聯(lián)網(wǎng)業(yè)務(wù)的主要場(chǎng)景，是采用mysql進(jìn)行數(shù)據(jù)存儲(chǔ)。正如MySQL的自己所說(shuō) —— most popular open source database。

當(dāng)然，為了扛住高并發(fā)場(chǎng)景，緩存也不可缺失。

因此，最主要的方案就是 MySQL + Redis。

適用于日常主要場(chǎng)景：

• MySQL滿(mǎn)足事務(wù)性要求
• Redis抗熱點(diǎn)

4.2 模糊搜索 or 全文檢索

MySQL數(shù)據(jù)庫(kù)擅長(zhǎng)在線(xiàn)業(yè)務(wù)（OLTP）讀寫(xiě)，不擅長(zhǎng)做統(tǒng)計(jì)、分析型業(yè)務(wù)（OLAP)。因此，一般會(huì)通過(guò)MySQL做持久化存儲(chǔ)，ES構(gòu)建索引進(jìn)行查詢(xún)、分析。

適用于搜索場(chǎng)景：

• 復(fù)雜查詢(xún)
• 模糊搜索
• 全文搜索
• 統(tǒng)計(jì)分析

4.3 大量數(shù)據(jù)場(chǎng)景

數(shù)據(jù)規(guī)模：100TB以?xún)?nèi)的數(shù)據(jù)量。

1）MySQL分庫(kù)分表 + es

傳統(tǒng)MySQL橫向擴(kuò)展方案，利用分庫(kù)分表中間件進(jìn)行存儲(chǔ)擴(kuò)展，利用ES進(jìn)行非分表鍵查詢(xún)和復(fù)雜查詢(xún)。

適用場(chǎng)景：

• 數(shù)據(jù)量較大
• 有中間件使用能力
• 已有MySQL橫向擴(kuò)展

2）云原生數(shù)據(jù)庫(kù)（以polarDB為例）

云時(shí)代的新方案。

PolarDB是阿里巴巴自研的新一代云原生關(guān)系型數(shù)據(jù)庫(kù)，在存儲(chǔ)計(jì)算分離架構(gòu)下，利用了軟硬件結(jié)合的優(yōu)勢(shì)，為用戶(hù)提供具備極致彈性、高性能、海量存儲(chǔ)、安全可靠的數(shù)據(jù)庫(kù)服務(wù),100%兼容MySQL 5.6/5.7/8.0。

最高100 TB，不再需要因?yàn)閱螜C(jī)容量的天花板而去購(gòu)買(mǎi)多個(gè)實(shí)例做分片，由此簡(jiǎn)化應(yīng)用開(kāi)發(fā)，降低運(yùn)維負(fù)擔(dān)。

適用場(chǎng)景：

• 數(shù)據(jù)量較大
• 有公有云使用基礎(chǔ)設(shè)施

3）mongo分片集群

適用場(chǎng)景：

• 數(shù)據(jù)量較大的NoSQL場(chǎng)景
• 表結(jié)構(gòu)變更頻繁場(chǎng)景，free-schema
• 對(duì)mongo使用有一定理解

4.4 海量數(shù)據(jù)場(chǎng)景

數(shù)據(jù)規(guī)模：100TB以上的數(shù)據(jù)量。

1）高可用數(shù)據(jù)庫(kù) + HBase

由于數(shù)據(jù)量非常大，需要考慮存儲(chǔ)成本。因此一般會(huì)考慮冷熱數(shù)據(jù)分離。

熱數(shù)據(jù)在高可用數(shù)據(jù)庫(kù)進(jìn)行讀寫(xiě)，可以選擇MySQL、Mongo等。冷數(shù)據(jù)存入成本較低的HBase或者對(duì)象存儲(chǔ)等組件。

適用場(chǎng)景：

• 海量數(shù)據(jù)
• 可靠性要求高

2）直接使用HBase

如果是非核心在線(xiàn)業(yè)務(wù)，或者離線(xiàn)業(yè)務(wù)，可以考慮直接使用HBase。

適用場(chǎng)景：

• 海量數(shù)據(jù)
• 低成本
• 可靠性要求不高

5.總結(jié)

在業(yè)務(wù)開(kāi)發(fā)過(guò)程中，除了常用的MySQL，一定要多關(guān)注市面上更合適的存儲(chǔ)方案，這是架構(gòu)師的基本功。

通過(guò)了解更多存儲(chǔ)組件的基本特性和使用場(chǎng)景，因地制宜選擇合適存儲(chǔ)，提高業(yè)務(wù)開(kāi)發(fā)效率，降低使用成本。

希望本文能夠拋磚引玉，提供一些啟發(fā)和思考。