relational database &&nosql Database

In the past, we only needed to learn and use a database technology to do almost all of the database application development. Because the mature and stable relational database products are not many, and for you to choose the free version is even less, so the Internet domain basically chose the free MySQL database. In the rapid development of the WEB2.0 era, we found that the relational database in performance, scalability, rapid data backup and recovery, to meet the needs of the ease of use is not always good to meet our needs, we are increasingly inclined to choose the appropriate database based on the business scenario, as well as the integration of a variety of databases to use.

When we talk about whether to use NoSQL, you also need to understand that there are many types of nosql, and the right choice for NoSQL today is more challenging than choosing a relational database. Although the use of NoSQL is simple, but the choice is a troublesome thing, this is a lot of people are waiting for a reason.

categories of NoSQL

NoSQL is just a concept, and NoSQL databases are divided into many categories based on the data storage model and features.

Type	Section represents	Characteristics
Column Storage	Hbase Cassandra Hypertable	As the name implies, data is stored in columns. The biggest feature is the convenient storage of structured and semi-structured data, easy to do data compression, for a column or a few columns of the query has a very large IO advantage.
Document storage	Mongodb Couchdb	Document storage is typically stored in a JSON-like format, and the stored content is document-based. This also gives you the opportunity to index certain fields and implement certain functions of the relational database.
Key-value Storage	Tokyo cabinet/tyrant Berkeley DB Memcachedb Redis	You can quickly query to its value with key. In general, the format of the store regardless of the value of the full receipt. (Redis includes other features)
Diagram Storage	Neo4j Flockdb	The best storage for graphical relationships. The use of traditional relational databases to address the performance of poor, and design use is not convenient.
Object storage	Db4o Versant	The database is manipulated by object-oriented syntax, and data is accessed through objects.
XML database	Berkeley DB XML BaseX	Efficiently stores XML data and supports internal query syntax for XML, such as Xquery,xpath.

The above-mentioned NoSQL database types are not absolute, but are generally divided from the storage model. There is no absolute demarcation between them, and there is a case, such as the table type store of Tokyo Cabinet/tyrant, which can be understood as a document-type storage, Berkeley DB XML database was developed on the basis of Berkeley db.

NoSQL or relational database

Although the 09 appeared a more radical article "Relational database is dead", but we all know that the relational database is actually alive and well, you can not use the relational database. But it also illustrates the fact that the relational database has a bottleneck when it comes to processing WEB2.0 data.

So are we using NoSQL or relational databases? I don't think we need to have an absolute answer. We need to decide what we use based on our application scenario.

If a relational database works perfectly well in your scenario, and you're very good at using and maintaining relational databases, then I don't think you need to move to nosql at all, unless you're a guy who likes to toss. If you are in the key areas of data-based finance, telecommunications, and so on, you are using Oracle database to provide high reliability, and don't try NoSQL unless you encounter a particularly large bottleneck.

However, in WEB2.0 's website, most of the relational databases have bottlenecks. Both disk IO and database extensibility have taken a considerable amount of effort on the part of developers to optimize, such as sharding, master-slave replication, heterogeneous replication, and so on, but these jobs require increasingly high technical capabilities and are increasingly challenging. If you're going through these situations, then I think you should try NoSQL.

Choosing the right NoSQL

So many types of nosql, and each type of nosql has a lot to choose what type of NoSQL to use as our storage? This is not a very good answer to the question, there are many factors that affect our choice, and there may be a variety of choices, with the business scenario, changes in requirements may be selected. We often need to consider the following situations:

1. Data structure features. Includes structured, semi-structured, whether fields are possible to change, whether there are large text fields, and whether data fields can change.
2. Write features. Includes the insert scale, the update scale, whether a small piece of data is frequently updated, and the atomic update requirement.
3. Query features. Includes the criteria for the query, the scope of the query hotspot. For example, the user information query, may be random, and the news query is based on time, the more new more frequent.

NoSQL and relational database combination

In fact, NoSQL database is only a relational database in some aspects (performance, expansion) of a make up, single-function, NoSQL almost all the functions, in the relational database can be satisfied, so the choice of NoSQL reason is not functional. So, we will generally use NoSQL and relational database, each to take the director, need to use relational characteristics when we use a relational database, we need to use NoSQL features when we use NoSQL database, to the point.

For A simple example , such as the storage of user reviews, comments about the primary key ID, comment on the object aid, comment content, user uid and other fields. What we can be sure of is that the content of the commentary will not be queried in the database with where content= ', and the comment content is also a large text field. Then we can store the primary key ID, the Comment object aid, the user ID in the database, the comment content is stored in NoSQL, so that the database saves the storage content occupied disk space, thus saving a lot of Io, the content is also easier to do cache.

Query from MySQL for comment primary key ID list commentids=db.query ("Select ID from comments where aid= ' comment object id ' LIMIT 0,20 '); Retrieve comment Entity Data Commentslist=nosql.get (Commentids) from NoSQL based on the list of primary key IDs;

NoSQL instead of MySQL

In some applications, such as some configured relational key-value mapping storage, user name and password storage, session sessions storage, and so on, NoSQL can completely replace the MySQL storage. Not only has higher performance, but also more convenient development.

NoSQL as a cache server

In Mysql+memcached's architecture, we design our caches everywhere, including the design of expiration times, the real-time design of caches, the evaluation of cache memory size, cache hit ratios, and so on.

NoSQL databases generally have very high performance, and under most scenarios you don't have to consider building a layer of memcached caching for NoSQL at the code level. The NoSQL data itself has done quite a lot of optimization work on the cache.

Memcached This kind of memory cache server cache data size is limited by memory size, if you use NoSQL instead of memcached to cache the database, you can no longer be limited by memory size. Although there may be a small amount of disk IO read and write, it may be slower than memcached, but can be used to cache database query operations.

Risk Avoidance

Since NoSQL is a relatively new thing, especially if the NoSQL database we choose is not a very mature product, we may encounter unknown risks. In order to get the benefits of NoSQL, but also to consider risk aversion, how to get the fish and bear paw?

Now the practice of many companies in the industry is to backup data. Storing data in NoSQL also stores a copy of it in MySQL. The NoSQL database itself also needs to be backed up (cold and hot spares). Or you might consider using two NoSQL databases, which can be toggled after a problem (avoiding the tragedy of Digg using Cassandra).

Summary

This article is simply an analysis of how to choose from a MySQL and nosql perspective, as well as the use of fusion. In fact, when you choose NoSQL, you may also encounter concerns about the CAP principle, eventual consistency, and base thinking. Because when you use the MySQL architecture, you also encounter the above problems, so there is no elaboration.

Reference: http://www.cnblogs.com/sunli/archive/2011/01/24/nosql_or_relation.html

relational database &&nosql Database