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

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

問題：

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

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

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

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

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

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

而在第二種情況下會(huì)是這樣：

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

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

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

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

答案：

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

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

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

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

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

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

第二個(gè)選項(xiàng)是“寬”：使用不同的限定符（其中限定符是valueid）將一堆值存儲(chǔ)在一行中。簡(jiǎn)單的做法是將一個(gè)用戶的所有值存儲(chǔ)在一行中。我猜你跳到了“分頁”版本，因?yàn)槟阏J(rèn)為在單行中存儲(chǔ)數(shù)百萬列會(huì)對(duì)性能造成影響，這可能是也可能不是真的; 只要你不想在單個(gè)請(qǐng)求中做太多事情，或者做一些事情，比如掃描并返回行中的所有單元格，它不應(yīng)該從根本上變壞。客戶端具有允許您獲取特定的列的片段的方法。

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

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