Cassandra is a distributed, column-oriented database designed to be highly scalable and fault-tolerant. It distributes data across nodes based on the partitioner, replicates data based on the replication strategy, and achieves consistency between replicas using a combination of hinted handoffs and read repair during reads and writes. Keyspaces contain column families which store rows of columns in a flexible schema-less data model that scales horizontally by adding more nodes.

1. Introduction to
Cassandra
Wellington Python User Group
Aaron Morton @aaronmorton
1/12/2010

2. Disclaimer.
This is an introduction not
a reference.

3. I may, from time to time
and for the best possible
reasons, bullshit you.

4. What do you already know
about Cassandra?

5. Get ready.

6. The next slide has a lot on
it.

7. Cassandra is a distributed,
fault tolerant, scalable,
column oriented data
store.

8. A word about “column
oriented”.

9. Relax.

10. It’s different to a row
oriented DB like MySQL.
So...

12. For now, think about keys
and values. Where each
value is a hash / dict.

13. {‘foo’ : {‘bar’ : ‘baz’,},}
{key : {col_name :
col_value,},}

14. Cassandra’s data model and
on disk storage are based
on the Google Bigtable
paper from 2006.

15. The distributed cluster
design is based on the
Amazon Dynamo paper
from 2007.

16. Easy.
Lets store ‘foo’ somewhere.

17. 'foo'

18. But I want to be able to
read it back if one machine
fails.

19. Lets distribute it on 3 of
the 5 nodes I have.

20. This is the Replication
Factor.
Called RF or N.

21. Each node has a token that
identifies the upper value of
the key range it is
responsible for.

22. #1
<= E
#5 #2
<= Z <= J
#4 #3
<= T <= O

23. Client connects to a
random node and asks it to
coordinate storing the ‘foo’
key.

24. Each node knows about all
other nodes in the cluster,
including their tokens.

25. This is achieved using a
Gossip protocol. Every
second each node shares
it’s full view of the cluster
with 1 to 3 other nodes.

26. Our coordinator is node 5.
It knows node 2 is
responsible for the ‘foo’
key.

27. #1
Client
<= E
#5 #2
<= Z 'foo'
#4 #3
<= T <= O

28. But there is a problem...

29. What if we have lots of
values between F and J?

30. We end up with a “hot”
section in our ring of
nodes.

31. That’s bad mmmkay?

32. You shouldn't have a hot
section in your ring.
mmmkay?

33. A Partitioner is used to
apply a transform to the
key. The transformed values
are also used to define the
range for a node.

34. The Random Partitioner
applies a MD5 transform.
The range of all possible
keys values is changed to a
128 bit number.

35. There are other
Partitioners, such as the
Order Preserving
Partitioner. But start with
the Random Partitioner.

36. Let’s pretend all keys are
now transformed to an
integer between 0 and 9.

37. Our 5 node cluster now
looks like.

38. #1
<= 2
#5 #2
<= 0 <= 4
#4 #3
<= 8 <= 6

39. Pretend our ‘foo’ key
transforms to 3.

40. #1
Client
<= 2
#5 #2
<= 0 "3"
#4 #3
<= 8 <= 6

41. Good start.

42. But where are the replicas?
We want to replicate the
‘foo’ key 3 times.

43. A Replication Strategy is
used to determine which
nodes should store replicas.

44. It’s also used to work out
which nodes should have a
value when reading.

45. Simple Strategy orders the
nodes by their token and
places the replicas
clockwise around the ring.

46. Network Topology Strategy
is aware of the racks and
Data Centres your servers
are in. Can split replicas
between DC’s.

47. Simple Strategy will do in
most cases.

48. Our coordinator will send
the write to all 3 nodes at
once.

49. #1
Client
<= 2
#5 #2
<= 0 "3"
#4 #3
"3" "3"

50. Once the 3 replicas tell the
coordinator they have
finished, it will tell the client
the write completed.

51. Done.
Let’s go home.

52. Hang on.
What about fault tolerant?
What if node #4 is down?

53. #1
Client
<= 2
#5 #2
<= 0 "3"
#4 #3
"3" "3"

54. After all, two out of three
ain’t bad.

55. The client must specify a
Consistency Level for each
operation.

