Posted on , updated on

1. Cassandra Cheat Sheet Printable
2. Cassandra Cheat Sheet
3. Cassandra Cheat Sheet Free
4. Cassandra Cheat Sheet Pdf

Cassandra Resources

About Cassandra

1. Apache Cassandra W. Cheat sheets: Apache Cassandra: A Fault-Tolerant, Massively Scalable NoSQL Database by Brian O’Neill pdf (refcardz.dzone.com).
2. Cassandra Docker Cheat Sheet. Common commands used when working with Cassandra and Docker: Status #Active containers $ docker ps #Container Utilization $ docker stats #Container.
3. Cassandra provides documented shell commands in addition to CQL commands. Given below are the Cassandra documented shell commands. The HELP command displays a synopsis and a brief description of all cqlsh commands.

Home Instant Answers Cassandra Cheat Sheet Next Steps. This is the home page for your Instant Answer and can be.

History

• Originally created at Facebook.
• Open sourced and now an official apache project.

When to use Cassandra

Cassandra is a great choice for a database when...

• Speed is the top goal and eventual consistency is acceptable.
• Table schema is stable and unlikely to change.

High Level Overview

Cassandra nodes are typically represented in a ring because there is no master node - it is a true peer to peer system.

All data stored in Cassandra is associated with a token value. Each data center has a set of token values, and each node in the data center is assigned to manage a portion of the token values. Virtual nodes can exist within each node. Virtual nodes distribute the load of token values somewhat randomly, making it so that each vnode is replicated on a different node. See this article for further reading.

Terminology

Naming Conventions / Rules

Best advice: Don't get creative. Stick with alpha, lowercase, snake-case names.

• Snake-case is the preferred naming style in Cassandra (e.g. my_table)
• No hyphens (e.g. my-table)
• No spaces (e.g. my table)
• Double quotes are required if something starts with a number (e.g. '2050predictions')
• Double quotes are required if mixed case names are used (e.g. 'myTable')

Setting up a Cassandra cluster

Creating a Sandbox Cluster

This sandbox is created using docker, VirtualBox, and boot2docker.

cassandra.yaml

Cassandra configuration is stored in cassandra.yaml file. By default this file is located at /data/conf/cassandra.yaml.

Creating Cassandra Nodes with Docker

Cassandra Cheat Sheet Printable

cassandra-rackdc.properties

By default, this file is located at /data/conf/cassandra-rackdc.properties

The dc (data center) and rack are stored in this properties file. This file is read in at node start-up and gossiped out to the other nodes in the cluster.

Working with cassandra

CQLSH

The cqlsh command line utility allows for interacting with Cassandra directly.

Once inside of a cqlsh prompt, these commands are available:

CQL (Cassandra Query Language)

Cassandra originally using a Thrift API (2008). CQL was introduced in Cassandra 0.8 in 2011.

CQL interacts with keyspaces, tables, and rows. Partitions, are implicitly handled within tables.

Note - both INSERT and UPDATE are functionally upsert statements (insert or update).Note - Use the IN () selector with caution. An IN will cause a single coordinator node to search through multiple partitions. It can become more efficient to perform multiple select queries rather than using a large IN clause to do a single select.

CQL Examples

Cassandra Data Types

• Numeric
  • bigint
  • decimal
  • double
  • float
  • int
  • varint
  • counter
• String
  • ascii
  • text
  • varchar
• Date
  • timestamp
  • timeuuid
• Other
  • boolean
  • uuid
  • inet
  • blob
• Collections
  • TTLs work for individual elements in a collection rather than the entire collection.
  • set<int> A set allows only unique values and does not preserve order.
  • list<int> A list allows duplicate values and preserves order.
  • map<text,timestamp> A map is a dictionary of key value pairs.
  • tuple<int,text,varchar,double,int> A tuple can have many different data types, but they must always appear in the same order.
  • Complex types can be nested. e.g. map<text,frozen<tuple<int,double>>>. Whenever a complex type is nested, it must be frozen. Nested complex types are written and read as blobs, so they are not particularly efficient.
  • User Defined types
    • CREATE TYPE clip (name varchar, duration int);
    • CREATE TYPE person (name varchar, id varchar);
    • CREATE TABLE courses (id text, author frozen<person>);
    • User defined types must always use the frozen keyword.
    • User defined types have the following advantages over using a tuple:
      • Ability to identify components by name, not just order.
      • Can be very helpful when multiple components have the same type.
      • Can be used across multiple tables.

