NoSQL資料庫作為資料庫市場最重要的組成之一，它的一舉一動都影響著成千上萬的企業。本專場邀請了行業頂級的NoSQL核心成員與大家共同展望NoSQL資料庫的未來，阿里巴巴、MongoDB、Redisson、鬥魚等公司的技術大咖與大家共同分享了阿里雲NoSQL資料庫的企業級特性及行業解決方案。

Redis & MongoDB雲資料庫技術剖析

阿里雲智慧事業群資料庫產品事業部技術總監，MongoDB中國使用者組杭州使用者會(葉翔)為大家深度剖析了Redis和MongoDB雲資料庫的技術。

Redis企業級資料庫服務Redis作為企業級資料庫需要關注四個方面：

 分散式：需要滿足企業快速成長和降低成本的需要，實現彈性擴容，以及從主從模式變為叢集模式。  相容性：相容性是永恆的話題，即使無法做到100%一致，但需要無限接近。  安全審計：安全在雲環境中越來越重要，Redis開源版的安全審計能力比較薄弱，阿里雲Redis對於這一點進行了加強。  資料同步：需要能夠支援混合雲部署，使得第三方雲廠商、IDC與阿里雲實現互通，以及資料遷移和轉換，滿足客戶上雲或者下雲的靈活決策。

Redis原生的Cluster架構採用了Gossip協議實現路由表的同步，但這種架構在社群以及企業中並沒有快速流行起來。雖然其有無中心架構、元件依賴少等優點，但也存在很多問題，如運維困難，路由存在不確定性，需要依賴Smart Client，並且不支援Multi-Key以及從主從模式遷移到叢集模式，進而造成升級困難。

為了解決上述問題，阿里雲Redis資料庫沒有采用Gossip協議，而是引入了新的兩個元件：Proxy和Config Server。阿里雲Redis採用了配置中心對於路由表資訊進行管理，可以透過Config Server進行智慧化排程，Proxy則能夠相容非Smart Client，支援Multi-Key，並能夠實現流量管理以及讀寫分離等。Proxy和Config Server雖然帶來了架構的複雜性，但管理大規模複雜架構正是雲廠商所擅長的。此外，這兩個新元件所造成的額外成本也會被削平。透過這樣的雲服務架構使得使用者能夠將Redis從主從架構無縫遷移到叢集版本。

隨著Redis Cluster雲服務架構的延伸，出現了一個新概念——Redis雲資料庫企業分散式矩陣。這個矩陣能從縱向和橫向進行擴充套件，縱向能夠隨著Shard的新增進行分片，從而實現彈性擴充套件；橫向則能夠實現讀寫分離，並且做了Group分組隔離。全域性來看，還支援Memcache和Redis雙協議，並且能實現叢集、主備之間的平滑切換。

阿里雲Redis的Proxy引入了Connection Session的概念，能夠對於Connection實現更細粒度的管理，並且透過連線池實現了長連線複用，不僅能夠相容多種協議，並透過C語言高效能程式碼也提升了短連線的效能。阿里雲Redis的Proxy還具有熱升級能力，能保證在服務不間斷的情況下升級版本。

阿里雲Redis在整個資料鏈路上進行了逐層加密處理，支援了SSL、白名單、許可權管理以及關鍵命令的禁用和審計等，增強了Redis的安全審計能力。Redis還提供了一些免費的開源工具，如同步工具RedisShake以及資料校驗工具RedisFullCheck等。

而Redis作為記憶體型的快取服務也存在很多挑戰，比如容量受限，成本較高以及持久化能力弱等。基於以上問題，阿里雲提供了混合儲存的Redis版本，其目的在於為使用者提供持久化、可安全儲存的Redis服務。其實現依賴於底層的RocksDB，透過不斷同步冷熱Key，使得記憶體處於可控範圍之內。

MongoDB企業級資料庫服務

MongoDB作為企業級資料庫需要關注四個方面，即安全審計、備份恢復、資料同步以及彈性伸縮。MongoDB的安全審計與Redis基本一致，進一步增加了TDE加密。MongoDB增加了物理備份，使得備份和恢復效率都有了大幅度提升，並且透過增量備份能力使得資料能夠恢復到任意時間點。此外，在備份的基礎之上，阿里雲MongoDB還提供了備份驗證能力。

