Cassandra storage type

Table of contents

1. Restrictions
   1. Operators
   2. Pagination
   3. Sorting
   4. Associations
   5. Access control
2. Collection types
   1. Foreign key arrays
   2. Array type attributes
3. Distributed data models

---

This page covers specifics related to the cassandra storageType. Cassandra is, in general, not a general purpose database — it aims to provide efficient access to Big Data by carefully describing the data and its specific access patterns. Zendro provides a standardized API for all defined models and assumes certain considerations when defining your data model. For the Cassandra storageType, a unique primary key attribute is required, providing access to a specific record identified by that key. Aside from simple primary keys, Cassandra also offers compound primary keys to define efficient access across a cluster of servers — these are not currently supported. A primary key must refer to a single attribute.

Restrictions

Compared to relational databases, accessing and querying data stored in a Cassandra database has several restrictions.

Operators

Zendro queries the Cassandra database directly via CQL (Cassandra Query Language) statements, using the DataStax cassandra-driver. CQL implements only a subset of the logical operators available in, for example, relational databases. The operators included in Zendro are:

zendro-operator	operation
eq	=
lt	<
gt	>
lte	<=
gte	>=
ne	!=
in	in
contains	contains*
and	and

* contains relates to Cassandra Collections.

Note that Cassandra specifically does not implement the logical or operator.

Pagination

Due to its distributed nature, Cassandra does not implement traditional limit-offset pagination. This means only the cursor-pagination based GraphQL Connection type readAllCursor query is supported. Zendro implements cursor-based pagination via the base64-encoded record.

Note that Cassandra does not support backward pagination, so the only valid pagination arguments are first and after.

Sorting

Cassandra only supports sorting query results by specifically defining this via the compound primary key and the column used to partition the data. Since Zendro does not implement that kind of primary key for now, no sorting of Cassandra results is possible. The default order is defined by Cassandra’s internal token function.

Associations

Associations with targetStorageType set to Cassandra have restrictions on searching. The association is resolved by adding a search for either eq on the respective foreign key, or in on the foreign key array in the case of many_to_many associations. Cassandra does not allow multiple equality restrictions on the ID field — the driver throws an error — so a workaround merges searches on the ID field with the search on the foreign key(s).

This workaround only works because Cassandra does not support the or operator. There are also the following pitfalls to consider:

• Cassandra does not allow SELECT queries with an IN clause on indexed columns for the primary key.
• Multiple equality restrictions on the ID field will throw an error.
• Multiple searches on the ID attribute will still throw the above error, since search nodes are merged one by one with the foreign key(s).
• This workaround only applies to associations where the foreign key is stored on the Cassandra model’s side, since IN clauses are only allowed on the primary key column, not on any foreign key column.

Access control

CQL implements an optional ALLOW FILTERING argument for its queries, allowing server-side filtering of the result set. Since these queries may have unpredictable performance depending on factors like secondary indices on columns, ALLOW FILTERING must be explicitly requested in the query.

Zendro implements this via the data models’ Access Control List. Only users with the editor role can send queries that require server-side filtering.

Collection types

Cassandra implements several different collection types — sets, lists and maps — each with different characteristics. Zendro uses sets and lists depending on the use case.

Foreign key arrays

Zendro implements many_to_many relations between models via paired-end foreign keys. In a Cassandra data model this is implemented via a set, a sorted list of unique values of a specific data type.

Array type attributes

Zendro supports array-type attributes, defined in the JSON data model definition with square brackets, e.g. [String]. In Cassandra models, Zendro implements this internally via list data types, a sorted collection of non-unique values.

Distributed data models

Due to the restrictions on ordering result sets in Cassandra (see Sorting above), it is not possible to define a distributed data model stored in both a relational and a Cassandra database, i.e. one with both sql and cassandra adapters. It is, however, possible to define distributed data models that live only in Cassandra databases. These need to set a cassandraRestrictions flag to ensure correct behaviour:

"model": "dog",
"storageType": "distributed-data-model",
"registry": ["dog_instance1", "dog_instance2"],
"cassandraRestrictions": true,