Data storage in the Big Data era, non-relational database MongoDB (i)

The explosive development of NoSQL technology

　　

For a long time in the past, relational databases (relational database Management System) have been the most mainstream database solution, He uses things and relationships in the real world to explain the abstract data architecture in the database. However, in the explosive development of information technology today, big data has become the cloud computing, the Internet of things after the new technological revolution, relational database in the processing of large data volume has begun to struggle, developers can only through the continuous optimization of the database to solve the problem of data volume, but optimization is not a long-term solution, So a new database solution was proposed to meet the advent of the big Data age-NoSQL (non-relational database).

NoSQL is very young, but he has a lot of good features that have been accepted by many companies and developers, so let's take a look at the database rankings from the US database knowledge site Db-engines last month.

　　

From the rankings, you can see that the MongoDB database stands out from many RDBMS (relational databases), has become the fifth place, and is still rising.

　　

If the database analogy to the adult class, then MongoDB can be said to be a prodigy, only 5-year-old he alone challenged a group of uncle-level characters, and according to the pace of development in recent years, he is about to surpass Pgsql to become the fourth place, Although the distance from the front three has NB Dad's rich second generation still have a certain distance, but in such a technology explosion of the era of what is impossible?

Why Choose MongoDB?

1. Performance

In the age of big data, the processing of large data volumes has become one of the most important reasons to consider a database. One of the main goals of MongoDB is to keep the database as excellent as possible, which largely determines the design of MongoDB. In an era dominated by traditional mechanical hard drives, the hard disk is likely to become a performance stub, and MongoDB chooses the maximum amount of memory resources to use as a cache for superior performance, and automatically chooses the fastest index for querying. MongoDB is one of the reasons why MongoDB can maintain superior performance by streamlining the database as much as possible and handing over as many operations as possible to the client.

2. Expansion

Now the amount of data on the Internet has changed from the past MB, GB into the current TB level, a single database is obviously unbearable, extensibility is an important topic, but now developers often choose to expand the way of the time to make a difficult, whether to choose scale-out or vertical expansion?

——————————————————————————————————————————————————————————————

　　Scaling out is a way to split a database into different chunks to distribute it across different machines, with the advantage of low expansion costs but difficult management.

　　 Scale-up vertical scaling differs from scale-out in that he will upgrade the original server to have more powerful computing power. This advantage is easy to manage without the need to consider the many problems that the extension brings, but the disadvantage is also obvious, that is the cost is high. The price of a mainframe is often very expensive, and such an upgrade may not be able to find a more powerful machine when the data reaches its limit.

———————————————————————————————————————————————————————————————

While MongoDB chooses a more economical scale-out, he can easily split the data into different servers. And when it comes to getting data, developers don't have to worry about multi-server issues, and MongoDB can automatically route developers ' requests to the right server, leaving developers free of the drawbacks of scale-out and focusing on program development.

3. Use

MongoDB uses a NoSQL design approach that allows for more flexible manipulation of data. In the traditional RDBMS you must have encountered dozens of rows or even hundreds of complex SQL statements, the traditional RDBMS SQL statement contains a large number of associations, subqueries and other statements, in addition to increase the complexity of the performance tuning becomes more difficult. MongoDB's document- oriented (document-oriented) design uses more flexible documentation as a data model to replace rows in an RDBMS, and document-oriented design makes it more flexible for developers to get data Even a developer can query a complex nested relationship with just one statement, so that developers don't have to rack their brains to get the data.

The influence of NoSQL on traditional database design thinking

1. Pre-design mode and dynamic mode

in traditional database design thinking, the design phase of the project needs to specify the field names, field types, and the database tables, and if you try to insert data that does not conform to the design, it will not accept the data to ensure the integrity of the data.

--database fields: NAME, SONGINSERT  intoT_infoVALUES('John','Come Together');--SuccessINSERT  intoT_infoVALUES('Xiao Ming', -,'[email protected]');--failed

　

NoSQL uses a dynamic append to a document in a collection (similar to a "row") that does not qualify the data type at the beginning of the collection, and any document can be appended to any collection, for example, we can add such two documents to a collection:

{"Name": "John", "Song": "Come Together"} {"name": "Xiaoming", "Age": "E"  , "email": "[email protected]"}

　　

MongoDB Chinese document format similar to our common JSON, so that we first have "name", "Song" Two fields, and the second one has "name", "Age", "email" three fields, this in the pre-design mode of the database is not possible to insert a successful, But in MongoDB dynamic mode is possible, the advantage of doing this is that we don't have to design a table for a few, but a lot of different kinds of fields, you can concentrate them in a single table for storage, but the disadvantage of doing so is also obvious, When we get the data, we need to differentiate the different documents in the same table, increasing the amount of code on the development. So at the beginning of the design it is necessary to weigh the merits of the dynamic mode to select the data type in the table.

2. Normalization and inverse normalization

　　Normalization (normalization) , the inventor of the relational model, Edgar F. Codd the concept in 1970, in which normalization would spread the data across different tables, using relational models to correlate, with the advantage that, in the latter case, Does not affect the data associated with it, it can be done only for its own modifications.

　　Inverse Normalization (denormalization) is the opposite idea of normalization, which puts the data of the current document in the table instead of being stored in a split way.

There is no good or bad problem between normalization and inverse normalization, and the more beneficial of normalization is the performance when we write, modify, delete, and the inverse normalization can improve our performance at query time. Of course, there are no associated queries in NoSQL to improve query performance, but we can still do this in a way that stores the ID of the associated table in the table. However, the concept of NoSQL in the anti-paradigm position is greater than the paradigm.

MongoDB is still young

MongoDB also has a number of outstanding designs, but MongoDB still has a lot of problems that are not good, including:

　　1. MongoDB does not support transactions, and now many of the software still requires transaction management, so the high transaction consistency requirements of the program can only be managed at the software level, and cannot be managed from the database.

　　2. the scope of support for other tools, MongoDB from the release to now less than 5 years, so will face many languages do not have a corresponding toolkit, so if you use the language does not have a corresponding package, it may be that you can not use MongoDB the biggest obstacle.

　　3. The amount of resources in the community, as in the second issue, is due to the fact that MongoDB is too young to be compared with other large database communities, but the community is often one of the important considerations, A lack of community resources can lead to a prolonged problem-solving cycle, delaying work.

In recent years, the rapid development of technology is exciting, every year there will be a bright product, but it needs to accumulate time to become a mature product, MongoDB also need to grow, but his excellent design, will certainly let more and more developers accept it.

Data storage in the Big Data era, non-relational database MongoDB (i)