Mongodb Guide (translation) (25)-developer zone-insert object (2) Schema Design)

Valid keyword name

The keywords in the document must follow the following two constraints during naming:

• "$" Cannot be the first character of a keyword.
• "." Characters cannot be used in keywords

Schema Design)

The Pattern Design in MongoDB is very different from that in relational DBMS. Before creating an application, it is necessary to understand the Pattern Design in MongoDB.

In the relational data model, there is a correct design in theory for a given relational model that depends on use cases. This is the third normal Paradigm (3nf). Most people think this is for efficiency consideration.

In MongoDB, pattern design is not only a method to model data, but also a case model. For the vast majority of use cases, the pattern design needs to be customized separately. This has advantages and disadvantages-use cases can be executed efficiently; however, it may be a blind spot mode, and it is not as elegant as the relational mode in a specific query.

When we design a model, we must answer the following questions:

1. When will we embed data (embed) with respect to links )? Our decision implies the answer to question 2:
2. How many sets do we need? What are they?
3. When do I need atomic operations? These operations can only be performed within the scope of a BSON document, and cannot be performed across documents.
4. What indexes will we create to make queries and updates faster?
5. How do we perform sharding? What is the shard key?

Embedded and link

When designing a MongoDB mode, a key issue is when to use the embedded mode and when to use the link. Embedding is to embed objects and arrays into the bson document. Links are references between documents.

There is no join in MongoDB-it is very difficult to distribute the association in a cluster with 1000 servers. Embedded Data is similar to "pre-associated" data. Operations in a document can be easily handled by servers. These operations can be very rich. The link must be processed on the client. The application initiates further queries to complete these operations.

Generally, to "maintain" the relationship between entities, you should choose to use embedded. When a link is not used, Data Replication may occur when a link is used.

Set

A collection in MongoDB is similar to a table in a relational database. Many documents are saved in each collection. As mentioned above, the content of these documents can be very rich.

The fields of a document in a set do not need to be declared. But for a pattern designer, he should have a concept about what these fields are and how these documents are structured in the collection. Mongodb does not require documents in a collection to have the same structure. However, in practice, most of the documents in the collection are of the same class structure. Although we can remove these as needed (a collection of documents has the same structure); for example, we can add a new field. In this case, operations similar to "alter table" are not required.

Atomic operation

Some problems need to be solved by performing atomic operations. For example, adding 1 to a counter is a common use case that requires atomic operations. Mongodb can also perform complex atomic operations:

atomically {
if( doc.credits > 5 ) {
doc.credits -= 5;
doc.debits += 5;
}
}

Another example may be the user registration process. We will never allow users to register two identical user names:

atomically {
if( exists a document with username='jane' ) {
print "username already in use please choose another";
} else {
insert a document with username='jane' in the users collection;
print("thanks you have registered as user jane.");
}
}

The key here is the scope of atomic operations/ACID content. In this way, we need to ensure that all fields involved in atomic operations belong to the same document.
Index

Mongodb supports declaring indexes. Indexes in mongodb are very similar to those in relational databases: they are designed for efficient queries and must be explicitly declared. In this case, as part of the pattern design, we need to consider defining those indexes. Like relational databases, indexes can be added later. If we decide to add new indexes in the future, we can add more indexes later.

Parts

Another thing to consider when designing a pattern is sharding. A bson document (which may have some important embedded fields) will only reside on one part.

A set can be sharded. When sharded, this set has a sharding keyword, which determines how the set is sliced into the cluster.

Generally (not required) the query of the shard set contains the shard keyword.

Note that it is very difficult to change the sharding keyword after the sharding.

Example

Let's consider an example of a content management system. The following example uses the mongo shell syntax, but it can also be implemented in any programming language-as long as the appropriate driver is used.

Our content management system saves the blog. Blog author. We also support comments and votes on blogs. We also want to add tags to provide the search function.

A good pattern design may use two mongodb sets, one is posts and the other is users. This is what we will use in our example.

Our users have some attributes-the user ID, name, and their karma used for registration. For example, we can:

> db.users.insert( { _id : "alex", name: { first:"Alex", last:"Benisson" }, karma : 1.0 } )

The _ id field must exist in mongodb and an index with unique attributes is automatically created for it. This is very suitable for using our username AS _ id. Although we do not need it, we can also add the username field and then let the system automatically generate the _ id field.

Now let's consider the blog. We assume that some blogs have been published. Let's query an article:

> db.posts.findOne()
{
_id : ObjectId("4e77bb3b8a3e000000004f7a"),
when : Date("2011-09-19T02:10:11.3Z",
author : "alex",
title : "No Free Lunch",
text : "This is the text of the post. It could be very long.",
tags : [ "business", "ramblings" ],
votes : 5,
voters : [ "jane", "joe", "spencer", "phyllis", "li" ],
comments : [
{ who : "jane", when : Date("2011-09-19T04:00:10.112Z"),
comment : "I agree." },
{ who : "meghan", when : Date("2011-09-20T14:36:06.958Z"),
comment : "You must be joking. etc etc ..." }
]
}

You will find it interesting to compare how to implement this mode in relational data. We will first have a collection of users and blogs. However, you also need to Add Tag sets, voting sets, and comment sets. It may be troublesome to collect all the information of a blog.

Here we can get a complete blog information:

> db.posts.findOne( { _id : ObjectId("4e77bb3b8a3e000000004f7a") } );

Query all blogs written by "alex:

> db.posts.findOne( { author : "alex" } )

If many of the above queries are used, we can index the author's fields:

> db.posts.ensureIndex( { author : 1 } )

The entire blog document may be large. If you only get the title of alex's blog, you can do this:

> db.posts.findOne( { author : "alex" }, { title : 1 } )

Search by TAG:

> // make and index of all tags so that the query is fast:
> db.posts.ensureIndex( { tags : 1 } )
> db.posts.find( { tags : "business" } )

Query all meghan comments:

> db.posts.find( { comments.who : "meghan" } )

You can create indexes to accelerate search:

> db.posts.ensureIndex( { "comments.who" : 1 } )

We hope that one person can only vote for a blog once. The following update example records the vote of calvin. Because the $ nin subexpression is used, if calvin has voted, this update will not update the database:

> db.posts.update( { _id : ObjectId("4e77bb3b8a3e000000004f7a"),
voters : { $nin : "calvin" } },
{ votes : { $inc : 1 }, voters : { $push : "calvin" } );

The above operation is atomic: if multiple users vote at the same time, no vote will be lost.

Suppose we want to display the latest blog title and author. This use case requires client connection:

> var post = db.posts.find().sort( { when : -1 } ).limit(1);
> var user = db.users.find( { _id : post.author } );
> print( post.title + " " + user.name.first + " " + user.name.last );