經常有人問，架構師的學習路線是什麼？
我一般推薦架構師的基本功，是從「儲存選型」開始的。
本文整理了儲存選型的思路和整體框架，主要包括幾個部分內容：
- 瞭解目前的儲存技術趨勢，以及對開發人員新的要求
- 儲存選型的原則，避免日常的經典誤區
- 結合典型資料庫特點，說明如何進行儲存選型，提高業務開發效率
- 常見的場景和解決方案
1、儲存技術發展看儲存選型
1.1 儲存型別多樣化
DB-Engines資料庫排名並不代表資料庫的安裝數量，或者使用量。但某資料庫越來越受歡迎則代表在一定時間範圍內更加廣泛的使用。
https://db-engines.com/en/ranking
這裡貼了一張2022年5月份的排行榜。
我們對於排名前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 全文檢索
適用於搜尋場景：
- 複雜查詢
- 模糊搜尋
- 全文搜尋
- 統計分析
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，一定要多關注市面上更合適的儲存方案，這是架構師的基本功。
通過了解更多儲存元件的基本特性和使用場景，因地制宜選擇合適儲存，提高業務開發效率，降低使用成本。
希望本文能夠拋磚引玉，提供一些啟發和思考。
都看到最後了，原創不易，點個關注，點個贊吧～
文章持續更新，可以微信搜尋「阿丸筆記 」第一時間閱讀，回覆【筆記】獲取Canal、MySQL、HBase、JAVA實戰筆記，回覆【資料】獲取一線大廠面試資料。
知識碎片重新梳理，構建Java知識圖譜：github.com/saigu/JavaK…（歷史文章查閱非常方便）