我可以通过减少hdfs块大小来提高HBase性能吗？

Question

我有大约2500个表参与计算。在我的开发环境中，我在这些表中的数据非常少，10到10,000行，大多数表位于此范围的下端。我的计算将多次扫描所有这些表。虽然整个数据集适合内存，但通过HBase轻松访问它的速度非常慢，并且磁盘活动量很大。

您认为这有助于减少hdfs块大小吗？我的理由是，如果每个表都在自己的块中，那么将浪费大量内存，从而阻止整个数据集驻留在RAM中。大大减小的块大小将允许系统保存RAM中的大部分（如果不是全部）数据。目前块大小为64MB。

最终系统将用于具有更多内存和节点的更大集群中，这纯粹是为了加快我的开发环境。

Answer 1

HBase将其数据存储在HFile中（后者又存储在Hadoop文件中） 这是摘录from the doc:

  

最小块大小。我们建议设置最小块大小   一般用途在8KB到1MB之间。较大的块尺寸是优选的   如果文件主要用于顺序访问。但是，它会导致   低效的随机访问（因为有更多的数据）   解压缩）。较小的块适用于随机访问，但需要   保存块索引的内存更多，创建速度可能更慢   （因为我们必须在每个结束时冲洗压缩机流   数据块，导致FS I / O刷新）。此外，由于   压缩编解码器中的内部缓存，可能的最小块   大小约为20KB-30KB。

无论块大小如何，您可能希望将表的列族设置为in-memory true，这使得hbase有利于将它们保留在缓存中。

最后你的情况似乎更适合像redis / memcache这样的缓存，而不是Hbase，但也许我没有足够的上下文

Answer 2

我的方案是我的密钥值对大小为100字节，我需要对这些数据执行随机读取。我应该增加还是减少群集中随机读取性能的块大小？

Answer 3

如果你的块大小太小，那么你需要更多的内存来保持块索引。如果块大小太大，则HBase必须扫描更多行以检测HBase块中是否存在搜索到的密钥。如果您的KV对是100字节，则640 KV适合一个值很好的块。