MongoDB Q&A

[00:00:00]
>> Speaker 1: So since morning this is what I was wondering. Is Mongo dynamic?
>> Scott Moss: Dynamic as in, like what do you mean? Give me an example.
>> Speaker 1: So our servers, they have limited memory, or they're 1tb long or 5T long.
>> Scott Moss: Yeah.
>> Speaker 1: From the looks of it, it looks like it's been expanded.

[00:00:26]
>> Scott Moss: It just goes until it eats all your stores. Yeah, you don't have to set. I mean, it's not like dynamodb where you're like, you gotta tell me exactly how much you need, and then I think that's more of a business decision for them, right, cuz they charge for that.

[00:00:40]
Right, but no, Mongo's not like that. This thing will eat your whole hard drive if you let it. But like I said, there's some scientific stuff behind how they calculate how much RAM they need, how much stuff they need, and then what do they allocate for indexes versus actual data versus what's actually on disk.

[00:00:59]
It's actually pretty smart the way they do it. But yeah, if you wanna look more into that, you can look up the what's called the WiredTiger engine. If you Google that you will find days and weeks worth of information about how that works. But yeah, you can just expand this stuff forever.

[00:01:15]
You don't have to set limits when you create your database. But when you go get a hosted database, yeah, it's going to be capped, right? It's like you get a terabyte. If you want more, you got to pay for something, right? Cuz that's just what those machines that host those databases are capped to.

[00:01:31]
Yes.
>> Speaker 1: How is consistency achieved in Mongo, in SQL Server when someone's performing a write operation, it's just-
>> Scott Moss: It blocks everything.
>> Speaker 1: Yeah, there's a locking mechanism which goes on, and nobody can write it unless this user is done with his writing.
>> Scott Moss: Yeah, so that's like a ACID compliant database.

[00:01:55]
So the answer to that is Mongo 4 just came out and Mongo 5 supports this new thing, transactions. So it's the same way you would use transactions to basically create a queue to block everything and get commands and put them in a queue. And then you run those commands and then you replay them back.

[00:02:12]
So you can do that, but the thing is this is running on Node, so everything's asynchronous. So all that it was doing on database, you have another request that's coming in that's doing stuff, too. So it can also happen asynchronously, but the transactions protect you on the database level.

[00:02:26]
So you can still do transactions, but you gotta go back to think about why would you need. If you think about why you need transactions in the first place, it's because you have tables that are all separated and you need to perform one thing but that one thing touches like five tables, right?

[00:02:42]
So you gotta make sure it does this and then this. Well, if this messes up, undo this. Whereas kind of like in Mongo you can put almost everything you need for one operation in one schema. So you don't really have to think about transactions. Transactions, that's why they added it so late cuz it was an afterthought, because you could just get away without ever having to use transactions just by modeling your data with nested objects.

[00:03:03]
So if you nest your objects and everything belongs to one model, then you don't need transactions. There's only one thing to worry about, it's not many things. So that's the way you have to think about it. But if you come from a relational database background, you start modeling data in Mongo, very relational, that's actually what I did.

[00:03:20]
You run into the problem where I need transactions immediately. And that's why we were so glad when they came out with them. But then after sitting down and talking to the people at Mongo, I realized I was just modeling my data like SQL. I should have been modeling like Mongo, and we didn't need transactions any more.

[00:03:36]
But yeah, they have transactions.
>> Speaker 3: I mean, if you are worried like about the multiple users using the same data, same record at the same time, you may wanna implement something, maybe to market or something, I don't know.
>> Scott Moss: You mean if two users were-
>> Speaker 3: Editing the same thing, for example, like [INAUDIBLE] or something like that.

[00:03:56]
>> Scott Moss: If they were writing at the same time?
>> Speaker 3: Yeah, it was like they're using the same piece of data.
>> Scott Moss: Yeah, so when you write to the database in Mongo, it doesn't actually write to the database. It writes it in memory. It writes it later, right? It has a journal log, yeah.

[00:04:09]
So it doesn't write to disk immediately. It writes everything in memory. So it can figure out what's happening if it's a split second thing and then it can dedupe it. So it can figure that stuff out. If you're writing to the database and it write into memory, there's something already in memory that was operation that already happening on the same thing, it's just like a replay.

[00:04:27]
It kind of knows what's happening there. So you don't have it locked to database because it's just in the memory, everything's in the memory until it's not. And it is like a flush and then it saves it and then you're good.