Recommended usage of get_range_split_points or GetRangeSplitPoints

Using FoundationDB
1

Hello,

I am experimenting with the Go bindings GetRangeSplitPoints (which wraps C.fdb_transaction_get_range_split_points ) and couldn’t figure out the expected usage pattern. I tried to get a range split across the entire db (’’ to xFF) and the call seems to take a while (i killed after a minute on each try). DB is about 10G with sample/placeholder data. I tried various chunkSize-s , 100k, 1mb, 1g, 10g and was expecting, probably naively, to get a range slice with which i can later query using GetRange() without hitting the 5 second timeout. For my tests though, even 10 minutes is a perfectly valid if that is what it takes to get the ranges. I let it ran for 2 hrs and then a traceback showed that it is waiting on a future that is never resolved

github.com/apple/foundationdb/bindings/go/src/fdb.fdb_future_block_until_ready(0x1c05840)

What is the ideal/appropriate use of this method?

I understand the data retrieved this way would be inconsistent since it spans many transaction, but at this point, I am merely experimenting with APIs to understand what is possible.

Thanks

–

Hari

2

You might be running into getRangeSplitPoints is missing from FuzzApiCorrectness · Issue #4167 · apple/foundationdb · GitHub. You can work around this by using the locality api get_boundary_keys function. (there should be an equivalent in go)

3

The API fdb_transaction_get_range_split_points() has a problem:
When storage server is wiggling，it returns wrong_shard_server, then fdb client failed at wait(waitForAll(fReplies)); foundationdb/NativeAPI.actor.cpp at 7.1.23 · apple/foundationdb · GitHub

getRangeSplitPoints() will retry until timeout occurs.

I think the API fdb_transaction_get_range_split_points() is not stable in this case. Any improvement proposal? Thanks!