EP. 252 Mastering Data Modeling in MongoDB: Insights from a Strategy Expert

0:06OK, hello to everybody at home. My name is Mark Smith. I'm just taking over for this slot and I'll be back along later for an interview. And I'm here with Daniel Kupal, which is fantastic. I was so pleased when your name came out of a hat for for my interview. Well, I'm happy to do that. It's so cool. So before we get talking like, why don't you say something about yourself? Like what's what's your role and what kind of stuff do you do day-to-day as when lobby beans?

0:35I've been up probably before a while over 10 years. My current role right now is to take care of this strategy. Customers like the 50 biggest accounts, we go see them and we do events a bit like this one where we do a bunch of presentations and then we have a second day where we do one-on-one design reviews with them on their data models and it's pretty cool. We love doing those. I'm sure we can elaborate a little bit more on that topic. Do you want me to elaborate now on that or?

1:07So well, I guess that was going to be my next question, talk about the design reviews and sort of data modeling side of things. So what? What exactly do you mean by designer view if somebody hasn't been? Yeah, it's a bit misleading because we, you know, you have a design, but really what we're trying to do is help you on your data model in their design. And then I think when you work with MongoDB, it's a little bit different than what we have done with other database, if you have our experience and these other technologies.

1:38So we have to start thinking a little bit differently. We, we want to be sure that you're, you're going to be successful with your first models, especially in these large customers. We're very bullish. Now we, I'm sure like me, you believe Mongo DB is by far the best database out there. So actually make you successful in your first projects, you're going to come back for more. So we and that's what that's the intent, you know, And if someone asks how much that going to cost me it, it's a free service that we offer again. So we want to be sure things gonna work and you won't have any issues.

2:11So generally people come in with their own design model that they have already or that they're considering putting into. That is a good question. Absolutely. We get the kind of a range of different scenarios. You can come at the beginning of your project and you won't see if Mongo DB would be going to be a good solution from the model. Can can I do that with Mongo DB right now? And we're going to be really honest with you. We if Mongo DB is not a good fit, we'll tell you.

2:37We'd rather that you don't use Mongo DB if it's not. Good, that's. Right. I love having a bad experience and then that bad experience, you know, being transmitted to other people in the organization. But you, you may be at the, you know, at the middle of your project where you have a data model then, but you have question, things don't seem clear. You want the education, you may be further in your model where you're close to going to production and you want the validation that everything is OK. Obviously if we're going to tell you it's not, there's no. You need to ensure you have enough buffer time to change things, so do it a little bit earlier is to be better in that case.

3:14Yeah, the opportunity to get clarity is really nice. I certainly remember going through that part of the journey myself where I just wasn't sure I had something seemed to work, but was it right? And it's very difficult to kind of to get that. Yeah, and it's, it's going to be like, you know, really useful with me and they find things. But the one thing to to also understand with MongoDB is if you have to do changes later, you can still do them without downtime. Now, if your model is right at the beginning, you're going to save a lot of effort doing right if you can. But the the requirements change and and be sure that if you have a successful project that's going to last for many years, things are going to change.

3:50You know, the worker is going to change the number of preparations and or maybe even requirements, you know, things that you have to start adding to your model and. And we're going to point out how you can do some of the, you know, medication all the time. Yeah, without done time and. It's great. So I guess maybe an interesting question for the people at home, like what's the most common the design mistake you see when doing his line reviews? Yeah, the most common or like the the worst mistake.

4:20Maybe both? Like give us both if they're not the same. The one we don't like is show me your ER diagram and then, you know, we see any tables and I'm like, OK, you know, and what's your first draft for your, you know, your collections, you know, diagram. And then we have 20 connections like, yeah, no, this is not working. Yeah, just. Relational modeling and. No, we do the other cuffs, we support the joints, but you don't want to do that on the most important and frequent operation.

4:48So yeah, that was, that's for me the worst mistake. And this is where you need to change your mindset and get in, you know, thinking a little bit different and we can guide you at all the app. So I mean that really comes what's the solution to those companies. I get that there are many solutions depending on what their model kind of really is as opposed to how you would model that in a relational database. But what's the overall rule for what's the remodeling? Well, are you get there in terms of training or some like basic rules that if you think you know, if you apply those you'll be, I was thinking much better shape. Yeah, I was thinking the latter.

