【摘要】?本文提出了一種通過引入內(nèi)存數(shù)據(jù)庫層，建立兩層多分區(qū)分布式數(shù)據(jù)庫架構(gòu)。此方案用于解決海量高并發(fā)系統(tǒng)的數(shù)據(jù)存儲(chǔ)和訪問問題，尤其適用于電子商務(wù)等數(shù)據(jù)模型復(fù)雜且業(yè)務(wù)復(fù)雜的互聯(lián)網(wǎng)站。

?

這些年互聯(lián)網(wǎng)站發(fā)展迅猛，為應(yīng)對(duì)海量數(shù)據(jù)下的高并發(fā)訪問，產(chǎn)生了各種分布式架構(gòu)設(shè)計(jì)思想，例如Key-Value引擎，數(shù)據(jù)分區(qū)等。而對(duì)于電子商務(wù)類網(wǎng)站，海量數(shù)據(jù)問題還有一個(gè)重要特點(diǎn)，就是數(shù)據(jù)結(jié)構(gòu)化及數(shù)據(jù)之間的關(guān)聯(lián)，淘寶如此，阿里巴巴也是如此，這是與社區(qū)、視頻、?博客等互聯(lián)網(wǎng)站的顯著差異。

?

1.? NoSQL?是靈丹妙藥嗎？

NoSQL、Key-Value?引擎如BigTable、Cassendra等在很多大型網(wǎng)站被采用，很好的解決了海量數(shù)據(jù)存儲(chǔ)和訪問問題。而對(duì)于電子商務(wù)類網(wǎng)站，Key-Value和NoSQL并不是解決此問題的靈丹妙藥。最多它們僅能用于一些數(shù)據(jù)模型較為簡(jiǎn)單的應(yīng)用。

原因有兩個(gè)方面：

1）數(shù)據(jù)模型復(fù)雜

淘寶和阿里巴巴的會(huì)員、寶貝、供求、訂單等核心實(shí)體數(shù)據(jù)模型復(fù)雜，屬性個(gè)數(shù)幾十到上百個(gè)。例如：會(huì)員(Member)就包含基本信息、聯(lián)系、工商、賬戶等多個(gè)域的信息；另外，核心實(shí)體之間，外圍實(shí)體與核心實(shí)體之間還存在復(fù)雜的關(guān)聯(lián)。

2）業(yè)務(wù)復(fù)雜：

模型的復(fù)雜源于業(yè)務(wù)和邏輯的復(fù)雜。電子商務(wù)網(wǎng)站大量查詢場(chǎng)景是結(jié)構(gòu)化查詢，例如：

在淘寶上查詢“賣家在江浙滬，價(jià)格在50-200元的男士T恤”，

在阿里巴巴上“列出某個(gè)會(huì)員所有待發(fā)貨的訂單”

這類查詢（當(dāng)然，阿里巴）主要針對(duì)多個(gè)非主鍵字段,?即便對(duì)于BigTable、Cassandra?這樣的基于Column的Key-Value數(shù)據(jù)庫，其簡(jiǎn)單的Query API還無法勝任此類需求。 因此在阿里巴巴和淘寶，Oracle、MySQL?等關(guān)系數(shù)據(jù)庫將仍然扮演重要角色。

?

2. MySQL?集群

引入K-V引擎等非關(guān)系數(shù)據(jù)庫無非是要解決海量數(shù)據(jù)在高并發(fā)環(huán)境下的高效讀寫問題，最大程度在可靠的持久化(Durable)與高訪問性能?(Performance)?之間選擇一個(gè)平衡點(diǎn)。在高度結(jié)構(gòu)化系統(tǒng)中，同樣的考慮驅(qū)使我們需要考慮另外的解決方案。

目前一種通行的做法是?MySQL?讀寫分離式集群，1個(gè)或少數(shù)Master寫，多數(shù)Slave讀，Master與Slave進(jìn)行變更數(shù)據(jù)的同步。首先，這種方案經(jīng)過大量的實(shí)踐，可靠且可行。

然而，直接向DB執(zhí)行寫操作，仍然比較耗時(shí)(參見表1，表2)，數(shù)據(jù)復(fù)制，也可能存在不一致延時(shí)的情形。是否還有更快的方案？

3.?內(nèi)存型關(guān)系數(shù)據(jù)庫

可靠的持久化指數(shù)據(jù)存儲(chǔ)到磁盤等設(shè)備上。圖1展示了傳統(tǒng)磁盤數(shù)據(jù)庫的基本訪問模式。

?

?圖1