阿里雲MongoDB還提供了診斷分析能力，並提供了MongoShake工具對資料進行同步。阿里雲MongoDB基於RocksDB引擎實現了共享儲存解決方案，可以實現儲存彈性伸縮，秒級新增只讀節點，並解決了oplog全域性鎖問題。當然，這樣的方案也面對著幾點挑戰，如與WiredTiger的相容性問題；Compaction帶來的效能抖動；以及共享儲存延遲穩定性。

基於MongoDB的資料中臺技術實現

MongoDB大中國區首席架構師唐建法為大家介紹了基於MongoDB的資料中臺技術實現。

如果企業業務需要對接不同的客戶資料，而這些資料的結構、型別各不相同，可能需要花費數週甚至數月。很多已有的解決方案就是實現資料統一平臺，將所有資料透過ETL抽取到資料平臺上，這種方式的共性是“T+1”的方式批次採集彙總，做成資料集，以互動方式提供下載。但這種方式存在著平臺資料滯後、響應速度慢、互動方式粗糙等問題。

資料中臺從技術的角度進行定義就是“資料統一平臺+資料即服務能力”。資料來源於業務，需要按照“T+0”方式採集，提供及時的資料。資料需要以API的服務化方式交付出去，而非打包。這使得資料中臺能夠對企業賴以生存的操作型系統提供支援，相比於分析型業務，操作型業務更加核心，更加能夠提高企業競爭力，這也是資料中臺火爆的原因。

資料中臺的定義就是包含企業實時全域資料的，主要面向操作型業務應用為主的資料服務技術平臺。其概念起源自國內，存在眾多流派，眾說紛紜。諮詢公司說資料中臺是一種組織架構的轉變，方案提供商則說資料中臺是像Hadoop一樣的技術平臺產品，不同的組織有不同的出發點。

中國97%小微企業與資料中臺基本不相關。腰部佔3%的120萬家大中型企業，可能有很多的開發人員但沒有資料專家，另外還有少部分頭部企業。對於腰部的大中企業而言，系統可能不多，而資料團隊基本沒有，無法快速構建完善的資料中臺，但是資料孤島的痛點、資料打通以及快速開發的需求卻是真實存在的。這些企業可以選用技術型架構，具體需要考慮的能力包括資料匯聚、資料治理以及建模、資料API服務，以及最關鍵的儲存、海量、多模和高效能。

RDBMS、MPP、Hadoop、NoSQL以及NewSQL資料技術各有長短板，在構建中臺時也可以做一些參考，企業需要根據自身實際情況進行考量。

之前，MongoDB用於大資料離線分析並不是很好的選擇，更多地是將其用於業務場景。而資料中臺面向的就是業務應用場景，因此MongoDB成為了一個不錯的選擇，其具有較強的橫向自動擴充套件能力，支援多模多型，並且API友好。此外，基於MongoDB實現建模所需要的工作遠少於傳統方式，能夠降低成本。

此外，MongoDB還具有資料採集、視覺化建模、無程式碼化API、資料視覺化等資料中臺構建所必須的能力。

如下圖所示的是較為完整的MongoDB資料中臺解決方案參考架構，從下到上依次是採集、儲存處理以及資料服務三層。

基於MongoDB構建資料中臺具有這樣幾個核心優勢，即無縫橫向擴充套件能力、多型別結構資料模型、邏輯模型即儲存模型、異構實時資料庫同步能力、無程式碼快速API釋出能力以及簡單、輕量和快速。

圖資料庫GDB的設計與實踐

阿里巴巴資深技術專家朱國雲(宗岱)為大家分享了阿里巴巴圖資料庫GDB的設計與實踐。

什麼是圖資料庫

圖資料庫是針對於圖結構設計的資料庫，而非圖片資料庫。什麼是圖結構呢？這是以社交網路模型為例介紹，該模型中存在人與人、人與論壇、人與帖子、帖子與論壇之間的關係，人、論壇、帖子就屬於圖中的點（即Vertex），點之間的關係就稱之為邊（即Edge），在點和邊上會有一些屬性（即Property）。

