We learned about ordered and unordered inserts,
now there is a second option we can specify on insertOone and insertMany and that is the write concern
option,
now let me explain what the write concern is all about.
We have a client and we have our mongodb server, the client would be the shell
or your application using a mongodb driver, the mongodb server is what you start
with the mongod executable.
Now let's say you want to insert one document in there and it would also be true for insert many and
for update and so on,
so for all the write operations because it's the write concern option we're talking about.
So we're trying to insert one document, now as you learned in the first module of this course, on the mongodb
server, we have a so-called storage engine,
this is the engine being responsible for really writing our data onto the disk
and also for managing it in memory.
So your write might first end up in memory here and there, it manages the data which it needs to
access with high frequency because that is faster than working with the disk.
Of course your write is also scheduled to then end up on the disk,
that is not the thing,
so it will also eventually store your data on the disk.
Now you can configure a so-called write concern on all the write operations like insert one with an
additional argument, the write concern argument which is in turn a document where you can set settings
like that,
now what does this mean?
The w simply means
write
and the number here indicates to how many instances, in case you're using multiple instances on one server,
that is also something we'll cover towards the end of the course so
let's ignore it for now,
so on how many instances you want this write to be acknowledged. With W1 which is the default, you're
basically saying hey my mongodb server should have accepted that write,
so the storage engine is aware of it and will eventually write it to the disk. The J stands for the
journal,
the journal is an additional file which the storage engine manages which is like a To-Do file.
The journal can be kept to then for example save operations that the storage engine needs to-do that have
not been completed yet,
like the write. Now it is aware of the write and that it needs to store that data on disk just by the write
being acknowledged and being there in memory,
it doesn't need to keep a journal for that.
The idea of that journal file which is a real file on the disk is just that it is aware of this
and if the server should go down for some reason or anything else happens, that file is still there
and if you restart the server or if it recovers basically, it can look into that file and see what it
needs to-do
and that is of course a nice back up because the memory might have been wiped by then.
So your write could be lost if it's not written to the journal, if it hasn't been written to the real
data files yet, that is the idea of the journal, it's like a back up to-do list.
Now the question is why do we write it in the journal and not directly into the database files? Because
writing into the database files simply is more performance heavy,
the journal is like a single line which describes the write operation, writing into the database files
is of course a more complex task because there you need to find the right position to insert it,
if you have indexes, something we'll cover later in this course,
you also need to update these,
so it simply takes longer, adding a to-do in a journal is faster.
Still that also takes longer than not using the journal
and the default is that the journal is not getting used with j undefined
and that does simply mean that the storage engine will eventually handle this write
and also write it to the journal but you don't have that information yet, you don't know if it has
been stored in the journal yet, if the write succeeded yet, if the write has been done on the disk, you don't
know any of that,
you just know that the server is aware of your write.
So if the server should go down in that exact moment, it might indeed not have done the write because
it hasn't been added to the journal yet, it hasn't been saved to the database files yet.
Now you can set a different option and set J to true, what you're now saying is hey please only report
a success for this write to me after it has been both acknowledged and been saved to the journal,
so now I have a greater security that this will happen and succeed even if the server should face issues
right now.
Now there also is a third option
not directly related to the journal but it's a W timeout option,
now this simply means which timeframe do you give your server to report a success for this write before
you cancel it.
So if you have some issues with the network connection or anything like that, you might simply timeout
here, obviously setting this too low might timeout even though it would have perfectly succeeded
normally and therefore you should know what you do when you set this timeout value because if you
set it to a very low number, you might fail a lot
even though there is no actual problem, just some small latency.
So this is the write concern and how you can control this, obviously enabling the journal confirmation
means that your writes will take longer because you don't just tell the server about them but you also need
to wait for the server to store that write operation in the journal
but you get higher security that the write also succeeded.
Again this is a decision you have to make depending on your application needs,
what you need.
Now let's see this in practice in the next lecture.