Key-Value Database |
Key-value databases are like hash tables used in traditional languages. You can use keys to add, query, or delete data. Because primary key access is used, the performance and scalability are good. |
Riak, Redis, Memcached, Amazon's Dynamo, Project Voldemort |
GitHub (Riak), BestBuy (Riak), Twitter (Redis and Memcached), StackOverFlow (Redis), Instagram (Redis), Youtube (Memcached), Wikipedia (Memcached) |
Stores user information, such as sessions, configuration files, parameters, and shopping carts. This information is generally linked to the ID (key). In this case, the key-value database is a good choice. |
1. Instead of querying by key, you can query by value. The Key-Value database does not use the Value query method at all. 2. The relationship between data needs to be stored. In the Key-Value database, two or more keys cannot be used to associate data. 3. transaction support. Rollback cannot be performed when a fault occurs in the Key-Value database. |
Document-Oriented database |
Document-oriented databases store data as documents. Each document is a self-contained data unit and a collection of data items. Each data item has a name and a corresponding value. The value can be either a simple data type, such as a string, number, or date, or a complex type, such as an ordered list and associated objects. The minimum unit of data storage is document. The document attributes stored in the same table can be different. data can be stored in XML, JSON, JSONB, and other forms. |
MongoDB, CouchDB, RavenDB |
SAP (MongoDB), Codecademy (MongoDB), Foursquare (MongoDB), and NBC News (RavenDB) |
1. logs. In an enterprise environment, each application has different log information. The Document-Oriented database does not have a fixed mode, so we can use it to store different information. 2. Analysis. Given its weak pattern structure, you can store different measurement methods and add new measurements without changing the pattern. |
Add transactions on different documents. The Document-Oriented database does not support inter-Document transactions. If you have requirements for this, you should not choose this solution. |
Column Store (Wide Column Store/Column-Family) Database |
The column storage database stores data in the column family. A column family stores data that is frequently queried together. For example, if we have a Person class, we usually query their names and ages together rather than their salaries. In this case, the name and age are put into one columnfamily, while the salary is in another columnfamily. |
Cassandra, HBase |
Ebay (Cassandra), Instagram (Cassandra), NASA (Cassandra), Twitter (Cassandra and HBase), Facebook (HBase), Yahoo! (HBase) |
1. logs. Because we can store data in different columns, each application can write information to its own column family. 2. blog platform. Each information is stored in different columns. For example, a tag can be stored in one, a category can be stored in one, and an article can be stored in another. |
1. If ACID transactions are required. Vassandra does not support transactions. 2. prototype design. If we analyze Cassandra's data structure, we will find that the structure is based on the expected data query method. At the beginning of model design, it was impossible to predict the query method. Once the query method changed, we had to redesign the column family. |
Graph (Graph-Oriented) Database |
Graph database allows us to store data in graphs. Objects are used as vertices, while relations between entities are used as edges. For example, if we have three entities: Steve Jobs, Apple, and Next, there will be two "Founded by" sides connecting Apple and Next to Steve Jobs. |
Neo4J, Infinite Graph, OrientDB |
Adobe (Neo4J), Cisco (Neo4J), T-Mobile (Neo4J) |
1. In some highly correlated data 2. recommendation engine. If we present the data in the form of graphs, it will be very beneficial for recommendation formulation. |
Unsuitable data model. Graph databases have a small scope of application, because few operations involve the entire graph. |