The getRange() API has argument “reverse” will following documentation: If non-zero, key-value pairs will be returned in reverse lexicographical order beginning at the end of the range.
Is this reverse traversal of Keys something which is natively supported by fdb and as efficient as non-reverse traversal OR is this flag a syntactic sugar provided in client API?
If former is true, I can assume that fdb is like a doubly linked list of sorted keys where one can iterate forward or backward with same efficiency.
This will also mean that if I make a simple value index using fdb keys, its available as both ascending and descending order.
Is this reverse traversal of Keys something which is natively supported by fdb and as efficient as non-reverse traversal OR is this flag a syntactic sugar provided in client API?
This is not syntactic sugar at the client API level, this is implemented by the storage nodes when they send batches of data (in reverse order). I’m not sure exactly what the overhead is, but it should be minimal.
The storage nodes have to do it themselves in order for batching to be efficient (the “streaming mode” parameter in the get range operator).
If former is true, I can assume that fdb is like a doubly linked list of sorted keys where one can iterate forward or backward with same efficiency.
The data is stored in a b-tree, so scanning the keys forward or backward in a leaf page should not matter much, or if there is any overhead, it will be dwarfed by the network overhead anyway.
This will also mean that if I make a simple value index using fdb keys, its available as both ascending and descending order.
Pretty much yes. Using reverse scan in indexes is frequently used for chronological data, to pop from stacks, or to get the last inserted entry (when using versionstamps or timestamps as keys).
And remember: as a fallback, if you find that there is an unacceptable overhead for your specific workload, you could always use a custom binary key encoding that automatically reverse the order of your keys to simulate this while still using a forward scan. Though 1) you would not be able to use versionstamps anymore 2) this is probably way overkill and reverse scans will do the job fine.