The Principles of Data Modeling for MongoDB

Ғылым және технология

Creating a schema for a relational database is a straightforward process. Designing a schema for a MongoDB application may seem a little more challenging. However, it doesn't have to be if you follow the main principles that MongoDB has identified for its users. This talk will go over these data modeling principles. We'll also reveal modeling tips to address the constant changes in the data technology world like new features in MongoDB, hardware evolution, data lakes, and the growing impact of analytics.
Speaker: Jay Runkel, Distinguished Solutions Architect
Company: MongoDB
Level: Intermediate
.local Toronto ’22 playlist ➡️ trymongodb.com/3VbiM6Y
Subscribe to MongoDB ➡️ bit.ly/3bpg1Z1
#MongoDBlocalToronto22

Пікірлер: 11

  • @omokechuku861
    @omokechuku861 Жыл бұрын

    Great talk...This will help in making engineering decisions on query optimization techniques

  • @rsrawat2000
    @rsrawat2000 Жыл бұрын

    Great presentation

  • @lesegoRunknown
    @lesegoRunknownАй бұрын

    Where can we access these notes?

  • @meepk633
    @meepk633 Жыл бұрын

    I've been trying to figure out if MongoDB is right for my use case. I've read a lot of familiarization content, including the Manual. Almost all of this content is sparse in two areas, 1) Many-to-many relationships between two types of documents that are large and complex. Tags and posts are easy. What about Courses and Students? Should I store an array of references on one, the other, or both? How do I optimize for a Student who wants to list all their Courses AND Teachers who want to list all the Students in a Course? 2) The practicalities of changing data in multiple locations. Say I have references in Students and Courses. If a Student needs to drop a Course, do I have to manually remove references in both locations? Will the aggregate system take care of that for me? What if someone comes along later and deletes the reference in Students but not Courses? What mechanisms can enforce the synchronization of references? Obviously I haven't read everything out there. I may be misunderstanding basic things. But the simple cases are not illustrative enough for me. This is especially true when update examples are not included. Someone please tell me where to go from here. Where are some practical examples of many-to-many relationships of complex documents?

  • @lalankeathauda7414
    @lalankeathauda7414Ай бұрын

    Very good informative talk..

  • @Mark.Brindle
    @Mark.Brindle Жыл бұрын

    Document Versioning with the C# driver is only implemented at the root level. If a nested class has a field removed, the deserialiser throws an exception. If a root level field is removed, the old value is added to the ExtraFields key/value list. The only fix for this is to implement full versioning in every subclass. When we deserialise each document, we check the version# at the root and if it's old we update the in-memory copy and set a flag to say the document has been upgraded (or downgradded if code was rolled back). The application can then decide to update the record back to Mongo or continue. The advantage is, a result set returned to the user is consistent and can be bound to the UI. This approach is working well for 100 million+ collections and very robust (we also automatically create/drop indexes based on the registered latest schema version). The downside, is having every subclass requiring a version number and a ExtraFields collection plus the logic to be able to check all nested classes including versions in every array element. The root ExtraFields field should include any missing fields from any level of subclasses. Every C# developer I have discussed this with, has found the same problem and given up on the implementation, which is sad, because in general the versioning works very well except for nested classes (which is a design pattern, not to have a lot of fields at the root).

  • @PankajNikam

    @PankajNikam

    9 ай бұрын

    Is there any git issue where we can upvote this to be solved?

  • @simonvandenhende5274
    @simonvandenhende5274 Жыл бұрын

    Really great overview! I have a question about the schema versioning approach for updating the data model: Since the application covers the migration ad-hoc, chances are there will be some less frequently accessed documents stuck on the old version. This means that the implementation of the old version will stay in the codebase much longer (and possibly indefinitely). Is there a good way to migrate all documents at once (in batches) or would you not recommend that? I would like to optimize for technical debt and legacy code. Many thanks in advance :)

  • @MongoDB

    @MongoDB

    Жыл бұрын

    Hi Simon! We appreciate your comment. Can you post this with more details in our MongoDB Community forums so our team can discuss this with you? www.mongodb.com/community/forums/

  • @graeme2103

    @graeme2103

    Жыл бұрын

    @Simon - typically after some period of time you would run a query to either upgrade any documents remaining on the prior version, or to archive them (perhaps to S3 using online archive in MonogDB Atlas) on the assumption that if they hadn't been accessed within that time period, they are no longer active. That would potentially allow you to clean-up / retire / remove any code associated with the older version from your application.

  • @mariacristinaarezzi
    @mariacristinaarezzi6 ай бұрын

    Hello

Келесі