Training Example: Apache Cassandra – Review the Data, Give Your Score & Compare to the Real AI Evaluation

[H1] Open Source NoSQL Database
[H2] Manage massive amounts of data, fast, without losing sleep
Learn More
Cassandra 5.0
Quickstart
[H3] Talks and Keynotes videos from the Cassandra Summit are published!
Watch all the videos
[H2] What is Apache Cassandra
[IMG: Registered]
?
[H3] Apache Cassandra is an open source NoSQL distributed database trusted by thousands of companies for scalability and high availability without compromising performance. Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data.
[IMG: hybrid]
[H3] Hybrid
Masterless architecture and low latency means Cassandra will withstand an entire data center outage with no data loss—across public or private clouds and on-premises.
[IMG: fault]
[H3] Fault Tolerant
Cassandra’s support for replicating across multiple datacenters is best-in-class, providing lower latency for your users and the peace of mind of knowing that you can survive regional outages. Failed nodes can be replaced with no downtime.
[IMG: scalable]
[H3] Focus on Quality
To ensure reliability and stability, Cassandra is tested on clusters as large as 1,000 nodes and with hundreds of real world use cases and schemas tested with replay, fuzz, property-based, fault-injection, and performance tests.
[IMG: performant]
[H3] Performant
Cassandra consistently outperforms popular NoSQL alternatives in benchmarks and real applications, primarily because of fundamental architectural choices.
[IMG: control]
[H3] You’re In Control
Choose between synchronous or asynchronous replication for each update. Highly available asynchronous operations are optimized with features like Hinted Handoff and Read Repair.
[IMG: cloud native]
[H3] Security and Observability
The audit logging feature for operators tracks the DML, DDL, and DCL activity with minimal impact to normal workload performance, while the fqltool allows the capture and replay of production workloads for analysis.
[IMG: decentral]
[H3] Distributed
Cassandra is suitable for applications that can’t afford to lose data, even when an entire data center goes down. There are no single points of failure. There are no network bottlenecks. Every node in the cluster is identical.
[IMG: scalable]
[H3] Scalable
Read and write throughput both increase linearly as new machines are added, with no downtime or interruption to applications.
[IMG: elastic]
[H3] Elastic
Cassandra streams data between nodes during scaling operations such as adding a new node or datacenter during peak traffic times. Zero Copy Streaming makes this up to 5x faster without vnodes for a more elastic architecture particularly in cloud and Kubernetes environments.
[H2] Cassandra Users
Cassandra is used by thousands of companies with large active data sets.
"Netflix uses Apache Cassandra heavily to satisfy its ever-growing persistence needs on its mission to entertain the world. We have been experimenting and partially using the 4.0 beta in our environments and its features like Audit Logging and backpressure."
*– Vinay Chella, Netflix Engineering Manager *
“Humankind is at a pivotal point in history, that requires us to work together to find new innovative ways to process the petabytes of data we create every day, and the WitFoo R&D team has found a friend in Cassandra through our endeavors to meet big-data needs in cybersecurity operations.”
*– Charles Herring, CTO of WitFoo *
"Since 2016, application engineers at Bloomberg have turned to Cassandra because it’s easy to use, easy to scale, and always available. We serve up more than 20 billion requests per day on a nearly 1 PB dataset across a fleet of 1,700+ Cassandra nodes."
– Isaac Reath, Software Engineering Team Lead, NoSQL Infrastructure at Bloomberg
"We needed something that would handle really high write throughput and keep scaling on the write throughput. That forced us to look at distributed stores, and Apache Cassandra was the option that fitted what we needed."
– Elliott Sims Senior Systems Administrator, Backblaze
Read Case Studies
[H2] Cassandra Ecosystem
Our ecosystem includes a range of third-party Cassandra projects, tools, products, and services that may be useful to end users.
Go to Ecosystem
[H2] Community Spotlight
Here’s what the Cassandra community has been doing to advance the world’s premier open source NoSQL database.
[H3] Behind the scenes of an Apache Cassandra Release
Formalizing how we balance the need to evolve and provide cutting-edge features with long-term stability. The simple rules we use to decide when to merge and why we’ll be supporting three GA releases going forward, but why we’ve decided to support four releases for the next cycle.
Read More
[IMG: Behind the scenes of an Apache Cassandra Release]
[H3] Tightening Security for Apache Cassandra: Part 1
The growth in ecommerce has demanded a greater focus on data security. This is the start of a mini-series by Maulin Vasavada on how to customize SSL/TLS configurations to tighten security in Cassandra 4.0+.
Read More
[IMG: Tightening Security for Apache Cassandra: Part 1]
[H3] Inside Cassandra: an interview with Marcel Birkner at Instana
A new series that we’ve dubbed "Inside Cassandra" where we interview engineers and devs in the community either about their use of Apache Cassandra to power their businesses or how they contribute to the project. The first installation features an interview with Marcel Birkner, Site Reliability Engineer at Instana, and how they use Apache Cassandra to store and process metric data at scale and benefit from Cassandra’s fault tolerance, and have learned the importance of dog-fooding.
Read More
[IMG: Inside Cassandra: Marcel Birkner]
[H2] Upcoming ASF Events
Join the Cassandra community at the next ASF event.

