MongoDB simple research

Background

Due to the influence of traditional RDB, most developers may have a mindset for designing database tables. In the context of cloud computing and big data, RDBMS is approaching the limit, and KV storage will attract more and more attention. Learning NoSQL is hard to get rid of RDBMS, but we hope to broaden our design philosophy. In many scenarios, the design and computing statements of SQL tables are quite uncomfortable.

RDBMS is not inherently distributed. Since it maintains the development of ACID, it attaches great importance to data integrity. However, when the machine grows, ACID cannot be expanded. At the same time, as the data volume and Access frequency increase, the overhead of ACID maintenance increases. The split database, both horizontal and vertical, is spreading the total data and reading requirements to achieve optimization, and the maintenance cost and difficulty also increase. However, KV search is essentially a discrete list, and no matter how much data volume increases, the search time is almost fixed, that is, it is very suitable for large-scale data. ACID pays great attention to C in CAP, and refers to many transactions in the real world, such as express delivery, from your order, payment to pick up the goods, the transfer of funds and items is not strictly consistent, as long as the final result of the entire transaction is consistent within a period of time. Similarly, NoSQL and RDBMS prefer the compromise of BASE (Basically Available, Soft-state, Eventually consistent), and pay attention to availability, but do not pursue state rigor and meet final consistency. Next I will take mongodb as an example to show some of its features and scenarios. I hope that NoSQL will be able to be used by more developers to show their skills.

Mongodb and RDBMS

Mongodb is a document-oriented nosql, while CouchDB is the ancestor of such databases. In general,

Mongodb is a NoSQL with the most affinity for RDBMS and can solve most of the problems solved by relational databases.

Compared with HBase for column-oriented storage, document-oriented storage is more similar to row-oriented storage. For example, if no index is available, the entire table is scanned and the entire document is scanned, and each field in the document

The mongodb index is also a B-tree, which is similar to that of MySQL in terms of index optimization and design. (Of course, you must follow the mongo design and do not fully calculate the same number)

You can use mongodb like RDBMS (which is not recommended of course), instead of converting a row of records into a json pair in mongodb between document (equivalent to a table in mysql, you can also make a reference similar to a foreign key.

Although mongodb does not have strict transactional operations, developers can perform similar transactions themselves. This is also a manifestation that mongodb is close to RDBMS.

The following will show the features of mongo from the main points of attention. It is more focused on people who want to investigate and use mongodb to see if mongodb meets their own business scenarios, I also hope my analysis will be helpful.

What is the storage structure?

The storage of Mongodb is similar to JSON. Each database has multiple collections, which is equivalent to a table. Each collection contains many documents, and the schemeless of this document. In essence, his document-oriented document refers to the value in key-value, which can be a value (reference id or basic type) or an array, it can also be a document (nested json pair ).

One-to-multiple is the most common scenario. in mysql, two or more tables must be joined or even joined for query. In mongo, nested or referenced types (id) are used directly) you can. If there is no special requirement, only one "table" can be nested. For example, I create a person's information:

{
Id: 1,
Name: "pelick ",
Hobbies :{
"GameA", "GameB", "GameC"
},
Friends :{
Male :{
2, 3, 4 # id refer to other person
},
Female :{
{
Name: "Rita ",
Hobbies: {"dancing "}
},
{
Name: "Kaka ",
Nickname: "Riva"
}
}
}
}

In the above structure, no mode is displayed, the value is an array, nested, reference, and so on.

Dealing with many-to-many relationships is the essence of NoSQL. Theoretically, storage can be completed in a collection. However, this situation is rare. This is caused by the diversity of queries. If there is only one type of query, this many-to-many relationship is placed in a well-designed collection, although there will be a lot of redundancy, however, the efficiency must be the highest. The key to designing such a database is to check the number of queries, the frequency of each query, and other requirements. For different queries, the performance of the same database design is also very different. Another point is that it should not be split into three sets, which is the traditional way of thinking about relational databases. The common case is to split the data into two sets, and then there is a part of redundancy to create an index for the most common queries.

The conclusion is that there are two tables, one with the id set in the other, with redundant storage. It is mainly designed and indexed Based on the query scenario and should not be changed to three like RDBMS. In addition, you can perform a forward/reverse query by adding an id array to each field.

Next, let's take a look at the highlights of page 2nd:

Recommended reading:

 

CentOS compilation and installation of MongoDB

 

CentOS compilation and installation of php extensions for MongoDB and mongoDB

CentOS 6 install MongoDB and server configuration using yum

Install MongoDB2.4.3 in Ubuntu 13.04

How to create a new database and set in MongoDB

MongoDB beginners must read (both concepts and practices)

1 2 3 Next Page