56. Consistency Level specifies
how many nodes must
agree before the operation
is a success.

57. For reads is known as R.
For writes is known as W.

58. Here are the simple ones
(there are a few more)...

59. One.
The coordinator will only
wait for one node to
acknowledge the write.

60. Quorum.
N/2 + 1

61. All.

62. The cluster will work to
eventually make all copies
of the data consistent.

63. To get consistent behaviour
make sure that R + W > N.
You can do this by...

64. Always using Quorum for
read and writes.
Or...

65. Use All for writes and One
for reads.
Or...

66. Use All for reads and One
for writes.

67. Try our write again, using
Quorum consistency level.

68. Coordinator will wait for 2
nodes to complete the
write before telling the
client it has completed.

69. #1
Client
<= 2
#5 #2
<= 0 "3"
#4 #3
"3" "3"

70. What about when node 4
comes online?

71. It will not have our “foo”
key.

72. Won’t somebody please
think of the “foo” key!?

73. During our write the
coordinator will send a
Hinted Handoff to one of
the online replicas.

74. Hinted Handoff tells the
node that one of the
replicas was down and
needs to be updated later.

75. #1
Client
<= 2
#5 #2
<= 0 "3"
#4 #3
"3" "3"
send "3"
to #4

76. When node 4 comes back
up, node 3 will eventually
process the Hinted
Handoffs and send the
“foo” key to it.

77. #1
Client
<= 2
#5 #2
<= 0 "3"
#4 #3
"3" "3"

78. What if the “foo” key is
read before the Hinted
Handoff is processed?

79. #1
Client
<= 2
#5 #2
<= 0 "3"
#4 #3
"" "3"
send "3"
to #4

80. At our Quorum CL the
coordinator asks all nodes
that should have replicas to
perform the read.

81. The Replication Strategy is
used by the coordinator to
find out which nodes
should have replicas.

82. Once CL nodes have
returned, their values are
compared.

83. If the do not match a Read
Repair process is kicked off.

84. A timestamp provided by
the client during the write
is used to determine the
“latest” value.

85. The “foo” key is written to
node 4, and consistency
achieved, before the
coordinator returns to the
client.

86. At lower CL’s the Read
Repair happens in the
background and is
probabilistic.

87. We can force Cassandra to
repair everything using the
Anti Entropy feature.

88. Anti Entropy is the main
feature for achieving
consistency. RR and HH are
optimisations.

89. Anti Entropy is started
manually via command line
or Java JMX.

90. Great so far.

91. But ratemylolcats.com is
going to be huge.
How do I store 100 Million
pictures of cats?

92. Add more nodes.

93. More disk capacity, disk IO,
memory, CPU, network IO.
More everything.

94. Except.

95. Less “work” per node.

96. Linear scaling.

97. Clusters of 100+ TB.

98. And now for the data
model.

99. From the outside in.

100. A Keyspace is the container
for everything in your
application.

101. Keyspaces can be thought
of as Databases.

102. A Column Family is a
container for ordered and
indexed Columns.

103. Columns have a name,
value, and timestamp
provided by the client.

104. The CF indexes the
columns by name and
supports get operations by
name.

105. CF’s do not define which
columns can be stored in
them.

106. Column Families have a
large memory overhead.

107. You typically have few (<10)
CF’s in your Keyspace. But
there is no limit.

108. We have Rows.
Rows have a key.

109. Rows store columns in one
or more Column Families.

110. Different rows can store
different columns in the
same Column Family.

111. User CF
username => fred
key => fred
d_o_b => 04/03
username => bob
key => bob
city => wellington

112. A key can store different
columns in different
Column Families.

113. User CF
username => fred
key => fred
d_o_b => 04/03
Timeline CF
09:01 => tweet_60
key => fred
09:02 => tweet_70

114. Here comes the Super
Column Family to ruin it all.

115. Arrgggghhhhh.

116. A Super Column Family is a
container for ordered and
indexes Super Columns.

117. A Super Column has a
name and an ordered and
indexed list of Columns.

118. So the Super Column
Family just gives another
level to our hash.

119. Social Super CF
key => fred
following => {
bob => 01/01/2010,
tom => 01/02/2010}
followers => {
bob => 01/01/2010}

120. How about some code?