我最近遇到了 HBase 的 BufferedMutator 类，它可以用于批量插入和删除。
我以前使用 List 将数据作为hTable.put(putList) 来做同样的事情。
对我的代码进行基准测试似乎也没有太大的不同，而我正在做mutator.mutate(putList);。
与 PutList 相比，使用 BufferedMutator 是否有显着的性能提升？
【问题讨论】：
标签： java optimization hbase hbase-client
BufferedMutator 通常比仅使用 Table#put(List<Put>) 提供更好的吞吐量，但需要适当调整 hbase.client.write.buffer、hbase.client.max.total.tasks、hbase.client.max.perserver.tasks 和 hbase.client.max.perregion.tasks 以获得良好的性能。
当您将 put 列表传递给 HBase 客户端时，它会按目标区域对 puts 进行分组，并按目标区域服务器对这些组进行批处理。为每个批次发送一个 rpc 请求。这减少了 rpc 开销，尤其是在 Put 非常小的情况下，从而使每个请求的 rpc 开销很大。
Table 客户端立即将所有 Puts 发送到区域服务器并等待响应。这意味着任何可能发生的批处理都仅限于单个 API 调用中的 Put 数量，并且从调用者的角度来看，api 调用是同步的。
但是，BufferedMutator 一直在缓冲区中缓冲 Put，并决定根据由名为 AsyncProcess 的类包裹的后台线程中的当前缓冲大小来刷新缓冲的 put。从调用者的角度来看，每个 API 调用仍然是同步的，但整个缓冲策略提供了更好的批处理。后台刷新模型还允许请求的连续流，结合更好的批处理意味着能够支持更多的客户端线程。然而，由于这种缓冲策略，缓冲区越大，调用者看到的每次操作延迟越差，但通过拥有更多数量的客户端线程可以维持更高的吞吐量。
控制 BufferedMutator 吞吐量的一些配置是：
hbase.client.write.buffer：缓冲区的大小（字节）（越高提供更好的峰值吞吐量，消耗更多内存）
hbase.client.max.total.tasks：在 AsyncProcess 开始阻塞请求之前，集群中的待处理请求数（越高越好，但会导致客户端 CPU 饿死，或导致服务器过载）
hbase.client.max.perserver.tasks：在 AsyncProcess 开始阻塞请求之前，一个区域服务器的待处理请求数。
hbase.client.max.perregion.tasks：每个区域的待处理请求数。
另外，为了完整起见，不言而喻，如果瓶颈出现在服务器端而不是客户端，那么在客户端上使用 BufferedMutator 而不是 Table 不会看到太多性能提升.
【讨论】：