架構師之路,從「儲存選型」起步

語言: CN / TW / HK


經常有人問,架構師的學習路線是什麼?

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

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

  • 瞭解目前的儲存技術趨勢,以及對開發人員新的要求

  • 儲存選型的原則,避免日常的經典誤區

  • 結合典型資料庫特點,說明如何進行儲存選型,提高業務開發效率

  • 常見的場景和解決方案

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,一定要多關注市面上更合適的儲存方案,這是架構師的基本功。

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

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





往期熱門筆記合集推薦:


原創:阿丸筆記(微信公眾號:aone_note),歡迎 分享,轉載請保留出處。

沒有留言功能的悲傷,掃描下方二維碼「加我」聊些有的沒的吧~

                                                                              覺得不錯,就點個  再看 吧👇



本文分享自微信公眾號 - 阿丸筆記(aone_note)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。