Services/KeyValueStorage: Difference between revisions
< Services
Jump to navigation
Jump to search
(Created page with "==Planning Questions== How simple can we get away with while still providing useful functionality? * maximum key size, value size? * key => single value? * key => set of values?...") |
|||
| Line 8: | Line 8: | ||
* keys in sorted order? (i.e. hash or btree?) | * keys in sorted order? (i.e. hash or btree?) | ||
* handling of concurrent edits, conflicts? | * handling of concurrent edits, conflicts? | ||
* bulk insert, update or delete operations? | |||
Crypto | Crypto | ||
Revision as of 05:33, 8 September 2011
Planning Questions
How simple can we get away with while still providing useful functionality?
- maximum key size, value size?
- key => single value?
- key => set of values? (like e.g. riak with siblings enabled)
- key + column => value? (like e.g. bigtable or cassandra)
- keys in sorted order? (i.e. hash or btree?)
- handling of concurrent edits, conflicts?
- bulk insert, update or delete operations?
Crypto
- can it sensibly be done at this layer, or do we need to defer to the application?
- encrypted keys would make key-ordering useless
Authentication to App
- can AppKeys be used for authentication, e.g. some sort of request signing with the app key?
We will probably want some sort of partitioning or "buckets".
- AppKey => list of buckets?
- AppKey + UserID => list of buckets?
- can a bucket be shared between multiple apps? multiple users?
It would be good to find and isolate some use cases in the existing Services apps.
- Build a SyncStorage plugin that stores data in the KVStore?