[H1] Cassandra Community

[H2] Welcome to Cassandra
The Cassandra community includes people from around the globe who are developing and using the open source NoSQL database the world relies on. We welcome and encourage participation by everyone.
[H3] We Strive To:
Be open. Be empathetic, welcoming, friendly, and patient. Be collaborative. Be inquisitive. Be careful in the words we choose. Be concise. Step down considerately.
Read the Apache Code of Conduct and Reporting Guidelines.
[H2] Discussions
If you are a Cassandra user or if you want to learn more, we invite you to join these channels created specifically for end user questions and discussions.
Please read the guide on how to Ask Good Questions.
[H3] Q&A Forums
For questions about developing apps or need help operating Cassandra, post on the Stack network.
Before asking a good question, please search the forums to see if it has already been answered. Please always use the cassandra tag when asking questions. Please do not cross-post the same question to other channels such as Slack or the mailing lists.

For developer questions including data modeling, coding, drivers, or API issues, please ask on Stack Overflow.
Ask on Stack Overflow
Browse Questions

For admin or ops questions including installation, upgrades, backups, or repairs, please ask on DBA Stack Exchange.
Ask on Stack Exchange
Browse Questions

Show your support for the community and follow the cassandra tag by clicking on the blue Watch tag button on Stack Overflow and Stack Exchange!
[H3] User Mailing List
For broad, opinion-based questions, general discussions, ask how to get help, or receive announcements, please subscribe to the user mailing list. Security issues need to be reported to the Apache Security Team.
Before submitting a new question, please search the forums above or the mailing list archive to see if it has already been answered.
New to the Mailing List? Read the Archives.
subscribe
unsubscribe
[H3] User Slack
To meet other users and developers, participate in general discussions and get involved with the project.
Sign up for an ASF Slack account
Those who wish to contribute to the project or want to stay up-to-date on Cassandra development should join these channels.
[H3] Developer Mailing List
Contributor discussions related to the development of the Cassandra project.
New to the Developer Mailing List? Read the Archives.
subscribe
unsubscribe
[H3] Commits Mailing List
Notification on commits done to the source repository and on JIRA updates. This is a fairly noisy mailing list mostly useful for Cassandra developers and those who would like to keep close tabs on Cassandra’s development.
New to the Commits Mailing List? Read the Archives.
subscribe
unsubscribe
[H3] Developer Slack
To participate and join the following channels.
Sign up for a Slack account

Strictly for questions or discussions related to Cassandra development.
#cassandra-dev

Results of automated test builds.
#cassandra-builds

