Approach
- There were > 900 Jiras associated with the 2.1 release
- Today I will go over them one by one
Cassandra 2.1 Overview
Contents
Approach
Approach
What we will do:
Forensic-Entomology
Loose definition: "The study of squashed bugs"
Forensic-Entomology
Current State: * Top 100 Jiras for 2.1
Contents
Methodology
Counters 2.0 CASSANDRA-4775
TL;DR:
2.0 counters == painful death — 2.1 counters still think twice.
There are more minor counter improvements in 2.1. And more pending for 3.0.
New Row Cache - Number of columns CASSANDRA-1956/CASSANDRA-2864/CASSANDRA-6487
Ryan Mcgure’s example:
CREATE TABLE status (
user text,
status_id timeuuid,
status text,
PRIMARY KEY (user, status_id))
WITH CLUSTERING ORDER BY (status_id DESC);
DTCS CASSANDRA-6602
Huge implications for Cassandra in terms of:
Read Shooky’s doc
Partially Off-heap memtables CASSANDRA-6689/CASSANDRA-6694
Move the cell name and buffer off (affects heap for large heaps and blobs):
memtable_allocation_type: offheap_buffers
Move the entire cell off heap:
memtable_allocation_type: offheap_objects
cassandra-stress 2.1 CASSANDRA-6146/CASSANDRA-7468
Incremental Repairs CASSANDRA-5351
-inc in your repairstools/bin/sstablerepairedset --is-repaired <sstable> but first verify using /tools/bin/sstablemetadata and looking at repairedAt.Impact on compaction:
Separate flush directory CASSANDRA-6357
flush_directoryIdea is to place flushes on a different drive, like we do today with the commitlog. Why?
User Defined Types CASSANDRA-5590
Refresher from Summitt:
User Defined Types CASSANDRA-5590
CREATE TYPE address (
street text,
city text,
zip int
);
CREATE TABLE user_profiles (
login text PRIMARY KEY,
first_name text,
last_name text,
email text,
addresses map<text, address>
);
User Defined Types CASSANDRA-5590
// Inserts a user with a home address
INSERT INTO user_profiles(login, first_name, last_name, email, addresses)
VALUES ('tsmith',
'Tom',
'Smith',
'tsmith@gmail.com',
{ 'home': { street: '1021 West 4th St. #202',
city: 'San Fransisco',
zip: 94110 }});
User Defined Types CASSANDRA-5590
// Adds a work address for our user
UPDATE user_profiles
SET addresses = addresses
+ { 'work': { street: '3975 Freedom Circle Blvd',
city: 'Santa Clara',
zip: 95050 }}
WHERE login = 'tsmith';
CREATE TYPE phone (
number text,
tags set<text>
);
// Add a 'phones' field to address that is a set of the 'phone' UDT above
ALTER TYPE address ADD phones set<phone>;
Read Sylvain’s post
Listen interface and RPC interface CASSANDRA-7417
#listen_interface: eth0 #rpc_interface: eth1
Contents
Methodology
counters++ CASSANDRA-6504
TL;DR:
2.0 counters == painful death — 2.1 counters still think twice.
Improvements and changes to counters:
1) Replicate on write is gone, now we have COUNTER_MUTATION
2) New configurable counter timeout
3) New counter cache
Note
There are more minor counter improvements in 2.1. And more pending for 3.0.
Warn on large batch sizes CASSANDRA-6487
Why? Monster batches hurt C*, even small unlogged batches can’t really help if they’re cross partitions.
Compare and Delete (CAD) CASSANDRA-5832
Allow LWT’s for delete.
Example:
DELETE FROM test1 WHERE k = 456 IF EXISTS
(Backported to 2.0)
2i for Collections CASSANDRA-4511
To create an index use the usual syntax (note when you index a map, you only index the Key not the Value):
CREATE INDEX keyword_index ON test2 (keywords);
For lists and sets:
SELECT * FROM myTable WHERE tags CONTAINS 'awesome';
For Maps (note you can only index the keys not the values):
select * from myTable where tags CONTAINS KEY 'awesome';
for indexing Map values or nested types see Future CASSANDRA-6382
Java 8 CASSANDRA-7028
Hot partitions CASSANDRA-7974
nodetool toppartitions <keyspace> <table> <duration> WRITES Sampler: Cardinality: ~0 (256 capacity) Top 10 partitions: Nothing recorded during sampling period... READS Sampler: Cardinality: ~0 (256 capacity) Top 10 partitions: Nothing recorded during sampling period...
Don’t start without JNA CASSANDRA-6575
Impact:
JVM_OPTS="$JVM_OPTS -Djna.tmpdir=/var/tmp"
Outlaw running -pr and -local repairs together CASSANDRA-7450
Not sure why this is labled as an Improvement. It’s a Bug! https://issues.apache.org/jira/browse/CASSANDRA-7248
Switch to logback CASSANDRA-5883
logback-test.xml or logback.xml
nodetool getlogginglevels
and
nodetool setlogginglevel <class> <level>
Bulk loading Improvements CASSANDRA-7405/CASSANDRA-3668
cqlsh uses python driver 6307
Netty performance things CASSANDRA-5663/CASSANDRA-6861/CASSANDRA-6236
Read Ariel’s blog
Contents
Methodology
Unique CF ID’s CASSANDRA-5202
A: Because the unique identifiers for tables were just the table name so you could read old data in some edge cases.
A: Actually, it’s much worse now because concurrent creates can break your cluster and mess up your data CASSANDRA-8387 also keep an eye out for CASSANDRA-9291
2.0:
/var/lib/cassandra/data/test/test$ ls test-test-jb-1-CompressionInfo.db test-test-jb-1-Index.db test-test-jb-1-TOC.txt test-test-jb-2-Filter.db test-test-jb-2-Summary.db test-test-jb-1-Data.db test-test-jb-1-Statistics.db test-test-jb-2-CompressionInfo.db test-test-jb-2-Index.db test-test-jb-2-TOC.txt test-test-jb-1-Filter.db test-test-jb-1-Summary.db test-test-jb-2-Data.db test-test-jb-2-Statistics.db
2.1:
/var/lib/cassandra/data/test/test-1262ef90ff3911e490a74f7807583d97# ls test-test-ka-1-CompressionInfo.db test-test-ka-1-Digest.sha1 test-test-ka-1-Index.db test-test-ka-1-Summary.db test-test-ka-1-Data.db test-test-ka-1-Filter.db test-test-ka-1-Statistics.db test-test-ka-1-TOC.txt
Hadoop releases CASSANDRA-5201
TL;DR:
We now use Twitter’s Elephant Bird to support multiple versions of Hadoop.
This means people can use hadoop1 and hadoop2 with C* (backported to 2.0)
Consistent range movements CASSANDRA-2434
Potential pitfall
Historical Cassandra Edge Case:
Pre 2434:
Post 2434:
Consistent range movements CASSANDRA-2434
A: Never fear, like everything C* this is configurable.
Procedural TL;DR: Turn off consistent range movements. In your cassandra-env.sh set:
JVM_OPTS="$JVM_OPTS -Dconsistent.rangemovement=false
see DOC-362 for details.
This actually broke PAXOS which was fixed CASSANDRA-8640 (backported into 2.0)
Hints & Metered Flusher private executors CASSANDRA-8285/CASSANDRA-8485
Put both hints and metered flushers on their own threads. That way they can’t get blocked!
Al Tobey has some awesome magic to make Hints DTCS
Flush on Truncate CASSANDRA-7511
2.0 Commitlog would continue to grow above the limit if you truncated a large table.
2.1 Now we flush after Truncate
Multiple clustering column Where-In clause CASSANDRA-6875
In thrift you used to be able to select multiple specific clustering keys in a single query.
Now in CQL we can do the following for parity: For the following table:
CREATE TABLE test ( k int, c1 int, c2 int, PRIMARY KEY (k, c1, c2) );
Code:
SELECT * FROM test WHERE k = 0 AND (c1, c2) IN ((0, 0), (1,1)) ;
Not sure why this is labled as a Bug! https://issues.apache.org/jira/browse/CASSANDRA-6875
Counter time bomb CASSANDRA-6405
TL;DR: 2.0 counters == painful death — 2.1 counters still think twice.
Idempotent — an operation that will continue to have the same outcome when executed multiple times.
C* is good at idempotent operations and counters are not, and will never be, idempotent. As a result there are accuracy and performance issues with counters.
2.0 fixes address a little bit of both.
Counter time bomb CASSANDRA-6405
Reasons for bad counter performance:
This ticket addresses incremental counter storage. As of 6405, we store final counter values at the commitlog. From the commitlog on, we make counters idempotent.
The final counter fix will not get done until 3.x CASSANDRA-6506
Counter time bomb CASSANDRA-6405
Reasons for bad counter accuracy:
DTCS Improvement CASSANDRA-8243
One of the big hitters of DTCS is that if you have TTL, you can expire entire SSTables for free (as in beer) thanks to CASSANDRA-5228
Unfortunately, conditions for expiry in 2.0 were unnecessarily strict limiting this significantly.
8243 loosens up the condition to maximize free sstable expiry! (backported to 2.0)
Note: For details on DTCS see Shooky’s Guide
Not sure why this is labeled as a bug! https://issues.apache.org/jira/browse/CASSANDRA-8243
10k column families CASSANDRA-6977
TL;DR:
¡¡¡It’s still a bad idea to have thousands of tables in C*!!!
Too many tables and too many keyspaces results in performance degradation for the table creation operation, regardless of whether the tables are separated into separate Keyspaces.
With 6977 performance goes from:
2.0
to 2.1
Linear wrt the number of tables in a keyspace
A: No! The memory allocation per table, the schema_columns issues/ CASSANDRA-9291, the compaction and repair pains still apply. Don’t do it!
Tuple type CASSANDRA-7248
Sylvain added this for the where in Thift parity ticket CASSANDRA-6875
You can use Tuples in tables now:
CREATE TABLE tupletable (k int PRIMARY KEY, t tuple<int, text, double>); INSERT INTO tupletable (k, t) VALUES ( 0, (3,'foo', 3.4))
Not sure why this is labled as a Bug! https://issues.apache.org/jira/browse/CASSANDRA-7248
Summary
From early field testing (Al Tobey):
THANK YOU
/