經常有人問，架構師的學習路線是什么？

我一般推薦架構師的基本功，是從「存儲選型」開始的。

本文整理了存儲選型的思路和整體框架，主要包括幾個部分內容：

• ?了解目前的存儲技術趨勢，以及對開發人員新的要求
• 存儲選型的原則，避免日常的經典誤區
• 結合典型數據庫特點，說明如何進行存儲選型，提高業務開發效率
• 常見的場景和解決方案?

1.存儲技術發展看存儲選型

1.1 存儲類型多元化

DB-Engines數據庫排名并不代表數據庫的安裝數量，或者使用量。但某數據庫越來越受歡迎則代表在一定時間范圍內更加廣泛的使用。

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

我們對于排名前10的數據庫中，比較熟悉的應該是MySQL、Redis和ES，這三個數據庫在我們日常開發中占據絕大多數的比例。

但是，這三個數據庫只代表了一小部分的數據庫類型，我們是不是可以把視野打開更多一些，看看沒有更多的數據庫類型，可以適合我們不同的業務，包括Relational、Document、Key-value、Search engine、Wide column、Time Series、Graph等等不同數據庫類型。

1.2 云原生存儲多元化

除去上面的傳統數據庫之外，云時代存儲技術又有了更多的變化。

除了簡單的把上面的數據庫托管到云上之外，還多了許多充分利用云的基礎設施產生的云原生數據庫，比如aws的Amazon Aurora、阿里云的PolarDB、騰訊云的TDSQL等。

另外，云時代還產生了更多類型的數據庫，比如阿里云的多模數據庫Lindorm、Pingcap的HTAP數據庫TiDb等。

多類型數據庫是各個云廠商發展的趨勢，他們為什么會支持越來越多用途的數據庫呢？

供給側的改變一定是來源于需求側，因為隨著互聯網、物聯網等場景發展，有很多業務需求不是任何單一的數據庫能解決的了。

1.3 告訴我們什么？

「數據庫類型多元化」 & 「云原生數據庫類型多元化」 是一個必然的發展趨勢。

我們要解決的場景會越來越多，我們需要掌握的數據庫領域也越來越廣，只有這樣，我們才能面對在線事務、離線分析、海量存儲、成本與效率等因素，真正做好存儲選型。

2.存儲選型原則：不要耍流氓存儲

2.1 不講場景的選型都是耍流氓

大家可能都知道，數據庫的選型一定是基于實際的業務場景的。但是，可能也遇到過類似的對話：

上面的對話可能有些夸張，但是實際生產中，可能是對場景的理解有誤，也可能是為了快速完成任務開發，結果是在「特定場景」選擇了錯誤的數據庫的情況時有發生。

常見的特定場景包括：

• 離線業務：日志、搜索、統計等。
• 事務需求：強事務型、分析型。
• 數據熱度：全熱數據、冷熱明顯等。
• 數據讀寫偏好：多讀、多寫。

數據增長方式：按日期、按用戶、按位置類型等。

對于存儲選型來說，一定需要識別特定場景的特點，是在線業務還是離線業務？數據冷熱是否明顯？數據訪問方式特點？數據增長方式等等。

如果沒有根據場景特點來做存儲選型，可能會帶來不良后果，包括無法滿足業務需求、存儲成本暴漲等，然后就需要花大代價做不停機數據遷移和代碼重構。

因此，針對特定業務場景的存儲選型一定要仔細、慎重，并在一開始就設計好。

2.2 不講數據規模的選型都是耍流氓

除了特定場景外，「數據規模」是存儲選型的另一個核心要素。

這樣的對話非常常見。

雖然在一些新業務場景下，確實很難準確評估業務的數據規模，但是無法評估的數據規模，往往意味著無法做好正確的存儲選型。

因此，如果有一定的先驗知識，我們需要盡量做好數據規模的評估。比如，之前有沒有類似的業務、其他組有沒有類似的需求或功能，它們目前的數據規模大致如何，然后進行評估。

常見的數據規模指標有三個：

