@halty makes a good point, don’t entirely agree with him. If there aren't many comments, the design put together is suitable, and what was said above is very good. But if there are too many comments, problems arise. The most important are two basic starting points: 1. The hard disk is too slow; 2. As long as the data is in memory, there is no problem.

1. find
   When the data is extremely large, a lot of data needs to be read on the disk, because the Memory Mapped File will be stored in the memory, but we only need a small part of it. The main problem is that the OS may page other data to the hard disk. . Just for listing articles, memory is not used efficiently.
2. insert
   On a disk file, if a document keeps growing longer and longer, many times, this is not a good thing. Because if new data is added, for example, a new comment is added, the document becomes larger and cannot fit in the original place, so a new place has to be found, and the previous holes will be reused. But the problem is that when the document location changes, all indexes related to it must change. If you also have an index on the array, such as the name of the user who posted the comment, then the updated index will be linearly related to the length of the array.
3. size
   The person above made a good point on this point. 16MB upper limit.

To sum up, when there are too many comments, it will affect the performance.

In summary, schema design should be considered

1. Data scale, as long as frequently accessed data is in memory, there is no problem in accessing it. The insufficient memory utilization mentioned in the first find above is actually not a big problem. Because the comments on popular articles are always read by many people, it is good to store them in memory. If the document keeps getting longer, MongoDB will automatically allocate more disk space when allocating it.
2. Compatible with Access Pattern. Writing comments is too small compared to reading articles and comments. Twitter's data is that the average tweet is 5K/s and the reading timeline is 300K/s. That's 60 times! As long as the read request can be satisfied in memory. Using MongoDB eliminates the need for additional caching. It doesn’t matter if the interview is really big or if there are too many articles, it’s easy to say. On that day, MongoDB's sharding will come in handy.
3. Easy to develop The cost of the product is not only the cost of machine hardware and network, but more importantly, the development cost of programmers, and the salary is so high... Therefore, it is also very important to write it as fast, convenient and not prone to errors, right? This explains why the flexibility of the MongoDB document model is widely praised.

Having said that, I think most of these applications will not have more than a hundred comments... At this time, a single document will come into play. If there are hundreds of comments, it will be no problem, and the problem of the topic owner will not be a problem. I hope the author’s application can exceed this number...

First of all, make sure that when the number of comments is large, it will not lead to inefficiency when querying the article list page. You can specify that the document in the query result set only returns part of the field data (it should be noted that if you update and then save such a document that only contains part of the field data, an error may occur). This is recommended and can be done easily. Good at saving network bandwidth.

In addition, currently mongodb has a limit on the size of a single document. If there are too many comments, it may exceed the default size limit of the document. At this time, the comment needs to be stripped.