行業頂級NoSQL成員坐陣，NoSQL數據庫專場重點解析！

時間 2019-12-30

原文原文鏈接

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

Redis & MongoDB雲數據庫技術剖析

阿里雲智能事業羣數據庫產品事業部技術總監，MongoDB中國用戶組杭州用戶會主席楊成虎(葉翔)爲你們深度剖析了Redis和MongoDB雲數據庫的技術。redis

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數據閉環。