• 數據總量
• QPS
• rt

不同的數據規模指標，往往意味著不同的存儲選型。

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

對于存儲選型，「掌控度」是非常重要的選型原則。

這里其實包括了兩個維度，開發同學對存儲的掌控度 & DBA對存儲的掌控度。

1）開發同學的掌控度

對開發同學來說，選擇一個存儲，一定是基于對該存儲的基本認知&最佳實踐的了解。

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

如果盲目使用一個自己不了解的存儲，很容易帶來不良后果，輕則造成資源浪費，重則引起線上故障（比如Mysql的慢sql、HBase的熱點訪問等）。

2）DBA對存儲的掌控度

對DBA來說，對一個存儲的基本認知&最佳實踐是基礎要求了。在此之上，還有其他更多的要求。

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

第二個是有沒有案例背書。最好是一些中廠、大廠最新的案例實踐（千萬不要被大廠多年前的案例迷惑，技術發展往往意味著更新更合適的解決方案）。如果案例與存儲不匹配，或者沒有什么案例來支持你的存儲選型，那么這個選型可能就是不合適的。

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

3.選型路線圖

結合上面的原則，我們來做一個存儲選型路線圖供大家參考。

進一步，針對各個類型數據庫，我們都需要了解它們的優點、缺點、最佳實踐等，來結合業務場景因地制宜。

3.1 Relational

以MySQL為代表的關系型數據庫。常用于在線業務（OLTP)場景，對于強事務有較好支持。

優點：

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

缺點：

• 不易水平擴展
• 大表表結構變更復雜
• 全文檢索能力弱
• 復雜分析、統計能力弱

最佳實踐：

• 索引設計
• 避免n+1輪訓
• 避免深分頁
• 單表千萬考慮分庫分表，或者使用云數據庫（polarDB或者TDSQL)
• 冷熱數據注意歸檔
• 不直接處理統計、分析型操作

3.2 Key-value

KV型NoSql顧名思義就是以鍵值對形式存儲的非關系型數據庫，是最簡單、最容易理解也是大家最熟悉的一種 NoSql。

Redis是其中的代表，典型用于緩存場景。

優點：

• 數據基于內存，讀寫效率高
• KV型數據，時間復雜度為O(1)，查詢速度快

缺點：

• 查詢方式單一
• 內存有限，且非常昂貴
• 由于存儲是基于內存的，會有丟失數據的風險（有持久化存儲方案）

最佳實踐：

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

3.3 Search engine

搜索型NoSql顧名思義主要是用在搜索場景下的。

盡管MySQL可以通過索引來加速查詢，但是對于全文搜索、模糊搜索等場景就比較無力，搜索型NoSql正是為了補足這個場景誕生的。

ElasticSearch是其中的代表產品。

優點：

• 支持分詞場景、全文搜索，這是區別于關系型數據庫最大特點
• 支持條件查詢，支持聚合操作，適合數據分析
• 在集群環境下可以方便橫向擴展，可承載PB級別的數據

缺點：

• 讀寫之間有延遲，寫入的數據不一定能馬上讀到
• 硬件性能要求高

最佳實踐：

• 核心在線應用強依賴ES需要考慮可行的降級方案
• 禁止使用單索引多type
• ES成本較高，因此建議僅數據庫加速、全文檢索情況下使用es
• ES中僅存儲索引字段，通過id回查數據庫，不要全量數據存儲ES
• 根據節點數量設置合理的分片數量、分片大小

3.4 Document

文檔型 NoSql 指的是將半結構化數據存儲為文檔的一種 NoSql，通常以 JSON 或者 XML 格式存儲數據。

Mongo是其中的代表產品。

優點：

• 沒有預定義的字段，擴展字段容易
• 相較于關系型數據庫，讀寫性能優越
• 分片集群易水平擴展

缺點：

• 文檔結構過于靈活，可能導致不易維護
• 客戶端控制力強，對開發、優化上有一定要求

最佳實踐：

