使用“性能”下的 Google Bigtable答案

【问题标题】：Google Bigtable under usage "performance"使用“性能”下的 Google Bigtable
【发布时间】：2018-01-22 13:45:18
【问题描述】：

我已经看到了不要将 Google Big Table 用于小型数据集的警告。

这是否意味着 100 QPS 的工作负载可能比 8000 QPS 的工作负载运行得更慢（总时间；不是每个查询）？

我知道 100 QPS 在 BigTable 上的效率非常低；但它会不会像 100 次插入需要 15 秒才能完成一样激烈？哪里可以在 1 秒内运行 8000 次插入？

只是寻找“理论上；有时；是”与“可能相对不太可能”类型的答案，作为我如何构建性能测试周期的粗略指南。

谢谢

【问题讨论】：

你能澄清一下你的问题吗？它似乎在谈论两个不同的事情：数据集大小和 QPS。不建议将 Bigtable 用于小型数据集，因为它将数据拆分为多个 tablet 并将这些 tablet 分布在多个服务器上。这允许它通过跨这些服务器的负载平衡来支持高 QPS。如果您的数据集很小，则不能将其拆分到多个服务器上，并且会热点单个服务器。
我的问题是关于这两点。那么单个热点服务器是否仍然能够在其拥有的小型数据集上以 10000 QPS 的速度提供服务？
假设键之间没有争用，应该没问题。另外，请注意，要实现写入的高吞吐量，您必须使用批量请求（即 java 中的 BufferedMutator 或 golang 中的 ApplyBulk）。

标签： bigtable google-cloud-bigtable

【解决方案1】：

运行任何 Cloud Bigtable 操作都有固定的启动成本。那个启动成本一般在1秒以内。我预计 100 次操作应该少于 8000 次操作。当我看到极度缓慢时，我通常会怀疑网络延迟或其他一些特殊情况。

【讨论】：

【解决方案2】：

在我们的 Developer Big Table 实例 (2.5 TB) 上运行小型工作负载时遇到问题，一个实例而不是 3 个。

我们在用户 ID 上设置了一个密钥，在密钥用户 ID 上设置了大约 100 行。数据库中的总记录数为几百万。我们查询大表并看到从获取与用户 ID 的单个键相关联的行有 1.4 秒的延迟。返回的记录总数少于 100 条，并且我们看到了超过一秒的延迟。在我看来，巨大的工作负载是使用这个数据存储的唯一方法。我们正在研究其他 NoSQL 替代方案，例如 Redis。

【讨论】：