Big discussion: What is the essence of database design or design principles in NOSQL?

Let's take a look at how the Blog table described in mongodb: varBlogSchemenewdb. schema ({title: String, desc: String, author: String, body: String, tags: [String], count: {type: Number, default: 0 }, hidde...

Let's take a look at the description of the Blog table in mongodb:
Var BlogScheme = new db. Schema ({
Title: String,
Desc: String,
Author: String,
Body: String,
Tags: [String],
Count: {type: Number, default: 0 },
Hidden: {type: Boolean, default: false },
Date: {type: Date, default: Date. now },
Comments: [{img: String, name: String, body: String, date: Date}],
Meta :{
Votes: Number,
Favs: Number
}
});
According to the mongodb design, each Blog is fully stored and basically not associated with other tables. This is also the essence of NoSQL! But how can we calculate the tag of a Blog?

This is an article I excerpted online.
The principles of NOSQL design are as follows. An article is a table, which is basically not associated with other tables. The comments in the article are directly placed in the blog. What I want to ask is, if so, how does one paging ???
For example, the Comment page ,,
What is the design principle of nosql? Is there a paradigm similar to that of relational databases?

I also found an article:
Http://www.cnblogs.com/AllenDang/p/3507821.html! Comments
Basically, the design idea is what I mentioned above: Put the blog and comments together.
This reduces the number of queries.
However, a problem occurs if the user's nickname changes.
Isn't every blog commented by this user going to be modified ????

Modify the relational database, and then join queries are the latest results.
How can I design or solve this problem in mongodb?

Reply content:

Let's take a look at the description of the Blog table in mongodb:
Var BlogScheme = new db. Schema ({
Title: String,
Desc: String,
Author: String,
Body: String,
Tags: [String],
Count: {type: Number, default: 0 },
Hidden: {type: Boolean, default: false },
Date: {type: Date, default: Date. now },
Comments: [{img: String, name: String, body: String, date: Date}],
Meta :{
Votes: Number,
Favs: Number
}
});
According to the mongodb design, each Blog is fully stored and basically not associated with other tables. This is also the essence of NoSQL! But how can we calculate the tag of a Blog?

This is an article I excerpted online.
The principles of NOSQL design are as follows. An article is a table, which is basically not associated with other tables. The comments in the article are directly placed in the blog. What I want to ask is, if so, how does one paging ???
For example, the Comment page ,,
What is the design principle of nosql? Is there a paradigm similar to that of relational databases?

I also found an article:
Http://www.cnblogs.com/AllenDang/p/3507821.html! Comments
Basically, the design idea is what I mentioned above: Put the blog and comments together.
This reduces the number of queries.
However, a problem occurs if the user's nickname changes.
Isn't every blog commented by this user going to be modified ????

Modify the relational database, and then join queries are the latest results.
How can I design or solve this problem in mongodb?

Nosql is relatively broad, and different database design principles are different.
For example, mongoDB and redis both belong to nosql, but one is document type and the other is KV type. The design principles differ greatly.

The design principle of mongoDB is still relatively close to relational databases. Its collection and table are similar. It is also a basic operation of insert, remove, update, and find. You can refer to relational databases for design. But it is more flexible than relational relationships.
For example, a microblog can insert nine images. If it is in MySQL, it may be designed as follows: Weibo is a table, image information is a table, and two tables are associated. Or this design: Add a large string type field named img_info to the table on Weibo, which stores the json string of 9 images.
In mongoDB, the second design is supported by nature. Remember, it is inherently supported, and it is inherently convenient to perform crud operations on the content in img_info.

Then return to the paging question you mentioned:
Paging mainly uses two functions: limit and skip
However, when the data volume is too large, it is not suitable to use skip paging.
The solution provided in the MongoDB authoritative guide is to get the last piece of data on the previous page, and then use gt and limit to get the data on the next page.

For redis, @ Tudou 2015 has already explained this in detail, so I will not go over it.

