Inside the Hades Architecture each customer has a separate Keyspace from each other. Inside a Keyspace an administrator can create tables distributed among clusters.
Each table can be partitioned by 2 main keys: id and sub_id. An automatic key is handled by the system for performance reasons, namely threshold_page (by default increased each 100K rows). A clustering key is used by the system, namely timestamp, in order to perform requests on the lastest data available in O(1).
What is a partition key
In order to retrieve the data in a very efficient way, it is stored according to the specified id and sub_id keys. Each compound key (the aggregation of the two) is stored in different locations of the cluster and therefore each request should specify both!
It is possible to ask the system to perform the request even if it is not optimized, but is highly discouraged
There are 2 indexes built on each table: subscriber and subscriber_id, in order to keep track of who inserted a row. An index allows you to perform a request without specifying the partition key, but you SHOULD NOT FILTER in any way the data, unless the partition is reasonably small.
|id||first partition key|
|sub_id||second partition key|
|threshold_page||third automatic partition key (default increased every 100K rows)|
|timestamp||DESC clustering key, first available is the most recent|
|subscriber||inserter subscriber type|
|subscriber_id||inserter subscriber id|
|any key||you can create any additional column|