• 選擇合理的片鍵
• 建立合適的索引
• 正確使用寫關注設置（Write Concern）
• 正確使用讀選項設置（Read Preference）
• 正確使用更新語句（局部更新、防止大量更新集中在一條數據內）

3.5 Wide column

一般用于可靠性要求不高的海量存儲場景。

HBase是代表產品（國外cassandra用得多，國內HBase用得多）。

優點：

• 動態列調整，不受表結構困擾
• 海量數據存儲，PB 級別數據
• 橫向擴展方便，且支持廉價存儲擴展，成本低，適用于無法預估存儲量的海量數據

缺點：

• Hadoop生態產品，組件依賴多，沒有云托管產品，運維能力要求比較高
• Rowkey設計需要一定經驗，避免熱點
• 單集群SLA一般3個9，如果用于在線核心業務，一定需要考慮降級和容災
• 只支持行級事務

最佳實踐：

• 適用于行數多，但單個kv數據量小（1M以下）
• 特別注意Rowkey設計，避免熱點
• 大value（10M以上)禁止存入HBase，考慮對象存儲
• 表創建時必須預分區
• 表的列族數量不得超過 2 個
• HBase是CP型系統，SLA一般是3個9，一般建議離線業務使用。如果核心在線業務使用，必須做好降級、容災

4.常見場景和選型方案

上文提出了 三條選型原則 和 常見數據庫的選型依據，下面結合不同場景做一下常規選型方案參考。

4.1 主要場景和方案

毋庸置疑，互聯網業務的主要場景，是采用mysql進行數據存儲。正如MySQL的自己所說 —— most popular open source database。

當然，為了扛住高并發場景，緩存也不可缺失。

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

適用于日常主要場景：

• MySQL滿足事務性要求
• Redis抗熱點

4.2 模糊搜索 or 全文檢索

MySQL數據庫擅長在線業務（OLTP）讀寫，不擅長做統計、分析型業務（OLAP)。因此，一般會通過MySQL做持久化存儲，ES構建索引進行查詢、分析。

適用于搜索場景：

• 復雜查詢
• 模糊搜索
• 全文搜索
• 統計分析

4.3 大量數據場景

數據規模：100TB以內的數據量。

1）MySQL分庫分表 + es

傳統MySQL橫向擴展方案，利用分庫分表中間件進行存儲擴展，利用ES進行非分表鍵查詢和復雜查詢。

適用場景：

• 數據量較大
• 有中間件使用能力
• 已有MySQL橫向擴展

2）云原生數據庫（以polarDB為例）

云時代的新方案。

PolarDB是阿里巴巴自研的新一代云原生關系型數據庫，在存儲計算分離架構下，利用了軟硬件結合的優勢，為用戶提供具備極致彈性、高性能、海量存儲、安全可靠的數據庫服務,100%兼容MySQL 5.6/5.7/8.0。

最高100 TB，不再需要因為單機容量的天花板而去購買多個實例做分片，由此簡化應用開發，降低運維負擔。

適用場景：

• 數據量較大
• 有公有云使用基礎設施

3）mongo分片集群

適用場景：

• 數據量較大的NoSQL場景
• 表結構變更頻繁場景，free-schema
• 對mongo使用有一定理解

4.4 海量數據場景

數據規模：100TB以上的數據量。

1）高可用數據庫 + HBase

由于數據量非常大，需要考慮存儲成本。因此一般會考慮冷熱數據分離。

熱數據在高可用數據庫進行讀寫，可以選擇MySQL、Mongo等。冷數據存入成本較低的HBase或者對象存儲等組件。

適用場景：

• 海量數據
• 可靠性要求高

2）直接使用HBase

如果是非核心在線業務，或者離線業務，可以考慮直接使用HBase。

適用場景：

• 海量數據
• 低成本
• 可靠性要求不高

5.總結

在業務開發過程中，除了常用的MySQL，一定要多關注市面上更合適的存儲方案，這是架構師的基本功。

通過了解更多存儲組件的基本特性和使用場景，因地制宜選擇合適存儲，提高業務開發效率，降低使用成本。

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