A comparison between NoSQL and relational databases

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.

Check out the list of comment primary key IDs from MySQL

Commentids=db.query ("Select ID from comments where aid= ' comment object id ' LIMIT 0,20 ');

Retrieve comment Entity data from NoSQL based on a list of primary key IDs

Commentslist=nosql.get (Commentids);

A comparison between NoSQL and relational databases