为什么在 H2 数据库上通过 getBytes(long pos, int length) 查看 BLOB 如此慢？
我有一个应用程序需要查看 blob 并获取少量字节（通过 getBytes(long pos, int length)）。这些 blob 约为 30MB。当我请求靠近 blob 开头的字节时，性能是合理的。当我请求靠近 blob 末尾的字节时，性能会更差。查看源代码（JdbcBlob.java），似乎 blob 是按顺序读取的，而不是随机读取的（通过输入流）。
有人知道任何解决方法吗？我是 H2 的忠实粉丝，这个问题不会影响交易，但我认为它可以改进。
谢谢
I have an application that needs to peek into blobs get out small numbers of bytes (via getBytes(long pos, int length)). The blobs are ~30MB. When I ask for bytes near the beginning of the blob, the performance is reasonable. When I ask for bytes near the end of the blob, the performance is much worse. Looking at the source code (JdbcBlob.java) it appears that the blob is read sequentially instead of randomly (via an input stream).
Does anybody know of any workarounds? I'm a huge H2 fan and this issue isn't a deal breaker but I think it could be improved.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
它很慢，因为H2使用InputStream并且不进行随机访问（所以你已经自己回答了这个问题）。不支持随机访问的原因是：到目前为止没有人请求此功能:-)
我认为没有简单的解决方法。需要更改H2以支持随机访问。对于 BLOB 数据，这应该相对容易；对于CLOB数据来说会更困难（因为数据以UTF-8形式存储，并且不太容易找到正确的点）。
我现在已经在路线图中添加了一个功能请求，但是如果您在不久的将来确实需要这个功能，那么恐怕您将不得不自己实现它。 H2 是开源的，欢迎提供补丁:-)
It's slow, because H2 uses an InputStream and doesn't do random access (so you have already answered the question yourself). The reason why random access it is not supported is: so far nobody requested this feature :-)
I don't think there is a simple workaround. H2 needs to be changed to support random access. For BLOB data, this should be relatively easy; for CLOB data it will be harder (because data is stored in UTF-8 form, and it's not so easy to seek to the right point).
I have now added a feature request in the roadmap, but if you really need this feature in the near future, then I'm afraid you will have to implement it yourself. H2 is open source, and patches are always welcome :-)
我刚刚升级到版本 1.3.166，很高兴发现这个问题已得到纠正。在我的例子中，查看斑点末端附近大约需要 500 毫秒。
现在需要 4 毫秒。
I just upgraded to version 1.3.166 and was happy to find that this issue has been corrected. Peeking near the end of the blob in my case took about 500ms.
It now takes 4ms.