拋開持久化的可靠性，即數(shù)據(jù)可以先不存儲(chǔ)到磁盤上(Disk)，內(nèi)存存儲(chǔ)的性能遠(yuǎn)高于磁盤存儲(chǔ)。下表展示了針對(duì)Oracle和Altibase所做的性能對(duì)比，后者在插入和查詢上性能是Oracle的5-7倍。

?

數(shù)據(jù)庫	測(cè)試結(jié)果	TPS
Oracle	203秒	246條/秒
Altibase	28.32秒	1785條/秒

表1. Oracle、Altibase性能對(duì)比?-插入5萬條?^【7】

?

數(shù)據(jù)庫	測(cè)試結(jié)果	TPS
Oracle	885秒	112條/秒
Altibase	170秒	588條/秒

表2 Oracle、Altibase性能對(duì)比?–?關(guān)聯(lián)查詢10萬條^【7】

?

由此可見：Pm? >>>? Pd?

（Pm -?內(nèi)存數(shù)據(jù)庫讀寫性能，?Pd -?磁盤數(shù)據(jù)庫讀寫性能）

?

結(jié)合前面分析的模型復(fù)雜性和業(yè)務(wù)復(fù)雜性原因，關(guān)系數(shù)據(jù)庫（RDBMS）必須采用。因此，這兩點(diǎn)考慮可以推導(dǎo)出另一個(gè)解決思路：內(nèi)存型關(guān)系數(shù)據(jù)庫。

?

?	磁盤型關(guān)系數(shù)據(jù)庫	Key-Value引擎	內(nèi)存型關(guān)系數(shù)據(jù)庫
功能?-結(jié)構(gòu)化操作和查詢等	Y	N	Y
性能	低	高	高

表3. DB選型對(duì)比分析

?

這個(gè)方案里，我們可以將內(nèi)存先看做一種“磁盤”，讀寫操作都針對(duì)內(nèi)存數(shù)據(jù)庫進(jìn)行，不再直接與磁盤數(shù)據(jù)庫交互，這較好的避免了單純MySQL?讀寫分離架構(gòu)存在的時(shí)間延遲和一致性問題。如下圖所示：

?

?圖2

4.?內(nèi)存數(shù)據(jù)庫的持久化

數(shù)據(jù)最終還是要存儲(chǔ)到磁盤(Disk)上，內(nèi)存數(shù)據(jù)庫中的數(shù)據(jù)變化需要復(fù)制到與磁盤數(shù)據(jù)庫上。這時(shí)，從內(nèi)存向磁盤復(fù)制數(shù)據(jù)的過程可以看作原始寫操作的異步操作，顯然，異步操作使得前端的寫操作顯得更快。如下圖所示：

?

?圖3

在事務(wù)型(OLTP)系統(tǒng)中，內(nèi)存數(shù)據(jù)庫中在啟動(dòng)時(shí)需要和磁盤數(shù)據(jù)庫保持一致。 因此，內(nèi)存數(shù)據(jù)庫需要有相同的庫表定義；并且在第一啟動(dòng)時(shí)，將所需庫表數(shù)據(jù)加載到內(nèi)存數(shù)據(jù)庫中。

?

5.?內(nèi)存數(shù)據(jù)庫集群化

目前，經(jīng)典的MySQL集群，通過讀寫分離，水平切分，實(shí)現(xiàn)海量數(shù)據(jù)存儲(chǔ)。為應(yīng)對(duì)海量數(shù)據(jù)存儲(chǔ)，內(nèi)存數(shù)據(jù)庫同樣需要做集群。垂直和水平切分策略，可用性策略與MySQL集群架構(gòu)設(shè)計(jì)基本相同。如下圖所示，其中?Ameoba?是分布式數(shù)據(jù)庫代理，它進(jìn)行數(shù)據(jù)路由等控制。

唯一的不同是，由于內(nèi)存數(shù)據(jù)庫的高性能，可以不再進(jìn)行讀寫分離設(shè)計(jì)。

?

?圖4

?

6.?混合分區(qū)（Hybrid Shard）

接第4節(jié)的分析，內(nèi)存數(shù)據(jù)最終仍需要持久化到磁盤。這里需要一種混合分區(qū)(Hybrid Shard)來解決。即原來一個(gè)MySQL節(jié)點(diǎn)承擔(dān)的一個(gè)水平分區(qū)，將由一個(gè)內(nèi)存數(shù)據(jù)庫節(jié)點(diǎn)和一個(gè)MySQL節(jié)點(diǎn)共同組成。

H-Shard = MDB + MySQL.

?

這種數(shù)據(jù)庫架構(gòu)將形成由兩級(jí)數(shù)據(jù)庫(2LDB)，混合分區(qū)構(gòu)成的集群。的如下圖所示：

