Why many refer to Cassandra as a Column oriented database?

Question

Reading several papers and documents on internet, I found many contradictory information about the Cassandra data model. There are many which identify it as a column oriented database, other as a row-oriented and then who define it as a hybrid way of both.

According to what I know about how Cassandra stores file, it uses the *-Index.db file to access at the right position of the *-Data.db file where it is stored the bloom filter, column index and then the columns of the required row.

In my opinion, this is strictly row-oriented. Is there something I'm missing?

Humus

Answer 1

• If you take a look at the Readme file at Apache Cassandra git repo, it says that,

Cassandra is a partitioned row store. Rows are organized into tables with a required primary key.

Partitioning means that Cassandra can distribute your data across multiple machines in an application-transparent matter. Cassandra will automatically repartition as machines are added and removed from the cluster.

Row store means that like relational databases, Cassandra organizes data by rows and columns.

• Column oriented or columnar databases are stored on disk column wise.

  e.g: Table Bonuses table

    ID         Last    First   Bonus
    1          Doe     John    8000
    2          Smith   Jane    4000
    3          Beck    Sam     1000
  

• In a row-oriented database management system, the data would be stored like this: 1,Doe,John,8000;2,Smith,Jane,4000;3,Beck,Sam,1000;

• In a column-oriented database management system, the data would be stored like this:
  1,2,3;Doe,Smith,Beck;John,Jane,Sam;8000,4000,1000;

• Cassandra is basically a column-family store

• Cassandra would store the above data as,

     "Bonuses" : {
           row1 : { "ID":1, "Last":"Doe", "First":"John", "Bonus":8000},
           row2 : { "ID":2, "Last":"Smith", "First":"Jane", "Bonus":4000}
           ...
     }

• Also, the number of columns in each row doesn't have to be the same. One row can have 100 columns and the next row can have only 1 column.

• Read this for more details.

Hubing

this is the correct answer for me +1 for the effort – Abert

It would be good to point out that you can use different columns for each row in Cassandra (big-table), some of them may have even thousands of them while some could be limited to just one. – Cockeye

This is really good answer for me. I got some confusion about row id, row key and primary key. Are they the same thing? If you can answer this, I will really appreciate – Underfur

One thing is not clear in your Cassandra example. If the table (ColumnFamily) is "Bonuses" then what's the partition key? if it's "ID" then the example is incorrect. Each partition key should be distributed in a different node, therefore it should lead each row and shouldn't be nested inside it. – Nola

The main purpose of column oriented DB is to scan columns of data efficiently by storing column data contiguously. Cassandra does not store contiguous keys on the same node. This makes it impossible to perform any scan efficiently. – Petitioner

Answer 2

Yes, the "column-oriented" terminology is a bit confusing.

The model in Cassandra is that rows contain columns. To access the smallest unit of data (a column) you have to specify first the row name (key), then the column name.

So in a columnfamily called Fruit you could have a structure like the following example (with 2 rows), where the fruit types are the row keys, and the columns each have a name and value.

apple -> colour  weight  price variety
         "red"   100     40    "Cox"

orange -> colour    weight  price  origin
          "orange"  120     50     "Spain"

One difference from a table-based relational database is that one can omit columns (orange has no variety), or add arbitrary columns (orange has origin) at any time. You can still imagine the data above as a table, albeit a sparse one where many values might be empty.

However, a "column-oriented" model can also be used for lists and time series, where every column name is unique (and here we have just one row, but we could have thousands or millions of columns):

temperature ->  2012-09-01  2012-09-02  2012-09-03 ...
                40          41          39         ...

which is quite different from a relational model, where one would have to model the entries of a time series as rows not columns. This type of usage is often referred to as "wide rows".

Forenoon

That's exactly the point! It perfectly explains the difference. In such way, Cassandra could be column oriented, but it depends on you use the column names. Thank you for make it clear! – Humus

You could demonstrate the column-orientedness by flipping the first table. Say the row key was "color", "weight", "price". Then the column names are the fruit types "apple", "orange", etc. – Vadim

Couldn't Cassandra be considered an EAV model? – Rosewater

Yes, I think there are similarities with EAV, particularly for my first example - but less so for the "wide rows" style of usage. – Forenoon

The first example appears very similar to documents in MongoDB. – Bestraddle

Answer 3

The most unambiguous term I have come across is wide-column store.

It is a kind of two-dimensional key-value store, where you use a row key and a column key to access data.

The main difference between this model and the relational ones (both row-oriented and column-oriented) is that the column information is part of the data.

This implies data can be sparse. That means different rows don't need to share the same column names nor number of columns. This enables semi-structured data or schema free tables.

You can think of wide-column stores as tables that can hold an unlimited number of columns, and thus are wide.

Here are a few links to back this up:

• This MongoDB article
• This Datastax article mentions it too, although it classifies Cassandra as a key-value store.
• This db-engines article
• This 2013 article
• Wikipedia

Rosewater

Answer 4

You both make good points and it can be confusing. In the example where

apple -> colour  weight  price variety
         "red"   100     40    "Cox"