如今，一些優秀的社交應用會將多維資料儲存到統一的圖空間中來，進行儲存、查詢和分析，為使用者帶來更好的體驗。近年來，資料量越來越大的同時，資料維度也逐漸增多，圖資料庫就是在這種背景下誕生的。

圖資料庫作為近年來資料庫領域中發展最快的一類，與關係型資料庫存在哪些差別呢？通常情況下，關係型資料庫中需要透過建七八張表才能做到的模型，圖資料庫能夠更加直觀、自然地表現出來。此外，圖資料庫做關聯查詢的速度更快，還能夠提供更多探索發現的能力。

前面提到的是屬性圖模型，在圖資料領域還有一種RDF模型。兩者的主要區別在於RDF的點和邊上不可以有屬性。

圖資料庫發展速度很快，因此種類也是特別多，主要可以分成四類，即知識圖/RDF、分析圖、圖資料庫、多模型圖資料庫。這些圖資料庫系統使用的主流查詢語言大致有三類，即Neo4j主推的最早使用類SQL查詢語言的Cypher、用於RDF上的描述語言SPARQL和目前支援最廣泛的基於屬性圖的查詢語言Gremlin。

什麼是圖資料庫GDB

GDB是一種圖資料庫，其主要處理高度連線資料的儲存和查詢，其支援了屬性圖模型和開源的TinkerPop Gremlin查詢語言。與其他資料庫不同的是：GDB是雲原生資料庫，從一開始就建設在阿里雲基礎設施之上，因此能夠做到彈性、實時和高可靠。

GDB脫胎於Tair Service中的TairGraph 子系統，後來其孵化出來，並放到阿里雲上來專注地解決高度連線資料場景中的問題。基於Tair 10年的技術基礎，GDB實現了高度最佳化的自研引擎，能夠實現實時更新和秒級查詢，並且完整地支援ACID事務，並透過多副本保障高可靠。此外，還做到了服務高可用，能夠實現節點故障迅速轉移；易運維，提供了開箱即用的能力；視覺化，更利於分析資料的內在關係。

在架構層面，GDB為客戶提供的是獨享專屬例項，這意味著資源獨立，無須擔心搶佔問題。HA方面採用了最經典主備架構，並提供只讀節點來提升實時查詢能力。GDB支援了Gremlin開源的TinkerPop SDK，為了實現每秒百萬級點邊過濾，GDB定製了專屬的圖友好資料庫引擎，並在查詢最佳化和並行執行等方面做了大量最佳化，還支援了事務和自動索引。在資料通道部分，GDB還提供了多種資料來源的高效匯入支援。

GDB的場景和案例

如今，GDB在社交網路、金融欺詐檢測、實時推薦引擎、知識圖譜以及網路/IT運營等場景中得到廣泛應用，而且這些場景往往交織在一起。使用GDB能夠將之前偏離線的場景做到實時或者準實時。

總結而言，在資料維度越來越多、資料相互關聯越來越緊密的今天，GDB提供了一種有效的圖儲存方式，能夠將多維資料很好地連線起來，並透過圖查詢、圖演算法把資料隱藏的價值實時地、智慧地挖掘出來。

從Java走向雲原生，Redisson不停地探索

Redisson聯合創始人顧睿為大家分享了Redisson從Java走向雲原生的探索之路。

Redisson是架設在Redis基礎上的一個Java駐記憶體資料網格。Redisson以Java介面方式而非命令的形式提供給大家，使用非常簡單。其優勢在於上手容易，只要能夠使用Java基本就能夠使用Redisson。此外，Redisson在設計時規避了多執行緒的問題，採用了執行緒安全的設計，同時引入了執行緒池和連線池的管理，在同步和非同步的場景中都能選到適合的方式。

除了使用簡單外，Redisson在功能上也提供了多種選擇，能夠支援31種分散式集合、14種分散式物件、8種分散式鎖和分散式同步器以及5種分散式服務。

Redisson的架構主要分為兩大塊，包含Redisson客戶端的連線管理、協議解析在內的基本功能和包括分散式結構、分散式中介軟體以及第三方功能支援在內的高階功能。

