MongoDB schema design

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP



MongoDB schema design



I'm planning to implement this schema in MongoDB, I have been doing some readings about schema design, and the notion was whenever you structure your data like a relational database you must be doing something wrong.



enter image description here



My questions:



what should I do when collection size gets larger than 16MB limit?
app_log in server_log collections gets might in some cases grow larger than 16MB depending how busy the server is.



I'm aware of the cap feature that I could use, but the requirement is store all logs for 90 days.



Do you see any potential issues with my design?



Thanks





Hi, I haven't done much with MongoDB but I think the 16MB limit is per document rather than collection. For retaining log files you could clear out this collection and use your db backups for the 90 days
– iestync
May 4 '16 at 8:25





why is this server1 and server2 collection?
– rummykhan
May 4 '16 at 8:26





probably Server1 and Server2 should be embedded into users collection
– Deano
May 4 '16 at 8:33





An essential question you need to answer is how are you going to be querying the data. You will not have the luxury of using JOINs the same way as you would in a relational database.
– PeterVC
May 4 '16 at 8:55




3 Answers
3



Whether this is a good design or not will depend on your queries. In general, you want to avoid using joins in Mongo (they're still possible, but if you're doing a bunch of joins, you're using it wrong, and really should use a relational DB :-)



For example, if most of your queries are on the server_log collection and only use the fields in that collection, then you'll be fine. OTOH, if your server_log queries always need to pull in data from the server collection as well (say for example the name and userId fields), then it might be worth selectively denormalizing that data. That's a fancy way of saying, you may wish to copy the name and userId fields into your server_log documents, so that your queries can avoid having to join with the server collection. Of course, every time you denormalize, you add complexity to your application which must now ensure that the data is consistent across multiple collections (e.g., when you change the server name, you have to make sure you change it in the server_logs, too).



You may wish to make a list of the queries you expect to perform, and see if they can be done with a minimum of joins with your current schema. If not, see if a little denormalization will help. If you're getting to the point where either you need to do a bunch of joins or a lot of manual management of denormalized data in order to satisfy your queries, then you may need to rethink your schema or even your choice of DB.



Your collection size is not restricted to 16MB, as one of the comments pointed out, you can check in the MongoDB manual that it is the largest document size. So there is no need to separate the same class of data between different collections, in fact it would be a major headache for you to do so :) One user collection, one for your servers and one for your server_logs. You can then create references from one collection to the next by using the id field.


user


server


server_log


id



what should I do when collection size gets larger than 16MB limit



In Mongodb there is no limit for collection size. Limit is exist for each document. Each document should not exceed the size of 16 MB.



Do you see any potential issues with my design?



No issue with above design






By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Popular posts from this blog

Firebase Auth - with Email and Password - Check user already registered

Dynamically update html content plain JS

How to determine optimal route across keyboard