It's late and I must be missing something (or maybe a lot).
ordered by key? ordered by value? ordered by insertion/update time?
Ordered for enumeration? or ordered where I can provide my own search? binary search is great, but I can think cases with better performance lookups with a bias in one direction.<p>I guess there are two main things.
1. what does ordered mean? I can think of lots of cases where having access to order would be super helpful. How do I tag the thing(s) I care about for lookup>
2. I'm not a super fan of go, but randomizing enumeration of maps was a really good move for avoiding inadvertent dependence on order.<p>I checked again, and I still don't see what order "means" (safari on OS X. maybe it's not rendering right?)<p>_edit_<p>after digging a little deeper, I guess I want to add 3
How are ties broken? Fastest result? Highest memory address?<p>Ordered KV would be super handy. But the devil is in the details, and I can't find any details.
There's almost no content in the linked article, but I'm confused at the sentence "there is none that meets all those requirements" taking into account the "software" link[0] at the end with plenty of examples. FoundationDB, TiKV, or any variation of RocksDB / LevelDB tend to include these features.<p>[0]: <a href="https://hyper.dev/81aabee4001a47bf9c8bdf4475201ba7.html" rel="nofollow">https://hyper.dev/81aabee4001a47bf9c8bdf4475201ba7.html</a>
A suggestion for the author: If you start a web page with 'Please bookmark the following address: <a href="https://okvs.dev" rel="nofollow">https://okvs.dev</a>' then you should probably put an explanation of <i>why</i> I should do that pretty soon after, don't just leave it at that!
This page looks incomplete.<p>Tangent: I'm very interested in implementations details for ordered key-value stores. B trees and their variants like B+ trees are pretty straightforward conceptually but there seems to be scarce resources on the nitty gritty details past find/insert/delete.<p>For example I'm interested in redistribution algorithms, duplicate key semantics, and merging. The relative naivety of their implementation can have a large impact on performance/storage depending on how the store is used.
Hey all, I've been seeing confusion in the comments, so I'll link to official FoundationDB docs that do a better job of explaining these concepts.<p>To get a high level overview and see what you can do:
<a href="https://apple.github.io/foundationdb/features.html" rel="nofollow">https://apple.github.io/foundationdb/features.html</a>
<a href="https://apple.github.io/foundationdb/design-recipes.html" rel="nofollow">https://apple.github.io/foundationdb/design-recipes.html</a><p>Then to dive in a bit:
<a href="https://apple.github.io/foundationdb/data-modeling.html" rel="nofollow">https://apple.github.io/foundationdb/data-modeling.html</a>
<a href="https://apple.github.io/foundationdb/developer-guide.html" rel="nofollow">https://apple.github.io/foundationdb/developer-guide.html</a> (Subspaces, Directories, and Transactions)<p>Also, the section on Anti-Features is interesting: <a href="https://apple.github.io/foundationdb/anti-features.html" rel="nofollow">https://apple.github.io/foundationdb/anti-features.html</a>
Redis also has sorted sets<p><a href="https://redis.io/topics/data-types#sorted-sets" rel="nofollow">https://redis.io/topics/data-types#sorted-sets</a>