Cassandra

Think of the Cassandra column family as a map of map:

an outer map keyed by a row key, and an inner map keyed by a column key. Both maps are sorted.

• A map gives efficient key lookup, and the sorted nature gives efficient scans. In Cassandra, we can use row keys and column keys to do efficient lookups and range scans.
• The number of column keys is unbounded. In other words, you can have wide rows.
• A key can itself hold a value. In other words, you can have a valueless column.

Range scan on row keys is possible only when data is partitioned in a cluster using Order Perserving Partitioner(OOP). OOP is almost never used.

So you can think of the outer map as unsorted:

Map<RowKey, SortedMap<ColumnKey,ColumnValue>>

 

Think about query patterns up front, and design column family accordingly, because of its high-scale distributed nature.

It's important to understand and start with Entities and Relationships, then continue modeling around query patterns by de-normalizing and duplicating.

Some queries might be executed only a few thousand times, while others a billion times.

Also consider which queries are sensitive to latency and which are not.

 

Don't de-normalize if you don't need to. It's all about finding the right balance.

 

Even if you can batch your reads, they will still be slower because Cassandra (Coordinator node, to be specific) has to query each row separately underneath(usually from different nodes).

Batch read will help only by avoiding the round trip - which is good, so you should always try to leverage it.

 

Remember that there are many ways to model. The best way depends on your use case and query patterns.