HBase模式案例研究：列表數(shù)據(jù)

HBase模式案例：列表數(shù)據(jù)

以下是用戶 dist-list 中關(guān)于一個相當常見問題的的交流：如何處理 Apache HBase 中的每個用戶列表數(shù)據(jù)。

問題：

我們正在研究如何在 HBase 中存儲大量（每用戶）列表數(shù)據(jù)，并且我們試圖弄清楚哪種訪問模式最有意義。一種選擇是將大部分數(shù)據(jù)存儲在一個密鑰中，所以我們可以有如下的內(nèi)容：

<FixedWidthUserName><FixedWidthValueId1>:"" (no value)
<FixedWidthUserName><FixedWidthValueId2>:"" (no value)
<FixedWidthUserName><FixedWidthValueId3>:"" (no value)

我們的另一個選擇是完全使用如下內(nèi)容：

<FixedWidthUserName><FixedWidthPageNum0>:<FixedWidthLength><FixedIdNextPageNum><ValueId1><ValueId2><ValueId3>...
<FixedWidthUserName><FixedWidthPageNum1>:<FixedWidthLength><FixedIdNextPageNum><ValueId1><ValueId2><ValueId3>...

每行將包含多個值。所以在一種情況下，讀取前三十個值將是：

scan { STARTROW => 'FixedWidthUsername' LIMIT => 30}

而在第二種情況下會是這樣：

get 'FixedWidthUserName\x00\x00\x00\x00'

一般的使用模式是只讀取這些列表的前30個值，并且很少的訪問會深入到列表中。一些用戶在這些列表中總共有30個值，并且一些用戶將擁有數(shù)百萬（即冪律分布）。

單值格式似乎會占用 HBase 上的更多空間，但會提供一些改進的檢索/分頁靈活性。是否有任何顯著的性能優(yōu)勢能夠通過獲取和掃描的頁面進行分頁？

我最初的理解是，如果我們的分頁大小未知（并且緩存設(shè)置恰當），那么執(zhí)行掃描應(yīng)該會更快，但如果我們始終需要相同的頁面大小，則掃描速度應(yīng)該更快。我聽到不同的人告訴了我關(guān)于表現(xiàn)的相反事情。我假設(shè)頁面大小會相對一致，所以對于大多數(shù)使用情況，我們可以保證我們只需要固定頁面長度的情況下的一頁數(shù)據(jù)。我還會假設(shè)我們將不經(jīng)常更新，但可能會插入這些列表的中間（這意味著我們需要更新所有后續(xù)行）。

答案：

如果我理解正確，你最終試圖以“user，valueid，value”的形式存儲三元組，對嗎？例如：

"user123, firstname, Paul",
"user234, lastname, Smith"

（但用戶名是固定寬度，而 valueids 是固定寬度）。

而且，您的訪問模式符合以下要求：“對于用戶 X，列出接下來的30個值，以valueid Y開頭”。是對的嗎？這些值應(yīng)該按 valueid 排序返回？

tl、dr 版本是，你可能應(yīng)該為每個用戶+值添加一行，除非你確定需要，否則不要自行構(gòu)建復(fù)雜的行內(nèi)分頁方案。

您的兩個選項反映了人們在設(shè)計 HBase 模式時常見的問題：我應(yīng)該選擇“高”還是“寬”？您的第一個模式是“高（tall）”：每行代表一個用戶的一個值，因此每個用戶的表中有很多行；行鍵是 user + valueid，并且會有（可能）單個列限定符，表示“值（value）”。如果您希望按行鍵來掃描排序順序中的行, 這是很好的。你可以在任何用戶 + valueid 開始掃描，閱讀下一個30，并完成。你放棄的是能夠在一個用戶的所有行周圍提供事務(wù)保證，但它聽起來并不像你需要的那樣。

第二個選項是“寬”：使用不同的限定符（其中限定符是valueid）將一堆值存儲在一行中。簡單的做法是將一個用戶的所有值存儲在一行中。我猜你跳到了“分頁”版本，因為你認為在單行中存儲數(shù)百萬列會對性能造成影響，這可能是也可能不是真的; 只要你不想在單個請求中做太多事情，或者做一些事情，比如掃描并返回行中的所有單元格，它不應(yīng)該從根本上變壞?？蛻舳司哂性试S您獲取特定的列的片段的方法。

請注意，這兩種情況都不會從根本上占用更多的磁盤空間; 您只是將部分識別信息“移動”到左側(cè)（在行鍵中，在選項一中）或向右（在選項2中的列限定符中）。在封面下，每個鍵/值仍然存儲整個行鍵和列名稱。

正如你注意到的那樣，手動分頁版本有很多復(fù)雜性，例如必須跟蹤每個頁面中有多少內(nèi)容，如果插入新值，則重新洗牌等。這看起來要復(fù)雜得多。在極高的吞吐量下它可能有一些輕微的速度優(yōu)勢（或缺點?。?，而要真正知道這一點的唯一方法就是試用它。如果您沒有時間來構(gòu)建它并進行比較，我的建議是從最簡單的選項開始（每個用戶 + valueid）。開始簡單并重復(fù)！