search

microsoft / LSKV

A Ledger-backed Secure Key-Value store (LSKV), built on the Confidential Consortium Framework (CCF)
https://microsoft.github.io/CCF
MIT License
35 stars 6 forks source link

Serving reads from the historical index #72

Closed jeffa5 closed 2 years ago

jeffa5 commented 2 years ago

Currently reads may be served from a non-leader node (serializable in etcd terminology). These however have the added consequence of being able to read values that are not necessarily going to be committed (write a value, read it, then other leader is found so txs get lost). This isn't ideal for the reader and the etcd API doesn't have a notion of this. More likely it would be useful for them to be able to work with the plain serializable reads: served from the index. The index gets only entries that have gone through consensus so won't be losing data (unless DR?) but they can be stale.

Maybe for now we should add a compile-time flag to trigger the different behaviour (read from CCF map vs read from Index). This does get tricky when a write and read are in a transaction as the read could read an older value than the write worked against so this might not be ideal at all and just expect clients to use watch streams to get values or query with a revision if they want to get values that have been through consensus.

jeffa5 commented 2 years ago

This will also impact the header revision we return to semantically match where we queried

jeffa5 commented 2 years ago

In terms of the consistency model I think it would be useful to keep the ability to read from the latest maps (which may not commit) and expose the commited revision in the response header in the case that users want to read committed values.