Results of patch test builds.
#cassandra-builds-patches
[H3] Contributor Meetings
An informal meeting to create real-time collaboration for questions, issues and discussion.
learn more
[H3] Kubernetes SIG
A special interest group (SIG) to discuss the creation of a community-based operator to make it easy to run C* on K8s.
learn more
[H3] Social Media
Engage in discussions on social media.
BlueSky
Linked In
YouTube
[H2] Project Governance
Like all Apache projects, Cassandra is independently managed by its Project Management Committee (PMC). The Cassandra PMC is tasked with project management—especially technical direction, votes on new committers and PMC members for the project, and sets policies as well as formally voting on software product releases. Our guiding philosophies are to default to the dev list and “decide as a community,” and to favor PMC minimalism.
[IMG: ASF Project Independence Overview]
ASF Project Independence Overview
[IMG: Cassandra PMC Governance Overview]
Cassandra PMC Governance Overview
[IMG: ASF PMC Overview]
ASF PMC Overview
[IMG: The Apache Way]
The Apache Way
[H2] How to Contribute
[H3] Becoming a contributor
Contributors are individuals who contribute patches—source code, documentation, help on mailing lists, website—to Apache projects. While contributors do not have a specific governance role, they are crucial to the project’s success. Read the docs to learn how to contribute to Cassandra, and review our governance page to understand how we vote on code contributions.
[H3] Becoming a Committer
Committers are members of a project development community who have been granted write access to an Apache project. New committers and PMC members are elected by the Cassandra PMC based on merit. More on committers.
[H3] Reporting Bugs
If you encounter a problem with Cassandra, the first places to ask for help are the user mailing list and the #cassandra Slack channel.
If, after having asked for help, you suspect that you have found a bug in Cassandra, you should report it by opening a ticket through the Apache Cassandra JIRA tracking system. Please provide as much detail as you can on your problem. Don’t forget to indicate which version of Cassandra you are running and on which environment.
To create a JIRA account, please request it on the #cassandra or #cassandra-dev channels on ASF Slack, or on the user or dev mailing list.
[H3] Reporting a Vulnerability
To report a vulnerability for Cassandra, contact the Apache Security Team.
[H3] Proposing New Features
The Cassandra Enhancement Proposal (CEP) provides a process for the proposal, discussion and endorsement of new feature development in Cassandra. Anyone can initiate a CEP, but it should only be done if you have the intention and capability to complete the proposed change. Learn how to propose and shepherd a CEP.
[H2] Meet the Community
[IMG: pmc team]
[IMG: Cassandra Community]
Apache Cassandra Committee

[H1] Get Started with Apache Cassandra

[H2] Interested in getting started with Cassandra? Follow these instructions.
[H3] STEP 1: GET CASSANDRA USING DOCKER
You’ll need to have Docker Desktop for Mac, Docker Desktop for Windows, or similar software installed on your computer.
Apache Cassandra is also available as a tarball or package download.
docker pull cassandra:latest
[H3] STEP 2: START CASSANDRA
A Docker network allows us to access the container’s ports without exposing them on the host.
docker network create cassandra
docker run --rm -d --name cassandra --hostname cassandra --network cassandra cassandra
[H3] STEP 3: CREATE FILES
The Cassandra Query Language (CQL) is very similar to SQL but suited for the JOINless structure of Cassandra.
Create a file named data.cql and paste the following CQL script in it. This script will create a keyspace, the layer at which Cassandra replicates its data, a table to hold the data, and insert some data into that table:
-- Create a keyspace
CREATE KEYSPACE IF NOT EXISTS store WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : '1' };
-- Create a table
CREATE TABLE IF NOT EXISTS store.shopping_cart (
userid text PRIMARY KEY,
item_count int,
last_update_timestamp timestamp
);
-- Insert some data
INSERT INTO store.shopping_cart
(userid, item_count, last_update_timestamp)
VALUES ('9876', 2, toTimeStamp(now()));
INSERT INTO store.shopping_cart
(userid, item_count, last_update_timestamp)
VALUES ('1234', 5, toTimeStamp(now()));
[H3] STEP 4: LOAD DATA WITH CQLSH
The CQL shell, or cqlsh, is one tool to use in interacting with the database. We’ll use it to load some data into the database using the script you just saved.
docker run --rm --network cassandra -v "$(pwd)/data.cql:/scripts/data.cql" -e CQLSH_HOST=cassandra -e CQLSH_PORT=9042 -e CQLVERSION=3.4.7 nuvo/docker-cqlsh
Note: The cassandra server itself (the first docker run command you ran) takes a few seconds to start up. The above command will throw an error if the server hasn’t finished its init sequence yet, so give it a few seconds to spin up.
[H3] STEP 5: INTERACTIVE CQLSH
Much like an SQL shell, you can also of course use CQLSH to run CQL commands interactively.
docker run --rm -it --network cassandra nuvo/docker-cqlsh cqlsh cassandra 9042 --cqlversion='3.4.7'
This should get you a prompt like so:
Connected to Test Cluster at cassandra:9042.
[cqlsh 5.0.1 | Cassandra 5.0.6 | CQL spec 3.4.7 | Native protocol v5]
Use HELP for help.
cqlsh>
[H3] STEP 6: READ SOME DATA
SELECT * FROM store.shopping_cart;
[H3] STEP 7: WRITE SOME MORE DATA
INSERT INTO store.shopping_cart (userid, item_count) VALUES ('4567', 20);
[H3] STEP 8: CLEAN UP
docker kill cassandra
docker network rm cassandra
CONGRATULATIONS!
Hey, that wasn’t so hard, was it?
To learn more, we suggest the following next steps:
Read through the Cassandra Basics to learn main concepts and how Cassandra works at a high level.
To understand Cassandra in more detail, head over to the Docs.
Browse through the Case Studies to learn how other users in our worldwide community are getting value out of Cassandra.