從Redisson架構角度來看，似乎和Redis的理念相沖突。Redis設計理念強調簡單，而Redisson設計卻比較複雜；Redis提供了9種資料結構，界限清晰，而Redisson提供了約60種，界限比較模糊；Redis以命令形式面向使用者，而Redisson卻以Java API形式面向使用者。看似分道揚鑣，實則殊途同歸，都是為了將複雜隱藏起來，將簡單的使用方式提供給使用者。

只支援Java是Redisson的優點，也是缺點。Java是Redisson的一個牢籠，這對於應用程式開發者而言是優勢，而對於程式庫開發者而言就是劣勢。因此，Redisson一直在思考如何走出困境，擁抱其他的生態。

2016年，Redisson首先嚐試了使用Vert.x框架，Vert.x的特點是叢集執行環境、多語言互動性和基於成熟技術，並且Vert.x對開發者的限制比較少。因此，Redisson做了相關的實驗，實現了Redisson在其他語言中的執行。但是這種方案學習成本非常大，而實際收益卻不高。

2018年，Redisson注意到ORACLE Labs推出的GraalVM，GraalVM的底層是Java執行層，包括GraalVM和SubstrateVM，可以讓其他語言都能夠編譯融合並放入JVM中執行，同時保證相互溝通的橋樑。SubstrateVM是最吸引Redisson的點，它可以理解為用Java編寫的嵌入式虛擬機器，使得真正的跨平臺和跨語言成為可能。

於是，Redisson開始了“逃跑之路”，實現了redisson-native。對於Java、Java+Warm UP以及Native三種方式的效能進行對比，能夠看出redisson-native的效能具有明顯的優勢。

因此，這說明藉助SubstrateVM逃離Java是非常好的解決方案，無需考慮JNI等相關問題，大部分操作只需要Java即可完成，學習成本較低，並且無需安裝獨立的JVM，生成檔案也較小，雲原生情況下效能較高，並且C呼叫非常簡單。延伸開去，可以將Redisson帶入到原生的二進位制狀態並進行二次封裝，實現遍地開花。

基於企業級HBase的大資料儲存與處理

阿里雲智慧事業群資料庫產品事業部技術總監，Apache HBase PMC沈春輝(天梧)為大家分享了基於企業級HBase的大資料儲存與處理。

進入大資料時代，資料量越來越多，資料種類也越來越豐富。資料量多這一點容易理解，而資料種類豐富則可以從三個維度來看：從靜態維度，如今能夠用數字化裝置越來越多；從動態維度，裝置、服務的執行狀態越來越多；此外，還有資料再加工又產生了新資料，使得資料變得無窮無盡。面對這麼多數量和種類的資料，如果沒有價值就都是廢墟。回顧這十年，大家對資料價值層面的認知越來越強烈，資料也越來越多地應用到生活中的各個場景。

隨著對資料的應用，系統會面臨很多挑戰。大資料提出了“4V”，具體對於開發者而言，資料體量非常大意味著系統需要高擴充套件性；資料種類非常豐富意味著系統需要具有高靈活性，能夠很好承載隨時隨地產生的新資料種類；資料時效性意味著系統具有高實時性，具有資料線上化能力；資料價值則意味著需要能夠商業化，系統需要降低資料的儲存和計算成本。

十多年前，Google首先遇到大資料問題，因此發表了Big Table論文。而HBase則是基於該論文設計的高可靠、高效能、可伸縮的開源大資料NoSQL系統。HBase放棄了對於關係型資料庫事務的支援，重點構建擴充套件效能力、靈活效能力、實時響應能力以及對大體量資料儲存低成本的能力。

阿里巴巴從2010年開始調研HBase，如今已經走過了近十個年頭。隨著這十年的逐步探索，阿里巴巴也豐富了HBase的使用場景，如訊息，訂單，Feed流，監控，大屏，軌跡，裝置狀態，AI儲存，推薦，搜尋，BI報表等。阿里巴巴自己使用HBase已經達到了非常大的體量和規模，也在產品上有了很多積累和沉澱，形成了如今雲HBase+X-Pack的架構。單獨依靠HBase資料庫無法解決業務場景下的複雜問題，因此X-Pack基於雲HBase在計算、檢索、多模型上進行了擴充套件，包含了Spark、Phoenix、Solr以及OpenTSDB等，形成了穩定、易用、低成本的一站式大資料NoSQL平臺。

