Column-oriented
Traditional relational database is row-oriented. Each row has a row id and every field store in one table.
When searching in row-oriented database, each row will be traversed, no matter a certain column data is needed or not. If you search a person whose birth month is September. Row-oriented database will search this table from left to right then from top to down.
Index the target column can promote search speed, but index each column cause extra overload and databse will traverse all columns to search data.
Column-oriented database will stores each column seperately. It’s very fast to search when the data amount is small.
This design looks like adding index for each row. It sacrifices space and writing more index to speed up searching ability. Index maps row ID to data, but column-based database maps data to rowID. Like the picture above, it is easy to search who like archery. This is an inverted index.
When to use row-oriented and when to use column-oriented? Column-based database is easy to add one new column, but is difficult to add one row. Therefore, row-oriented database is bettern than column-based on transaction. Because it achieves real-time update. It is commonly used in marketing business.
Column-oriented database has advantage of data analysis, like sum of values. Batch processing can adopt column-oriented database at night, and it supports quick search and MapReduce aggregation.
Example: HBase, Cassandra
K/V stores
This is the easiest store in NoSQL databases.
the complex k/v paire is like:
Example: Redis, Amazon Dynamo
Document-oriented stores
Store based on K/V pair, but structure more complex.