This is an introduction to the Apache Cassandra data model. For the benefit of those not familiar with Cassandra, it is an open source, highly scalable, highly available NoSQL database. Some key architectural highlights of Cassandra are :
No Single point of failure.
No Master - All servers in cluster are equal.
Peer to peer communication between nodes to exchange data and configuration.
Data is partitioned across nodes based on consistent hash.
Data is automatically replicated.
(and recently added) SQL like data access model.
Cassandra has moved to a simple model that is described by a SQL like language called CQL. Lower level constructs like column family are no longer mentioned. Note that earlier column family models were without much of a schema. You needed to define column family upfront. But the column name in each family could be added as needed. The new CQL model is more schema oriented.
1.0 Tables, row keys and columns
Data is stored in Tables which has rows and columns.
Table is partitioned by the primary key, which is the row key.
For columns , CQL supports various data type like int , varchar, text, float, Set , List and many more
The CQL create statement below creates the users table with userid as the primary key.
create Table Users (
userid varchar,
name varchar,
email varchar,
address varchar,
PRIMARY KEY(userid)
) ;
You insert rows into this table using the insert statement. Rows of table are partitioned across nodes based on the primary key.
insert into Users(userid,name,email) values('user1', 'user1 name', 'user1@gmail.com') ;
2.0 No Joins but wide columns
Let us say you want groups of users. In a RDBMS , you might have a table with columns, groupid and userid with userid being a foreign key into Users table. In a distributed database like Cassandra joins are expensive. Hence the data needs to be de-normalized. You can create a table GroupsOfUsers with groupid as the primary key. As de-normalization, in addition to having userid column, repeat some useful columns like user name and user email that you might need when looking at members of the group.
create Table GroupsOfUsers (
groupid varchar,
groupname varchar,
userid varchar,
user_name varchar,
user_email varchar
PRIMARY KEY(groupid,userid)
)
When you have a compound primary key, the first column, in this case group id is used as the partition key. The other columns, in this case userid is used to cluster the remaining columns by userid. Additionally, the columns in the row are sorted based of the other columns of the primary key, namely userid.
If you do ,
select * from GroupsOfUsers where groupid = "group1" ;
The result might be
group1 user1 name1 email1
group1 user2 name2 email2
group1 user3 name3 email3
Think of the above as logical rows.
Under the hood , the columns might be stored physically as 1 row with one or more columns for each user.
key column1 column2 column3 column4 column5 column6
group1 user1:name1 user1:email1 user2 :name2 user2:email1 user3:name3 user3:email3
Each row can have as many as 2 billion columns if necessary. This is very useful in other use cases such as creating indexes or storing collections.
3.0 Collection column types
If each user had a number of friends, in RDBMS, this would be modeled by joining with a Friends table. In Cassandra you can do that by adding a column type of Collection. The collections supported are List, Map and Set.
Alter Table Users add friends Set ;
insert into Users set friends = friends + {'friend6'} where userid = 'user1' ;
4.0 Indexes using wide columns
Index is a data structure that enables fast look up based on a Key. In Cassandra the table is partitioned across nodes based on the primary key. By default, each node in Cassandra maintains an index for the primary keys that it host.
You can create additional indexes on other columns. For such indexed columns, Cassandra under the hood creates another table whose primary key is the indexed column.
For example , if frequently had to do a query such as
select groupid from GroupOfUsers where userid = 'user1' ;
It could be worthwhile to create an index on userid column to speed up the query.
create index userid_index on GroupOfUsers(userid) ;
Logically this would be like creating a table
create table userid_idx (
userid varchar,
groupid varchar,
primary key(userid,groupid)
)
The partition key will be userid and the columns in the row will be the groups to which the user belong. This makes use of the wide column feature of Cassandra mentioned above.
5.0 Note on consistency
The original Dynamo paper on which Cassandra is based on, talks about being eventually consistent. Eventual consistency scares people even though we see it in life all the time. For example, the ATM may let you take more cash than you have in your account. When the bank reconciles ATM withdrawals with your account and realizes that you have overdrawn, it takes appropriate action.
Cassandra extends eventually consistency by offering a model of tunable consistency.
A write consistency of ANY means that it is enough for write to be written to any one node. This gives low consistency but high availability. A write consistency on ONE, TWO, THREE or QUORUM implies that writes need to be written to that many replicas. Higher the writes , more the consistency and less availability.
A read consistency of ONE, TWO, THREE, QUORUM indicates the number of replicas to be consulted before returning the most recent data from the replicas.
Note that unlike what is described in the Dynamo paper, when there is a conflict between data in replicas, Cassandra returns the most recent data and not vector clocks with different versions that clients need to resolve.
In summary, with CQL Cassandra provides a simple data model that makes it easier to model and develop applications. With CQL, Cassandra can be looked at as a viable alternative to a relational database when scalability and high availability are important. For additional details, the Cassandra documentation is at http://www.datastax.com/documentation/cassandra/2.0/webhelp/index.html
No Single point of failure.
No Master - All servers in cluster are equal.
Peer to peer communication between nodes to exchange data and configuration.
Data is partitioned across nodes based on consistent hash.
Data is automatically replicated.
(and recently added) SQL like data access model.
Cassandra has moved to a simple model that is described by a SQL like language called CQL. Lower level constructs like column family are no longer mentioned. Note that earlier column family models were without much of a schema. You needed to define column family upfront. But the column name in each family could be added as needed. The new CQL model is more schema oriented.
1.0 Tables, row keys and columns
Data is stored in Tables which has rows and columns.
Table is partitioned by the primary key, which is the row key.
For columns , CQL supports various data type like int , varchar, text, float, Set , List and many more
The CQL create statement below creates the users table with userid as the primary key.
create Table Users (
userid varchar,
name varchar,
email varchar,
address varchar,
PRIMARY KEY(userid)
) ;
You insert rows into this table using the insert statement. Rows of table are partitioned across nodes based on the primary key.
insert into Users(userid,name,email) values('user1', 'user1 name', 'user1@gmail.com') ;
2.0 No Joins but wide columns
Let us say you want groups of users. In a RDBMS , you might have a table with columns, groupid and userid with userid being a foreign key into Users table. In a distributed database like Cassandra joins are expensive. Hence the data needs to be de-normalized. You can create a table GroupsOfUsers with groupid as the primary key. As de-normalization, in addition to having userid column, repeat some useful columns like user name and user email that you might need when looking at members of the group.
create Table GroupsOfUsers (
groupid varchar,
groupname varchar,
userid varchar,
user_name varchar,
user_email varchar
PRIMARY KEY(groupid,userid)
)
When you have a compound primary key, the first column, in this case group id is used as the partition key. The other columns, in this case userid is used to cluster the remaining columns by userid. Additionally, the columns in the row are sorted based of the other columns of the primary key, namely userid.
If you do ,
select * from GroupsOfUsers where groupid = "group1" ;
The result might be
group1 user1 name1 email1
group1 user2 name2 email2
group1 user3 name3 email3
Think of the above as logical rows.
Under the hood , the columns might be stored physically as 1 row with one or more columns for each user.
key column1 column2 column3 column4 column5 column6
group1 user1:name1 user1:email1 user2 :name2 user2:email1 user3:name3 user3:email3
Each row can have as many as 2 billion columns if necessary. This is very useful in other use cases such as creating indexes or storing collections.
3.0 Collection column types
If each user had a number of friends, in RDBMS, this would be modeled by joining with a Friends table. In Cassandra you can do that by adding a column type of Collection. The collections supported are List, Map and Set.
Alter Table Users add friends Set
insert into Users set friends = friends + {'friend6'} where userid = 'user1' ;
4.0 Indexes using wide columns
Index is a data structure that enables fast look up based on a Key. In Cassandra the table is partitioned across nodes based on the primary key. By default, each node in Cassandra maintains an index for the primary keys that it host.
You can create additional indexes on other columns. For such indexed columns, Cassandra under the hood creates another table whose primary key is the indexed column.
For example , if frequently had to do a query such as
select groupid from GroupOfUsers where userid = 'user1' ;
It could be worthwhile to create an index on userid column to speed up the query.
create index userid_index on GroupOfUsers(userid) ;
Logically this would be like creating a table
create table userid_idx (
userid varchar,
groupid varchar,
primary key(userid,groupid)
)
The partition key will be userid and the columns in the row will be the groups to which the user belong. This makes use of the wide column feature of Cassandra mentioned above.
5.0 Note on consistency
The original Dynamo paper on which Cassandra is based on, talks about being eventually consistent. Eventual consistency scares people even though we see it in life all the time. For example, the ATM may let you take more cash than you have in your account. When the bank reconciles ATM withdrawals with your account and realizes that you have overdrawn, it takes appropriate action.
Cassandra extends eventually consistency by offering a model of tunable consistency.
A write consistency of ANY means that it is enough for write to be written to any one node. This gives low consistency but high availability. A write consistency on ONE, TWO, THREE or QUORUM implies that writes need to be written to that many replicas. Higher the writes , more the consistency and less availability.
A read consistency of ONE, TWO, THREE, QUORUM indicates the number of replicas to be consulted before returning the most recent data from the replicas.
Note that unlike what is described in the Dynamo paper, when there is a conflict between data in replicas, Cassandra returns the most recent data and not vector clocks with different versions that clients need to resolve.
In summary, with CQL Cassandra provides a simple data model that makes it easier to model and develop applications. With CQL, Cassandra can be looked at as a viable alternative to a relational database when scalability and high availability are important. For additional details, the Cassandra documentation is at http://www.datastax.com/documentation/cassandra/2.0/webhelp/index.html
No comments:
Post a Comment