Mongo Q&A

[00:00:00]
>> Speaker 1: Can Scott explain the pros and cons between Mongo NoSQL, versus traditional SQL databases like MS SQL, Oracle, Postgres?
>> Scott Moss: Wow,
>> Scott Moss: I could talk about that for a week. And I know everybody says this, but it really depends on your app. But I can tell you from practical use from my experience in the different types of apps that I've built, the pros and cons.

[00:00:26]
So pros for Mongo, for me, was that it was just easier to get started with, without having to fight a database with all of its restrictions to get something going. I mean, you will see, just in a couple lines we're able to spin up a database and throw some data in it without having to think about things like foreign keys and primary keys and ids and all that stuff.

[00:00:49]
We're able to just spin something up. So it's really great to started, so that's one thing. Two, it is very flexible. Although we do have a schema, you saw in the first attempt when I created a student, I didn't have to add a first name, and it just doesn't matter, cuz it wasn't required.

[00:01:04]
So it just adds it there and it won't freak out about it. So that can be good or bad, but it's just really flexible to get started. Three, the other thing that I've realized is that when it comes to shaping data, it's really flexible because it's just JSON by default.

[00:01:18]
Sure, Postgres now has support for like JSONB, I think, where you can just store JSON and Postgres. But how you create that JSON and how you store it is two different things. I don't think you can query the JSON and Postgres the same way you could query JSON in Mongo.

[00:01:32]
Because all the keys are actually fields in Mongo, whereas in JSON, it's just JSON. So there's a difference there. The other thing about Mongo is that it's kind of built with JavaScript in mind, and Node in mind. So it's event-based and it takes advantage of that architecture, which is really easy to work with.

[00:01:53]
So that's why I think Mongoose itself has one of the best ORMs. It's promise-based. It's modern. It kinda just works with everything. Whereas a lot of other databases, it's like, this just wasn't made for Node and you kinda gotta finesse it to do a lot of work. If you've never had to use Postgres in Node, then good for you.

[00:02:10]
If you did, you know what I'm talking about. And when you get into performance reasons and scaling and all that stuff, I think at the higher end, if you're like Google's of the world, I think Postgres and SQL's gonna perform for better. I think it's just a more complete database at that end.

[00:02:28]
I mean, Postgres and SQL's been around forever. There's just so much support on it. It's been ASIC compliant for awhile. Mongo's getting there, they're just now becoming ASIC compliant. They have transactions. And they're definitely getting there, but I would say because Postgres and SQL's been around for much longer, it's probably just gonna be better for you.

[00:02:45]
There's just more support for those types of databases. I mean, if you go to AWS, there's just so many different types of SQL databases. Sure they have Dynamo, but they also have Aurora, which is a serverless SQL database. And pretty much everybody has some SQL something. So because of support, I would say it's probably better if you're the Googles of the world.

[00:03:02]
But for everybody else, I think Mongo is just great. It's just fantastic to get going. But yeah, I think it really depends on your applications. Because if you have high writes or low reads or low reads and high writes, it's really gonna depend on what the application is and what type of server it's running on.

[00:03:20]
Are you running Mongo on Python? Are you running it on Node? That really all depends, so it's really hard to compare apples to apples. But from my experience, Mongo has just been a pleasure. I haven't run into a problem where I was like, I absolutely need SQL right now.

[00:03:33]
It's the only solution that's gonna help me. I've never run into that problem, so yeah, yes?
>> Speaker 3: Maybe you answered this, but what is Mongo written in? Is it written in C? Is it written in C++?
>> Scott Moss: Yeah,
>> Scott Moss: It's written in a lot of things. [LAUGH] You know what, I'm not going to try to answer that.

[00:03:56]
Let's go,
>> Scott Moss: See if we can find that out right now. I don't think it is on GitHub.
>> Scott Moss: I wanna say it's mostly written in C+. But I know it's written in a lot of things. So here we go, yeah, C++. So it's mostly written in C++, but you can see, like I said, it's a lot of things.

[00:04:18]
We got JavaScript, Python, Go, Shell, Java and then other, whatever that is. So yeah, it's mostly C++, but yeah, it's written a lot of things. And that's why it's a pretty compatible with JavaScript, because V8, C++. So yeah, it's a pretty good database.
>> Speaker 4: What are the ideal situations like, or applications to use Mongo and versus relational DB?

