时间戳

首页 > 解决方案 > 具有设置字段的记录的 Bigtable 行键设计

hbase - 具有设置字段的记录的 Bigtable 行键设计

问题描述

我需要提高从 Bigtable 获取数据的服务的性能，并且考虑到所涉及的访问模式和数据，我认为行键设计主要是问题所在。我还需要不同服务的性能来推动数据保持一致（或改进）。

这是一个例子（请耐心等待）。我每天收到成批发送的数百万条记录。假设它是每天更新的全球宠物主人信息，每条记录的格式如下：

例子：

目前，针对服务的查询类型为（按频率/重要性排序）：

  1. 在第 32 天，向我提供所有拥有鸟类但不拥有鱼或猫的人的宠物主人信息。这是典型的格式 - 即，告诉我拥有这只特定宠物的人，而不是这些 X 数量的其他宠物。我们经常想排除很多很多宠物。这个世界上的人也可以拥有很多宠物——有时是几十只宠物。
  2. 在第 3 天、第 4 天、第 5 天告诉我，我为您提供的这 1000 个人中，哪些人是或不是宠物主人。
  3. 从第 7 天到第 20 天，给我所有“新”宠物主人的宠物主人信息。如果在第 7 天有 2 个，而在第 20 天有 1 个原来的 2 个加上 1 个新的，只需给我信息1.

现在行键/列的格式是这样的（列包括所有其他信息）：

需要注意的一些事项：这一天总是很重要的。查询总是围绕一天展开。批次只包含一天的数据，而不是很多（假设很多批次可以同时到达）。此外，无需担心极端情况——世界上没有人驯养过一种叫做“史蒂夫”的动物，也没有人给他们的孩子取名为“乌鸦”。

今天，对于第一个查询，我们在测试我们正在查看的行是否包含我们想要排除的宠物条目时包含一个列值过滤器（它是一个正则表达式过滤器）——该集合只是一个字符串。我认为这是我们被搞砸的地方，因为宠物排除清单有时很长。我试过忘记值过滤器，只是自己在内存中进行过滤（这很冒险......零星的内存问题），这可以缩短请求的周转时间，但我希望我能做得更好。

约束：

我的想象力让我失望了。

标签： hbasegoogle-cloud-bigtable

解决方案

您的问题非常笼统，有很多事情可能会导致 Bigtable 中的性能问题，您可以在此处咨询：

https://cloud.google.com/bigtable/docs/performance#slower-perf

请在此处查看 BigTable 的预期性能：

https://cloud.google.com/bigtable/docs/performance#typical-workloads

您可以参考此链接测试您的服务功能：

https://cloud.google.com/bigtable/docs/performance#testing

并解决常见问题：

https://cloud.google.com/bigtable/docs/performance#troubleshooting

总而言之，这些文档将帮助您了解 BigTable 的性能影响。

您也可以考虑按照以下方式重新设计您的架构： https ://cloud.google.com/bigtable/docs/schema-design

推荐阅读