Apache Cassandra structure

Apache Cassandra is a distributed database system, meaning that data is spread across multiple nodes in a cluster. Because data may be spread across distributed nodes, it’s important to design your schema and queries with this fact in mind, to ensure optimal performance and scalability. Each node in the cluster store some of the pieces, or partitions, of the total data.

These partitions play a key role in efficiently retrieving data. The partition key is a critical element of data modeling.

Let’s step back for a moment to look at the overall structure of how data is stored in Cassandra, from the point of view of the Cassandra Query Language (CQL).

ks table

The first database object that must be defined is a keyspace. A keyspace is an object that will store one or more tables. Its main characteristic is that the replication factor, or how many replicas of a particular piece of data, will be stored in the Cassandra cluster.

As mentioned, tables are database objects stored in keyspaces. Tables define the bits of information that will be stored together. Generally, tables group information that is related to answer a query, so that retrieval will be fast and performant.

Tables may be thought of as storing rows of data in columns. The contents of a particular row-column pair will be stored in a cell, and must conform to a definition of data type. The data type of each column defined in a table must be defined. One or more columns will be used to define a partition key. A partition key is required in all table definitions as part of the primary key. A primary key consists of a partition key, and optionally, one or more clustering columns. Clustering columns will define how rows are sorted within a partition.

Tables can be indexed, making non-partition key columns available for query. Apache Cassandra has multiple methods of indexing. DSE can use secondary indexes (2i), SASI indexes, SAI indexes, or DSE search indexes.

Indexes allow data to be retrieved from tables without specifying a primary key. However, they are less performant that data retrieved with a primary key, and their use should be considered carefully when data modeling and designing table structure.

Security is an important feature of all databases, and Cassandra is no different. Table data can be secured with a login-password combination based on defined roles. In addition, row-based access can be controlled.

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2024 DataStax | Privacy policy | Terms of use

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: +1 (650) 389-6000, info@datastax.com