How does Cassandra store data? – A simple explanation

Every time a record is inserted into Cassandra - it follows the write-path as per the diagram above. First, the record is written to a commit log (on disk). All records irrespective of schema tables  are written to the commit log. The commit log enables recovery of memtable in case of hardware failure. Second,  the … Continue reading How does Cassandra store data? – A simple explanation

Cassandra Migration Tips

#1. Cassandra allows creating a composite primary key (primary key consisting of more than one columns - first part being partition key and rest being clustering keys) For any queries using a composite pk column without including all of its partitioning key columns will require an index for lookup. For example: CREATE TABLE test.groupmechanism ( … Continue reading Cassandra Migration Tips

Migrating SQL applications to Cassandra – Strategy

Today's typical Java application consists of SQL statements defined either using Data Access Object pattern or Java Persistence Query Language (JPQL). These SQLs can be categorized into three categories: Simple SQL: These are one table SQLs like select * from Employee where employeeID=1 Simple multi-table SQL: These are simple SQLs but involve more than one … Continue reading Migrating SQL applications to Cassandra – Strategy

Migrating SQL applications to Cassandra – Pattern #3

Pattern #3: Get rid of all NOT operators from sql where clauses. For example, consider a typical SQL query to find all employees who have NOT completed a mandatory information security training: select ee1.* from employee ee1 where NOT exists (     select ‘true’ from employee_training et1     where et1.employeeID = ee1.employeeID     and … Continue reading Migrating SQL applications to Cassandra – Pattern #3

Migrating SQL applications to Cassandra – Pattern #2

Pattern #2: Get rid of all EXISTS and IN from sql where clauses. For example, consider a typical SQL query to find all employees who have completed a mandatory information security training: select ee1.* from employee ee1 where exists (     select 'true' from employee_training et1     where et1.employeeID = ee1.employeeID     and … Continue reading Migrating SQL applications to Cassandra – Pattern #2

Ohioedge 2.0 Architecture

Ohioedge 2.0 is a linearly scalable, no single point of failure (SPOF) architecture built using Cassandra, Zookeeper and Kafka. In addition, Ohioedge document component uses pithos.io service to save/retrieve documents from the underlying Cassandra data store. At the core of Ohioedge is a schema-driven request-to-response transformation engine - Ohioedge Builder. Out-of-the-box it enables CRUD and relationship … Continue reading Ohioedge 2.0 Architecture