?

?圖5

?

7.?內(nèi)存數(shù)據(jù)庫選型

常見的內(nèi)存數(shù)據(jù)庫產(chǎn)品包括商業(yè)版和免費(fèi)版兩類。商業(yè)版如：Altibase，Timesten，Berkley DB等。他們?cè)陔娦?#xff0c;金融，證券等高性能計(jì)算應(yīng)用中運(yùn)用較為廣泛。商業(yè)版功能強(qiáng)大，然而，價(jià)格比較昂貴，不適合目前“廉價(jià)PC+免費(fèi)軟件”的架構(gòu)搭建思想。

筆者曾就職與中國移動(dòng)系統(tǒng)提供商，其中計(jì)費(fèi)、運(yùn)營等系統(tǒng)就運(yùn)用Timesten提供高性能運(yùn)算，但還主要用于高頻度小數(shù)據(jù)計(jì)算，如計(jì)費(fèi)批價(jià)，優(yōu)惠計(jì)算，信控等，采用單節(jié)點(diǎn)模式使用。

開源領(lǐng)域產(chǎn)品主要有H2，HsqlDB，Derby等。在混合分區(qū)架構(gòu)中，內(nèi)存數(shù)據(jù)庫將承擔(dān)OLTP的職責(zé)，因此除了讀寫性能外，功能的完備，事務(wù)等都需要作為優(yōu)先評(píng)估的因素。

?

8.?新架構(gòu)的挑戰(zhàn)

通過引入內(nèi)存數(shù)據(jù)庫作為中間持久層，再加入分布式架構(gòu)以支撐海量數(shù)據(jù)訪問，這種架構(gòu)設(shè)計(jì)頗具挑戰(zhàn)。最先而易見的情況就是新架構(gòu)的復(fù)雜度，正如大規(guī)模MySQL集群架構(gòu)誕生初始一樣。

我們以?H2?，一個(gè)開源的高性能內(nèi)存數(shù)據(jù)庫為例說明：

1)??整合?Ameoba?與?H2

Ameoba?是分布式數(shù)據(jù)庫代理，它與?MySQL?整合已經(jīng)在阿里巴巴核心業(yè)務(wù)中成功運(yùn)用。如果僅將數(shù)據(jù)庫節(jié)點(diǎn)看作一個(gè)存儲(chǔ)，MySQL Node?和?H2 Node?并無本質(zhì)區(qū)別。JDBC驅(qū)動(dòng)，DB切分，路由，皆由Ameoba?統(tǒng)一負(fù)責(zé)。

?

2)??異步持久化

每個(gè)邏輯混合分區(qū)= H2 + MySQL，誰來完成H2?中的數(shù)據(jù)變更異步寫入?MySQL？

比較好的方案是內(nèi)存數(shù)據(jù)庫提供實(shí)時(shí)增量的復(fù)制器（Replicator)?，例如：基于聯(lián)機(jī)日志復(fù)制的雙機(jī)熱備機(jī)制。AltiBase?等產(chǎn)品就提供了此功能。

?

3）高可用性

內(nèi)存數(shù)據(jù)庫一旦崩潰，數(shù)據(jù)不復(fù)存在。因此首先要做到數(shù)據(jù)快速異步寫入MySQL作持久化存儲(chǔ)。同時(shí)要有健壯的容錯(cuò)和Failover機(jī)制，保證一個(gè)H2節(jié)點(diǎn)崩潰，同一邏輯分區(qū)中的替補(bǔ)H2節(jié)點(diǎn)立即頂替工作。

一種方案是分布式數(shù)據(jù)庫代理如?Ameoba?來解決，例如：每個(gè)Shard，H2至少設(shè)2個(gè)節(jié)點(diǎn)，采用Primary-Secondary模式，如圖6所示：

?

?圖6

?

另一種方案是前面提到的內(nèi)存數(shù)據(jù)庫實(shí)時(shí)復(fù)制功能。

雖然有些內(nèi)存DB如H2自身能支持內(nèi)存，磁盤兩級(jí)存儲(chǔ)，但其自身提供的磁盤存儲(chǔ)和訪問方案可靠性不如?MySQL。因此，使用內(nèi)存式Primary-Secondary?模式更為可行。

?

4）分布式事務(wù)

數(shù)據(jù)庫切分架構(gòu)帶來分布式事務(wù)問題，對(duì)一些事務(wù)要求較高的場(chǎng)景，這頗具挑戰(zhàn)。Ameoba?目前還在解決中。Ameoba + H2組合面臨同樣的挑戰(zhàn)。