雲HBase+X-Pack架構實現了低成本的資料儲存，將HBase執行在OSS上面，並且讓整體介面模型複用HDFS能力。並且同時克服了OSS在面向檔案場景下的問題，將原本物件導向的儲存系統當做類似雲盤來使用，使得儲存成本降低3到7倍。此外，還基於HBase做到了一體化冷熱分離，並使得業務無感知。

除了低成本儲存之外，阿里雲HBase還投入了大量的精力來最佳化效能。相比開源版本，阿里雲HBase在各個效能指標上都有較大的提升。在這背後是不斷的最佳化，如原本將基於HDFS Pipeline日誌三副本轉變向LLC機制，並將序列改為並行；將原本序列獲取鎖的方式變為並行；並且實現了10倍的Java GC最佳化。

最後一點，HBase屬於大資料領域，必須結合很多元件，因此易用性也是大家最為迫切需要的。阿里雲HBase實現了HBase和Spark的資料聯動以及線上和離線的高效融合。此外，阿里內部也提供了一套易用的資料遷移系統，能夠實現平滑線上搬遷。

無論是從穩定性、易用性還是效能和成本上來說，阿里雲HBase都有很大的提升。未來，阿里雲HBase還會透過共享塊儲存等技術進一步降低成本，也將會推出Serverless能力，並且會透過新硬體來加速計算，降低成本。

鬥魚直播從0到1混合雲架構演進

鬥魚技術總監馬勇為大家分享了鬥魚直播的混合雲架構演進之路。

鬥魚直播成立於2014年，是以遊戲賽事為主的直播平臺，平臺簽約國內Top100主播約50位，覆蓋遊戲主播Top10中8位，月活達1.5億，2019年Q1付費使用者約600萬。鬥魚主要有三條業務特點：頭部主播熱點效應，流量水位波動較大，以及線上互動場景較多。目前的技術現狀是每天業務呼叫量在千億左右，Redis例項叢集達2000以上，單個介面QPS達20萬以上。

鬥魚直播從2016年開始保持每年25%以上的月活增長，目前面對的技術困境主要有三點：(1)“炸魚”，頭部流量拖死全站房間；(2)伺服器資源利用率低，日常水位大量伺服器閒置；(3)Redis維護和容災成本高。

鬥魚混合雲架構歷程主要分為三個階段，在探索期做了獨立業務上雲的嘗試；在成長期透過IDC+雲的方式實現了橫向流量擴容；在成熟期完成橫向擴容之後實現對資源的最大化利用。

探索期的主要背景是IDC硬體資源呈現為長期緊缺狀態，研發支撐跟不上業務發展，而公有云逐步成熟。因此在這一階段，鬥魚嘗試性選取了廣告業務作為上雲試點，並且取得了較大收益，系統的吞吐量直線上升，依賴穩定性顯著提升，計算成本也大幅下降。但是這一模式的適用範圍較窄，無法直接複製到其他業務場景，而且這一模式只適用於單一資料中心的情況，於是就進入了成長期。

成長期的背景是需要解決IDC到公有云的資料通道構建問題。針對這一問題，鬥魚和阿里雲共同構建了RedisShake資料同步工具，支援了Redis全量、增量資料同步、支援雲上、雲下不同資料中心的同步，還支援秒級資料監控。透過RedisFullCheck實現了資料多維度對比，基本能保證資料通路的資料一致性問題。這一階段的收益在於實現了單一機房到多機房的資料擴充套件過程。這個階段存在存在兩點有待改進，即資源排程成本比較高和資源缺乏精細化運營。

成熟期的主要最佳化方向是職責分離和彈性伸縮，最佳化方案包括四個方面，即流量分級、資料冷熱分離、彈性伸縮和流量排程。其中排程策略包括了手動排程、定時排程、資源消耗排程和Hook排程。

