Shulou(Shulou.com)06/02 Report--

This article introduces the process of combing and reviewing several questions of MongoDB. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

Mainly responsible for the work of the system is mainly MongoDB database, the development process has accumulated some experience and the actual use of case, some time ago to sort out the relevant scenes, organized several articles.

When I tried to publish these articles to the MongoDB Chinese community, after communicating with the person in charge, they put forward some questionable and imprecise aspects of the article, and I would like to make a review and revision here.

About the selection of time storage type

"MongoDB development series-starting with the design of data sets" wrote

Time can be directly defined as formatted time, which is easy to identify and query. There is no need to specifically store timestamps, which makes it easy for visual tools to query and check.

The formatted time here is ambiguous and will be considered a time string, such as (2019-07-03 19:10:11). My original intention is to express the use of ISODate-type time format storage.

The storage of timestamp and time format is a matter of choice, some people are used to using timestamp storage, some people are used to using time type storage.

It is recommended to save the timestamp that it is very convenient to convert time into string, and it is very inconvenient to convert string into time. There is also the question of efficiency.

Field semantics and field mapping

The length of the field should be as short as possible, not too long. Memory optimization is also taken into account.

The advice of the experts of the original factory is

In fact, there is no question of length, because there is compression, and duplicate fields such as field names can be ignored after compression.

At first I was thinking that MongoDb is a memory-based and key value-based database, and I didn't find a positive response to the [naming convention, short character suggestion] in both the official and community.

Most of the official documents are defined by lowercase names, so I am gradually rejecting this view, or the optimization of memory is not obvious, but at the expense of field semantics, increasing the cost of developing field mapping and communication.

Example of official documentation

The normal practice is to name the hump or all lowercase semantically.

Single document width

Note that in this case, the document must not be too wide. How to avoid this situation, my method is to estimate the maximum number of fields, 20 fields as nodes, more than 20 using the design of nested document to organize the document.

This is the work of the design experience, there are not rigorous places, easy to mislead readers. There should not be 20 of this quantitative data, my original intention is that if there are too many first-level attributes, it can be organized into second-level nested fields, that's all.

On several questions about MongoDB carding and review process is shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.