[H1] Cassandra Basics

[H2] What is Apache Cassandra?
Cassandra is a NoSQL distributed database. By design, NoSQL databases are lightweight, open-source, non-relational, and largely distributed. Counted among their strengths are horizontal scalability, distributed architectures, and a flexible approach to schema definition.
NoSQL databases enable rapid, ad-hoc organization and analysis of extremely high-volume, disparate data types. That’s become more important in recent years, with the advent of Big Data and the need to rapidly scale databases in the cloud. Cassandra is among the NoSQL databases that have addressed the constraints of previous data management technologies, such as SQL databases.
[H3] Distribution provides power and resilience
[IMG: NoSQL Distributed Database]
One important Cassandra attribute is that its databases are distributed. That yields both technical and business advantages. Cassandra databases easily scale when an application is under high stress, and the distribution also prevents data loss from any given datacenter’s hardware failure. A distributed architecture also brings technical power; for example, a developer can tweak the throughput of read queries or write queries in isolation.
"Distributed" means that Cassandra can run on multiple machines while appearing to users as a unified whole. There is little point in running Cassandra as a single node, although it is very helpful to do so to help you get up to speed on how it works. But to get the maximum benefit out of Cassandra, you would run it on multiple machines.
Since it is a distributed database, Cassandra can (and usually does) have multiple nodes. A node represents a single instance of Cassandra. These nodes communicate with one another through a protocol called gossip, which is a process of computer peer-to-peer communication. Cassandra also has a masterless architecture – any node in the database can provide the exact same functionality as any other node – contributing to Cassandra’s robustness and resilience. Multiple nodes can be organized logically into a cluster, or "ring". You can also have multiple datacenters.
[H3] Want more power? Add more nodes
[IMG: scale their databases dynamically]
One reason for Cassandra’s popularity is that it enables developers to scale their databases dynamically, using off-the-shelf hardware, with no downtime. You can expand when you need to – and also shrink, if the application requirements suggest that path.
Perhaps you are used to Oracle or MySQL databases. If so, you know that extending them to support more users or storage capacity requires you to add more CPU power, RAM, or faster disks. Each of those costs a significant amount of money. And yet: Eventually you still encounter some ceilings and constraints.
In contrast, Cassandra makes it easy to increase the amount of data it can manage. Because it’s based on nodes, Cassandra scales horizontally (aka scale-out), using lower commodity hardware. To double your capacity or double your throughput, double the number of nodes. That’s all it takes. Need more power? Add more nodes – whether that’s 8 more or 8,000 – with no downtime. You also have the flexibility to scale back if you wish.
This linear scalability applies essentially indefinitely. This capability has become one of Cassandra’s key strengths.
[H3] Introducing partitions
[IMG: scales linearly]
In Cassandra, the data itself is automatically distributed, with (positive) performance consequences. It accomplishes this using partitions. Each node owns a particular set of tokens, and Cassandra distributes data based on the ranges of these tokens across the cluster. The partition key is responsible for distributing data among nodes and is important for determining data locality. When data is inserted into the cluster, the first step is to apply a hash function to the partition key. The output is used to determine what node (based on the token range) will get the data.
[IMG: Replication ensures reliability and fault tolerance]
When data comes in, the database’s coordinator takes on the job of assigning to a given partition – let’s call it partition 59. Remember that any node in the cluster can take on the role as the coordinator. As we mentioned earlier, nodes gossip to one another; during which they communicate about which node is responsible for what ranges. So in our example, the coordinator does a lookup: Which node has the token 59? When it finds the right one, it forwards that data to that node. The node that owns the data for that range is called a replica node. One piece of data can be replicated to multiple (replica) nodes, ensuring reliability and fault tolerance. So far, our data has only been replicated to one replica. This represents a replication factor of one, or RF = 1.
The coordinator node isn’t a single location; the system would be fragile if it were. It’s simply the node that gets the request at that particular moment. Any node can act as the coordinator.
[H3] Replication ensures reliability and fault tolerance
[IMG: multiple (replica) nodes]
One piece of data can be replicated to multiple (replica) nodes, ensuring reliability and fault tolerance. Cassandra supports the notion of a replication factor (RF), which describes how many copies of your data should exist in the database. So far, our data has only been replicated to one replica (RF = 1). If we up this to a replication factor of two (RF = 2), the data needs to be stored on a second replica as well – and hence each node becomes responsible for a secondary range of tokens, in addition to its primary range. A replication factor of three ensures that there are three nodes (replicas) covering that particular token range, and the data is stored on yet another one.
[IMG: distributed nature of Cassandra]
The distributed nature of Cassandra makes it more resilient and performant. This really comes into play when we have multiple replicas for the same data. Doing so helps the system to be self-healing if something goes wrong, such as if a node goes down, a hard drive fails, or AWS resets an instance. Replication ensures that data isn’t lost. If a request comes in for data, even if one of our replicas has gone down, the other two are still available to fulfill the request. The coordinator stores a “hint” for that data as well, and when the downed replica comes back up, it will find out what it missed, and catch up to speed with the other two replicas. No manual action is required, this is done completely automatically.
[IMG: The use of multiple replicas also has performance advantages]
The use of multiple replicas also has performance advantages. Because we aren’t limited to a single instance We have three nodes (replicas) that can be accessed to provide data for our operations, which we can load balance amongst to achieve the best performance.
Cassandra automatically replicates that data around your different data centers. Your application can write data to a Cassandra node on the U.S. west coast, and that data is automatically available in data centers at nodes in Asia and Europe. That has positive performance advantages – especially if you support a worldwide user base. In a world dependent on cloud computing and fast data access, no user suffers from latency due to distance
[H3] Tuning your consistency
[IMG: Available Partition-tolerant) database]
We’ve been talking a lot about distributed systems and availability. If you are familiar with CAP theorem, Cassandra is by default an AP (Available Partition-tolerant) database, hence it is “always on”. But you can indeed configure the consistency on a per-query basis. In this context, the consistency level represents the minimum number of Cassandra nodes that must acknowledge a read or write operation to the coordinator before the operation is considered successful. As a general rule, you will select your consistency level (CL) based on your replication factor.
[IMG: Available Partition-tolerant) database]
For the example below, our data is replicated out to three nodes. We have a CL=QUORUM (Quorum referring to majority, 2 replicas in this case or RF/2 +1) therefore the coordinator will need to get acknowledgement back from two of the replicas in order for the query to be considered a success.
As with other computing tasks, it can take some skill to learn to tune this feature for ideal performance, availability, and data integrity – but the fact that you can control it with such granularity means you can control deployments in great detail.
[IMG: Cassandra is deployment agnostic]
Ultimately, Cassandra is deployment agnostic. It doesn’t care where you put it – on prem, a cloud provider, multiple cloud providers. You can use a combination of those for a single database. That gives software developers the maximum amount of flexibility.