blob: d0e32c1b7f533391448fc849317642668dada505 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
# Tradeoffs/Design Decisions
* Key-Value store instead of relational
* `+` Schemaless, easier to evolve
* `-` No need to fully normalize the data in order to make it queriable. And without full normalization SQL is not really useful and bad performance wise.
* `-` We need to maintain our own indexes
* Individual store per resource
* Storage format defined by resource individually
* `-` Each resource needs to define it's own schema
* `+` Resources can adjust storage format to map well on what it has to synchronize
* `+` Synchronization state can directly be embedded into messages
* `+` Individual resources could switch to another store technology
* `+` Easier maintenance
* `+` Resource is only responsible for it's own store and doesn't accidentaly break another resources store
* `-` Inter`-`resource moves are both more complicated and more expensive from a client perspective
* `+` Inter`-`resource moves become simple additions and removals from a resource perspective
* `-` No system`-`wide unique id per message (only resource/id tuple identifies a message uniquely)
* `+` Stores can work fully concurrently (also for writing)
* Indexes defined and maintained by resources
* `-` Relational queries accross resources are expensive (depending on the query perhaps not even feasible)
* `-` Each resource needs to define it's own set of indexes
* `+` Flexible design as it allows to change indexes on a per resource level
* `+` Indexes can be optimized towards resources main usecases
* `+` Indexes can be shared with the source (IMAP serverside threading)
* Shared domain types as common interface for client applications
* `-` yet another abstraction layer that requires translation to other layers and maintenance
* `+` decoupling of domain logic from data access
* `+` allows to evolve types according to needs (not coupled to specific application domain types)
# Risks
* key-value store does not perform with large amounts of data
* query performance is not sufficient
* turnaround time for modifications is too high to feel responsive
* design turns out similarly complex as Akonadi
|
