An Introduction to Cassandra - Oracle User Group

An Introduction to Cassandra - Oracle User Group

• 1.
  An Introduction toCassandra
• 2.
  • 18 Yearsof Data infrastructure management consulting • 200+ Top brands • 6000+ databases under management • Over 400 DBA’s, in 35 countries • Top 5% of DBA work force, 9 Oracle ACE’s, 2 Microsoft MVP’s, 1 Cassandra MVP • Oracle, Microsoft, MySQL, • Datastax partners, Netezza, • Hadoop and MongoDB plus • UNIX Sysadmin and Oracle apps 2© 2016. All Rights Reserved. About Pythian
• 3.
  •Cassandra Consultant •First contactwas 0.8 •Cassandra MVP & Datastax Certified Architect •Lisbon Cassandra Meetup •Passion for distributed systems •Loves a good challenge •Waterpolo is my sport •@cjrolo 3 About me
• 4.
  4 Cassandra 101 • Cassandrais a highly scalable distributed masterless noSQL database • Column Store Architecture • Log Structured Data • CAP Theorem • Eventually Consistent
• 5.
  Introduction • Cassandra isa highly scalable distributed masterless noSQL database • All nodes are the same, highly resilient
• 6.
  CAP Theorem • TheCAP theorem states that you have to pick two of Consistency, Availability, Partition tolerance: You can't have the three at the same time and get an acceptable latency… • … at any given moment. • Cassandra values Availability and Partitioning tolerance (AP). Tradeoffs between consistency and latency are tunable in Cassandra (Per request!). • Requests offer a tunable level of consistency, all the way from "writes never fail" to "block for all replicas to be readable".
• 7.
  Consistent Hashing • Ahash consists of one or more arithmetic operations on a piece of data – e.g. MD5, Murmur3 • We hash keys in an attempt to spread key hashes in a uniform manner for any given set of keys. • A consistent hash is one where the hash range is divided up into ranges called a map. • Once the map is defined a given key will always end up in the same map range.
• 8.
  Log Structured Data •Instead of rewriting records in place or storing records near each other based on key (clustering), just simply write new records, updates to records or deletes at the end of the file that holds the table. • Add an index so you can read the table randomly without loading the whole thing into memory • UPSERT people (1,”Jonathan”,”Ellis”); • UPSERT people (2,”Billy”,”Bosworth”); • UPSERT people (2,”William”,”Bosworth”); • DELETE people (1);
• 9.
  CRUD, ACID andCassandra • C* doesn’t really have CRUD. Update is a special case of Create, and Delete is not a real Delete. • C* is not ACID. C* doesn’t support transactions. • C* is BASE: Basically Available Soft-state Eventual consistency. • Different versions may live in the cluster at the same time. Eventually all the nodes will see the newest data.
• 10.
  Write Path
• 11.
  Read Path
• 12.
  Compaction and Repair •Compaction is a process that Cassandra uses to keep local data in check. • Tables are append only, so obsolete data will live with current data • Compaction “cleans the house” • Repair is a process that Cassandra uses to keep Cluster data in check: • Nodes can get out-of-sync (Hardware failure, network issues, etc…) • Repair makes sure every node have the latest data
• 13.
  CQL - CassandraQuery Language • CQL is not SQL • Very similar: • cqlsh> CREATE KEYSPACE sandbox WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', DC1 : 1}; • cqlsh> USE sandbox; • cqlsh:sandbox>CREATE TABLE data (id uuid, data text, PRIMARY KEY (id)); • cqlsh:sandbox> INSERT INTO data (id, data) values (c37d661d-7e61-49ea- 96a5-68c34e83db3a, 'testing'); • cqlsh:sandbox> SELECT * FROM data; • Abstracts from the user from the internal structure (Can be dangerous!) • Provides several benefits over older model (Thrift)
• 14.
  14 Cassandra vs Oracle •Scale up vs Scale out • High availability vs Continuous availability • Highly structured vs Semi-structured • Replication is easy
• 15.
  15 Data Distribution
• 16.
  16© 2015. AllRights Reserved. Cassandra is not RDBMS • You need to know your reads before you write • Replication Factor affects your availability, choose wisely! • Per operation consistency – All the way from "writes never fail" to "block for all replicas to be readable". • Update is a special case of Create, and Delete is not a real Delete.
• 17.
  17© The good, thebad and the ugly • The Good: – Distributed – No single point of failure – It's easy to use – You get to sleep at night! • The Bad: – SQL != CQL, can't just drop in • The Ugly – Not enough users!
• 18.
  18 Opportunities • New applications –loose data model avoids app re-writing, data migration, etc... • Augmentation • Scale out better • Have a data model that allows Cassandra to absorb high velocity data • Absorb traffic from several locations
• 19.
  19 Pitfalls! • Hardware isimportant – Get SSDs... • Cassandra "just works" – Can lead to overlooking how the system is performing • Cassandra is new and is changing fast!
• 20.
  20© 2015. AllRights Reserved. Q&A • Thanks for listening!