我们正在实现一个hbase存储机制，它将有一个表，该表将使用（字符串）行键和（长）时间戳来维护一行的多个版本。这是hbase的核心功能，对我们非常有用。
在大多数情况下，行只有十几个版本，每个版本在所有单元格中的大小应该只有几kb。但是，有一种边缘情况，一行可能有数百个版本，每个版本都有不同的时间戳，将每行的最大版本数（仅在这一个表上）设置为“1000”（1000）是否会有任何性能或扩展成本尚不清楚。
就访问模式而言，当我们提取数据时，它将是：
给定行键，拉出行的“最新”版本
在给定行键和时间戳的情况下，拉出该行的指定版本
在给定行键的情况下，从每个版本的行中拉出一个包含long的单元格（称为“ts”）
最后，在3）中，允许我们发现每一行存在哪些版本，而不必取出一行的所有版本。最坏情况；我们最终会在hbase get请求中返回1000（一千）个long。这将是64 kb。我们永远不需要在一个get请求中请求行的每个版本上的每个单元格。
团队内部有人建议，这可能会导致性能问题，但是，我们在hbase手册中找不到任何澄清。
因此，考虑到上述情况，我的问题是-对于一个每行（可能）有1000个版本的表，有没有任何性能成本？
1条答案
按热度按时间vuktfyat1#
{row，column，version}元组精确地指定hbase中的单元格。行和列相同但单元格地址仅在版本维度上不同的单元格可能有无限个。
行和列键用字节表示，而版本是用长整数指定的。。。。。链接
正如您所看到的，hbase的最大版本是integer.max\u value，但是如果您插入的版本接近这个数字，那么可能会有很多风险等待着您。
版本37.1的数量。最大版本数通过hcolumndescriptor为每个列族配置要存储的最大行版本数。max versions的默认值是1。这是一个重要的参数，因为如数据模型部分所述，hbase不会覆盖行值，而是按时间（和限定符）为每行存储不同的值。多余的版本将在主要压缩过程中删除。根据应用程序的需要，可能需要增加或减少最大版本的数量。
不建议将max versions的数量设置为非常高的级别（例如，数百个或更多），除非这些旧值对您来说非常重要，因为这将大大增加storefile的大小。
从官方文件中我们可以得到一些关于你问题的信息
首先，它很可能在压缩时内存不足。
其次，单个rowkey的区域不会被分割。