Confirmed users
358
edits
| Line 36: | Line 36: | ||
== Strawman Proposal == | == Strawman Proposal == | ||
In order to guide the design process, I have developed a strawman refactoring of the server-storage code to use a KeyValueStore instead of an RDBMS. The dummy KVS implementation is available | In order to guide the design process, I have developed a strawman refactoring of the server-storage code to use a KeyValueStore instead of an RDBMS. Uploaded to a user hg repo here: http://hg.mozilla.org/users/ryan_rfk.id.au/server-storage-kvs/ | ||
The proposed python API is defined in http://hg.mozilla.org/users/ryan_rfk.id.au/server-storage-kvs/file/tip/syncstorage/storage/kvstore/__init__.py | |||
The dummy KVS implementation is built on top of SQL and is available in http://hg.mozilla.org/users/ryan_rfk.id.au/server-storage-kvs/file/tip/syncstorage/storage/kvstore/sql.py | |||
The refactoring of the storage interface to use KVS is available in http://hg.mozilla.org/users/ryan_rfk.id.au/server-storage-kvs/file/tip/syncstorage/storage/kvs.py | |||
The design is based mostly on my high-level understanding of the functions provided by Riak, but I've also been thinking about how it might be implemented on top of other backend technology e.g. HBase or Cassandra. So it's definitely intended to be backend-agnostic as much as possible. | The design is based mostly on my high-level understanding of the functions provided by Riak, but I've also been thinking about how it might be implemented on top of other backend technology e.g. HBase or Cassandra. So it's definitely intended to be backend-agnostic as much as possible. | ||