[00:04:44]
>> Scott Moss: Yes, almost every time. No, that's such a bad answer. [LAUGH] I feel like I'm selling Mongo over here. Like I need a Mongo cape. I would say for simple apps, definitely Mongo. It's just so easier. The time you save starting and getting back to the app is just free.

[00:05:03]
And then any app where the shape changes constantly, like for instance, a CMS. If you're building a CMS and you allow people to create their own custom shapes and their own custom types, their own custom schemas, you need something that can change schemas. So Mongo's perfect for that, because it's forgiving.

[00:05:20]
It's just like, yeah, you can do whatever you want. Whereas, if you use something like Postgres, you'd have to run a migration every single time somebody changed one thing. So it can get pretty annoying and then developer cost for that can just be ridiculous, like running migrations. If you have some globally deployed architecture and you're running migrations on a primary, now you gotta block everything, and then you gotta write it concern to these other databases.

[00:05:43]
It can just get pretty annoying there. So I think Mongo is just really good for those types of applications. I also think it's really good for real-time applications, for things like chats and stuff like that. It's just perfect because you can just store the data the exact same way that you need it without having any different types of formats.

[00:06:01]
You can just store an array of things and it will scale up until it hits the document collection limit. Or you can do relational if you want. So I think those type of applications are the best. Yeah, in my opinion.
>> Scott Moss: Yeah, but I wouldn't use it for something like a social network, where it's like you need graphs, right?

[00:06:21]
Yeah, you can do graphs look up in Mongo, and that's really advanced, but I wouldn't default to a Mongo database for a graph scenario or a time series database where I'm doing analytics. I wouldn't use it in that scenario. I would use it pretty much in any scenario where I'm just building a traditional application and not something that's specific to something like graphs, time series, or something like that, yeah.

[00:06:47]
>> Speaker 5: Would you recommend it for e-commerce applications?
>> Scott Moss: It's perfect for e-commerce applications. It's basically a CMS, yeah. It's fantastic for e-commerce applications, yeah, those types of apps is where it's good at. It's just a traditional, hardcore, not gonna surprise you app. Nothing that's like you're doing machine learning models with real-time web sockets that's spitting out an audit log.

[00:07:08]
Like no, that's just crazy. You can do that in Mongo, but it's gonna be pretty complicated.
>> Speaker 5: Can we store blob data types? Like from WSIWYG editors, you can get a bunch of HTML and stuff combined and then you can store it in MySQL databases.
>> Scott Moss: Yep, you can store it in whatever fort type you want.

[00:07:26]
In fact, I do that on my application that we built. We have tons of editors and we just store it as that. At the end of the day, you can store however you want, anyway that you want and you can run validations on it, too.
>> Speaker 6: So that was sort of like replications database, you can [INAUDIBLE]?

[00:07:42]
>> Scott Moss: Actually, it uses that for replication, yeah. So you don't have to do replication yourself if you use something like MongoDB Atlas. There's [INAUDIBLE]. So they do replication for you. But they use that technique to do replication, where they have primary, secondary, secondary. So yeah, they'll do that for you.

[00:07:58]
But you can also subscribe to it yourself and do all types of things. We use it to actually create an auto-log on the front end for activity on a company's profile. Like, here's everything that users have been doing in the last 20 days, and it will just format it and show you.

[00:08:12]
So we do stuff like that. So yeah, [LAUGH] if I had to create a database with something that's two years old, then, yeah, I would just make sure I don't have to create a database in something two years old and just send it somewhere else. That should be like an S3 file somewhere I would say.

[00:08:27]
That way you can just go S3, give me all the logs from the database for the last two years for this customer. And that should be backed up in S3 or Glacier on AWS, somewhere like that.
>> Speaker 1: Or Redis?
>> Scott Moss: Probably not Redis, because that's long-term storage. Redis is just short-term, in memory, and it's volitile.

[00:08:46]
It'll be erased once you restart everything. You definitely wanna put that in some cheap storage that's never, almost, gonna be touched. So, literally, Glacier is what AWS uses for that.