我需要提高从bigtable获取数据的服务的性能，并且考虑到访问模式和所涉及的数据，我认为行键设计是主要的问题。我还需要一个不同的服务的性能，该服务将数据推入以保持一致（或改进）。
这里有一个例子（请容忍我）。我每天收到成批发送的数百万条记录。假设它的全球宠物主人信息每天更新，并且每个记录都有以下格式：
名字
姓氏
地址
家庭型
宠物
例子：
彼得
谢尔曼
悉尼沃勒比路42号
公寓
[猫，狗，鱼，鸟，袋鼠]
目前，指向服务的查询类型有（按频率/重要性排序）：
给我的宠物主人的信息，为所有人拥有鸟，但不是鱼或猫在第32天。这是典型的格式-即，告诉我的人，拥有这个特定的宠物，但不是这些x数的其他宠物。我们经常想把许多宠物排除在外。这个世界上的人也可以养很多宠物，有时甚至有几十只宠物。
告诉我在第3天，第4天，第5天我提供给你的1000个人中，你是还是不是宠物主人。
给我从第7天到第20天所有“新”宠物主人的宠物主人信息。如果第7天有2个，第20天有1个原来的2加1个新的，只要给我1的信息。
当前行键/列的格式如下（列包括所有其他信息）：
dayx宠物名字姓氏（答案1）
dayx名字姓氏（答案2/3）
需要注意的是：这一天总是很重要的。询问总是围绕着一天。批处理只包含一天的数据，而不是很多（假设一次可以到达多个批处理）。另外，不必担心边缘案件-没有人驯养一种动物称为“史蒂夫”，也没有人命名他们的孩子“乌鸦”在这个世界上。
今天，对于第一个查询，在测试我们正在查看的行是否包含要排除的pet的条目时，我们包含了一个列值过滤器（它是regex过滤器）——集合只是一个字符串。我认为这是我们在性能方面的失误，因为宠物被排除在外的名单有时相当长。我试着忘记值过滤器，自己在内存中进行过滤（这是一个不确定的……偶发的内存问题），这样可以缩短请求的周转时间，但我希望我能做得更好。
约束条件：
此时无法更改数据存储（接受更好的建议）
将数据推送到bigtable的服务理想情况下应该在大致相同的时间（或更短的时间）内推送大致相同数量的数据（或更少）。在更长的时间里，不按数量级推进更多是可以的。
我的想象力正在衰退。