Since the official use of MongoDB, more than once made fun of MongoDB garbage Settings, including but not limited to:
- No transaction
- No table joins (new version supports this, but the performance is not good)
That is to say, the same operation, in SQL through JOIN control atomicity, through MongoDB may have to check twice, and atomicity is not guaranteed — MongoDB official is also very honest, others said in the selection, If your system has a strong demand for Concurrency, MongoDB might not be your cup of tea. We also provided a brief introduction to the locking mechanism in the MongoDB sneak peek, which you can read if necessary.
Two days ago, I was bored and then read “MongoDB Authority Guide” when I saw some views, I feel that the design of MongoDB database has played a certain guidance and reference role, so I write this article (note) :
First we understand two concepts:
- Formalization: Split the data into different collections that can be referred to each other, so that the data can be modified as long as the document in which the data resides is modified, and other areas are independent of the content of the data.
- Antistereotype: The data required for each document is stored within the document, and each document has its own copy of the data. To modify this piece of data, you need to modify each document corresponding to this piece of data.
As we said earlier, since there is no “join,” formalization means that we may have to perform multiple queries to get the complete data we need, whereas antiformalization requires only one query. From the perspective of writing, we can see that the consumption of formal writing is less and the locking mechanism is coordinated. For MongoDB with the concept of subdocument, we need to weigh it according to our actual needs.
In SQL, we often talk about one-to-one, one-to-many, many-to-many, but in a database like MongoDB, we can divide it into new types: “Less” and “more”, then we will conduct some detailed analysis of database design based on “less” and “more”. First, we will simply refer to the table in the Authoritative Guide to MongoDB based on the previous introduction:
| More suitable for embedding | More quotable |
|---|---|
| Small subdocument | Subdocument is large |
| The data do not change regularly | Data changes frequently |
| The final data is consistent | The data for the intermediate stage must be consistent |
| Document data increased slightly | Document data increases substantially |
| Data is usually obtained by performing a secondary query | Data is usually not included in the results |
| A quick read | Fast write |
In general, the “less” relationship is more appropriate for embedding, and the “more” relationship is more appropriate for referencing: for example, articles and tags might be many-to-few, articles and comments might be one (less) many-to-many.
So our Tags can be embedded, and comments are better with references.
Because MongoDB documents will automatically expand their size, it will cause performance problems if documents are moved too frequently. In the design stage, sufficient space can be reserved to improve the writing speed.
According to this design principle, combined with some restrictions of MongoDB, the following problems can be solved to a certain extent, rather than relying on metaphysics to design according to mood:
- Should I use MongoDB?
- Should I use a reference or a SubDocument?