MongoDB: Data Model introduction, mongodb Data Model

MongoDB: Data Model introduction, mongodb Data Model

Data in MongoDB has a flexible mode. Unlike SQL databases, you must determine the mode of a table before inserting data. The MongoDB set does not force the structure of the document. This flexibility facilitates ing documents to objects or objects. Each document can match the data field that represents the object, even if the data changes significantly. However, in practice, a collection of documents shares a similar structure.

The key challenge of the data model is to balance the needs of applications, the performance of the database engine and the data access mode. When designing a data model, consider the usage of data in applications (such as querying, updating, and processing data) and the internal structure of the data.

Document Structure

When designing a data model for a MongoDB application, the key is how to express the relationship between data around the structure and application of the document. There are two tools that allow applications to express these relationships:Reference and embed documents(References and embedded statements ).

• Reference

References store the relationship between data through a link or a reference from one document to another. The application can parse these references and ask for relevant data. Broadly speaking, these are all normalized data models (normalized data models ).

To contact the document. Both the contract document and the access document protect the reference of the user document.

The following describes the advantages and disadvantages of using the normalized Data Model for reference:

The normalization model uses reference to describe the relationship between documents. Generally, normalization models are used,

References are more flexible than embedded documents. However, the client application must handle the query problems caused by references. In short, the normalized data model requires more round-trip servers.

• Embedded Data

Embedded documents capture the relationship between data by storing relevant data in a single document structure. MongoDB documents allow a field or field data in a document to be embedded into a document as a subdocument. These nonstandard data allows applications to obtain and manipulate data in a single database.

The data model of is embedded fields to protect all relevant information.

The following describes the advantages and disadvantages of the data model embedded in the sub-document:

With MongoDB, You can embed relevant data in a single structure or document. This model is a famous "nonstandard" model that leverages the advantages of MongoDB's rich documentation.

The embedded data model allows the application to store related fragment information in the same database record. Therefore, when an application completes a common operation, it only needs to process a few queries or updates.

Generally, the embedded data model can be used in the following situations:

In general, embedding provides better read performance and the ability to request and obtain relevant data in a single database operation. The embedded data model makes it possible to update related data in which atomic operation.

However, embedding a data model in a document may result in a document growth after creation. Document growth affects Write Performance and causes data fragmentation problems. In addition, the document size in MongoDB must be smaller than the maximum BSON document size. For large binary data, consider GridFS.

Atomicity of write operations

In MongoDB, write operations are atomic at the document level, and there is no single write operation that affects multiple documents or sets atomically. A nonstandard Data Model with embedded data contains data that can represent an object in a single document. This is conducive to the atomicity of write operations, because a single write operation can directly insert or update data to an object. Normalized data disperses data in multiple sets, which requires multiple write operations, so it is not atomic.

However, an atomic write mode restricts the data usage or modification methods of an application. Therefore, it is necessary to balance atomicity and balance.

Document Growth

Some updates, such as adding elements to an array or adding new fields, will increase the document size. If the document size exceeds the space allocated to the document, MongoDB will relocate the document. Document growth affects the selection of standardized and non-standardized data.

Data Usage and Performance

When designing a document model, consider how the application uses your database. For example, if your application only uses recently inserted data, consider using Capped Collections. Or, your application must always perform read operations. Adding indexes is a common way to improve performance.

Is MongoDB suitable for data warehouses?

Today, I took some time to browse MongoDB's authoritative guide. Several highlights of MongoDB recommendations: the wide range of data models have good scalability, and the ability to quickly and easily manage the above highlights are not significant advantages for data warehouses. The data warehouse can be divided into two layers: one layer is an ETL computing server, the main requirement is big data computing, and the concurrency requirement is not very high; the other layer is the front-end report Presentation of BI, although the data in the front-end reports is finished after ETL processing, sometimes the data in the main business tables may contain millions of data from time to time, of course, we can also make a summary on the basis of several millions, but it sacrifices the flexibility of the model. Therefore, the front-end presentation of the Report Server must have both a certain degree of computing capability and a certain degree of concurrency capability. MongoDB is obviously not suitable for ETL servers, and its computing capabilities are not comparable to those of hadoop and Greenplum. It is estimated that the computing capabilities are average (not tested ). Front-end reports can be displayed, with fast speed, support for certain computing power, and good concurrency. There are also many shortcomings to think about. The most terrible thing is that join is not allowed, and analysis functions are used in many situations in report presentation. data analysts often use them when analyzing data, this is a big problem. Otherwise, more ETL work is required for the report, and the Analyst's workload will increase a lot. Currently, MongoDB shell scripts cannot be compared with SQL's flexibility and ease of use. What's more difficult is that the current technical staff are all learning relational databases, and suddenly they are converted into NOsql databases, which is a huge cost. If only one or two people have a better transformation, it is very difficult to transform a team.

A client tool used to connect to the mongodb database.

Jmongobroue, MonvoVUE, and windows command lines can also be used.

However, it is best to use the next enhanced cmd Tool, such as powercmd, because it cannot be displayed in the command line, and it is not necessarily displayed in the client tool. If you want to learn mongo, you 'd better learn to knock on commands instead of "click it"