This document summarizes new features in Cassandra 3.0, including user defined functions, improved garbage collection, hints management, materialized views, and a new storage engine. User defined functions allow running custom Java or JavaScript functions on Cassandra data. The G1 garbage collector replaces older collectors for better performance and predictability. Hints are now written to files instead of using Cassandra as a queue. Materialized views automatically create and maintain secondary indexes. The new storage engine reduces data duplication and wasted space.

1. ©2013 DataStax Confidential. Do not distribute without consent.
@rustyrazorblade
Jon Haddad
Technical Evangelist, DataStax
Cassandra 3.0 Awesomeness
1

2. 2.2 Stuff First

3. User Defined Functions
• Apply functions to data in a table
• Defined as Java or Javascript
• Bring your own Python/Ruby
CREATE OR REPLACE
FUNCTION fLog (input double)
CALLED ON NULL INPUT
RETURNS double
LANGUAGE java AS
'return Double.valueOf(Math.log(input.doubleValue()));';

4. Functions in Action
cqlsh:test> create table blah2
( id double primary key,
name text );
cqlsh:test> insert into blah2 (id, name)
values (1.0334343, 'jon');
cqlsh:test> select flog(id) from blah2;
test.flog(id)
---------------
0.032888
(1 rows)

5. Aggregates
• Several built ins
• min(), max(), avg(), count(), sum()
• Can provide user defined aggregates
• Defined as Java or JavaScript
• Do not aggregate across partitions
• Enable in cassandra.yaml

6. Native JSON Support
INSERT INTO mytable
JSON '{"myKey": 0, "value": 0}'
SELECT JSON name, occupation
FROM users WHERE userid = 199;

7. 3.0 Stuff

8. G1GC
• Improvement over ParNew+CMS
• Hard to tune
• CASSANDRA-8150
• G1 has more predictable pauses
• Better latency
• Many new gen, many old gen
• G1 is adaptive to usage
E SO
SO E
O S
EE
Eden Old GenS0 S1

9. Improved vnode allocation
• Previous method was randomly allocate
• vnode problems
• increased sockets
• repairs take longer
• New clusters can allocate less (4-12)
• CASSANDRA-7032

10. Pre 3.0 Hints
• Cassandra is a pretty bad queue
• Pre 3.0 hints are a queue
• Generates lots of tombstones
• Can result in instability
CREATE TABLE system.hints (
target_id uuid,
hint_id timeuuid,
message_version int,
mutation blob,
PRIMARY KEY (target_id,
hint_id,
message_version)
) WITH COMPACT STORAGE
X X

11. 3.0 Hints
• CASSANDRA-9427
• Write hints to a file instead
• Removes overhead of compaction
• No longer using C* as a queue

12. Materialized Views

13. Cassandra Data Modeling
sensor_id timestamp value
1 1 1
1 2 2
2 1 2
2 2 1
create table sensor_data
( sensor_id int,
timestamp int,
value int,
primary key
(sensor_id, timestamp)
);

14. Cool… but…
• What if we want to query sensor
data by timestamp?
• We can't efficiently query on
timestamp
• Need to maintain 2 tables
• In 3.0, use materialized views
CREATE MATERIALIZED VIEW
sensor_by_value as
SELECT value,
timestamp, sensor_id
FROM sensor_data
WHERE value is not null
AND timestamp is not null
PRIMARY KEY (timestamp,
sensor_id,
value);

15. Materialized View
• Table managed for you
• Updated async behind the scenes
• Built automatically when created
• Can't be mixed w/ functions yet
• CASSANDRA-9664
cqlsh:test> select * from sensor_by_value;
timestamp | sensor_id | value
-----------+-----------+-------
1 | 1 | 1
1 | 2 | 2
2 | 1 | 2
2 | 2 | 1
(4 rows)
cqlsh:test> select * from sensor_by_value
where timestamp = 1;
timestamp | sensor_id | value
-----------+-----------+-------
1 | 1 | 1
1 | 2 | 2
(2 rows)

16. New Storage Engine

17. Pre 3.0
• Clustering keys are repeated for each cell
• Timestamps are repeated in each cell
• TTLS are.. you get the idea
• Rows are a bolted on construct, only
known by a convention
• Lots of wasted space
• Lots of repetition

18. Storage in 3.0
• Rows are a first class entity
• Timestamps and TTLS can be
stored on the Row
• Clustering keys are not repeated
• Conversion to iterators for
memory efficiency

19. ©2013 DataStax Confidential. Do not distribute without consent. 19