Apache Cassandra 2.0
Download as PPTX, PDF6 likes6,397 views
Apache Cassandra 2.0 introduces significant improvements including CQL enhancements, lightweight transactions for strong consistency, and experimental triggers for asynchronous execution. The update supports better data management strategies, such as improved compaction methods and eager retries to enhance read performance. Additionally, it emphasizes developer productivity and high scalability, making it suitable for complex big data infrastructure needs.
![Lightweight Transactions
How do we use it?
Is isolated to the “partition key” for a CQL3 table
INSERT
IF NOT EXISTS
i.e. INSERT INTO users (username, email, full_name) values (‘hellocas',
cas@updateme.com', ‘Hello World CAS', 1) IF NOT EXISTS;
UPDATE
IF column = some_value
IF map[column] = some_value
The some_value is what you read or expected the value to be prior to your change
i.e. UPDATE inventory set orderHistory[(now)] = uuid, total[wharehouse13] = 7 where
itemID = uuid IF map[wherehouse13] = 8;
Conditional updates are not allowed in batches
The columns updated do NOT have to be the same as the columns in the IF clause.](https://image.slidesharecdn.com/jstein-131001101536-phpapp02/85/Apache-Cassandra-2-0-10-320.jpg)
Apache Cassandra 2.0
- 1. Apache Cassandra 2.0 http://www.stealth.ly Joe Stein
- 2. About me Tweets @allthingshadoop All Things Hadoop Blog & Podcast – http://www.allthingshadoop.com Watched 0.3 from a distance Tried to integrated C* into my stack using 0.4 and 0.5 and 0.6 0.7 was awesome! Expiring columns, live schema updates, hadoop output 0.8 things got more interesting with counters and I did our first prod deploy, partial 1.0 it all came together for us with compression, full deploy Cassandra in prod supported over 100 million daily unique mobile devices Born again into CQL3 Apache Kafka http://kafka.apache.org/ committer & PMC member Founder & Principal Consultant of Big Data Open Source Security LLC – http://www.stealth.ly BDOSS is all about the "glue" and helping companies to not only figure out what Big Data Infrastructure Components to use but also how to change their existing (or build new) systems to work with them. Working with clients on new projects using Cassandra 2.0
- 3. Apache Cassandra 2.0 Based on Big Table & Dynamo High Performance Reliable / Available Massively Scalable Easy To Use Developer Productivity Focused
- 4. What’s new in C* 2.0 Finalized some legacy items CQL Improvements Lightweight Transactions Triggers Compaction Improvements Eager Retries More, More, More!!!
- 5. Super Columns refactored to use composite keys instead
- 6. Virtual Nodes are the default
- 7. CQL Improvements Support for multiple prepared statements in batch Prepared statement for the consistency level, timestamp and ttl Add cursor API/auto paging to the native CQL protocol Support indexes on composite column components ALTER TABLE to DROP a column Column alias in SELECT statement SASL (Simple Authentication and Security Layer ) support for improved authentication Conditional DDL - Conditionally tests for the existence of a table, keyspace, or index before issuing a DROP or CREATE statement using IF EXISTS or IF NOT EXISTS Support for an empty list of values in the IN clause of SELECT, UPDATE, and DELETE commands, useful in Java Driver applications when passing empty arrays as arguments for the IN clause Imports and exports CSV (comma-separated values) data to and from Cassandra 1.1.3 and higher. COPY table_name ( column, ...) FROM ( 'file_name' | STDIN ) or TO ( 'file_name' | STDOUT ) WITH option = 'value' AND ...
- 8. Lightweight Transactions – Why? Cassandra can provide strong consistency with quorum reads & writes A write must be written to the commit log and memory table on a quorum of replica nodes. Quorum = (replication_factor / 2) + 1 (rounded down to a whole number) This is sometimes not enough when transactions need to be handled in sequence (linearized) or when operating concurrently achieve the expected results without race conditions. "Strong" consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create.
- 9. Lightweight Transactions - "when you really need it," not for all your updates. Prepare: the coordinator generates a ballot (timeUUID in our case) and asks replicas to (a) promise not to accept updates from older ballots and (b) tell us about the most recent update it has already accepted. Read: we perform a read (of committed values) between the prepare and accept phases. RETURNS HERE IF CAS failure Accept: if a majority of replicas reply, the coordinator asks replicas to accept the value of the highest proposal ballot it heard about, or a new value if no in-progress proposals were reported. Commit (Learn): if a majority of replicas acknowledge the accept request, we can commit the new value. The coordinator sends a commit message to all replicas with the ballot and value. Because of Prepare & Accept, this will be the highest-seen commit ballot. The replicas will note that, and send it with subsequent promise replies. This allows us to discard acceptance records for successfully committed replicas, without allowing incomplete proposals to commit erroneously later on. 1 second default timeout for total of above operations configured in cas_contention_timeout_in_ms For more details on exactly how this works, look at the code https://github.com/apache/cassandra/blob/cassandra- 2.0.1/src/java/org/apache/cassandra/service/StorageProxy.java#L202
- 10. Lightweight Transactions How do we use it? Is isolated to the “partition key” for a CQL3 table INSERT IF NOT EXISTS i.e. INSERT INTO users (username, email, full_name) values (‘hellocas', [email protected]', ‘Hello World CAS', 1) IF NOT EXISTS; UPDATE IF column = some_value IF map[column] = some_value The some_value is what you read or expected the value to be prior to your change i.e. UPDATE inventory set orderHistory[(now)] = uuid, total[wharehouse13] = 7 where itemID = uuid IF map[wherehouse13] = 8; Conditional updates are not allowed in batches The columns updated do NOT have to be the same as the columns in the IF clause.
- 11. Trigger (Experimental) Experimental = Expect the API to change and your triggers to have to be refactored in 2.1 … provide feedback to the community if you use this feature its how we make C* better!!! Asynchronous triggers is a basic mechanism to implement various use cases of asynchronous execution of application code at database side. For example to support indexes and materialized views, online analytics, push-based data propagation. Basically it takes a RowMutation that is occurring and allows you to pass back other RowMutation(s) you also want to occur triggers on counter tables are generally not supported (counter mutations are not allowed inside logged batches for obvious reasons – they aren’t idempotent).
- 12. Trigger Example https://github.com/apache/cassandra/tree/trunk/examples/triggers RowKey:ColumnName:Value to Value:ColumnName:RowKey 10214124124 – username = to joestein – username = 10214124124 CREATE TRIGGER test1 ON "Keyspace1"."Standard1" EXECUTE ('org.apache.cassandra.triggers.InvertedIndex'); Basically we are returning a row mutation from within a jar so we can do anything we want pretty much public Collection<RowMutation> augment(ByteBuffer key, ColumnFamily update) { List<RowMutation> mutations = new ArrayList<RowMutation>(); for (ByteBuffer name : update.getColumnNames()) { RowMutation mutation = new RowMutation(properties.getProperty("keyspace"), update.getColumn(name).value()); mutation.add(properties.getProperty("columnfamily"), name, key, System.currentTimeMillis()); mutations.add(mutation); } return mutations; }
- 13. Improved Compaction During compaction, Cassandra combines multiple data files to improve the performance of partition scans and to reclaim space from deleted data. SizeTieredCompactionStrategy: The default compaction strategy. This strategy gathers SSTables of similar size and compacts them together into a larger SSTable This strategy is best suited for column families with insert-mostly workloads that are not read as frequently. This strategy also requires closer monitoring of disk utilization because (as a worst case scenario) a column family can temporarily double in size while a compaction is in progress.. LeveledCompactionStrategy: Introduced in Cassandra 1.0, this strategy creates SSTables of a fixed, relatively small size (5 MB by default) that are grouped into levels. Within each level, SSTables are guaranteed to be non-overlapping. Each level (L0, L1, L2 and so on) is 10 times as large as the previous. This strategy is best suited for column families with read-heavy workloads that also have frequent updates to existing rows. When using this strategy, you want to keep an eye on read latency performance for the column family. If a node cannot keep up with the write workload and pending compactions are piling up, then read performance will degrade for a longer period of time….
- 14. Leveled Compaction – in theory Reads are through a small amount of files making it performant Compaction happens fast enough for the new L0 tier coming in
- 15. Leveled Compaction – high write load This will cause read latency using level compaction when the tiered compaction can’t keep up with the writes coming in
- 16. Leveled Compaction Hybrid – best of both worlds
- 17. Eager Retries Speculative execution for reads Keeps metrics of read response times to nodes Avoid query timeouts by sending redundant requests to other replicas if too much time elapses on the original request ALWAYS 99th (Default) X percentile X ms NONE
- 18. Eager Retries – in action The JIRA for this test
- 19. More, More, More!!! The java heap and GC has not been able to keep pace with the heap to data ratio with the structures that C* has that can be cleaned up with manual garbage collection…. This was done initially started in 1.2 and finished up in 2.0. New commands to disable background compactions nodetool disableautocompaction and nodetool enableautocompaction Auto_bootstrapping of a single-token node with no initial_token Timestamp condition eliminates sstable seeks with sstable holding min/max timestamp for each file skipping unnecessary files Thrift users got a major bump in performance using a LMAX disruptor implementation Java 7 is now required Level compaction information is moved into the sstables Streaming has been rewritten – better control, traceability and performance! Removed row level bloom filters for columns Row reads during compaction halved … doubling the speed