Cassandra
first look at the application’s needs, determine the required workflows, then map them to a number of queries, finally design a table around each query.
Notice how the two tables contain the same set of posts, but group them differently: table posts_by_user is partitioned by user, while table posts_by_room is partitioned by room - and the corresponding outputs reflect this fact. This is very much related to the fact that these two tables, in the data modeling process, were designed to answer two different questions, "what are the posts by user X?" and "what are the posts in room Y?" respectively. Moreover, within any partition in both tables, right as we required when creating the table, posts are kept (and displayed) sorted by decreasing post_id (which, due to the nature of TIMEUUIDs, implies a time-ordering as well).
That’s where UPDATE comes into play. The use case is as follows: in our chat app, users are allowed to edit their previous posts.
The final operation from our CRUD acronym is DELETE. This is the operation we use when we want to remove data from the database. In Apache Cassandra you can DELETE from the cell level all the way up to the partition (meaning I could remove a single column in a single row or I could remove a whole partition) using the same DELETE command.
Generally speaking, it’s best to perform as few delete operations as possible on the largest amount of data. Think of it this way, if you want to delete ALL data in a table, don’t delete each individual cell, just TRUNCATE the table. If you need to delete all the rows in a partition, don’t delete each row, DELETE the partition, and so on.
Get The Simple Learning’s stories in your inbox
Join Medium for free to get updates from this writer.
Partition Key, Clustering Column(Clustering columns are those columns that are part of the primary key, but are not the partition key.), No auto increment unique key like recreational database. Distributed databases does not have a concept of unique key. Technique to avoid collision, Querying Clustering Columns (only primary key and clustering columns are allow in where statement and that too in same order which is defined when creating the table)
Changing Default Ordering
Allow Filtering: causes to scan all partitions in the tables (DON’T USE IT). Also if you have database model that needs this option, think twice, you probably don’t.
Clustering Column: Help able to get the first/last record on top within a partition. Order_by
Node: How much a single node can handle?
A single node can handle 6000 to 12000 transactions/second/core, 2–4 TB data. If you want to more than that, need to tweak configuration.
Nodetool:
