Google二级索引

Question

在查看Google时，我发现它没有提供定义二级索引的能力。

因此，如果你有10亿笔交易，对于1000万个客户来说，你似乎需要一个完整的表格扫描来提取一个客户的所有事务。

由于Google似乎正在使用Apache HBase，我的第一个想法是:大概可以将Apache凤放在首位。

然而，我发现在这个方向上几乎没有发现，最相关的似乎是2018年的邮寄单邮寄，提到“这将是困难的，因为不支持协处理器”。

好吧，现在我们还有很长的路要走，虽然我确认协处理器似乎仍然不被支持，但我想知道是否出现了支持二级指数的模式？

Answer 1

因此，如果你有10亿笔交易，对于1000万个客户来说，你似乎需要一个完整的表格扫描来提取一个客户的所有事务。

这是一种读取访问模式。如果每个客户的查询是一种频繁的访问模式，那么有效的模式设计将以客户ID为前缀的行键，这样，每个客户读取的查询就会转换为对该客户数据的非常快速的查找。

如果您能够识别额外的读和写访问模式，每个访问模式发生的频率，与每个访问模式的延迟和吞吐量相关的需求，那么就可以设计出模式设计的额外细化。如果你能提供这些细节，我很乐意帮你想清楚。

在查看Google时，我发现它没有提供定义二级索引的能力。

这是正确的。

当似乎在使用Apache HBase时.

这是不完全正确的，但接近了。HBase是以BigTable为模型的。这两个项目都不依赖于对方的实现。但是，与Cloud通信的一种方法是通过Cloud client，这是Apache的定制版本。

由于Google似乎正在使用Apache HBase，我的第一个想法是:大概可以将Apache凤放在首位。

您可以重构菲尼克斯，使其与compatible客户端兼容。这将是一个为期一年的项目，至少，如果单独工作。至于缺少像协处理器这样的特性，您肯定会找到一种方法来复制HB协处理器实现的那种并行性。

好吧，现在我们还有很长的路要走，虽然我确认协处理器似乎仍然不被支持，但我想知道是否出现了支持二级指数的模式？

尽管没有什么比StackOverflow的答案更糟糕的，它对OP已经做出的所有潜在的技术选择提出了疑问，但是基于关于OP的用例的很少信息，我还是要继续这样做…请问您为什么要使用BigTable？通过容量、速度、变化、访问和安全性来分解数据配置文件，不同的存储系统可能是更好的方法之一。如果你能提供这些细节，我很乐意帮你想清楚。

批量:需要更多的信息，但是如果数据确实是十亿个事务，那么假设每个事务都有合理的行大小(这是一个重要的假设，请让我更多地了解每个事务的大小)，那么您的数据将很容易地适合我列出的任何解决方案，包括CloudSQL，它的最大实例大小为30 to 64结核病。64 TB除以10亿等于64 KB。作为比较，Server的最大行长为8KB。例如，在GCP之外，Server允许数据库大小为50万兆字节。

就速度而言，我怀疑这个数据是低速的，原因有两个。首先，数据的性质:收集和存储人工输入数据的Web应用程序和移动应用程序通常是低速的，至少在单个用户测量时是如此。第二，从您提供的有关数据的详细信息来看:如果1000万客户有10亿个交易，即每个客户有100个交易。同样，听起来像是sql服务器或MongoDB/Firebase是合适的。

数据的变化:考虑到客户事务的性质，并且考虑到您试图将bigtable封装在OLTP DB外观中，例如菲尼克斯，这听起来像是一个典型的OLTP关系DB用例，也就是说，高度结构化和低变化。但是，如果是较高的变化，则可以使用Firebase或MongoDB。

访问:你告诉过我一种读-访问模式，尽管可能还有很多其他的，这是我无法预知的。对于每种访问模式，您可能想要回答的问题：

1. 在读取操作中检索了多少数据？(您已经回答了您在问题中描述的访问模式)
2. 插入操作中写入了多少数据？
3. 每隔多久写一次数据？
4. 数据被读取多久一次？

至于写访问模式，我怀疑有一个单一的写访问模式，其特点是一次只写少量数据，速率很低。