Those first two are pretty trivial. Keys are already stored in sorted order in a b-tree. Secondary indexing involves putting the indexed value to the left of the primary key in the key you write.
FoundationDB provides the building blocks. Secondary indexes can be built on top of the regular primary index. Transactions make it possible to maintain a consistent 2I using a K/V interface.
I thought FoundationDB stored data in a hash table. Didn't realize it uses a b-tree. Thanks for the clarification.
> Secondary indexing involves putting the indexed value to the left of the primary key in the key you write
By secondary index I meant having a sort order that's different from the primary key sort order.