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

我有大约2500张表格参与计算。在我的开发环境中，这些表中的数据很少，只有10-10000行，大多数表都在这个范围的低端。我的计算将多次扫描所有这些表格。虽然整个数据集都可以放在内存中，但通过HBase轻松访问数据集的速度非常慢，需要大量磁盘活动

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

---

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

HBase将其数据存储在HFiles中（HFiles反过来存储在Hadoop文件中） 这里有一段摘录

最小块大小。我们建议设置最小块大小 一般情况下，在8KB到1MB之间。最好使用较大的块大小 如果文件主要用于顺序访问。然而，这将导致 效率低下的随机访问（因为要访问的数据更多） 减压）。较小的块有利于随机访问，但需要 存储块索引的内存更多，创建速度可能较慢 （因为我们必须在每次试验结束时冲洗压缩气流 数据块，导致FS I/O刷新）。此外，由于 压缩编解码器中的内部缓存，尽可能小的块 大小大约为20KB-30KB

无论块大小如何，您都可能希望将表的列族设置为内存中的true，这使得hbase更倾向于将它们保留在缓存中

---

最后，您的情况似乎比Hbase更适合像redis/memcache这样的缓存，但可能我没有足够的上下文

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

太棒了！谢谢你的回复。最终，这些表将相当大，超过百万行，并且需要持久化。redis/memcache可以在这种情况下使用吗？有关redis大小限制，请参阅。同样，我对您的需求了解得不够。因此，您可能需要考虑的其他相关技术包括数据网格解决方案，如Gridgain、HAZELCAST、GigAsPACS或FuniSnP留存，认为HDFS块大小和HBASE块大小是不同的。