對於混合雲架構而言，鬥魚也總結了三點經驗：

 充分合理評估：雲上計算網路與IDC差異較大，需要結合業務實際情況進行測試，避免產生影響。  投入產出比：混合雲架構對資源冗餘存在一定要求或者帶來一定負面影響。  延時問題：企業應透過評估業務的重要性決定是否做混合雲，雖然從資料中心到雲有專線，但也存在一定延時。

Cassandra&X-Pack Spark雲資料庫技術剖析

阿里雲智慧高階技術專家曹龍(封神)為大家剖析了Cassandra與X-Pack Spark雲資料庫技術。

為什麼選擇Cassandra呢？Cassandra是一種完全沒有中心的資料庫，其每個節點都是主節點，如果Kill掉其中任何一個節點都不會影響叢集的QPS以及延時。除了Cassandra使用的P2P-QUORUM機制之外，還有HA機制、Raft以及單記憶體副本+共享儲存等機制，而只有Cassandra能夠做到幾乎沒有感知時間，因此Cassandra的Slogan就是“Always Online”。

Cassandra能夠實現平滑擴充套件，一方面可以增加節點資料量，甚至擴充套件多個DC。另一方面在雲上還可以增加記憶體等。平滑擴充套件是Cassandra的重要特性，其他資料庫往往難以做到。Cassandra還可以實現全球多DC，架構師可以根據業務自由適配。

對於學習成本而言，Cassandra提供類似於SQL語句的CQL，會MySQL的DBA或者開發人員基本上一天之內就能學會Cassandra。在安全方面，Cassandra和主流資料庫一樣提供了完善的認證以及鑑權體系。在多語言方面，Cassandra採用了非Thrift方式，採用客戶端和服務端直連方式，並且支援主流的語言，並且具有良好的效能。最後一點，就是運維簡單，Cassandra整體只有一個程式，沒有Proxy、HA以ZK等角色節點。

Cassandra具有很多功能，比較特別的就是其索引支援物化檢視、還支援SASI全文索引，並且整合了Lucene做更強的全文索引，以及支援CDC對接流式系統。

Cassandra的功能和生態比較豐富，其可以和其他元件進行搭配，比如Spark、Kafka、ES、Lucene、RocksDB等。

Cassandra在寬表領域排名全球第一，即使在國內缺乏宣傳的情況下排名也是靠前的。Cassandra的發展目前已經經過了十年，其將AWS的DynamoDB和Google的BigTable兩者的長處融合在一起形成的。阿里巴巴也在2019年公測併發布了阿里雲Cassandra資料庫服務，並且對原生的Cassandra進行了多方面提升，比如實現了自動化運維、相容DynamoDB、全鏈路最佳化效能提升100%等。

總結而言，雲資料庫Cassandra版是線上可靠的NoSQL可調一致性的分散式資料庫服務，支援類SQL語法CQL，提供強大的分散式索引能力，提供安全、多活容災、監控、備份恢復等企業級能力，相容DynamoDB協議。

X-Pack Spark不僅僅支援Cassandra，還能夠支援HBase、Phoenix、RDS和MongoDB。X-Pack Spark不僅具有強大的連線能力和歸檔能力，還能夠透過ElasticNode降低計算和儲存成本。

Cassandra+Spark能夠應用於非常廣泛的業務場景中，比如使用者畫像、Feed、小物件儲存以及推薦平臺等。

總結而言，將Spark與Cassandra的優點結合在一起能夠滿足多種業務場景的需求，能夠實現Always Online、擴充套件性強、好用、功能和生態豐富以及Spark資料閉環。

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。

雲棲乾貨回顧 | 行業頂級NoSQL成員坐陣，NoSQL資料庫專場重點解析！

Redis & MongoDB雲資料庫技術剖析

MongoDB企業級資料庫服務

基於MongoDB的資料中臺技術實現

圖資料庫GDB的設計與實踐

什麼是圖資料庫

什麼是圖資料庫GDB

GDB的場景和案例

從Java走向雲原生，Redisson不停地探索

基於企業級HBase的大資料儲存與處理

鬥魚直播從0到1混合雲架構演進

Cassandra&X-Pack Spark雲資料庫技術剖析

相關文章