keyspace

Replication strategy is defined at the keyspace level.

SimpleStrategy

The replication_factor tells cassandra how many copies of each partition in the keyspace to store.

create keyspace <keyspace-name> with replication = {'class': 'SimpleStrategy', 'replication_factor': 3};

NetworkTopologyStrategy

When using NetworkTopologyStrategy, you specify how many copies of each partition to store in each data center.

create keyspace <keyspace-name> with replication = {'class': 'NetworkTopologyStrategy', '<dc-name>': 3, '<dc-name>': 2};

tables

partition keys

The primary key is defined as the first partition key.

A single primary key can be specified using CREATE TABLE my_table (id varchar PRIMARY KEY, title varchar); or CREATE TABLE my_table (id varchar, title varchar, PRIMARY KEY (id)).

A composite primary key is specified using CREATE TABLE my_table (id varchar, title varchar, name varchar, PRIMARY KEY ((id, title)));

clustering keys

A composite key is specified using PRIMARY KEY(partition_key, clustering_key). For example: CREATE TABLE my_table (id varchar, title varchar, name varchar, PRIMARY KEY (id, title));

When clustering keys are used, the data inserted can be visualized as an entirely separate row. All of the common data must be inserted each time unless static columns are used.

A partition can hold a maximum of 2 billion cells. All of the data from a single partition must fit on a single node in the cluster. To address these limitations, consider ways to appropriately bucket the data. For example, when storing timestamps for events, buckets could be created for year, month, and day, depending on the volume that is anticipated. Another approach would be to create a bucket_id key that is a string of your choosing (e.g. '2016-12-07').

static

Cassandra Cheat Sheet

The STATIC modifying makes static fields associated with the partition key rather than including all of that data in each of the clusterking key rows.

Secondary index

A secondary index allows you to query based on columns that are not part of the primary or clustering keys.

Do not use a secondary index when...

Cassandra Cheat Sheet Free

• The column has high (or very low) cardinality. (Cardinality is a measure of the number of elements in a set.) e.g., it would not be a good idea to make an index on an email column, where every entry will be unique. Also not a good idea to make an index on a boolean column where each entry will be one of two values.
• The table contains a counter column.
• The column is frequently updated or deleted.
• The table has very large partitions.
• Cassandra currently does not support indexing static columns.

Cassandra Cheat Sheet Pdf

In cases where a secondary index cannot, or should not, be used, a separate table can be used as a manual index. For example, if you have a courses table with a static tags collections and you want to be able to query for courses by tag, you can create a separate table that has a primary key of (tag, course_id) which can serve as an index.

Reads and Writes

Each node in the cluster functions the same. The node that you connect to when making a query becomes the 'coordinator node'. Nodes that get written to in a statement are called 'replica nodes'.

Single data center consistency options:

Multiple data centers consistency options:

If a node is down when a write occurs so that the node misses data, the data will be repaired during a read.

To see what the default consistency is, run consistency;

To set the default consistency to use from the command line, use consistency <level>; e.g. consistency quorum;

If the consistency required cannot be achieved, the read or write will fail.

Batches

A batch is not a transaction - it does not have rollback support. A batch does guarantee that every command in the batch will be executed. Batches are useful for keeping related data in sync.

tombstones

When something is deleted in Cassandra, a tombstone is created. The tombstone is treated just a like a write, so that nodes that are down can be repaired. When the node that was down when the delete occurred comes back online, the normal read repair process will update the node with the tombstone.

Tombstones are automatically garbage collected on a configurable interval (default is 10 days). It is important not to clean up tombstones too quickly, because if the tombstones are removed, and then a node that was offline when the tombstone was created comes back online, the the read repair will restore the data from the node that was offline when the delete occurred, making it so that the data that was supposed to be deleted comes back into the database.