Reminder @ 2015: mongoDB maps some data in memory to maximize the use of memory, and persistence will still be stored on the disk. If there is no persistence, restart mongoDB and the data will not be available. Even memory-only databases like redis have data persistence.

The essence you said is true, but it is only half right. For a blog post, the comment can indeed be an attribute, but you have not chosen the comment key, user_id should be used to avoid the problem caused by your nickname change. (You can't put everything in a document. You always have a set of user_info, right)
Therefore, the essence of mongodb design is not simply to advocate your anti-paradigm, but to understand how to choose.
Let's talk about the tag statistics you asked.
The tag of your blog entity is designed as a list structure.
It's like

Tags = {"blog_id_11108tag": ["NBA", "Yao Ming", "playoffs"],}

There are actually a lot of statistical methods. you should want to count the number of blog posts under topic_1 and the number of blog posts under topic_2. In fact, statistics are also very good. In python, you can use dictionary derivation to reverse the tag. As follows:

Tag_mapper = {v: k for k in tags for v in tags [k]} # Then you get {"NBA": "blog_id_111_tag", "Yao Ming ": "blog_id_111_tag", "playoffs": "blog_id_111_tag "}

Every Blog Post adopts this method to collect statistics on the similar blog posts under each tag.

1. The essence of non-relational database products is the functional caasma version of relational database products. Castrated [relationship] and other functions to achieve higher performance and more convenient usability.

2. Starting from the above, non-relational database products are suitable for data warehouses. Because the data in the data warehouse is characterized by a large amount of data and loose relationships.

3. However, due to the high performance of non-relational databases, many people have begun to think about it and want to lose the relational data. This is certainly a problem, because you are standing on the Code layer and trying to maintain the relational functions on your own in a non-Relational Database Engine with no relational functions, it will definitely be expensive. This price may be:
---- 1. Very low efficiency. For example, if you try to combine an object distributed in multiple attribute tables in a relational database into a large object in a non-relational database, each time you query an attribute, the engine has to extract the entire large object.
---- 2. Very dirty data. Because most non-relational database products do not have multi-table and database transactions, someone creates a separate relational database to maintain the relationship between two databases with different objects. However, as there is no transaction, several operations cannot guarantee the transaction atom, so conflicts often occur, resulting in "dirty" data ".

4. In summary, when you are full of brains about how to deal with strong relationships, please do not stick to non-relational databases, or you will be pitted.

For relational databases, ACID is the four requirements for strong consistency (ACID: atomicity, consistency, isolation, durability ;)

BASE is the principle that NoSQL databases generally have weak requirements on availability and consistency. BASE: Basically Available, Soft-state, Eventually Consistent.

Nosql is regardless of the relational structure, but we can use the existing database structure to construct the relationship!

I have never used mongodb. I use redis for nosql. The processing page is as follows:

First, there is a full blog list, only storing blog. id. For example, the name is list: blog.
Another hash corresponds to the blog data structure. The name can be as follows: <# id>.
When creating a blog, combine the redis transaction> start
Redis: rpush ('list: blog', <# blog. id>); // store the id in the list first.
Redis: hmset ('blog: '+ <# blog. id>, 'title',..., 'content',...) // Save the hash
Transaction <

Use the sort limit command to operate the list and hash
Sort list: blog limit 0 10 get # get blog:-> Title get blog:-> Content
Of course, you can also perform sort based on certain blog attributes.
Sort list: blog by blog:-> Createtime desc limit 0 10 get # get blog:-> Title get blog: *-> content

The paging Method for comments is similar.

From your perspective, we can see that your data is completely dependent on mongodb and memory. Where is your data persistence?

Let me express my opinions:
The data to be updated is put in a set, rather than the data to be displayed in a set. Therefore, placing comments in the blog table is incorrect.
This problem cannot be solved:
What should I do if the user's nickname is updated.
Therefore, the design principles are to be updated together.

De-paradigm, distributed