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?