Key-Value Database
Applicable cases
Now let's talk about a few things that are appropriate for using key-value databases.
1 Memory-Touch Session information
Typically, each network session is unique, so the session ID values assigned to them are also different. If the application originally wanted to put the session ID on disk or in a relational database, it would benefit a lot after migrating it to a key-value database, since all session content could be stored with a PU T request, and only one get request could be made. This "single Request Operation" (Single-request operation) is fast because all the information in the session is placed in an object. Many Web applications use solutions such as memcached. If availability is important, use Riak.
2 User Configuration information
Almost every user has Userld, usemame, or other unique attributes, and their configuration information is separate, such as language, color, time zone, products visited, and so on. These can all be placed in an object so that all of the configuration information for a user is obtained with a single get operation. Similarly, product information can be stored in this way.
3 Shopping Cart Data
Users of e-commerce sites are bound to their shopping carts. Because the contents of the shopping cart should be consistent in different times, different browsers, different computers, and different sessions, the shopping information can be placed in the Value property and bound to the UserID key name. Such applications are best used with Riak clusters.
non-applicable occasions
The key-value database is not the best solution in some situations.
1 Relationship between data
If you want to not establish a relationship between datasets or connect different sets of keywords, they are not the best choice even if some key-value databases provide functionality such as link traversal.
2 transactions that contain multiple operations
A key-value database is not the best solution if you save multiple key-value pairs, one of which has an error, and you need to revert or back resist the rest of the operation.
3 Querying data
If you want to search for a keyword based on the value of a key pair, then the key value database is not ideal.
We cannot directly view the values in the key-value database unless you are using something like Riak search or a "search engine" such as Lucene or SOLR (indexing engines).
4 Operation keyword Collection
Because the key-value database can operate on only one key at a time, it cannot manipulate multiple keywords at the same time. If you need to manipulate multiple keywords, it is best to handle this problem on the client side.
Document Database
Applicable cases
1 Event Logging
The application has every need for event logging. In an enterprise-class solution, many different applications need to log events. The document database can save all of these different types of events and is used as the central data store for the event store. If the data type that the event captures is constantly changing, you should use the document database more. You can also "Shard" by the application name of the triggering event, or by an event type such as order processed or customer_logged E.
2 Content management system and Bo kiln platform
Because the document database does not have a "preset schema" (predefined schema) and usually supports JSON, they are well suited for use in the Content management system and Web publishing programs, as well as to manage user reviews, User registration, user landscape, and Web document-oriented.
3 website analysis and real-time analysis
The document database can store real-time analytics data. Because it is possible to update only part of the document content, it is convenient to use it to store "page views" or "independent visitors" (Unique v isitor) and add metrics without changing the schema.
4 E-commerce applications
E-commerce applications typically require more flexible patterns to store products and orders. At the same time, they also need to evolve their data models without doing Gao Hubon database refactoring and data migration (see section 1 2.3).
non-applicable occasions
In some cases the document database well is not the best solution.
1 complex transactions with multiple operations
The document database may not be suitable for "atomic operations across Documents" (Atomic cross-document operation), but document databases like RAVENDB actually support such operations.
2 querying a continuously changing aggregation structure
A flexible pattern means that the database does not impose any restrictions on the schema. The data is stored in the form of an "application entity" (Application entity). If you want to query these continuously changing entities on the fly, the query commands you use will have to change constantly (in the relational database terminology, it is: The table to be connected is changing when you use the JOIN statement to connect the data table to the query criteria). Since the data is kept in the aggregation, if the aggregation design continues to change, then the aggregation needs to be preserved at the "lowest granularity" (lowest level of granularity), which is actually equivalent to unifying the data format. In this case, the document database may not be appropriate.
Column Family Database
Applicable cases
Now discuss several issues that are appropriate for the column family database.
1 Event Logging
Because the column family database can hold arbitrary data structures, it is ideal for storing event information such as application state or errors encountered during a run. In an enterprise-wide environment, all applications can write events to the Cassandra database. They can use the Appname:timestamp (application name: timestamp) as the row key and the columns they need. Because Cassa Ndra has an extensible writer capability, it works well in the event logging system (see Figure 1 0.2).
2 Content management system and Bo kiln platform
Using the column family, you can place attributes such as tag, category (Catelog〉, link, and Mckback) in different columns. " Comment information can be placed on the same line as above, or it can be moved to another "key space". Similarly, blog users and actual posts can be stored in different column families.
3 counter
In a Web application, it is common to count the number of visitors to a page and classify it to calculate the analytical data.
You can use Countercolum NType to create a column family.
CREATE COLUMN FAMILY Visit counter
With Default_validation_class=countercolumntype
and Key--va l Ida t Loriecla Sszutf8type and C. Mpara T. R=utf8type J
After you create a column family, you can use any column to record the number of times each user accesses each page in a network application.
INCR visit counter[' mfowler ' 1 [home] by 1;
INCR visit counter[' mfow1er '] (products) by 1;
I NCR visit counter[' Mfowler ') (ContactUs) by 1;
You can also use C QL to increase the value of the counter:
UPDATE Visi t counter SET home = home + 1 WHERE key= ' Mfowler '
4 Period of Use
We may need to provide a trial version of the user or display a certain amount of time on the site. This
Functions can be done with "columns with Expiration Time" (expiring column). This column is automatically deleted by Cassandra after a given time limit. This time limit is called TTL (Time to Live, lifetime), in seconds. This column is deleted after the TTL has been specified for the length of time. If the program detects that the column does not exist, it can reclaim user access or remove the ad bar.
SET Customer (' Mfowler ') (' demo access ') = ' allowed ' with ttl=2592000;
non-applicable occasions
There are some problems with the column family database to solve is not the best choice, such as the "ACID transaction" to perform write and read operations of the system. If you want the database to aggregate data based on the results of the query (for example, Sum or AVG), you have to read each row of data to the client and perform the operation here. It is not appropriate to use Cassandra when developing an early prototype or just starting to test a technical solution. The change of query pattern cannot be determined at the beginning of development, and the design of the column family should be modified when the query pattern changes. This will hinder the work of the Product innovation Team and reduce the developer's production capacity. In the relational database, the cost of modifying the data schema is very high, which reduces the cost of modifying the query mode. Cassandra, by contrast, changes its query pattern to a higher cost than changing its data schema.
Graph database
Applicable cases
Let's talk about some of the use cases suitable for working with graph databases.
1 Connected data
Deploying and using a graph database to process social networks is highly efficient. There is not only a "friend" relationship in the social graph, for example, they can also be used to represent the knowledge of employees, employees, and the positions of employees and other employees in different projects. Any area rich in link relationships is well suited to be represented in a graph database. As a database contains domain entities in different domains (such as social, space, business, etc.), and these entities are related, the cross-domain traversal capabilities provided by the graph database can make these relationships more valuable.
.2 arranging transport routes, dispatching goods and location-based services
Each location or address in the delivery process is a node that can be modeled as a node graph by all the nodes that deliver the goods. Inter-node relationships can have distance attributes for efficient delivery of goods. The distance and location properties are also available in the landmarks (graph of places of interest) so that the application can recommend good restaurants and entertainment venues nearby. You can also make point of sales at a bookstore, restaurant, and so on, and notify users when they are close to provide location-based services.
3 Recommended Engines
When you create nodes and relationships in your system, you can use them to recommend information to your customers, such as "Your friends have bought this product" or "When you invoice these items, you will usually be invoiced for those items as well". You can also use them to suggest to travelers that people who come to Barcelona will usually go to see Anthony · The architecture designed by Gaudí. When using the graph database to recommend information, there is a side effect worth noting: As the data is more quantitative, the number of nodes and relationships used in the recommendation information also increases. The same data can unearth different information. For example, you can see that the customer always buys it with the product, and can also identify the remaining products that are invoiced with the product. If the two do not match, you can issue a warning. Because the database is like other "recommendation engines" (recommendation engine), transaction fraud can also be detected based on patterns between relationships (fraud in transaction).
non-applicable occasions
The graph database may not be applicable in some cases. This is the case when updating an entity in all or a subset. For example, in a "Data analysis solution" (analytics solution), all entities have to be updated as soon as one attribute is changed. The effect of the graph database is not ideal, because the simple operation can change a property in all nodes at once. Even if the data model is appropriate for the problem domain, some graph databases may not be able to handle that large data disk, especially when performing global graph operation, which involves the operation of the entire graph.
Summary of scenarios for four types of NoSQL databases