apple is the key value and the column is the data, which contains all 4 data items. From what was described it sounds like all 4 data items are stored together as a single object then parsed by the application to pull just the value required. Therefore from an IO perspective I need to read the entire object. IMHO this is inherently row (or object) based not column based.

Column based storage became popular for warehousing, because it offers extreme compression and reduced IO for full table scans (DW) but at the cost of increased IO for OLTP when you needed to pull every column (select *). Most queries don't need every column and due to compression the IO can be greatly reduced for full table scans for just a few columns. Let me provide an example

apple -> colour  weight  price variety
         "red"   100     40    "Cox"

grape -> colour  weight  price variety
         "red"   100     40    "Cox"

We have two different fruits, but both have a colour = red. If we store colour in a separate disk page (block) from weight, price and variety so the only thing stored is colour, then when we compress the page we can achieve extreme compression due to a lot of de-duplication. Instead of storing 100 rows (hypothetically) in a page, we can store 10,000 colour's. Now to read everything with the colour red it might be 1 IO instead of thousands of IO's which is really good for warehousing and analytics, but bad for OLTP if I need to update the entire row since the row might have hundreds of columns and a single update (or insert) could require hundreds of IO's.

Unless I'm missing something I wouldn't call this columnar based, I'd call it object based. It's still not clear on how objects are arranged on disk. Are multiple objects placed into the same disk page? Is there any way of ensuring objects with the same meta data go together? To the point that one fruit might contain different data than another fruit since its just meta data or xml or whatever you want to store in the object itself, is there a way to ensure certain matching fruit types are stored together to increase efficiency?

Larry

Stingy

I think the point is that in Cassandra columns can have a double usage. It stores for each row the ordered list of couples which are composed by the column name and column value. It means you can make your column family Fruits with key the fruit name and the columns you said. In the other hand, you can also define a cf fruit_cols which has as key the colors and the names of the fruit of that color as columns . In such way they would be stored in the same page. I think this could be considered a columnar approach. isn't? – Humus

Answer 5

Column Family does not mean it is column-oriented. Cassandra is column family but not column-oriented. It stores the row with all its column families together.

Hbase is column family as well as stores column families in column-oriented fashion. Different column families are stored separately in a node or they can even reside in different node.

Shahjahanpur

Answer 6

IMO that's the wrong term used for Cassandra. Instead, it is more appropriate to call it row-partition store. Let me provide you some details on it:

Primary Key, Partitioning Key, Clustering Columns, and Data Columns:

Every table must have a primary key with unique constraint.

Primary Key = Partition key + Clustering Columns

# Example
Primary Key: ((col1, col2), col3, col4)     # primary key uniquely identifies a row
                                            # we need to choose its components partition key
                                            # and clustering columns so that each row can be
                                            # uniquely identified
Partition Key: (col1, col2)                 # decides on which node to store the data
                                            # partitioning key is mandatory, and it
                                            # can be made up of one column or multiple
Clustering Columns: col3, col4              # decides arrangement within a partition
                                            # clustering columns are optional

Partition key is the first component of Primary key. Its hashed value is used to determine the node to store the data. The partition key can be a compound key consisting of multiple columns. We want almost equal spreads of data, and we keep this in mind while choosing primary key.

Any fields listed after the Partition Key in Primary Key are called Clustering Columns. These store data in ascending order within the partition. The clustering column component also helps in making sure the primary key of each row is unique.

You can use as many clustering columns as you would like. You cannot use the clustering columns out of order in the SELECT statement. You may choose to omit using a clustering column in you SELECT statement. That's OK. Just remember to sue them in order when you are using the SELECT statement. But note that, in your CQL query, you can not try to access a column or a clustering column if you have not used the other defined clustering columns. For example, if primary key is (year, artist_name, album_name) and you want to use city column in your query's WHERE clause, then you can use it only if your WHERE clause makes use of all of the columns which are part of primary key.

Tokens:

Cassandra uses tokens to determine which node holds what data. A token is a 64-bit integer, and Cassandra assigns ranges of these tokens to nodes so that each possible token is owned by a node. Adding more nodes to the cluster or removing old ones leads to redistributing these token among nodes.

A row's partition key is used to calculate a token using a given partitioner (a hash function for computing the token of a partition key) to determine which node owns that row.

Cassandra is Row-partition store:

Row is the smallest unit that stores related data in Cassandra.

Don't think of Cassandra's column family (that is, table) as a RDBMS table, but think of it as a dict of a dict (here dict is data structure similar to Python's OrderedDict):

• the outer dict is keyed by a row key (primary key): this determines which partition and which row in partition
• the inner dict is keyed by a column key (data columns): this is data in dict with column names as keys
• both dict are ordered (by key) and are sorted: the outer dict is sorted by primary key

This model allows you to omit columns or add arbitrary columns at any time, as it allows you to have different data columns for different rows.

Berns

Answer 7

Cassandra has a concept of column families(table), which originally comes from BigTable. Though, it is really misleading to call them column-oriented as you mentioned. Within each column family, they store all columns from a row together, along with a row key, and they do not use column compression. Thus, the Bigtable model is still mostly row-oriented.

Protolithic