5:29Yeah, You know, when I do my presentation is something I like to say is, you know what you're going to be using together in the application should be stored together in database. I think that's the main principle. There's a lot of the design rules that come out of that. When you look at some of the pattern, that's exactly what you're doing. You know, we're not embedding everything or we're not referencing. We're trying to be in between because these things are used together, but not all of them. Yeah, that'd be like the main thing that you you should apply, you should start thinking of.

5:59I've heard whole rooms full of people like chant that like a man just kind of what you queries together that's. A good idea. I haven't done it, but I think I'm going to try that next time. I'm going to repeat it many times in this in the 30 minutes or 35. Minutes. So I think my first exposure to your work at Mongo DB was actually in a series of blog posts on design pads, which I think is something I recommend in pretty much every live stream I ever do.

6:24Every time I give a talk, it's like you're using Mongo DB. Go and read. You have to go and read these posts so there's, I can't remember how many like 12 or 13 patterns. Yeah, there was 12 in the in the series, yeah. So what what would you say is like the most, the most fair? I don't know whether to go with interesting or kind of useful design patterns in there. What do you think most illustrous in there? Well, the one I use often in the reviews, the two I will say that come back the most often would be the extended reference and would be the computer pattern. And in very short description, the, you know, when you model with Mongo DB, you always have the choice between embedding or referencing entities.

7:08But sometimes you're in a case where it's in between, let's say neither of those is the like perfect or right solution. So what should I do? And then the extended reference is a good pattern for that because basically what's going to tell you is to bring some embed a little bit, but not everything, but embed whatever you need to avoid doing those costly join on the important information. And if you need more information once in a while, we'll fetch it, but you're not going to fetch all the time.

7:34So you're going to save a lot of resources. So that's the first one. The second one is in the case with what you're trying to model is either AUI or an application that send response to API calls. What's important in those cases is the latency you you want to build that answer as quickly as possible. And one mistake that you could be doing is having to do operation that are often the same and when you go a bit more to that all the time at the time that you're trying to provide the answer.

8:10So if you add the leisure to spend a little bit more time at write time to prepare the data in a form that the UI will make only one read and everything for that page, then it's going to be much faster. Yeah. So and one of the sign also you get where when you should apply the computer pattern is you're going to have a high ratio of read operation versus the write operation. So if you have something like that, it means, let's say I have 1000 times more reads and writes in average, I'm computing the same thing 1000 times. So why not doing it at no at write time? Yeah, and relational databases don't generally give you the ability to do that pre computation and then store it back in the database cuz you're usually doing those joins and create.

8:56Yeah, you can store it, but you'll store it sometimes in middle table. You still have to do a join. Mom would let you put it in the entity that you query all the time that the important query the important entity that you want to retrieve. Yeah. It's interesting to see that the sort of engineering sort of relearns this over time. Yeah, you need. To start thinking a little bit differentiating, you know, start thinking with these patterns, You, you get it after a while, you know, it's just a matter of practice.

9:18And yeah. So if if somebody was trying to going to data modeling like they maybe been using Mongo DB for a little while, but they once get better at data model and specifically within Mongo DB like what's the best way would you say? We have all the reference, we have the blogs and I'm done and put my plug here. I did write a book that has all the patterns and it's a bit more. If I need to Google for it later. Yeah, and I can sign it. One of the best resource we have is the university courses.

9:51So we do have a path for learning data modeling and there's association associated to it. But another plug is on Monday, October 14th, we're starting a new series of webinar on data modeling where we're going to display very short topic, 1015 minutes and then as the audience where they want to see in the next session. So it's going to be my whole team doing it like, you know, rotating, but we can also try to model live some of the problems that some of our audience going to bring.

10:23So that should be fun. And basically what I'm saying is if you attend a design review session, you're going to be learning how we do it. You can see the question we're asking and basically repeating those question yourself on your own project. It's going to be a way to learn a lot about that modeling. Yeah, that sounds fantastic. And especially that length as well. It's almost like it's no excuse really not to not to sign up for that. So that I'm guessing those webinars, if I was to Google for that, it would come up with something in a MongoDB, a sign up page for that also, just you what? Oh, that's great.

10:58So yeah, I kind of want to have questions. It's not very good, is it? Not very professional. This is my first thing to be that I've ever done. So this has been a great conversation. I really appreciate the time. Thank you. Very. Much thanks for having me because really good bye.