Data Modeling

Feature matrix

Before modeling your data schema you need to understand the following feature matrix:

image 1 - Posibility of 3 base structure

Product comparsion:

  • Hosted: AcapellaDB - hosted multiuser database as service (you must have acapella cloud account).
  • Box: you must think about it and use it in one user mode, emulate same username in url.


Values are located by two keys: partiotion key, clustering key (like composite key of 2 components): partition key - data distributed by cluster (select several replica machines) clustering key - data placed sorted in every relica.


For partition key test:foobar:k1:k2:k3, that contains 5 parts.

First 2: part test - username and test:foobar - keyspace.

In tail parts :k1:k2:k3 just a user parts of a partiotion key.

Keyspace used, for example for work with data indexes.

In hosted mode keyspace can have share settings, that can be public or private.

Billing also use keyspace binding.

Strict Distributed Transactional operations. Smart replication settings for every keyspace.


KV ia a Key-Value storage.


  • fast IO by exact match of key
  • very fast non-transactional reads and writes (including CAS)
  • KV key is a patrition key - the keys distribute over whole cluster
  • 3 options N, R, W per each operation - you can balance beetween availability and consistency

partiotion key (just key) has list structure like this : ["prefix 1", "prefix 2", "aplicationID", "k1", "k2"] in json. You can build a hierarchy of keys using prefixes.


DT store key seuence in tree - whole tree distributed over cluster. Can be used for very big "index" with frequent reading, and a rare inserting. If this index can not be placed in any machine, and must be distributed - DT is good solution


  • transactional cursors: next, prev
  • limited transactional ranges
  • fast read (like KV), but very slow insert (~ 100 insert/sec to one tree)
  • automatically distributes data across the cluster


SortedMap has data model like Cassandra column store.

TODO переформулировать

In AcapellaDB_1.0 SortedMap the main item is the key, its version and its meaning - not the key sequence. Its mean that the SortedMap can not give any guarantee of transaction work with lists and breaks in it, unlike DT.


  • fast get , set, cas, like KV (transactional or not)
  • fast index navigation next, prev and range search request (not transactional)


We have transactional and NOT transactional access at the same time.