实现声明的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连接，单个连接似乎仅限于单节点吞吐量。