實現聲明的Cloud Bigtable寫入QPS

Question

我們已經設置了5個節點的Bigtable羣集，並且GCP控制檯聲明它應該支持5K QPS @ 6ms的讀取和寫入操作。

我們正在嘗試加載一個大型數據集（約800M記錄），其中包含大約50個包含大部分數字數據的字段以及一些簡短的字符串。密鑰是11位數字字符串。

當通過HBCE API從GCE中的單個客戶端虛擬機加載此數據集時，我們將每個字段放入單獨的列時可以觀察到高達4K QPS。我們使用單個HBase連接，並使用多個線程（5-30）批量處理10K記錄。

將所有字段組合到單列（Avro編碼，每個記錄約250字節）時，批量投入的寫入性能提高到10K QPS。併發線程數似乎不會影響QPS。當每個線程使用單獨的HBase連接時，5個線程的寫入性能會提高到20K QPS。

客戶端VM與Bigtable集羣處於相同的可用區域，並且在加載過程中它幾乎保持空閒狀態，因此它看起來不像客戶端的瓶頸。

問題：

1. 從我們的測試中，它似乎是寫QPS與插入的列的數目減少。這是否是預期的，這種關係如何量化？ （順便說一下，如果這在Bigtable performance documentation中提到過會很好）。
2. 爲了達到聲明的寫入QPS，我們可能會丟失什麼？我的理解是，每個集羣節點應該支持10K寫入QPS，但看起來我們只針對具有單個HBase連接的單個節點，並且僅針對具有多個HBase連接的2個節點。

Answer 1

要使用Cloud Bigtable獲得最佳性能，您需要使用OpenSSL而不是alpn-Boot。

BufferedMutator 0.2.3-SNAPSHOT with OpenSSL和Java8爲4 CPU機器上的小（1KB）突變和32 CPU機器上的高達90K提供了22-23K QPS。 0.2.2給出10K-12K QPS。打開一個HBase連接以獲得最佳性能。

Answer 2

回答第二個問題：通過從批量HBase Puts切換到mutators，我們設法達到了超過50K QPS。我們仍在使用多個HBase連接，單個連接似乎僅限於單節點吞吐量。