2019年以來，Lindorm已經服務了包括淘寶、天貓、螞蟻、菜鳥、媽媽、優酷、高德、大文娛等數十個BU，在今年的雙十一中，Lindorm峯值請求達到了7.5億次每秒，天吞吐22.9萬億次，平均響應時間低於3ms，整體存儲的數據量達到了數百PB。
這些數字的背後，凝聚了HBase&Lindorm團隊多年以來的汗水和心血。Lindorm脫胎於HBase，是團隊多年以來承載數百PB數據，億級請求量，上千個業務後，在面對規模成本壓力，以及HBase自身缺陷下，全面重構和引擎升級的全新產品。相比HBase，Lindorm無論是性能，功能還是可用性上，都有了巨大飛躍。本文將從功能、可用性、性能成本、服務生態等維度介紹Lindorm的核心能力與業務表現，最後分享部分我們正在進行中的一些項目。
極致優化，超強性能
Lindorm比HBase在RPC、內存管理，緩存、日誌寫入等方面做了深度的優化，引入了衆多新技術，大幅提升了讀寫性能，在相同硬件的情況下，吞吐可達到HBase的5倍以上，毛刺更是可以達到HBase的1/10。這些性能數據，並不是在實驗室條件下產生的，而是在不改動任何參數的前提下，使用開源測試工具YCSB跑出來的成績。我們把測試的工具和場景都公佈在阿里雲的幫助文件中，任何人都可以依照指南自己跑出一樣的結果。
取得這麼優異的性能的背後，是Lindorm中積攢多年的“黑科技”，下面，我們簡單介紹下Lindorm內核中使用到的部分“黑科技”。
Trie Index
Lindorm 的文件LDFile（類似HBase中的HFile）是隻讀 B+ 樹結構，其中文件索引是至關重要的數據結構。在 block cache 中有高優先級，需要儘量常駐內存。如果能降低文件索引所佔空間大小，我們可以節省 block cache 中索引所需要的寶貴內存空間。或者在索引空間不變的情況下，增加索引密度，降低 data block 的大小，從而提高性能。而HBase中的索引block中存的是全量的Rowkey，而在一個已經排序好的文件中，很多Rowkey都是有共同前綴的。
數據結構中的Trie (前綴樹) 結構能夠讓共同前綴只存一份，避免重複存儲帶來的浪費。但是傳統前綴樹結構中，從一個節點到下一個節點的指針佔用空間太多，整體而言得不償失。這一情況有望用 Succinct Prefix Tree 來解決。SIGMOD2018年的最佳論文 Surf 中提出了一種用 Succinct Prefix Tree 來取代 bloom filter，並同時提供 range filtering 的功能。我們從這篇文章得到啓發，用 Succinct Trie 來做 file block index。
我們在線上的多個業務中使用了Trie index實現的索引結構。結果發現，各個場景中，Trie index可以大大縮小索引的體積，最多可以壓縮12倍的索引空間！節省的這些寶貴空間讓內存Cache中能夠存放更多的索引和數據文件，大大提高了請求的性能。
ZGC加持，百GB堆平均5ms暫停
ZGC(Powerd by Dragonwell JDK)是下一代Pauseless GC算法的代表之一，其核心思想是Mutator利用內存讀屏障(Read Barrier)識別指針變化，使得大部分的標記(Mark)與合併(Relocate)工作可以放在併發階段執行。
這樣一項實驗性技術，在Lindorm團隊與AJDK團隊的緊密合作下，進行了大量的改進與改造工作。使得ZGC在Lindorm這個場景上實現了生產級可用，主要工作包括：
- Lindorm內存自管理技術，數量級減少對象數與內存分配速率。(比如說阿里HBase團隊貢獻給社區的CCSMap)。
- AJDK ZGC Page緩存機制優化(鎖、Page緩存策略)。
- AJDK ZGC 觸發時機優化，ZGC無併發失敗。AJDK ZGC在Lindorm上穩定運行兩個月，並順利通過雙十一大考。其JVM暫停時間穩定在5ms左右，最大暫停時間不超過8ms。ZGC大大改善了線上運行集羣的RT與毛刺指標，平均RT優化15%～20%，P999 RT減少一倍。在今年雙十一螞蟻風控集羣中，在ZGC的加持下，P999時間從12ms降低到了5ms。
LindormBlockingQueue
上圖是HBase中的RegionServer從網絡上讀取RPC請求並分發到各個Handler上執行的流程。HBase中的RPC Reader從Socket上讀取RPC請求放入BlockingQueue，Handler訂閱這個Queue並執行請求。而這個BlockingQueue，HBase使用的是Java原生的JDK自帶的LinkedBlockingQueue。
LinkedBlockingQueue利用Lock與Condition保證線程安全與線程之間的同步，雖然經典易懂，但當吞吐增大時，這個queue會造成嚴重的性能瓶頸。因此在Lindorm中全新設計了LindormBlockingQueue，將元素維護在Slot數組中。維護head與tail指針，通過CAS操作對進隊列進行讀寫操作，消除了臨界區。並使用Cache Line Padding與髒讀緩存加速，同時可定製多種等待策略(Spin/Yield/Block)，避免隊列爲空或爲滿時，頻繁進入Park狀態。LindormBlockingQueue的性能非常突出，相比於原先的LinkedBlockingQueue性能提升4倍以上。
VersionBasedSynchronizer
LDLog是Lindorm中用於系統failover時進行數據恢復時的日誌，以保障數據的原子性和可靠性。在每次數據寫入時，都必須先寫入LDLog。LDLog寫入成功之後，纔可以進行後續的寫入memstore等操作。因此Lindorm中的Handler都必須等待WAL寫入完成後再被喚醒以進行下一步操作，在高壓條件下，無用喚醒會造成大量的CPU Context Switch造成性能下降。針對這個問題，Lindorm研發了基於版本的高併發多路線程同步機制(VersionBasedSynchronizer)來大幅優化上下文切換。
VersionBasedSynchronizer的主要思路是讓Handler的等待條件被Notifier感知，減少Notifier的喚醒壓力。經過模塊測試VersionBasedSynchronizer的效率是JDK自帶的ObjectMonitor和J.U.C(java util concurrent包)的兩倍以上。
全面無鎖化
HBase內核在關鍵路徑上有大量的鎖，在高併發場景下，這些鎖都會造成線程爭搶和性能下降。Lindorm內核對關鍵鏈路上的鎖都做了無鎖化處理，如MVCC，WAL模塊中的鎖。另外，HBase在運行過程中會產生的各種指標，如qps，rt，cache命中率等等。而在記錄這些Metrics的“不起眼”操作中，也會有大量的鎖。面對這樣的問題，Lindorm借鑑了tcmalloc的思想，開發了LindormThreadCacheCounter，來解決Metrics的性能問題。
Handler協程化
在高併發應用中，一個RPC請求的實現往往包含多個子模塊，涉及到若干次IO。這些子模塊的相互協作，系統的ContextSwitch相當頻繁。ContextSwitch的優化是高併發系統繞不開的話題，各位高手都各顯神通，業界有非常多的思想與實踐。其中coroutine(協程)和SEDA(分階段事件驅動)方案是我們着重考察的方案。基於工程代價，可維護性，代碼可讀性三個角度考慮，Lindorm選擇了協程的方式進行異步化優化。我們利用了阿里JVM團隊提供的Dragonwell JDK內置的Wisp2.0功能實現了HBase Handler的協程化，Wisp2.0開箱即用，有效地減少了系統的資源消耗，優化效果比較客觀。
全新Encoding算法
從性能角度考慮，HBase通常需要將Meta信息裝載進block cache。如果將block大小較小，Meta信息較多，會出現Meta無法完全裝入Cache的情況, 性能下降。如果block大小較大，經過Encoding的block的順序查詢的性能會成爲隨機讀的性能瓶頸。針對這一情況，Lindorm全新開發了Indexable Delta Encoding，在block內部也可以通過索引進行快速查詢，seek性能有了較大提高。Indexable Delta Encoding原理如圖所示：
通過Indexable Delta Encoding， HFile的隨機seek性能相對於使用之前翻了一倍，以64K block爲例，隨機seek性能基本與不做encoding相近（其他encoding算法會有一定性能損失）。在全cache命中的隨機Get場景下，相對於Diff encoding RT下降50%
其他
相比社區版HBase，Lindorm還有多達幾十項的性能優化和重構，引入了衆多新技術，由於篇幅有限，這裏只能列舉一部分，其他的核心技術，比如：
- CCSMap
- 自動規避故障節點的併發三副本日誌協議 (Quorum-based write)
- 高效的批量組提交(Group Commit)
- 無碎片的高性能緩存—Shared BucketCache
- Memstore Bloomfilter
- 面向讀寫的高效數據結構
- GC-Invisible內存管理
- 在線計算與離線作業架構分離
- JDK/操作系統深度優化
- FPGA offloading Compaction
- 用戶態TCP加速
- ……
豐富的查詢模型，降低開發門檻
原生的HBase只支持KV結構的查詢，雖然簡單，但是在面對各項業務的複雜需求時，顯的有點力不從心。因此，在Lindorm中，我們針對不同業務的特點，研發了多種查詢模型，通過更靠近場景的API和索引設計，降低開發門檻。
WideColumn 模型（原生HBase API）
WideColumn是一種與HBase完全一致的訪問模型和數據結構，從而使得Lindrom能100%兼容HBase的API。用戶可以通過Lindorm提供的高性能原生客戶端中的WideColumn API訪問Lindorm，也可以通過alihbase-connector這個插件，使用HBase客戶端及API(無需任何代碼改造)直接訪問Lindorm。同時，Lindorm使用了輕客戶端的設計，將大量數據路由、批量分發、超時、重試等邏輯下沉到服務端，並在網絡傳輸層做了大量的優化，使得應用端的CPU消耗可以大大節省。像下表中，相比於HBase，使用Lindorm後的應用側CPU使用效率提升60%，網絡帶寬效率提升25%。
在HBase原生API上，我們還獨家支持了高性能二級索引，用戶可以使用HBase原生API寫入數據過程中，索引數據透明地寫入索引表。在查詢過程中，把可能全表掃的Scan + Filter大查詢，變成可以先去查詢索引表，大大提高了查詢性能。關於高性能原生二級索引，大家可以參考：
https://help.aliyun.com/document_detail/144577.html
TableService模型(SQL、二級索引)
HBase中只支持Rowkey這一種索引方式，對於多字段查詢時，通常效率低下。爲此，用戶需要維護多個表來滿足不同場景的查詢需求，這在一定程度上既增加了應用的開發複雜性，也不能很完美地保證數據一致性和寫入效率。並且HBase中只提供了KV API，只能做Put、Get、Scan等簡單API操作，也沒有數據類型，所有的數據都必須用戶自己轉換和儲存。對於習慣了SQL語言的開發者來說，入門的門檻非常高，而且容易出錯。
爲了解決這一痛點，降低用戶使用門檻，提高開發效率，在Lindorm中我們增加了TableService模型，其提供豐富的數據類型、結構化查詢表達API，並原生支持SQL訪問和全局二級索引，解決了衆多的技術挑戰，大幅降低普通用戶的開發門檻。通過SQL和SQL like的API，用戶可以方便地像使用關係數據庫那樣使用Lindorm。下面是一個Lindorm SQL的簡單示例。
-- 主表和索引DDL
create table shop_item_relation (
shop_id varchar,
item_id varchar,
status varchar
constraint primary key(shop_id, item_id)) ;
create index idx1 on shop_item_relation (item_id) include (ALL); -- 對第二列主鍵建索引，冗餘所有列
create index idx2 on shop_item_relation (shop_id, status) include (ALL); -- 多列索引，冗餘所有列
-- 寫入數據，會同步更新2個索引
upsert into shop_item_relation values('shop1', 'item1', 'active');
upsert into shop_item_relation values('shop1', 'item2', 'invalid');
-- 根據WHERE子句自動選擇合適的索引執行查詢
select * from shop_item_relation where item_id = 'item2'; -- 命中idx1
select * from shop_item_relation where shop_id = 'shop1' and status = 'invalid'; -- 命中idx2
相比於關係數據庫的SQL，Lindorm不具備多行事務和複雜分析(如Join、Groupby)的能力，這也是兩者之間的定位差異。
相比於HBase上Phoenix組件提供的二級索引，Lindorm的二級索引在功能、性能、穩定性上遠遠超過Phoenix，下圖是一個簡單的性能對比。
FeedStream模型
現代互聯網架構中，消息隊列承擔了非常重要的職責，可以極大的提升核心系統的性能和穩定性。其典型的應用場景有包括系統解耦，削峯限流，日誌採集，最終一致保證，分發推送等等。
常見的消息隊列包括RabbitMq，Kafka以及RocketMq等等。這些數據庫儘管從架構和使用方式和性能上略有不同，但其基本使用場景都相對接近。然而，傳統的消息隊列並非完美，其在消息推送，feed流等場景存在以下問題：
- 存儲：不適合長期保存數據，通常過期時間都在天級
- 刪除能力：不支持刪除指定數據entry
- 查詢能力：不支持較爲複雜的查詢和過濾條件
- 一致性和性能難以同時保證：類似於Kafka之類的數據庫更重吞吐，爲了提高性能存在了某些狀況下丟數據的可能，而事務處理能力較好的消息隊列吞吐又較爲受限。
- Partition快速拓展能力：通常一個Topc下的partition數目都是固定，不支持快速擴展。
- 物理隊列/邏輯隊列：通常只支持少量物理隊列(如每個partition可以看成一個隊列)，而業務需要的在物理隊列的基礎上模擬出邏輯隊列，如IM系統中爲每個用戶維護一個邏輯上的消息隊列，用戶往往需要很多額外的開發工作。
針對上述需求，Lindorm推出了隊列模型FeedStreamService，能夠解決海量用戶下的消息同步，設備通知，自增ID分配等問題。
FeedStream模型在今年手機淘寶消息系統中扮演了重要角色，解決了手機淘寶消息推送保序，冪等等難題。在今年雙十一中，手淘的蓋樓和回血大紅包推送都有Lindorm的身影。手淘消息的推送中，峯值超過了100w/s，做到了分鐘級推送全網用戶。
全文索引模型
雖然Lindorm中的TableService模型提供了數據類型和二級索引。但是，在面對各種複雜條件查詢和全文索引的需求下，還是顯得力不從心，而Solr和ES是優秀的全文搜索引擎。使用Lindorm+Solr/ES，可以最大限度發揮Lindorm和Solr/ES各自的優點，從而使得我們可以構建複雜的大數據存儲和檢索服務。Lindorm內置了外部索引同步組件，能夠自動地將寫入Lindorm的數據同步到外部索引組件如Solr或者ES中。這種模型非常適合需要保存大量數據，而查詢條件的字段數據僅佔原數據的一小部分，並且需要各種條件組合查詢的業務，例如：
- 常見物流業務場景，需要存儲大量軌跡物流信息，並需根據多個字段任意組合查詢條件
- 交通監控業務場景，保存大量過車記錄，同時會根據車輛信息任意條件組合檢索出感興趣的記錄
- 各種網站會員、商品信息檢索場景，一般保存大量的商品/會員信息，並需要根據少量條件進行復雜且任意的查詢，以滿足網站用戶任意搜索需求等。
全文索引模型已經在阿里雲上線，支持Solr/ES外部索引。目前，索引的查詢用戶還需要直接查詢Solr/ES再來反查Lindorm，後續我們會用TableService的語法把查詢外部索引的過程包裝起來，用戶全程只需要和Lindorm交互，即可獲得全文索引的能力。
更多模型在路上
除了上述這些模型，我們還會根據業務的需求和痛點，開發更多簡單易用的模型，方便用戶使用，降低使用門檻。像時序模型，圖模型等，都已經在路上，敬請期待。
零干預、秒恢復的高可用能力
從一個嬰兒成長爲青年，阿里HBase摔過很多次，甚至頭破血流，我們在客戶的信任之下幸運的成長。在9年的阿里應用過程中，我們積累了大量的高可用技術，而這些技術，都應用到了HBase增強版中。
MTTR優化
HBase是參照Gooogle著名論文BigTable的開源實現，其中最核心特點是數據持久化存儲於底層的分佈式文件系統HDFS，通過HDFS對數據的多副本維護來保障整個系統的高可靠性，而HBase自身不需要去關心數據的多副本及其一致性，這有助於整體工程的簡化，但也引入了"服務單點"的缺陷，即對於確定的數據的讀寫服務只有發生固定的某個節點服務器，這意味着當一個節點宕機後，數據需要通過重放Log恢復內存狀態，並且重新派發給新的節點加載後，才能恢復服務。
當集羣規模較大時，HBase單點故障後恢復時間可能會達到10-20分鐘，大規模集羣宕機的恢復時間可能需要好幾個小時！而在Lindorm內核中，我們對MTTR（平均故障恢復時間）做了一系列的優化，包括故障恢復時先上線region、並行replay、減少小文件產生等衆多技術。將故障恢復速度提升10倍以上！基本上接近了HBase設計的理論值。
可調的多一致性
在原來的HBase架構中，每個region只能在一個RegionServer中上線，如果這個region server宕機，region需要經歷Re-assgin，WAL按region切分，WAL數據回放等步驟後，才能恢復讀寫。這個恢復時間可能需要數分鐘，對於某些高要求的業務來說，這是一個無法解決的痛點。另外，雖然HBase中有主備同步，但故障下只能集羣粒度的手動切換，並且主和備的數據只能做到最終一致性，而有一些業務只能接受強一致，HBase在這點上望塵莫及。
Lindorm內部實現了一種基於Shared Log的一致性協議，通過分區多副本機制達到故障下的服務自動快速恢復的能力，完美適配了存儲分離的架構, 利用同一套體系即可支持強一致語義，又可以選擇在犧牲一致性的前提換取更佳的性能和可用性，實現多活，高可用等多種能力。
在這套架構下，Lindorm擁有了以下幾個一致性級別，用戶可以根據自己的業務自由選擇一致性級別：
客戶端高可用切換
雖然說目前HBase可以組成主備，但是目前市面上沒有一個高效地客戶端切換訪問方案。HBase的客戶端只能訪問固定地址的HBase集羣。如果主集羣發生故障，用戶需要停止HBase客戶端，修改HBase的配置後重啓，才能連接備集羣訪問。或者用戶在業務側必須設計一套複雜地訪問邏輯來實現主備集羣的訪問。阿里HBase改造了HBase客戶端，流量的切換髮生在客戶端內部，通過高可用的通道將切換命令發送給客戶端，客戶端會關閉舊的鏈接，打開與備集羣的鏈接，然後重試請求。
如果需要使用此項功能，請參考高可用幫助文檔：https://help.aliyun.com/document_detail/140940.html
雲原生，更低使用成本
Lindorm從立項之初就考慮到上雲，各種設計也能儘量複用雲上基礎設施，爲雲的環境專門優化。比如在雲上，我們除了支持雲盤之外，我們還支持將數據存儲在OSS這種低成本的對象存儲中減少成本。我們還針對ECS部署做了不少優化，適配小內存規格機型，加強部署彈性，一切爲了雲原生，爲了節省客戶成本。
ECS+雲盤的極致彈性
目前Lindorm在雲上的版本HBase增強版均採用ECS+雲盤部署（部分大客戶可能採用本地盤），ECS+雲盤部署的形態給Lindorm帶來了極致的彈性。
最開始的時候，HBase在集團的部署均採用物理機的形式。每個業務上線前，都必須先規劃好機器數量和磁盤大小。在物理機部署下，往往會遇到幾個難以解決的問題：
- 業務彈性難以滿足：當遇到業務突發流量高峯或者異常請求時，很難在短時間內找到新的物理機擴容。
- 存儲和計算綁定，靈活性差：物理機上CPU和磁盤的比例都是一定的，但是每個業務的特點都不一樣，採用一樣的物理機，有一些業務計算資源不夠，但存儲過剩，而有些業務計算資源過剩，而存儲瓶頸。特別是在HBase引入混合存儲後，HDD和SSD的比例非常難確定，有些高要求的業務常常會把SSD用滿而HDD有剩餘，而一些海量的離線型業務SSD盤又無法利用上。
- 運維壓力大：使用物理機時，運維需要時刻注意物理機是否過保，是否有磁盤壞，網卡壞等硬件故障需要處理，物理機的報修是一個漫長的過程，同時需要停機，運維壓力巨大。對於HBase這種海量存儲業務來說，每天壞幾塊磁盤是非常正常的事情。而當Lindorm採用了ECS+雲盤部署後，這些問題都迎刃而解。
ECS提供了一個近似無限的資源池。當面對業務的緊急擴容時，我們只需在資源池中申請新的ECS拉起後，即可加入集羣，時間在分鐘級別之內，無懼業務流量高峯。配合雲盤這樣的存儲計算分離架構。我們可以靈活地爲各種業務分配不同的磁盤空間。當空間不夠時，可以直接在線擴縮容磁盤。同時，運維再也不用考慮硬件故障，當ECS有故障時，ECS可以在另外一臺宿主機上拉起，而云盤完全對上層屏蔽了壞盤的處理。極致的彈性同樣帶來了成本的優化。我們不需要爲業務預留太多的資源，同時當業務的大促結束後，能夠快速地縮容降低成本。
一體化冷熱分離
在海量大數據場景下，一張表中的部分業務數據隨着時間的推移僅作爲歸檔數據或者訪問頻率很低，同時這部分歷史數據體量非常大，比如訂單數據或者監控數據，降低這部分數據的存儲成本將會極大的節省企業的成本。如何以極簡的運維配置成本就能爲企業極大降低存儲成本，Lindorm冷熱分離功能應運而生。Lindorm爲冷數據提供新的存儲介質，新的存儲介質存儲成本僅爲高效雲盤的1/3。
Lindorm在同一張表裏實現了數據的冷熱分離，系統會自動根據用戶設置的冷熱分界線自動將表中的冷數據歸檔到冷存儲中。在用戶的訪問方式上和普通表幾乎沒有任何差異，在查詢的過程中，用戶只需配置查詢Hint或者TimeRange，系統根據條件自動地判斷查詢應該落在熱數據區還是冷數據區。對用戶而言始終是一張表，對用戶幾乎做到完全的透明。詳細介紹請參考：
https://yq.aliyun.com/articles/718395
ZSTD-V2，壓縮比再提升100%
早在兩年前，我們就把集團內的存儲壓縮算法替換成了ZSTD，相比原來的SNAPPY算法，獲得了額外25%的壓縮收益。今年我們對此進一步優化，開發實現了新的ZSTD-v2算法，其對於小塊數據的壓縮，提出了使用預先採樣數據進行訓練字典，然後用字典進行加速的方法。我們利用了這一新的功能，在Lindorm構建LDFile的時候，先對數據進行採樣訓練，構建字典，然後在進行壓縮。在不同業務的數據測試中，我們最高獲得了超過原生ZSTD算法100%的壓縮比，這意味着我們可以爲客戶再節省50%的存儲費用。
HBase Serverless版，入門首選
阿里雲HBase Serverless 版是基於Lindorm內核，使用Serverless架構構建的一套新型的HBase 服務。阿里雲HBase Serverless版真正把HBase變成了一個服務，用戶無需提前規劃資源，選擇CPU，內存資源數量，購買集羣。在應對業務高峯，業務空間增長時，也無需進行擴容等複雜運維操作，在業務低谷時，也無需浪費閒置資源。
在使用過程中，用戶可以完全根據當前業務量，按需購買請求量和空間資源即可。使用阿里雲HBase Serverless版本，用戶就好像在使用一個無限資源的HBase集羣，隨時滿足業務流量突然的變化，而同時只需要支付自己真正使用的那一部分資源的錢。
關於HBase Serverless的介紹和使用，可以參考：https://developer.aliyun.com/article/719206
面向大客戶的安全和多租戶能力
Lindorm引擎內置了完整的用戶名密碼體系，提供多種級別的權限控制，並對每一次請求鑑權，防止未授權的數據訪問，確保用戶數據的訪問安全。同時，針對企業級大客戶的訴求，Lindorm內置了Group，Quota限制等多租戶隔離功能，保證企業中各個業務在使用同一個HBase集羣時不會被相互影響，安全高效地共享同一個大數據平臺。
用戶和ACL體系
Lindorm內核提供一套簡單易用的用戶認證和ACL體系。用戶的認證只需要在配置中簡單的填寫用戶名密碼即可。用戶的密碼在服務器端非明文存儲，並且在認證過程中不會明文傳輸密碼，即使驗證過程的密文被攔截，用以認證的通信內容不可重複使用，無法被僞造。
Lindorm中有三個權限層級。Global，Namespace和Table。這三者是相互覆蓋的關係。比如給user1賦予了Global的讀寫權限，則他就擁有了所有namespace下所有Table的讀寫權限。如果給user2賦予了Namespace1的讀寫權限，那麼他會自動擁有Namespace1中所有表的讀寫權限。
Group隔離
當多個用戶或者業務在使用同一個HBase集羣時，往往會存在資源爭搶的問題。一些重要的在線業務的讀寫，可能會被離線業務批量讀寫所影響。而Group功能，則是HBase增強版（Lindorm）提供的用來解決多租戶隔離問題的功能。
通過把RegionServer劃分到不同的Group分組，每個分組上host不同的表，從而達到資源隔離的目的。
例如，在上圖中，我們創建了一個Group1，把RegionServer1和RegionServer2劃分到Group1中，創建了一個Group2，把RegionServer3和RegionServer4劃分到Group2。同時，我們把Table1和Table2也移動到Group1分組。這樣的話，Table1和Table2的所有region，都只會分配到Group1中的RegionServer1和RegionServer2這兩臺機器上。
同樣，屬於Group2的Table3和Table4的Region在分配和balance過程中，也只會落在RegionServer3和RegionServer4上。因此，用戶在請求這些表時，發往Table1、Table2的請求，只會由RegionServer1和RegionServer2服務，而發往Table3和Table4的請求，只會由RegionServer3和RegionServer4服務，從而達到資源隔離的目的。
Quota限流
Lindorm內核中內置了一套完整的Quota體系，來對各個用戶的資源使用做限制。對於每一個請求，Lindorm內核都有精確的計算所消耗的CU（Capacity Unit），CU會以實際消耗的資源來計算。比如用戶一個Scan請求，由於filter的存在，雖然返回的數據很少，但可能已經在RegionServer已經消耗大量的CPU和IO資源來過濾數據，這些真實資源的消耗，都會計算在CU裏。在把Lindorm當做一個大數據平臺使用時，企業管理員可以先給不同業務分配不同的用戶，然後通過Quota系統限制某個用戶每秒的讀CU不能超過多少，或者總的CU不能超過多少，從而限制用戶佔用過多的資源，影響其他用戶。同時，Quota限流也支持Namesapce級別和表級別限制。
最後
全新一代NoSQL數據庫Lindorm是阿里巴巴HBase&Lindorm團隊9年以來技術積累的結晶，Lindorm在面向海量數據場景提供世界領先的高性能、可跨域、多一致、多模型的混合存儲處理能力。對焦於同時解決大數據(無限擴展、高吞吐)、在線服務(低延時、高可用)、多功能查詢的訴求，爲用戶提供無縫擴展、高吞吐、持續可用、毫秒級穩定響應、強弱一致可調、低存儲成本、豐富索引的數據實時混合存取能力。
本文轉載自公衆號阿里技術（ID：ali_tech）。
原文鏈接：