互聯(lián)網(wǎng)架構(gòu)之下的數(shù)據(jù)存儲(chǔ)技術(shù)選型邏輯
之前一篇文章介紹了在互聯(lián)網(wǎng)架構(gòu)下如何使用MySQL解決千萬(wàn)數(shù)據(jù)量的選型問(wèn)題，詳見(jiàn)：一天幾千萬(wàn)訂單，也是MySql做存儲(chǔ)嗎？
那除了MySQL之外，互聯(lián)網(wǎng)技術(shù)架構(gòu)體系之下還有哪些數(shù)據(jù)存儲(chǔ)技術(shù)在應(yīng)用？以及他們選型背后的邏輯是什么？
今天簡(jiǎn)單聊聊這個(gè)。
業(yè)務(wù)架構(gòu)下的存儲(chǔ)服務(wù)
隨著互聯(lián)網(wǎng)、移動(dòng)互聯(lián)網(wǎng)、物聯(lián)網(wǎng)大潮的高速發(fā)展，互聯(lián)網(wǎng)與智能手機(jī)的廣泛使用，人們有了更多的時(shí)間是被互聯(lián)網(wǎng)支配的。
作為平臺(tái)型的互聯(lián)網(wǎng)大廠(chǎng)，一些日活過(guò)億的APP后端，每天所面對(duì)的數(shù)據(jù)量勢(shì)必非常非常的大。
傳統(tǒng)軟件公司，或者早期的互聯(lián)網(wǎng)公司的數(shù)據(jù)存儲(chǔ)主要使用關(guān)系型數(shù)據(jù)庫(kù)技術(shù)，比如Oracle就是其中的代表。
但傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)在可擴(kuò)展性方面也存在著一些缺陷，即使采用并行數(shù)據(jù)庫(kù)集群，最多也只能管理百臺(tái)機(jī)器左右，總之海量數(shù)據(jù)的管理成本將會(huì)非常高。
目前電子制造業(yè)技術(shù)快速發(fā)展，包括磁盤(pán)、SSD、內(nèi)存在內(nèi)的存儲(chǔ)設(shè)備成本都在大幅下降。不排除有些公司或者業(yè)務(wù)，已經(jīng)選擇大量使用基于內(nèi)存的KV存儲(chǔ)數(shù)據(jù)實(shí)現(xiàn)服務(wù)性能大幅提升。
其實(shí)這真的是一種選擇，特別是在云原生時(shí)代之下，比如PingCAP創(chuàng)始人黃東旭就說(shuō)：TiDB在云上不會(huì)考慮有磁盤(pán)這件事，內(nèi)存那么便宜。
Redis是著名的內(nèi)存KV數(shù)據(jù)庫(kù)，大家肯定用的比較多。
對(duì)于內(nèi)存數(shù)據(jù)庫(kù)來(lái)說(shuō)，首先要解決的第一個(gè)問(wèn)題就是數(shù)據(jù)的高可用性。
看下Redis是如何做數(shù)據(jù)副本維護(hù)的：
Master負(fù)責(zé)數(shù)據(jù)讀寫(xiě)，可以有多個(gè)Slave來(lái)存儲(chǔ)數(shù)據(jù)副本，副本只讀且不做更新操作。
Slave初次啟動(dòng)之后，從Master獲取數(shù)據(jù)，在數(shù)據(jù)復(fù)制過(guò)程中，Master是非阻塞的，可以同時(shí)支持讀寫(xiě)操作。Master采用快照增量異步方式完成數(shù)據(jù)復(fù)制。
由于Master更新數(shù)據(jù)和Slave接收數(shù)據(jù)副本過(guò)程存在時(shí)間差，可能存在數(shù)據(jù)丟失的情況。
上面的邏輯其實(shí)是一種學(xué)習(xí)的邏輯，就是從what開(kāi)始。
但對(duì)于日常技術(shù)選型過(guò)程中，我更推薦從問(wèn)題本身出發(fā)的技術(shù)選型思維。
選型背后的邏輯是對(duì)問(wèn)題的理解
在互聯(lián)網(wǎng)場(chǎng)景下，在數(shù)據(jù)的使用上，對(duì)數(shù)據(jù)的一致性要求沒(méi)有銀行那么高。很多時(shí)候更看重?cái)?shù)據(jù)的高可用及架構(gòu)的可擴(kuò)展性。因此NoSQL數(shù)據(jù)庫(kù)對(duì)很多互聯(lián)網(wǎng)應(yīng)用場(chǎng)景是非常合適的。
NoSQL數(shù)據(jù)庫(kù)不追求應(yīng)用場(chǎng)景的統(tǒng)一，而是對(duì)不同類(lèi)型應(yīng)用有專(zhuān)門(mén)的NoSQL數(shù)據(jù)庫(kù)來(lái)進(jìn)行存儲(chǔ)管理。
這也是NoSQL數(shù)據(jù)庫(kù)的一個(gè)特點(diǎn)，就是說(shuō)在NoSQL數(shù)據(jù)庫(kù)選型時(shí)，考慮到其使用的場(chǎng)景反而更重要，而不是簡(jiǎn)單的站在NoSQL本身的技術(shù)視角去考慮問(wèn)題。
每一個(gè)NoSQL產(chǎn)品的背后其實(shí)是多種分布式問(wèn)題解決方案的體現(xiàn)，不同的NoSQL產(chǎn)品是解決分布式下的特定問(wèn)題的。
有的問(wèn)題是如何從包含數(shù)億成員的集合中快速找到某個(gè)成員屬于這個(gè)集合；
有的問(wèn)題是如何極其高效的將大數(shù)據(jù)量寫(xiě)入存儲(chǔ)系統(tǒng)中；
有的問(wèn)題是如何高效的判斷海量數(shù)據(jù)中哪些數(shù)據(jù)發(fā)生了變化；
有的問(wèn)題是如何高效的壓縮與解壓PB級(jí)的數(shù)據(jù)；
所以不同場(chǎng)景選擇什么樣的數(shù)據(jù)庫(kù)，其背后的選型邏輯是你怎么定義你當(dāng)前遇到的問(wèn)題。
如果只是簡(jiǎn)單的kv存儲(chǔ)解決數(shù)據(jù)庫(kù)qps壓力，其實(shí)說(shuō)實(shí)話(huà)選擇Redis還是memcache差別不大，更別說(shuō)選擇什么樣的redis分片集群機(jī)制了。
比如以下這兩種選型方式我不太贊成，這種看起來(lái)還是一種淺層次的對(duì)比，沒(méi)有到問(wèn)題本質(zhì)的層面。
bad case1：
bad case2：
比如如何判斷一個(gè)數(shù)在海量數(shù)據(jù)中？
有的人會(huì)直接去想：redis怎么判斷元素是否在數(shù)據(jù)集合中？
而你一旦意識(shí)到需要不斷挖掘這個(gè)問(wèn)題，你會(huì)發(fā)現(xiàn)它是個(gè)大數(shù)據(jù)量下的Bloom Filter問(wèn)題。
Bloom Filter常用于高效監(jiān)測(cè)某個(gè)元素是否在巨量集合中。那就可以就這這個(gè)點(diǎn)去看現(xiàn)有你已經(jīng)具備的NoSQL了，哪些可以解決這個(gè)問(wèn)題，實(shí)在不行你是否可以基于現(xiàn)有的存儲(chǔ)NoSQL自己搞個(gè)。
比如Chrome瀏覽器怎么進(jìn)行惡意URL判斷的？網(wǎng)絡(luò)爬蟲(chóng)怎么對(duì)以及爬過(guò)的URL判斷的？比特幣怎么對(duì)歷史交易進(jìn)行驗(yàn)證的？數(shù)據(jù)庫(kù)領(lǐng)域怎么解決兩個(gè)差異巨大的表Join過(guò)程的？
其實(shí)抽象下來(lái)，都是Bloom Filter的問(wèn)題。但你看到Chrome背后的redis了嗎？
所以不從問(wèn)題出發(fā)，而是拿著NoSQL去直接解決這個(gè)事，就是拿著錘子找釘子，想用redis去解決一切。
很多人都懂了“不要拿著錘子找釘子”這句話(huà)的道理，但為什么在技術(shù)選型的時(shí)候還是犯這個(gè)錯(cuò)誤？
兩個(gè)原因：
?這句話(huà)還僅僅停留在嘴上，并沒(méi)到心里，很多時(shí)候可能只是個(gè)談資；
對(duì)問(wèn)題沒(méi)有深挖，還是在看得見(jiàn)的二手信息中做判斷，要穿透現(xiàn)象看本質(zhì)；
一旦找到了你要解決的技術(shù)問(wèn)題的本質(zhì)，再做選型就非常簡(jiǎn)單了。
以這個(gè)例子來(lái)說(shuō)，你就看各個(gè)NoSQL如何支持BF的。或者看不同NoSQL用BF解決什么問(wèn)題就。這比你死記硬背一些Redis、Cassandra特性好用得多。
那你怎么快速定位海量數(shù)據(jù)下少量變化的數(shù)據(jù)內(nèi)容呢？
我們就遇到過(guò)類(lèi)似的問(wèn)題，比如我們做營(yíng)銷(xiāo)推薦。營(yíng)銷(xiāo)本身就是千店千面的，而且外賣(mài)是很強(qiáng)的LBS場(chǎng)景，理論上方圓五公里的商家數(shù)量是有限的。
但每個(gè)商家有屬于不同類(lèi)型的門(mén)店，有的是大連鎖，有的是小連鎖，有的是品牌，有的就是小店。
商家在后臺(tái)可以給自己商家設(shè)置對(duì)于不同用戶(hù)畫(huà)像的滿(mǎn)減、同享、津貼等各種活動(dòng)。平臺(tái)運(yùn)營(yíng)也可以對(duì)品牌商家設(shè)置不同的營(yíng)銷(xiāo)策略。商家也可以參加平臺(tái)的活動(dòng)。
而且不同活動(dòng)有不同的時(shí)間段，比如午高峰是從11:00~13:00。10:59領(lǐng)取的券和11:00領(lǐng)取的券效果和參加的活動(dòng)是不一樣的，最后結(jié)算的價(jià)格是不一樣的。
這一系列問(wèn)題你應(yīng)該怎么解決，既要數(shù)據(jù)一致性、又要高QPS、還要做活動(dòng)頻繁上下線(xiàn)、對(duì)不同人千人千面、解決多個(gè)活動(dòng)沖突曝光的問(wèn)題？
你可以考慮下。
數(shù)據(jù)庫(kù)選型只是數(shù)據(jù)存儲(chǔ)選型的一部分
其實(shí)選擇什么樣的數(shù)據(jù)庫(kù)，只是數(shù)據(jù)存儲(chǔ)選型的一部分。
不僅要考慮存儲(chǔ)量、使用場(chǎng)景、數(shù)據(jù)結(jié)構(gòu)、分布式算法，還需要考慮數(shù)據(jù)分片之后的分布式協(xié)調(diào)。
比如分布式鎖就是其中常見(jiàn)的一個(gè)分布式協(xié)調(diào)問(wèn)題。比較著名的分布式協(xié)調(diào)管理系統(tǒng)包括：谷歌的chubby、雅虎的zk、以及現(xiàn)在常用的etcd。
當(dāng)數(shù)據(jù)量變大之后，做了分片之后，多個(gè)客戶(hù)端應(yīng)用程序之間需要同步，并對(duì)系統(tǒng)環(huán)境或資源達(dá)成一致共識(shí)。
比如那個(gè)服務(wù)應(yīng)該作為leader、多個(gè)服務(wù)對(duì)一個(gè)競(jìng)態(tài)數(shù)據(jù)做并發(fā)、網(wǎng)絡(luò)分區(qū)之后腦裂了怎么辦。
這些問(wèn)題都是在大量數(shù)據(jù)選型，需要考慮的存儲(chǔ)之外的問(wèn)題。
比如我們做異地多活的時(shí)候，數(shù)據(jù)是需要多個(gè)可用區(qū)之間做復(fù)制的，那么數(shù)據(jù)之間如何解決沖突問(wèn)題？沖突了用哪份數(shù)據(jù)？怎么知道哪個(gè)節(jié)點(diǎn)數(shù)據(jù)同步落后了？分區(qū)了怎么達(dá)成共識(shí)？怎么低成本解決數(shù)據(jù)不一致問(wèn)題？
其實(shí)借助的就是很多分布式系統(tǒng)的協(xié)調(diào)方案，而并沒(méi)有哪類(lèi)NoSQL是可以直接解決類(lèi)似問(wèn)題的，我們需要針對(duì)不同NoSQL的特性做進(jìn)一步的封裝實(shí)現(xiàn)來(lái)解決我們當(dāng)前的難題。
互聯(lián)網(wǎng)架構(gòu)下的分布式存儲(chǔ)服務(wù)
在互聯(lián)網(wǎng)架構(gòu)下，還有一些分布式存儲(chǔ)服務(wù)，但大家關(guān)注的沒(méi)有mysql或者redis多。
分布式文件系統(tǒng)
其主要的功能有兩個(gè)：
?存儲(chǔ)文檔、圖像、視頻之類(lèi)的Blob類(lèi)型數(shù)據(jù)；
作為分布式表格系統(tǒng)的持久層；
分布式鍵值系統(tǒng)
是一種只支持KV的增刪改操作的數(shù)據(jù)庫(kù)，上面介紹的redis是其中的一種。
淘寶的Tair是阿里自研一個(gè)分布式kv存儲(chǔ)引擎。
其分為持久化存儲(chǔ)和非持久化存儲(chǔ)兩種方式：
非持久化：可以看做一個(gè)分布式緩存，類(lèi)似redis和memcache；?
持久化：是將數(shù)據(jù)放在磁盤(pán)中；
分布式表格系統(tǒng)
其對(duì)外提供表格模型，每個(gè)表格由很多行組成，通過(guò)唯一標(biāo)識(shí)，每一列包含很多列，整個(gè)表格在系統(tǒng)中全局有序。
谷歌的Bigtable是分布式表格系統(tǒng)的始祖，它有雙層結(jié)構(gòu)，底層采用GFS作為持久化存儲(chǔ)。GFS+BigTable雙層架構(gòu)是一種里程碑似的架構(gòu)，其他分布式表格系統(tǒng)對(duì)其都有一定借鑒。
分布式數(shù)據(jù)庫(kù)
關(guān)系數(shù)據(jù)庫(kù)Oracle、MySQL、SqlServer在互聯(lián)網(wǎng)及軟件場(chǎng)景廣泛應(yīng)用?？梢哉f(shuō)如果沒(méi)有關(guān)系型數(shù)據(jù)庫(kù)，就沒(méi)有IT行業(yè)的今天。
關(guān)系數(shù)據(jù)庫(kù)很長(zhǎng)時(shí)間只能運(yùn)行在單機(jī)之上，但技術(shù)人并沒(méi)有放棄將其變?yōu)榉植际郊軜?gòu)下的產(chǎn)品。
其中衍生出了很多思路想要解決關(guān)系數(shù)據(jù)庫(kù)的擴(kuò)展性問(wèn)題。
比如在應(yīng)用層劃分?jǐn)?shù)據(jù)，將數(shù)據(jù)劃分到不同的關(guān)系數(shù)據(jù)庫(kù)上；有的則是在關(guān)系數(shù)據(jù)庫(kù)內(nèi)部支持?jǐn)?shù)據(jù)自動(dòng)分片；或者干脆重寫(xiě)存儲(chǔ)引擎，變成新的分布式關(guān)系數(shù)據(jù)庫(kù)。
數(shù)據(jù)庫(kù)中間層是屬于在應(yīng)用層劃分?jǐn)?shù)據(jù)的一種方式，做好數(shù)據(jù)拆分，屏蔽后端數(shù)據(jù)庫(kù)拆分細(xì)節(jié)。這種思想也大量用于NoSQL數(shù)據(jù)庫(kù)的分布式擴(kuò)展架構(gòu)之下。
互聯(lián)網(wǎng)架構(gòu)之下對(duì)數(shù)據(jù)使用，不只有OLTP場(chǎng)景需要應(yīng)對(duì)大數(shù)據(jù)量的架構(gòu)問(wèn)題。OLAP也是其中需要面對(duì)的問(wèn)題，接下來(lái)簡(jiǎn)單說(shuō)下大數(shù)據(jù)常用架構(gòu)體系及AI時(shí)代的大數(shù)據(jù)架構(gòu)體系。
大數(shù)據(jù)
大數(shù)據(jù)分析是互聯(lián)網(wǎng)公司使用數(shù)據(jù)的另一個(gè)主要場(chǎng)景，比如從海量的數(shù)據(jù)中挖掘知識(shí)，過(guò)程上包括數(shù)據(jù)源收集、數(shù)據(jù)存儲(chǔ)管理、數(shù)據(jù)分析與挖掘、數(shù)據(jù)監(jiān)控展現(xiàn)等。
大數(shù)據(jù)與AI
大數(shù)據(jù)前幾年在組織上可能還是屬于獨(dú)立的一部分。但這幾年隨著人工智能、AI的場(chǎng)景不斷落地，大數(shù)據(jù)+AI慢慢變成了一個(gè)業(yè)務(wù)之下了。
比如大數(shù)據(jù)平臺(tái)之上會(huì)有風(fēng)控部門(mén)、數(shù)據(jù)分析部門(mén)、數(shù)據(jù)推薦部門(mén)、用戶(hù)畫(huà)像部門(mén)、各種指標(biāo)平臺(tái)等。
所以新的在大數(shù)據(jù)系統(tǒng)體系下包括，大數(shù)據(jù)存儲(chǔ)、批處理、流式計(jì)算、交互式數(shù)據(jù)分析、圖數(shù)據(jù)庫(kù)、并行機(jī)器學(xué)習(xí)等在內(nèi)的多個(gè)方向。
腦中還有很多想法，一時(shí)半會(huì)寫(xiě)不完，有時(shí)間再寫(xiě)吧。
希望對(duì)你有用。