目前一種比較一致意見和做法就是冷處理——盡量不用事務(wù)。 一致性問題根據(jù)業(yè)務(wù)的特點(diǎn)，采用數(shù)據(jù)訂正來解決；個(gè)別業(yè)務(wù)使用補(bǔ)償事務(wù)。因?yàn)槟壳按蟛糠謶?yīng)用，即便是核心業(yè)務(wù)，對(duì)事務(wù)的要求也不高。

?

9.?進(jìn)一步思考

1） 多種數(shù)據(jù)切分模式

????在一個(gè)大型互聯(lián)網(wǎng)站，不同的應(yīng)用和數(shù)據(jù)需要做不同的處理。在總體垂直切分模式基礎(chǔ)上，選擇數(shù)據(jù)量大的功能進(jìn)行水平切分，例如：供求、訂單、交易記錄。

???

2）數(shù)據(jù)緩存（Data Cache）

雖然內(nèi)存數(shù)據(jù)庫層(MDB)能更高效支撐交易型數(shù)據(jù)庫，特別是應(yīng)對(duì)結(jié)構(gòu)化應(yīng)用及復(fù)雜查詢服務(wù)，但對(duì)高頻度的查詢(Query)和實(shí)體查找(Find)，Key-Value緩存仍然是一項(xiàng)必要的設(shè)計(jì)。Cache能提供更高的查詢速度，并減少對(duì)MDB的訪問壓力，特別是讀寫密集的高并發(fā)場(chǎng)景。因?yàn)檫@個(gè)架構(gòu)中，內(nèi)存數(shù)據(jù)庫仍然作為一種存儲(chǔ)Store，而不是Cache。

?

?圖7

上圖展示了，MDB層之上還需要DCL層來提供高性能緩存服務(wù)。

?

10.?總結(jié)

本文提出了一種通過引入內(nèi)存數(shù)據(jù)庫層，并建立兩層，多分區(qū)的分布式數(shù)據(jù)庫架構(gòu)。此方案用于解決海量高并發(fā)系統(tǒng)的高性能數(shù)據(jù)存儲(chǔ)和訪問問題，尤其是電子商務(wù)類等業(yè)務(wù)復(fù)雜的互聯(lián)網(wǎng)站。其核心思想是：

1）高性能：是通過內(nèi)存數(shù)據(jù)庫提供高性能關(guān)系數(shù)據(jù)庫存取服務(wù)，這是此架構(gòu)的最主要目標(biāo)；

2）持久化：通過兩級(jí)數(shù)據(jù)庫及異步寫完成持久化；

3）海量數(shù)據(jù)支撐：通過垂直和水平分區(qū)實(shí)現(xiàn)海量數(shù)據(jù)的支撐；

4）高可用性：在Ameoba基礎(chǔ)上，通過主備節(jié)點(diǎn)進(jìn)一步實(shí)現(xiàn)MDB的高可用性；二級(jí)磁盤數(shù)據(jù)庫可以實(shí)現(xiàn)數(shù)據(jù)的快速恢復(fù)。

?

【參考資料】

1.??阿里巴巴?Ameoba分布式數(shù)據(jù)庫設(shè)計(jì)和實(shí)踐

2.?岳旭強(qiáng),?《淘寶網(wǎng)架構(gòu)師岳旭強(qiáng)的年度展望》，?http://www.infoq.com/cn

3.?廣東移動(dòng)BOSS2.0分布式數(shù)據(jù)庫架構(gòu)方案，計(jì)費(fèi)系統(tǒng)設(shè)計(jì)和實(shí)踐.

4. Cassandra，http://cassandra.apache.org/

5. Oracle, Timesten?官方文檔,?http://www.oracle.com/timesten/index.html

6. Fenng,《Oracle?內(nèi)存數(shù)據(jù)庫-TimesTen》,?http://www.dbanotes.net/database/oracle_timesten.html

7.?張澄,包文菖,《內(nèi)存數(shù)據(jù)庫在BSS賬務(wù)處理中的應(yīng)用》，《計(jì)費(fèi)&OSS世界》，http://database.51cto.com/art/200612/36973.htm

8. Titan,《常用內(nèi)存數(shù)據(jù)庫介紹》，http://titan.javaeye.com/blog/364345

9. Ricky Ho,?《NoSQL的模式》，程序員2010-1；《NoSQL?數(shù)據(jù)庫的查詢處理》，程序員2010-2

https://blog.csdn.net/tolys/article/details/5963506

總結(jié)

以上是生活随笔為你收集整理的基于内存数据库的分布式数据库架构的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。