Introdcution to Cassandra for RDB Folks
2 likes706 views
This document summarizes key differences between MySQL and Cassandra for users familiar with MySQL. It notes that Cassandra uses a similar but scaled down query language called CQL instead of SQL. While CQL and data types like tables and databases have different names in Cassandra, the syntax is generally similar. However, Cassandra does not support features like joins, aggregates or expressions in queries. The document also explains Cassandra's data model and that writes are optimized for speed and scalability over consistency.
![And CREATE looks kinda similar
except...
CREATE COLUMNFAMILY...
● Never uses auto_increment
● Never uses NOT NULL
● Never uses DEFAULT
● Never uses array qualifiers [e.g. varchar(8)]
● Indexes “kludged” to a separate space](https://image.slidesharecdn.com/cassandra-141211175954-conversion-gate01/85/Introdcution-to-Cassandra-for-RDB-Folks-5-320.jpg)
Introdcution to Cassandra for RDB Folks
- 1. Cassandra for MySQL Folks Solomon Chang skevin521@yahoo.com
- 2. Cassandra as a NoSQL platform NoSQL has been retroactively re-acronymed as “Not Only SQL”. Cassandra uses its own query language, CQL. CQL has many aspects of SQL, but could be considered a scaled down version of Structured Query Language.
- 3. Cassandra sorta looks like MySQL except... ● Databases are called “Keyspaces” ● Tables are called “Column Families” ● Port 9160 instead of 3306 ● Client prompt called with cqlsh instead of mysql
- 4. And CQL looks kinda like SQL except... SQL CQL SHOW DATABASES DESCRIBE KEYSPACES CREATE DATABASE... CREATE KEYSPACE... CREATE TABLE... CREATE COLUMNFAMILY... SHOW CREATE TABLE... DESCRIBE COLUMNFAMILY...
- 5. And CREATE looks kinda similar except... CREATE COLUMNFAMILY... ● Never uses auto_increment ● Never uses NOT NULL ● Never uses DEFAULT ● Never uses array qualifiers [e.g. varchar(8)] ● Indexes “kludged” to a separate space
- 6. Getting used to new data types MySQL TEXT BIGINT BLOB BIT DECIMAL DOUBLE FLOAT INT ENUM TEXT TIMESTAMP VARCHAR CQL ASCII BIGINT BLOB BOOLEAN COUNTER DECIMAL DOUBLE FLOAT INET INT LIST MAP SET TEXT TIMESTAMP UUID TIMEUUID VARCHAR
- 7. Not all Data Types have a partner ● ENUM(x,y,z,etc.) ● DATE() ● DATETIME() ● TIME() ● YEAR()
- 8. CQL SELECTs do not: ● Support Joins ● Support aggregate functions (AVG, SUM, etc) ● Support expressions ● Seem to be satisfied with Double Quotes
- 9. But at least WHERE is still the same SELECT * FROM users WHERE fname = 'Solomon'; ^^^^^^^^^^^^^^^^^^ ● Except all fields referenced by WHERE must be indexed or primary key ● ...And all comparisons are strictly by EQ, not GT or LT
- 10. Inserts INSERT syntax is almost the same, except: ● A conflicting PK will replace the matching entry! ● You have to specify your own PK value. ● No SELECT statements for large groups of inserts. VALUE statements only!
- 11. Updates/Deletes UPDATE and DELETE are pretty much the same, except: ● No performing Joins on an UPDATE or DELETE ● WHERE clauses must reference a PK field
- 12. However, this frees up memory that might have been used on: ● A Join buffer ● A Sort buffer Or heaven forbid ● A query cache
- 13. Missing functionality offloaded to client side ● Sorts: large data sets cannot use ORDER BY. They must be sorted on the client. ● Aggregates: the client side will have to parse the data for records matching a certain criteria and perform the aggregate function on it. ● Joins: the client side will simply have to make additional calls to the database for records matching FKs.
- 14. So why use Cassandra? (Or any other NoSQL solution for that matter?) ● Speed ● Scalability
- 15. Cassandra for MySQL Folks Solomon Chang skevin521@yahoo.com