資料庫新兵:分散式實時分析記憶體資料庫eSight
近幾年,中國資料庫的發展迎來了一波小高潮,不僅傳統資料庫廠商在投入力量,以技術為驅動的網際網路企業也在積極投入。在第七屆TOP100全球軟體案例研究峰會上,筆者發現了一個新面孔——來自餓了麼的分散式實時分析記憶體資料庫eSight。
陳永庭 ,餓了麼高階架構師。10+年軟體研發經驗,曾先後就職於WebEx、Cisco、騰訊公司,現就職於餓了麼,先後負責餓了麼多活架構方案設計、DRC中介軟體研發、eSight分散式資料庫研發、IDC容量評估和服務容量彈性伸縮工作。在高吞吐、高可靠性服務架構、海量資料儲存等方面具備豐富的經驗。
專案背景
一般來說,一個新產品的誕生必定伴隨著業務或技術的瓶頸,eSight的誕生也不例外。以一個很小的場景為例,假設一個外賣平臺在通常情況下日訂單是超過一千萬,但是某一天突然訂單數量下降了。那麼,老闆就一定會去問產品人員、運營人員或者是資料分析師,“為什麼會訂單下降了?”但是在這樣的資料級別下,員工很難快速實時的對資料做出診斷,並定位到出現問題的原因。
面對這樣的場景,餓了麼也很困惑。之前,餓了麼內部有一個專門的大資料部門負責這一場景,但是實時性遠遠達不到要求,很多資料需要T+1的時間或者幾個小時的延遲時間才能看到結果,往往會失去最佳的處理時間。
為了彌補當前大資料平臺不能滿足實時資料分析的場景,陳永庭及其團隊在2017年8月份開始調研新技術,調研過程中發現Facebook有三大典型的大資料儲存分析場景,分別為ODS、Scuba和Hive,其中Scuba paper很具有參考意義,eSight也正是站在Scuba paper的肩膀上誕生的。
據陳永庭介紹,eSight的研發團隊大概是三到四個人,從調研到Beta版本上線只花了5個月時間。
架構設計與功能特點
eSight的架構設計如上圖所示, 支援MySQL command和HTTP query,其中所有計算節點都聚合成aggregator tree平行計算,儲存節點可在單個伺服器或平行計算中同時啟動N個節點,且儲存節點也可以支援少量的計算,單機支援超過百萬的TPS。
eSight的關鍵設計和亮點功能主要集中在以下幾個方面:面向列的設計、極致的查詢響應、平行計算、向量化查詢處理、資料編碼與資料壓縮、cross IDC、資料持久化、資料恢復與資料副本以及SQL查詢。除此之外,eSight還弱化了以下功能,limited update、limited data availability和limited data replicas,完全摒棄了transaction、able join、delete和advanced standard SQL query功能。
效能測試
立項之初,餓了麼在國內並沒有找到非常匹配自己使用場景的、已公開的技術產品,但是產品上線之後,餓了麼發現了俄羅斯最大的搜尋公司釋出過一款類似產品——ClickHouse。
ClickHouse和eSight雖然功能類似,但是在架構設計和部署方式等方面有所不同,所以為了更詳細的對比兩款產品,餓了麼做了效能測試。其中,ClickHouse的效能資料來自官方公開的資料,所以測試結果只做參考。
與其它PB級產品不同,eSight和ClickHouse適用的場景不需要儲存這麼多的資料,但是效能要求很高,可能要是類似於Hive這樣產品的好幾個數量級。從上圖來看,我們可以發現eSight和ClickHouse的效能總體是在一個數量級上的,但是各自都有擅長的領域。
在首次查詢,eSight的效能明顯要更好,因為eSight是純記憶體的,而ClickHouse首次查詢會涉及到磁碟資料的讀寫;在某些特殊場景下,尤其是資料量級別特別小(百萬級別)的時候,ClickHouse因為做了極致的記憶體最佳化,效能表現極其突出,而eSight因為是分散式的設計,測試環境又是多機房,所以百萬級資料量和億級資料量,效能差距不大。
何時eSight的效能表現最為突出呢?陳永庭表示當資料容量在100G到500G的範圍內,資料量不低於10億條記錄時,整個eSight叢集的查詢效能和低延時都表現得很好,99%的查詢請求會在10秒之內返回結果。
未來計劃
任何產品都不是一蹴而就的,而是不斷經過演進的,陳永庭也透露了一些eSight未來的計劃。
目前,eSight服務於餓了麼整個機房,所以計算節點未來要適配於容器化部署,儲存節點也要考慮使用用分散式的儲存檔案系統來做整個儲存的載體。在效能方面也會做相應的最佳化,例如有些叢集比較小,可能只有10臺機器,如果使用者查詢的資料量非常大,那麼就極有可能導致節點負載很高,出現記憶體被打滿或者導致整個程式退出等情況。造成這種情況的原因有很多,一方面是查詢的資料量確實很大導致整個節點無法滿足查詢要求,針對此餓了麼會做了一些保護。另一方面,eSight的技術設計方面可能還不夠細膩,類似於物件在記憶體中的分配、物件的大小等等都還需要做一個非常極致的精簡化設計。
對於未來的發展推廣規劃,陳永庭也有自己的看法,首先eSight是一個分散式資料庫產品,資料庫產品最有價值的地方就是裡面存放的資料,其次就是作為工具產品的穩定性,各個技術指標要達到可靠性的預期。所以,接下來eSight團隊的重點會落在接入更多核心業務資料,並且在資料積累的基礎上,建立各種資料應用場景的玩法。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31545814/viewspace-2285405/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- (二) MdbCluster分散式記憶體資料庫——分散式架構1分散式記憶體資料庫架構
- 分析型資料庫:分散式分析型資料庫資料庫分散式
- 【記憶體資料庫】TimesTen記憶體資料庫
- 分析師解讀記憶體資料庫MemSQLSP記憶體資料庫SQL
- 分散式資料庫分散式資料庫
- 柏睿資料阿爾曼:全記憶體分散式資料庫RapidsDB助力產業“數實融合”記憶體分散式資料庫API產業
- (一) MdbCluster分散式記憶體資料庫——基礎架構介紹分散式記憶體資料庫架構
- PG資料庫記憶體告警了怎麼分析資料庫記憶體
- 資料庫實現原理#6(共享記憶體)資料庫記憶體
- 分散式資料庫Google Spanner原理分析KP分散式資料庫Go
- TDSQL交易型分散式資料庫背景分析SQL分散式資料庫
- 磁碟資料庫與記憶體資料庫的特點比較資料庫記憶體
- 分散式資料庫中介軟體 MyCat | 分庫分表實踐分散式資料庫
- 【大資料】BigTable分散式資料儲存系統分散式資料庫 | 複習筆記大資料分散式資料庫筆記
- 實時資料庫與時序資料庫資料庫
- 鴻蒙Next資料同步藝術:分散式記憶體資料庫高階效能最佳化策略鴻蒙分散式記憶體資料庫
- 記憶體資料庫如何發揮記憶體優勢?記憶體資料庫
- iOS開發筆記— 資料庫、Crash、記憶體問題分析iOS筆記資料庫記憶體
- openGauss 分散式資料庫能力分散式資料庫
- Oracle - 資料庫的記憶體結構Oracle資料庫記憶體
- Oracle - 資料庫的記憶體調整Oracle資料庫記憶體
- 瀚高資料庫記憶體結構資料庫記憶體
- 分散式資料庫火了 開源填補資料庫空白分散式資料庫
- MySQL資料庫分散式事務XA的實現原理分析MySql資料庫分散式
- 基於記憶體的關聯式資料庫memsql初探記憶體資料庫SQL
- 【大頁記憶體】Oracle資料庫配置大頁記憶體記憶體Oracle資料庫
- 分散式時序資料庫QTSDB的設計與實現分散式資料庫QT
- 原生分散式資料庫與子資料庫子表中介軟體的區別分散式資料庫
- 分散式資料庫中介軟體 MyCat 搞起來!分散式資料庫
- (三) MdbCluster分散式記憶體資料庫——節點狀態變化及分片調整分散式記憶體資料庫
- 《分散式資料庫HBase案例教程》分散式資料庫
- 資料庫運維 | 攜程分散式圖資料庫NebulaGraph運維治理實踐資料庫運維分散式
- 南大通用極速記憶體資料庫記憶體資料庫
- 資料庫分散式事務的實現原理!資料庫分散式
- 高速遷移MySQL資料到分散式時序資料庫DolphinDBMySql分散式資料庫
- 分散式資料庫入門:以國產資料庫 TDSQL 為例分散式資料庫SQL
- 分散式資料庫強勢崛起,達夢資料庫如何破局?分散式資料庫
- 達夢資料庫基礎知識(三)達夢資料庫記憶體結構資料庫記憶體