存儲查詢日誌中的HBase模式設計

最近，我正在制定一個解決方案，將用戶的search log/query log存儲到HBase表中。存儲查詢日誌中的HBase模式設計

讓我們簡單的原始查詢日誌：

query timestamp req_cookie req_ip ...

數據訪問模式：

掃描通過時間範圍內的所有querys。
掃描通過與指定的查詢

所有的搜索歷史記錄我想出了以下行按鍵設計：

<query>_<timestamp>

但查詢可能很長或在不同的編碼，把query直接進入rowkey似乎不明智。

我正在尋找優化此架構的幫助，任何人在處理此方案之前？

來源

2014-01-22 hahakubile

1-您可以使用時間範圍進行全表掃描。如果您需要實時響應，您必須保留一個反向行鍵表<timestamp>_<query>（首先仔細計劃您的區域分割策略）。

但是要注意，連續的行鍵的前綴會得到一些你地區的非常熱的，如果你有很多的同意，所以這將是明智緩衝寫入該表。此外，如果您獲得的寫入量超過單個區域可處理的數量，您將實施某種分片前綴（即時間戳模），但這會使您的檢索更爲複雜（必須合併多次掃描的結果爲）。

2-哈希的方式查詢字符串，你總是有一個固定長度的行鍵，而無需關心編碼（MD5也許？）

來源

2014-01-22 10:22:01

感謝，也許MD5（查詢）是一個好辦法。 – hahakubile

它會很好地工作，你會得到25byte的rowkeys，這不是很小，但它不是太糟糕。只有在極端情況下，當你需要更小的rowkeys時，你可以從hash中提取4-8個第一個字符，但是你會從多個不同的查詢中得到相同的hash，如果你存儲在其中一列中添加原始查詢，以便添加SingleColumnValue過濾器以放棄不需要的查詢（8字節哈希應該足以獲得最少量的衝突）。 –

存儲查詢日誌中的HBase模式設計

回答

相關問題