December 13, 2024 • 11 mins
Join us for an insightful discussion with a MongoDB expert as we delve into the intricacies of data modeling and design reviews. With over a decade of experience, our guest shares valuable strategies for optimizing data models, avoiding common pitfalls, and ensuring successful implementations. Learn about the importance of aligning your data structure with application needs and discover practical design patterns that can enhance your MongoDB projects. Whether you're new to MongoDB or looking to refine your skills, this episode is packed with actionable insights to elevate your data modeling game.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:06):
OK, 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
(00:28):
about yourself? Like what's what's your role and
what kind of stuff do you do day-to-day as when lobby beans?
I'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
(00:49):
presentations and then we have asecond 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?
So well, I guess that was going to be my next question, talk
(01:10):
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 adesign, but really what we're
trying to do is help you on yourdata model in their design.
And then I think when you work with MongoDB, it's a little bit
(01:32):
different than what we have donewith other database, if you have
our experience and these other technologies.
So 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
(01:54):
in your first projects, you're going to come back for more.
So we and that's what that's theintent, you know, And if someone
asks how much that going to costme 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.
So generally people come in withtheir own design model that they
(02:14):
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 ofyour project and you won't see
if Mongo DB would be going to bea 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.
(02:37):
We'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
(03:00):
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.
Yeah, 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,
(03:21):
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
(03:43):
if you can. But the the requirements change
and and be sure that if you havea successful project that's
going to last for many years, things are going to change.
You know, the worker is going tochange the number of
preparations and or maybe even requirements, you know, things
that you have to start adding toyour model and.
And we're going to point out howyou can do some of the, you
know, medication all the time. Yeah, without done time and.
(04:05):
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.
Maybe both? Like give us both if they're not
the same. The one we don't like is show me
(04:26):
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
(04:46):
most important and frequent operation.
So yeah, that was, that's for methe 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.
(05:07):
I get that there are many solutions depending on what
their model kind of really is asopposed 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
(05:27):
shape. Yeah, I was thinking the latter.
Yeah, 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 storedtogether 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.
(05:48):
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.
I'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
(06:08):
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 streamI ever do.
Every 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
(06:33):
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 thereviews, the two I will say that
come back the most often would be the extended reference and
(06:55):
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.
But 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
(07:17):
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 informationonce in a while, we'll fetch it,
but you're not going to fetch all the time.
So you're going to save a lot ofresources.
So that's the first one. The second one is in the case
(07:40):
with what you're trying to modelis 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
(08:03):
same and when you go a bit more to that all the time at the time
that you're trying to provide the answer.
So 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 forthat page, then it's going to be
much faster. Yeah.
(08:24):
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 writesin average, I'm computing the
same thing 1000 times. So why not doing it at no at
(08:46):
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.
Yeah, 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
(09:06):
want to retrieve. Yeah.
It's interesting to see that thesort 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.
And yeah. So if if somebody was trying to
going to data modeling like theymaybe been using Mongo DB for a
(09:27):
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 haveis the university courses.
(09:51):
So 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
(10:11):
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 tomodel live some of the problems
that some of our audience going to bring.
So 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
(10:33):
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 forthat, it would come up with
something in a MongoDB, a sign up page for that also, just you
(10:56):
what? Oh, that's great.
So 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.
OK, 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
(00:28):
about yourself? Like what's what's your role and
what kind of stuff do you do day-to-day as when lobby beans?
I'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
(00:49):
presentations and then we have asecond 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?
So well, I guess that was going to be my next question, talk
(01:10):
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 adesign, but really what we're
trying to do is help you on yourdata model in their design.
And then I think when you work with MongoDB, it's a little bit
(01:32):
different than what we have donewith other database, if you have
our experience and these other technologies.
So 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
(01:54):
in your first projects, you're going to come back for more.
So we and that's what that's theintent, you know, And if someone
asks how much that going to costme 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.
So generally people come in withtheir own design model that they
(02:14):
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 ofyour project and you won't see
if Mongo DB would be going to bea 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.
(02:37):
We'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
(03:00):
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.
Yeah, 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,
(03:21):
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
(03:43):
if you can. But the the requirements change
and and be sure that if you havea successful project that's
going to last for many years, things are going to change.
You know, the worker is going tochange the number of
preparations and or maybe even requirements, you know, things
that you have to start adding toyour model and.
And we're going to point out howyou can do some of the, you
know, medication all the time. Yeah, without done time and.
(04:05):
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.
Maybe both? Like give us both if they're not
the same. The one we don't like is show me
(04:26):
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
(04:46):
most important and frequent operation.
So yeah, that was, that's for methe 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.
(05:07):
I get that there are many solutions depending on what
their model kind of really is asopposed 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
(05:27):
shape. Yeah, I was thinking the latter.
Yeah, 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 storedtogether 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.
(05:48):
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.
I'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
(06:08):
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 streamI ever do.
Every 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
(06:33):
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 thereviews, the two I will say that
come back the most often would be the extended reference and
(06:55):
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.
But 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
(07:17):
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 informationonce in a while, we'll fetch it,
but you're not going to fetch all the time.
So you're going to save a lot ofresources.
So that's the first one. The second one is in the case
(07:40):
with what you're trying to modelis 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
(08:03):
same and when you go a bit more to that all the time at the time
that you're trying to provide the answer.
So 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 forthat page, then it's going to be
much faster. Yeah.
(08:24):
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 writesin average, I'm computing the
same thing 1000 times. So why not doing it at no at
(08:46):
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.
Yeah, 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
(09:06):
want to retrieve. Yeah.
It's interesting to see that thesort 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.
And yeah. So if if somebody was trying to
going to data modeling like theymaybe been using Mongo DB for a
(09:27):
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 haveis the university courses.
(09:51):
So 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
(10:11):
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 tomodel live some of the problems
that some of our audience going to bring.
So 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
(10:33):
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 forthat, it would come up with
something in a MongoDB, a sign up page for that also, just you
(10:56):
what? Oh, that's great.
So 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.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Bobby Bones Show
Listen to 'The Bobby Bones Show' by downloading the daily full replay.