Scribd
Upload
327 views4 pages

The Cassandra Data Model

The Cassandra data model differs from a relational database in several key ways. Cassandra uses a column family structure instead of tables, does not enforce relationships between column families like foreign keys, and does not support joining column families at query time. Developers must design their column families and add secondary indexes to support the specific queries needed by their application.

Uploaded by

Jorge Ivann
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
327 views4 pages

The Cassandra Data Model

The Cassandra data model differs from a relational database in several key ways. Cassandra uses a column family structure instead of tables, does not enforce relationships between column families like foreign keys, and does not support joining column families at query time. Developers must design their column families and add secondary indexes to support the specific queries needed by their application.

Uploaded by

Jorge Ivann
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

The Cassandra Data Model

For developers new to Cassandra and coming from a relational database background, the data model can be a bit confusing. The following section provides a comparison of the two.

Comparing the Cassandra Data Model to a Relational Database


The Cassandra data model is designed for distributed data on a very large scale. Although it is natural to want to compare the Cassandra data model to a relational database, they are really quite different. In a relational database, data is stored in tables and the tables comprising an application are typically related to each other. Data is usually normalized to reduce redundant entries, and tables are joined on common keys to satisfy a given query. For example, consider a simple application that allows users to create blog entries. In this application, blog entries are categorized by subject area (sports, fashion, and so on.). Users can also choose to subscribe to the blogs of other users. In this example, the user id is the primary key in the users table and the foreign key in the blog and subscriber tables. Likewise, the categoryid is the primary key of the category table and the foreign key in the blog_entry table. Using this relational model, SQL queries can perform joins on the various tables to answer questions such as "what users subscribe to my blog" or "show me all of the blog entries about fashion" or "show me the most recent entries for the blogs I subscribe to".

In Cassandra, the keyspace is the container for your application data, similar to a database or schema in a relational database. Inside the keyspace are one or more column family objects, which are analogous to tables. Column families contain columns, and a set of related columns is identified by an application-supplied row key. Each row in a column family is not required to have the same set of columns. Cassandra does not enforce relationships between column families the way that relational databases do between tables: there are no formal foreign keys in Cassandra, and joining column families at query time is not supported. Each column family has a self-contained set of columns that are intended to be accessed together to satisfy specific queries from your application. For example, using the blog application example, you might have a column family for user data and blog entries similar to the relational model. Other column families (or secondary indexes) could then be added to support the queries your application needs to perform. For example, to answer the queries: What users subscribe to my blog? Show me all of the blog entries about fashion. Show me the most recent entries for the blogs I subscribe to. You need to design additional column families (or add secondary indexes) to support those queries. Keep in mind that some denormalization of data is usually required.

About Keyspaces
In Cassandra, the keyspace is the container for your application data, similar to a schema in a relational database. Keyspaces are used to group column families together. Typically, a cluster has one keyspace per application. Replication is controlled on a per-keyspace basis, so data that has different replication requirements should reside in different keyspaces. Keyspaces are not designed to be used as a significant map layer within the data model, only as a way to control data replication for a set of column families.

Defining Keyspaces
Data Definition Language (DDL) commands for defining and altering keyspaces are provided in the various client interfaces, such as Cassandra CLI and CQL. For example, to define a keyspace in CQL: CREATE KEYSPACE keyspace_name WITH strategy_class = 'SimpleStrategy' AND strategy_options:replication_factor='2'; Or in Cassandra CLI: CREATE KEYSPACE keyspace_name WITH placement_strategy = 'SimpleStrategy' AND strategy_options = {replication_factor:2}; See Getting Started Using the Cassandra CLI and Getting Started with CQL for more information on DDL commands for Cassandra.

from distutils.core import setup from os.path import abspath, join, dirname setup( name='ccm', version='1.0dev', description='Cassandra Cluster Manager', long_description=open(abspath(join(dirname(__file__), 'README'))).read(), author='Sylvain Lebresne', author_email='[email protected]', url='https://github.com/pcmanus/ccm', packages=['ccmlib', 'ccmlib.cmds'], scripts=['ccm'], requires=['pyYaml'], classifiers=[ "License :: OSI Approved :: Apache Software License", "Programming Language :: Python", ], )

You might also like