I am new to NoSQL and have always heard of key-value DBs like Cassandra or Riak and expected their tables to literally have two columns: a key-col and a value-col. I just started working at a new shop where the senior engineers chose Cassandra as the main datastore and setup their own Cassandra cluster themselves. Based on the design and use of the tables, however, I'm beginning to suspect that we're not using Cassandra the right way; that is, the way its intended to be used (as a KV DB).The tables are all totally relational, just like a MySQL or Postgres DB, with non-key UUID columns in some tables acting as the primary keys for records in other tables. And the tables are wide, sometimes having 10+ columns and multiple columns making up the table key.However in Cassandra you can't do joins so the software is jumping through all of these ridiculous hurdles to treat the non-relational KV datastore as if it was relational, where the code queries the data for one table, and fetches a UUID (key) for the records it wants to JOIN to in another table, then it queries that second table for records with a matching UUID/key. To me this just seems crazy. I think I get the buzzphrase Code is king, but it just seems bonkers and wildly inefficient to be hitting the database multiple times and stitching the data together in the app layer...I feel like this means our data is actually relational and that we should be using some RDBMS.So all this to ask: Is this truly the way Cassandra was intended to be used, or should the tables truly be 2-column KV pairs, or is the proper use of Cassandra something else entirely?
Using key-value NoSQL DBs relationally
relational database;nosql;cassandra
If you use Cassandra and need to emulate a lot of JOIN's, then you are doing it wrong. The reason for such a data model is usually that you are following the habit you learned from relational databases and normalize your data as much as possible. This leads to data getting spread out over many tables. This is a bad idea in Cassandra, because you have no efficient way to JOIN these tables back together.The first thing one must learn when switching from relational databases to Cassandra is that you must not be afraid of data duplication. Redundancies in Cassandra data models are normal and often recommended. Let's take a simple invoice database, for example.An invoice in a relational database would have one entry in a table for the invoice head and several entries in another table for the invoice positions. In Cassandra you would drop the head-table and instead duplicate all that information from the head in all rows of the position-table.In a relational database, your invoice-table would likely have a column productId which is the primary key of another table Products. In Cassandra that Products table would likely still exist, but you would replicate all the fields from it which are relevant for invoices in the invoice position table. The goal of all this is that you can show an invoice to the user with all the relevant information by only making a single query on the invoice positions table.The result of this is that your tables in Cassandra tend to be far wider than in relational databases. A lot of small tables usually means that you need to query a lot of different tables to get the information you need. Yes, Cassandra is called a key-value database, but that doesn't mean that there is a size restriction for either keys or values or that values must not be more than one field. The values can be as large as you want.For further reading, I recommend the article Basic Rules of Cassandra Data Modeling by DataStax.