We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Redo, Undo and WAL logs | The Backend Engineering Show
0:00 database logs
0:02 are a critical component of any dbms
0:06 system in order to ensure
0:09 durability and
0:12 crash recovery if you will
0:14 so
0:15 logs like
0:17 uh i'm referring to logs such as
0:19 the right ahead log or wall for short
0:24 wal that is
0:26 uh the redo
0:28 logs
0:29 and the undo logs
0:32 uh these are the only three that i know
0:34 there might be other type of logs that
0:35 are there for specific implementation
0:38 but i think these are the three most
0:40 popular
0:41 uh in fact you can argue that the wall
0:44 is actually identical to the redo logs
0:48 you know and i'm gonna talk about all of
0:50 this in this episode of the backend
0:51 engineering show it's been a while
0:54 and i'm almost recovered now so i can
0:57 do videos like this
0:59 yay
1:00 nice
1:01 coffee time
1:02 speaking of coffee
1:04 i partnered with a company called
1:06 clemeter
1:08 they
1:09 do
1:10 fantastic
1:12 coffee you know when you brew coffee
1:15 um
1:17 there are so many things that you need
1:20 to do
1:22 uh
1:24 to to nail the quantity of the beans
1:28 first
1:29 to grind them in a specific
1:33 size how coarse how fine the
1:36 the beans need to be
1:38 grinded
1:39 and once you grind it then
1:42 you brew them by basically pouring water
1:45 into them right
1:47 and
1:48 the temperature of water
1:50 really affect the taste of the final
1:53 product which is the coffee you can get
1:56 into warm
1:58 uh
1:59 warm coffee if you put too
2:02 cold of a coffee then you get basically
2:05 water flavored coffee you know if you
2:08 will or coffee flavored water if you
2:10 were too hot then you feel the burn
2:12 and that's what you basically taste in
2:14 diners coffees and it's like always like
2:16 burned and some people enjoy the burned
2:18 flavor that's why we have dark roast and
2:21 this is like a side of me that
2:23 i don't talk about in this youtube
2:25 channel i usually talk about an
2:26 instagram
2:27 but uh cometier
2:31 what they do is they they
2:33 nail all these parameters in a perfect
2:35 manner
2:36 and then
2:39 brew the coffee for you
2:42 and then they flash freeze it at that
2:45 moment of time
2:47 and they send you these nice capsules so
2:50 what you do is you take these capsules
2:53 and
2:54 you just
2:56 take it out
2:57 put in a glass water
3:00 pour hot water and that's it
3:02 you enjoy that cup of color and this is
3:05 actually committee
3:07 this is um
3:10 dominance making this is onyx coffee so
3:12 it's a medium roast but it's fantastic
3:15 so i'll leave it i'll leave a link below
3:17 if you're interested go to
3:18 commentary.com
3:21 for
3:22 uh twenty dollar off
3:24 your first order and thank you for
3:25 coming here
3:27 welcome to the backend engineering show
3:30 with your host hussein nasser and
3:34 if we really think about
3:36 durability
3:39 in database system
3:42 you are you really need to think about
3:46 how do you persist data right
3:50 well you might say i say okay you have
3:52 tables you have
3:54 data structures on those tables such as
3:56 indexes indexes
3:58 sequences constraints stuff like that
4:01 and these live in files because
4:04 that's what we have today file system so
4:07 we have to work with files you might
4:09 argue with that no
4:10 we can work with block storage directly
4:13 but
4:14 most generic implementations work with
4:16 files and there are pros and cons
4:18 right to that
4:20 right and i like to always think about
4:23 this
4:25 think about there is not only one way to
4:28 do thing
4:29 and
4:30 never pitch and hold your thing into one
4:33 thing you know always look outside the
4:36 box as cheesy as it may sound
4:38 you know trying to look outside the box
4:41 and then
4:42 understand why
4:47 do you
4:50 do you say
4:51 the things you say
4:52 you know
4:55 so if things live in files and we're
4:57 working with data files so table live in
4:59 a data file indexes live in a data file
5:01 and this is up to you as the database
5:03 implementer to whether to put these two
5:07 into one file or put them in separate
5:09 files there are pros and cons for both
5:11 cases right
5:13 and
5:14 whether you put all indexes in one file
5:16 or put each index in one file in its own
5:20 file it all really depends on the
5:22 implementation
5:24 then this is something we never think
5:27 about as back in engineers like because
5:29 hey it's behind
5:32 black box and the database does this
5:34 thing but it's good to understand how
5:36 databases are going to the database is
5:37 just a program at the end of the day
5:40 right
5:40 it's now really
5:43 well
5:44 what i was about to say rocket science
5:46 but
5:47 you can argue it is as complex as rocket
5:50 science
5:51 database engineer
5:53 um
5:55 so
5:56 when when i make a change as a
5:58 transaction i begin my transaction i
6:00 start changing my table
6:03 the changes that i make to my table will
6:05 trigger side behavior
6:08 to update indexes
6:10 and these indexes need to be updated as
6:12 a result
6:14 and the tables need to be updated as a
6:16 result
6:18 the tables consist of pages and the
6:20 pages are touched and getting dirty and
6:22 there's a little at the end of the day
6:24 we
6:25 we gonna say
6:27 commit my changes i just made a bunch of
6:29 changes go ahead and commit them
6:34 now
6:35 if i say commit my changes
6:40 what does that mean
6:45 it means logically
6:47 i want anything that's highest high
6:50 level speak
6:51 everything that i wrote i want to be
6:54 there forever
6:56 i want to see it next time i
6:58 read
7:00 right
7:02 and this means
7:04 i want it to be doable that means if the
7:06 day was shut down after i successfully
7:09 committed
7:11 that's another thing what does it mean
7:13 to successfully commit it means i
7:15 receive a successful
7:17 synchronous response from my commit
7:20 operation
7:21 so i say
7:22 yep all done when you tell me yup all
7:26 done i assume that even if i shut you
7:29 there down in that second if i unplug
7:32 you
7:33 i come back
7:35 everything that i wrote should be there
7:39 so if we go back to this commit
7:40 operation for a minute
7:42 and ask yourself how is this actually
7:45 implemented how can i implement it let's
7:48 not get pigeonholed again with
7:50 implementation
7:51 one way you would implement it and say
7:54 okay
7:55 anytime i write
7:57 if i begin my transaction i start
8:00 updating a row and inserting a new row
8:02 and i doing all these changes and i
8:04 update the indexes
8:06 i am going to make all these changes in
8:08 memory because you see if i want to
8:11 update row number seven i need to fetch
8:14 the page where row number seven lives
8:18 and update the page in memory that's
8:20 what i'm gonna do that's one
8:21 implementation i'm gonna write in memory
8:25 then i'm going to insert a new row on
8:27 the same page in memory
8:29 and then i'm going to insert another row
8:31 but this tables cluster so the page is
8:34 at the end
8:35 at the tail of the table so i need to
8:36 fish that page which
8:38 put in the pool the buffer pool the
8:40 memory
8:41 and then right there to it and i keep
8:43 writing to memory writing to my writing
8:45 memory
8:46 and that's fine
8:47 because these changes are dirty and i
8:51 didn't commit right
8:54 now if i say
8:55 if the client tells me to commit
8:58 i'll take everything that i have in
9:01 memory and i literally just
9:03 flush it to disk that means i am
9:06 overwriting
9:08 the same location where the page existed
9:12 in the file with my changes
9:16 and you can see if you make a lot of
9:18 changes the commit operation will be
9:21 slow
9:23 right this implementation
9:25 naturally because all of this stuff is
9:27 your memory and you have to take time
9:30 to persist these changing to disk trash
9:34 rises you as you write them to disk
9:37 you're taking a hit you're going to the
9:40 disk and writing these different pages
9:43 and that might take a while to write all
9:46 this
9:47 and the problem here is not the time per
9:50 se
9:50 of this implementation the problem here
9:52 what happened if i if you wrote half of
9:55 these pages and the database crash in
9:57 the middle of your commit
10:03 that is dangerous
10:07 why
10:09 because you just flushed something
10:11 and you changed
10:13 the presentation of the table
10:17 for a transaction
10:18 that was half asked
10:21 it was half committed
10:23 and what does it mean to have commit
10:25 well it doesn't mean anything
10:27 have committed transaction is a rolled
10:28 back transaction is a bad transaction
10:30 and should not be considered
10:34 that's rule number one in acid
10:36 transactions atomicity right
10:40 so that's a problem that implementation
10:42 sucks
10:44 right but it was so good because my
10:47 rights were so fast right because i am
10:50 writing all my changes are in memory
10:53 but that sucks
10:56 so what people did what computer
10:58 scientists did
10:59 we said okay computer sciences said this
11:02 what if
11:04 as i am writing these
11:07 dirty changes
11:09 i keep a log
11:12 an actual journal
11:15 of what exactly changed not the whole
11:19 thing
11:20 because remember
11:21 when you pull a page of 6 kilobyte eight
11:24 kilobyte page depending on the ssd size
11:27 and the database page size and how they
11:29 agree on that
11:31 and you change
11:33 one byte
11:35 or you change 32 bits or whatever the
11:39 size you of the row you change
11:42 and you said flush
11:44 there is no flush one byte when it comes
11:47 to disk
11:49 not until we get byte addressability on
11:52 it on ssds and hard drives it doesn't
11:54 exist today you've the minimum size is
11:58 called
11:59 and people argue about this
12:01 it's called a page i believe in ssd
12:03 sometimes it's called the block
12:04 sometimes it's called erasable unit
12:07 in a database in heart this is called
12:10 sector
12:11 there is a specific size and we don't
12:12 care what is called because names don't
12:15 go anywhere to be honest this is i've
12:16 been in this business for a long time
12:19 and everybody invents a name from their
12:21 ass okay so you can invent your
12:24 own name from your own ass
12:26 and be satisfied with that
12:28 but what what the technology does not
12:31 allow us to write one byte because of
12:34 physical limitation of the disk okay
12:36 because it's not worth it to write one
12:38 byte i believe that's the reason so we
12:41 write a bunch of them so if i change
12:44 something
12:45 that i have to write 8k
12:48 even if i change one thing right and
12:50 that's that's costly so that
12:53 back to what computer scientists say
12:54 okay because we have this limitation
12:57 and instead of
12:58 i changed one thing
13:01 let's keep a log of that thing that
13:03 changed
13:06 that's a good idea
13:08 and let's make sure that that log
13:11 is immediately persisted to disk because
13:14 that log
13:16 that uh
13:20 journal
13:21 is the source of truth
13:24 you change this
13:26 row a became b and row
13:29 column 7
13:31 in row 6 became this value and the
13:34 string hello becomes word you make
13:37 changes you can't you just
13:40 journal the changes and this is called
13:43 the right ahead log and it's called
13:45 right ahead because you're writing ahead
13:47 of time almost like you're predicting
13:52 what's gonna change because that's
13:54 that's that's what's gonna change
14:02 so
14:08 if i write this now
14:10 and i have this log and i make sure
14:13 every right i do
14:15 to the wall
14:16 to the right ahead log
14:18 is persisted to disk
14:22 then that's nice
14:23 because i can keep
14:25 my dirty pages in memory
14:29 and now
14:32 if i say commit
14:37 i already written all the changes to the
14:41 log
14:42 i have a journal
14:44 of every possible thing that my
14:46 transaction did and all other
14:48 transactions as well
14:50 so i can replay this
14:54 if i want to
14:57 so now let's let's take this into
14:59 consideration again you have a
15:01 presentation
15:02 of what the page looks like or the table
15:05 looks like on disk
15:07 you pulled it into memory and you start
15:09 making the changes in memory you still
15:11 make the changes to that page in memory
15:14 but you also take note of what these
15:18 tiny changes just what changed into this
15:21 wall so the wall will be so compact and
15:24 it's also compressed and done all sorts
15:27 of stuff to it and you flush the changes
15:30 to disk you keep those in memory you
15:33 might say hey what you're not flushing
15:35 this
15:36 it's okay not to flush it we're gonna
15:38 talk about it we're going to need to
15:39 flush it eventually but not immediately
15:42 because this are expensive these are
15:44 large pages
15:46 so now you keep all these changes
15:51 and now you say commit
15:54 commit the transaction
15:56 what is the minimum amount of work that
15:58 the database need to do to commit
16:02 well
16:03 all i have to do is just commit make
16:05 sure all the walls committed
16:08 and if the walls committed we can
16:10 persist the fact that this transaction
16:12 is successfully committed and we can
16:15 crash if we want
16:17 you might say i'm saying the pages are
16:18 old
16:20 that's true
16:21 the pages in the disk still is in its
16:24 original representation but the memory
16:28 was the final one it was it was
16:31 everything we made the changes was in
16:32 the memory
16:35 we don't have to commit that
16:37 we can try later but we don't have to
16:41 so let's do take this consideration that
16:43 i committed and i committed all the
16:45 changes in the wall
16:47 or the right ahead log
16:49 and boom
16:51 my database crashed but i committed
16:54 it comes back up
16:57 it detected that
17:00 well the page now is completely out of
17:02 sync with the wall right because the
17:05 wall is ahead
17:07 in this case
17:08 the right ahead log is literally ahead
17:11 of the data files the data files was the
17:14 old original one so the database knows
17:17 this
17:18 how does it know because there are
17:20 records of this and says oh wait a
17:22 minute
17:23 it starts off as a oop wait a minute
17:27 this is old i can't let people read this
17:30 because nobody reads from the wall
17:33 that's another question i got from the
17:34 database course uh what if i can i read
17:37 it from the wall can my transaction go
17:39 to the wall and read it that's a bad
17:41 idea
17:42 well you can
17:44 let's not say anything is a bad idea
17:46 it's just
17:46 you can if you can do anything you want
17:49 you own the software if you're building
17:50 it you own the software you can write
17:52 anything you do
17:54 you own it
17:56 you can you can decide hey let's write
17:58 from the let's read from the wall
18:00 the changes
18:02 but the work that you have to do is
18:04 enormous
18:06 and clients don't necessarily want to do
18:08 that they want to read a nice tucked in
18:10 page
18:11 and they want to just crack the rows and
18:14 read them they don't want to just
18:16 figure things out here because remember
18:18 this only has the changes you still need
18:20 more stuff so you'll end up reading
18:22 multiple places
18:24 so it can be done but it's hard
18:26 so the database crashed and stored back
18:29 and then
18:30 it detected
18:32 that there was a crash
18:34 and the page that is on this is out of
18:37 sync the wall is ahead of us
18:40 right
18:42 the right ahead log is way ahead of us
18:45 so the wall is ahead
18:49 so what does the database do takes that
18:51 page
18:53 and then reads it into memory he says
18:56 wait a minute
18:59 let me
19:00 apply
19:01 the changes in the wall to this page and
19:05 then starts
19:07 redoing the changes because at one point
19:10 we did that changes this is a redo of
19:14 these changes so you start to redo these
19:17 changes
19:18 applying these changes again because
19:20 this is have been done at one point
19:22 right but we lost it now we're redoing
19:25 it
19:26 that's why the wall is also called the
19:28 redo log
19:31 so we're redoing these changes so take
19:33 that beautiful old stale page which is
19:36 consistent by the way because at that
19:38 moment of time
19:39 we didn't then apply that that that that
19:42 all the changes that that transaction or
19:44 other transaction made
19:46 until we are done with the wall
19:50 and now that page is freshly dirty with
19:54 the latest changes so i can have clients
19:57 read from this dirty page
20:00 and
20:01 i can safely flush this page to disk
20:06 right
20:10 and now when you flush this
20:13 page to disk
20:15 you're you're now consistent with the
20:17 wall effect you might say now
20:20 now this is a very good point right we
20:23 talked about the data files on the
20:25 indexes and we talked about the wall
20:28 and how often should i flush data files
20:31 to disk it's up really it's all of this
20:34 is configurable for you
20:37 as a dba
20:39 you know there is a something called the
20:40 wall size how big the wall can get
20:43 the wall shouldn't
20:45 you think about shouldn't go infinity
20:47 right
20:49 because
20:50 once i flush
20:53 that dirty
20:54 changes
20:56 the wall
20:58 can be purged
21:00 right
21:02 because those changes are already synced
21:05 with the data files there is no point
21:07 for me to keep these old walls
21:10 all changes because those changes has
21:12 been completely the only purpose of the
21:15 wall was in case of a crash
21:17 i can recover
21:19 and redo the changes and if you did them
21:22 and all the data files are in sync why
21:24 the heck do you keep them around it's
21:26 just wasted space
21:28 that's why the wall is also presented
21:31 sometimes as a circle
21:33 right
21:34 you
21:34 you whoa whoa whoa your right right
21:36 change it
21:38 just changes and
21:40 once you end the end of the circle that
21:42 means it's time to flush
21:44 the wall is almost full go and flush
21:47 every
21:48 data file that the page and memory
21:52 down
21:53 to disk and if the flushing was
21:56 successful
21:57 go and purge the wall
21:59 he might say he's saying isn't this the
22:00 same problem that you originally start
22:02 when you started this show you talked
22:04 about that what happened if while you're
22:07 flushing that page
22:10 the database crash that's fine because
22:12 we know
22:14 right we know the moment where the
22:18 the pages were consistent
22:20 and we know that the wall is not
22:23 whatever's in the wall is the truth
22:25 so you go back and you say okay
22:28 from this point that's when things were
22:30 good
22:31 that changes all garbage
22:34 so you need to
22:35 remove all these changes
22:37 and then you have to reapply them again
22:41 so that's
22:42 that's another thing that the database
22:44 do so in the case of a car so it's a
22:46 complicated process right they take care
22:49 of all of these
22:51 situations so the
22:53 that process that we talked about just
22:55 now
22:56 where the flushing of these dirty pages
23:01 so that we can get rid of the wall
23:04 is called check pointing
23:06 and
23:08 it really happens at the most random
23:12 time
23:13 because check pointing
23:15 if you think about it
23:17 is a
23:18 data intensive i o intensive operation
23:23 because now
23:24 while i'm doing check pointing
23:27 it depends really on the database
23:28 implementation but i believe
23:31 things need to get paused
23:34 during checkpointing because you really
23:36 need to make sure that
23:38 north new things comes to the wall as
23:40 you checkpoint
23:42 you can you can you can argue that hey
23:44 i'm gonna put a checkpoint pawn on my
23:46 wall this is where i'm checkpointing
23:48 right now right everything flush
23:50 everything to disk and then yeah the
23:52 wall can continue to grow and
23:54 transaction can keep coming in and you
23:56 can implement something like that right
23:58 with a little bit of finesse engineering
24:00 i guess
24:01 right
24:03 uh yeah i believe it's going to be a
24:05 little bit complex
24:07 but this checkpointing operation and
24:09 postgres warns about it my sequel warns
24:12 about it every database warns about it
24:14 because hey
24:15 just watch out for this because
24:18 cpu
24:20 ram
24:20 disk activity will spike
24:24 as checkpoint happens
24:26 and this can happen at the most random
24:28 places you might have a very high
24:30 intensive workload
24:33 right that is happening at the same time
24:35 as a checkpoint and that will suffer as
24:37 a result do you want to suffer
24:39 well
24:40 life is suffering unfortunately so we
24:43 all need to suffer
24:46 so yeah sometimes we cannot escape this
24:48 stuff
24:50 but you have you can understand now that
24:53 if this happens
24:56 right this explains why sometimes the
24:58 query takes a fraction of a millisecond
25:01 sometimes it takes
25:03 50 milliseconds out of nowhere like what
25:06 is this because the database might be
25:08 doing something
25:10 so what do you do
25:11 well
25:12 you try to make the wall as short as
25:14 possible
25:16 right as small as possible if you make a
25:19 wall small as small as possible then the
25:21 checkpoint size will be smaller so the
25:24 flushing will be more frequent the
25:26 checkpointing one will be more frequent
25:29 and
25:30 in this case you're only flushing
25:33 certain amount of
25:34 data as a given time
25:37 and that could be tolerable and it will
25:39 be almost consistent and you can argue
25:42 that let's make the wall is so large
25:44 such that uh yeah i don't want to deal
25:47 with checkpoint in until i don't know
25:49 certain
25:50 time right
25:52 but if you kept that
25:54 that for a long time then
25:57 it can also
25:58 grow into other problems right
26:01 everything is a trade-off unfortunately
26:03 i don't have solutions to any of this
26:05 stuff it's just understanding that this
26:07 exists and we have to deal with them
26:10 all for white for dual ability
26:13 we are doing all of this for durability
26:16 we want to be durable and want to
26:18 recover and be consistent in case of a
26:20 crash
26:22 if you can guarantee that you'll never
26:24 crash
26:25 remove the wall i dare you
26:28 remove
26:29 the wall
26:38 some say computer scientists
26:41 built a wall
26:43 and the dbas
26:46 paid for it
26:48 get it
26:50 no that was a bad joke
26:53 all right
26:58 so
26:59 we talked about redo logs
27:01 which is the wall the right ahead log
27:03 and
27:04 and go go to their configuration and
27:06 you'll get to see this plastered
27:08 everywhere wall this wall that wall time
27:11 all this wool
27:12 flush time
27:14 or do you want fsync or not right
27:17 yeah let's talk about this actually the
27:19 fsync in the wall
27:22 so you see
27:23 if you are building your database on top
27:25 of an operating system
27:28 you might say what kind of stupid
27:30 statement is that i'm saying
27:31 what else are you going to build your
27:33 database on
27:35 hey i have to be
27:36 very specific because you might build
27:39 your own operating system that is a
27:41 database yeah because you might you
27:43 might you might build your own os that
27:46 happens to be a database without the
27:48 bloat
27:49 of the operating system
27:53 but if you decide if like any database
27:56 there is
27:57 to build your database that lives on top
28:00 of this blow that is called the os
28:02 the general purpose
28:05 right os
28:07 then you have to live with the rules of
28:09 the os which is linux or windows or mac
28:15 or temple os is that an os
28:17 then
28:20 there is there is something that the
28:22 operating system does because its
28:23 general purpose it doesn't trust any app
28:26 it says hey all apps are stupid
28:29 so if the day if
28:31 so so
28:32 the apps tend to do
28:34 some
28:35 repetitive job they write to the same
28:38 file multiple times in the same
28:41 microsecond
28:43 you know if the operating system let
28:45 that
28:46 right
28:47 go to disk immediately
28:49 your ssd will be
28:52 dead effectively right in
28:54 in a few
28:56 years let's say right
28:59 right because like how many times do you
29:01 write save control as controllers
29:02 controllers imagine all these rights
29:04 going immediately
29:07 right
29:08 no
29:10 uh what the operating system has is like
29:13 it has a file system cache so
29:16 if you write something it says
29:18 do you really want to write it let's
29:19 just just wait let's buffer these rights
29:22 so it it it buffers these rights in
29:24 memory
29:26 and it keeps them in memory
29:28 in the cache
29:30 hoping that it might the same page will
29:33 receive more rights because
29:35 same problem
29:37 right because
29:38 if i write one byte i have to flush the
29:40 whole disk it's just not worth it not
29:43 this whole page right it's just not
29:45 worth it so let's just wait for more
29:47 rights
29:48 that hopefully this dirty page receives
29:50 so i can flush the whole page
29:53 with with rich
29:55 dirty
29:56 rights
29:58 the more rights the page receives in
30:00 memory
30:01 like the better the economics of writing
30:04 a page because
30:06 otherwise if you write if you change one
30:08 character and that writes to desk and
30:10 then you change another character and
30:11 that writes to disk you're writing 8k 8k
30:15 8k 8k
30:17 8k 8k
30:20 every microsecond every millisecond that
30:24 you're writing and that's too much right
30:27 uh so the operating system has the cache
30:30 and waits for this cache to film then
30:33 flush that chat cache to disk
30:36 right
30:39 so
30:43 that's a problem
30:45 we talked about the wall the right
30:47 headlock
30:48 right if i if i'm if i told you to
30:53 flush the wall
30:55 change that wall i i want to make sure
30:58 the wall is actually persist don't put
31:00 it in a cache
31:01 don't try to be
31:02 smart don't try to be efficient
31:05 operating system
31:07 go to disk
31:09 i want a way to bypass this cache that
31:13 you have
31:14 right
31:15 so that's why
31:17 most databases
31:19 in certain operations right like the
31:22 wall
31:23 because wall is critical right it says
31:25 tiny things
31:27 but we need to flush them directly to
31:29 risk
31:34 and that's called fsync
31:36 that obviously is called liftsync
31:39 so if if sync is enabled which is the
31:41 default i believe
31:42 then
31:44 no if everything is disabled
31:47 right which is off that's the default
31:49 then it goes to the cache if if sync is
31:51 enabled the force the sync
31:54 make the change go directly to disk
31:58 bypass it's it's it's a make it as a
32:00 right through cache okay
32:03 punch through a hole through the cache
32:07 so yeah
32:08 you can turn it off if you want and you
32:10 gotta get a little bit more speed but in
32:12 a danger of uh losing your data
32:15 i have that option off by the way in my
32:17 testing data because i don't care it's a
32:19 testing data
32:20 and i load the data on a daily basis so
32:23 if there is a crash which is very highly
32:25 unlikely i just reordered again and
32:28 i didn't really notice much difference
32:30 to be honest but never mind
32:33 so databases have this enabled most of
32:35 the time
32:37 not necessarily postgres doesn't have it
32:39 enabled for like reading and writing
32:41 pages because we know that it's okay uh
32:44 let's write it to the cache and or
32:47 operating system cache let's read it
32:48 from the operating system cache
32:50 and that's fine
32:53 so if you think about it postgres has
32:54 almost two caches the cache in the
32:57 buffer pool like i think it's called the
32:59 working memory
33:01 or maybe it's called the buffer form i
33:03 forgot and then there is the operating
33:05 system cache itself
33:10 two layers of caching
33:13 so yeah so there's something to watch
33:15 out for
33:17 right
33:18 so yeah database engineering is very
33:19 complex
33:20 so the final thing we're going to talk
33:21 about is the undo log
33:27 who's saying
33:29 iro changes
33:32 right
33:34 and by the way
33:35 not all databases have this and undo log
33:39 thing postgres doesn't because it does
33:41 it differently
33:43 the undo log was designed specifically
33:48 for
33:50 give me the state of the row
33:54 before it was changed
33:57 am i saying
33:59 what
34:01 why
34:02 why are you doing this
34:04 well
34:05 if you are in a running transaction a
34:07 long-running transaction you're changing
34:09 changing changing changing right
34:12 right you're making changes directly to
34:15 the page right in memory
34:17 and you're writing the changes you made
34:20 to the wall
34:22 so now
34:26 what happened
34:27 to transactions
34:29 that
34:30 started before you
34:34 right
34:37 transaction have this thing that's
34:38 called isolation level
34:40 since they started before you make this
34:42 change and you still didn't commit
34:45 right in almost all isolation levels
34:48 accelerated and committed
34:51 those transactions need the old state of
34:55 the row before you changed it
34:58 so it cannot read from the page that is
35:01 dirty because it has the latest stuff it
35:03 does not need the related stuff
35:07 it needs the old state
35:11 so what the database do
35:12 is they keep a record of the undue log
35:17 specifically
35:18 how this role looked like in its
35:21 entirety
35:23 right
35:24 in a old
35:26 row
35:28 in a in a specific log area that's
35:30 called the undo log
35:32 oracle sql server i believe
35:36 uh i'm not 100 sure about sql server but
35:39 my sequel and oracle have this model
35:41 which is the undo log right postgres
35:44 doesn't
35:46 because it uses versioning
35:48 a virgin is the row
35:51 postgres
35:52 makes the changes in the page right it
35:56 if you made an update it's a new role in
35:59 postgres so the old row already lives
36:01 which is perfect right
36:03 i i love this design like much better if
36:06 you think about it
36:08 again it's all personal at the end of
36:10 the day
36:11 preferences
36:13 but now all transactions
36:17 that want to read rows that have been
36:19 changed
36:21 those rows don't exist on the page
36:24 so that they have to do a little bit
36:25 more extra work they have to go to the
36:28 undo log
36:29 crack it open
36:31 i don't know what that means crack it
36:32 open
36:33 just want to make sure that it's slower
36:36 that's why i said that
36:38 and then
36:39 take the page the row from the page and
36:42 then
36:43 undo the changes that because the row is
36:46 latest you want to undo the changes you
36:49 want to apply changes to make it
36:52 older if you will right
36:55 so you want to undo these changes
36:59 so that
37:00 uh
37:01 it goes back effectively
37:06 to the old state so you can read it
37:09 so a little bit more work
37:12 for
37:14 older transactions
37:16 or for that matter newer transactions
37:19 right
37:21 because
37:22 the problem is
37:24 we have a transaction that did not
37:26 commit
37:27 we have a long running transaction
37:29 that's why a long-running transaction is
37:31 is the worse
37:33 for performance reasons
37:35 because we the undo log will keep
37:37 filling up and
37:39 those
37:40 transactions will have to go to the log
37:42 and crack it open and apply the changes
37:45 and roll back if you will to read the
37:48 old roads it has to do this all the time
37:50 and you might say you can do all sorts
37:52 of caching but this is work that the
37:55 databases has to do if you think about
37:57 right
37:58 it's all work
38:00 saying do you persist the undo log i
38:04 believe you should
38:06 right
38:07 let's think this through you should do
38:09 the same with the undo log as you do
38:11 with the redo log
38:14 because the reader lock tells you what's
38:16 the final state right
38:19 the undo log tells you
38:21 the
38:23 the older states
38:26 right
38:27 and the correct way to do this is in
38:30 case of a crash you're going to have a
38:32 bunch of wall
38:34 which is the reduce log and then you're
38:37 going to have the undo logs
38:39 and you've got to have a state
38:41 of the page as it existed in desk so in
38:44 case of a crash you have the undo log
38:46 you have the redo log you have the old
38:48 page okay so what do you do
38:50 the correct order is take that page and
38:53 whatever is in the wall is the truth
38:55 apply all the wall changes
38:59 apply all of them
39:01 and then
39:02 because you might have applied stuff
39:04 from a transaction that have been rolled
39:06 back
39:07 right
39:08 go and take the undo log and then redo
39:13 redo
39:15 undo the changes up until the point
39:18 where the transaction has been rolled
39:20 back
39:22 all right so you're going to read what
39:23 you do
39:24 and then undo undo undo and
39:27 until you reach a consistent state right
39:30 that's one one implementation that i can
39:32 think of
39:33 right can you not persist undo log and
39:37 only apply the redo logs for transaction
39:40 that has committed
39:42 i suppose
39:44 you can
39:45 but then you have to differentiate
39:48 uh
39:49 committed transactions
39:51 versus not committed transaction in the
39:53 wall
39:54 right which i believe that information
39:56 doesn't exist a wall has changes and it
39:59 doesn't know if this is from this
40:01 transaction versus that transaction
40:03 i suppose you can store this information
40:05 another
40:07 data file
40:09 containing the transactions that are
40:11 being committed but it's just easier
40:13 this way
40:14 i don't know
40:16 guys
40:17 this has been an episode of the back
40:19 engineering show discussing the logs
40:22 of the database
40:23 and pretty sure i missed some of this
40:25 stuff but i believe that's the one of
40:27 the most important things you know logs
40:30 undo log wall
40:32 and
40:34 the radio logs
40:36 can i see in the next one hope you
40:37 enjoyed this one stay awesome goodbye
0:00 Nhật ký cơ sở dữ liệu là một phần vô cùng quan trọng của bất kỳ hệ thống DBMS nào, nó đảm bảo tính bền vững và khả năng phục hồi sau sự cố.
0:15 Vậy nên, nhật ký, ý tôi là các loại nhật ký như nhật ký ghi trước, hay còn gọi là WAL, là nhật ký redo và nhật ký undo.
0:32 Theo tôi biết thì chỉ có ba loại này thôi. Có thể có thêm các loại nhật ký khác tùy thuộc vào từng cách triển khai cụ thể, nhưng tôi nghĩ đây là ba loại phổ biến nhất.
0:41 Thực tế thì, bạn có thể tranh luận rằng WAL thực chất giống hệt với nhật ký redo, và tôi sẽ nói về tất cả những điều này trong tập Backend Engineering Show hôm nay. Cũng lâu rồi tôi mới làm lại video này, giờ thì tôi gần như khỏe hẳn rồi.
0:59 Yay! Đến giờ uống cà phê rồi.
1:02 Nhân tiện nói về cà phê, tôi đang hợp tác với một công ty tên là clemeter.
1:08 Họ làm cà phê rất ngon. Bạn biết đấy, khi pha cà phê, có rất nhiều công đoạn cần thực hiện.
1:24 Đầu tiên là phải xác định chính xác lượng hạt, sau đó xay chúng đến một kích thước nhất định, độ thô, độ mịn của hạt cần xay.
1:39 Xay xong thì mình pha bằng cách đổ nước vào, đúng không?
1:47 Và nhiệt độ của nước thực sự ảnh hưởng đến hương vị cuối cùng của cà phê.
1:53 Nếu bạn cho quá nhiều nước lạnh thì cà phê sẽ bị loãng, hoặc nói đúng hơn là nước có vị cà phê.
2:08 Còn nếu nước quá nóng thì cà phê sẽ bị khét, và đó là vị mà bạn thường thấy ở cà phê trong các quán ăn, lúc nào cũng bị khét. Một số người lại thích cái vị khét đó. Đó là lý do tại sao chúng ta có cà phê rang đậm, và đây là một khía cạnh mà tôi ít khi chia sẻ trên kênh YouTube này. Tôi thường nói về nó trên Instagram hơn.
2:27 Nhưng, Cometier, họ làm rất tốt việc xác định chính xác tất cả các thông số này, và sau đó pha cà phê cho bạn, rồi đóng băng nhanh ngay lập tức.
2:47 Họ gửi cho bạn những viên nang rất đẹp. Bạn chỉ cần lấy viên nang ra, cho vào cốc, đổ nước nóng vào là xong.
3:02 Bạn có thể thưởng thức tách cà phê ngon lành. Đây là sản phẩm của Committee. Đây là cà phê Onyx, loại rang vừa, nhưng rất ngon.
3:15 Tôi sẽ để đường link ở bên dưới nếu bạn quan tâm. Hãy truy cập commentary(dot)com để được giảm giá hai mươi đô la cho đơn hàng đầu tiên. Cảm ơn các bạn đã theo dõi.
3:27 Chào mừng đến với Backend Engineering Show, người dẫn chương trình là Hussein Nasser.
3:34 Nếu chúng ta thực sự nghĩ về tính bền vững trong một hệ thống cơ sở dữ liệu, thì điều quan trọng là phải suy nghĩ về cách bạn lưu trữ dữ liệu, đúng không?
3:50 Bạn có thể nói rằng, "Được rồi, chúng ta có các bảng, có các cấu trúc dữ liệu trên các bảng đó như chỉ mục, chuỗi, ràng buộc, vân vân, và chúng tồn tại trong các tệp vì đó là những gì chúng ta có ngày nay, hệ thống tệp, vì vậy chúng ta phải làm việc với các tệp."
4:09 Bạn có thể tranh luận rằng chúng ta có thể làm việc trực tiếp với bộ nhớ khối, nhưng hầu hết các triển khai chung đều làm việc với các tệp, và điều này có cả ưu và nhược điểm, đúng không?
4:20 Tôi luôn thích nghĩ về điều này, hãy nhớ rằng không chỉ có một cách để làm mọi việc và đừng quá cố chấp với một điều gì đó. Hãy luôn suy nghĩ vượt ra khỏi khuôn khổ, dù nghe có vẻ sáo rỗng.
4:38 Hãy cố gắng nhìn nhận mọi thứ một cách khác biệt, và sau đó hiểu tại sao bạn lại nói những điều bạn nói.
4:55 Vì vậy, nếu mọi thứ tồn tại trong các tệp và chúng ta đang làm việc với các tệp dữ liệu, thì các bảng tồn tại trong một tệp dữ liệu, các chỉ mục tồn tại trong một tệp dữ liệu. Việc bạn, với tư cách là người triển khai cơ sở dữ liệu, quyết định gộp hai thứ này vào một tệp hay đặt chúng trong các tệp riêng biệt là tùy thuộc vào bạn. Cả hai cách đều có ưu và nhược điểm riêng, đúng không?
5:13 Việc bạn đặt tất cả các chỉ mục vào một tệp hay đặt mỗi chỉ mục vào một tệp riêng biệt, tất cả đều phụ thuộc vào cách triển khai.
5:24 Đây là điều mà chúng ta, những kỹ sư back-end, thường không nghĩ đến, bởi vì nó nằm sau một hộp đen và cơ sở dữ liệu sẽ tự động xử lý. Nhưng việc hiểu cách cơ sở dữ liệu hoạt động là rất tốt. Cơ sở dữ liệu, xét cho cùng, cũng chỉ là một chương trình, đúng không?
5:40 Nó không hẳn là khoa học tên lửa, nhưng bạn có thể tranh luận rằng nó phức tạp như khoa học tên lửa, kỹ sư cơ sở dữ liệu.
5:56 Vì vậy, khi tôi thực hiện một thay đổi, ví dụ như một giao dịch, tôi bắt đầu giao dịch của mình, tôi bắt đầu thay đổi bảng của mình.
6:03 Những thay đổi mà tôi thực hiện đối với bảng sẽ kích hoạt các hành vi phụ để cập nhật chỉ mục, và các chỉ mục này cần được cập nhật theo đó, và các bảng cũng cần được cập nhật theo đó.
6:18 Các bảng bao gồm các trang, và các trang bị chạm vào và bị bẩn. Đến cuối ngày, chúng ta sẽ nói "hãy cam kết các thay đổi của tôi".
6:27 Tôi vừa thực hiện một loạt các thay đổi, hãy cam kết chúng.
6:34 Vậy, "cam kết các thay đổi của tôi" có nghĩa là gì?
6:45 Về mặt logic, tôi muốn mọi thứ ở cấp cao nhất, mọi thứ tôi đã viết, đều phải ở đó vĩnh viễn.
6:56 Tôi muốn nhìn thấy nó vào lần tới khi tôi đọc, đúng không?
7:02 Và điều này có nghĩa là tôi muốn nó có thể thực hiện được. Điều đó có nghĩa là nếu máy bị tắt sau khi tôi cam kết thành công, thì đó lại là một chuyện khác.
7:11 "Cam kết thành công" có nghĩa là gì?
7:13 Điều đó có nghĩa là tôi nhận được phản hồi đồng bộ thành công từ hoạt động cam kết của mình.
7:21 Vì vậy, tôi nói, "Vâng, tất cả đã xong." Khi bạn nói với tôi, "Vâng, tất cả đã xong," tôi cho rằng ngay cả khi tôi tắt bạn ngay lúc đó, nếu tôi rút phích cắm của bạn.
7:33 Khi tôi quay lại, mọi thứ tôi đã viết phải ở đó.
7:39 Vậy, nếu chúng ta quay lại hoạt động cam kết này một chút và tự hỏi làm thế nào nó thực sự được triển khai, làm thế nào tôi có thể triển khai nó?
7:48 Đừng quá bó hẹp vào một cách triển khai.
7:51 Một cách bạn có thể triển khai nó là nói, "Được rồi, bất cứ khi nào tôi viết, nếu tôi bắt đầu giao dịch của mình, tôi bắt đầu cập nhật một hàng và chèn một hàng mới, và tôi thực hiện tất cả những thay đổi này và tôi cập nhật các chỉ mục, tôi sẽ thực hiện tất cả những thay đổi này trong bộ nhớ."
8:08 Bởi vì bạn thấy đấy, nếu tôi muốn cập nhật hàng số bảy, tôi cần tìm nạp trang nơi hàng số bảy tồn tại và cập nhật trang đó trong bộ nhớ. Đó là những gì tôi sẽ làm. Đó là một cách triển khai.
8:21 Tôi sẽ viết vào bộ nhớ, sau đó tôi sẽ chèn một hàng mới trên cùng một trang trong bộ nhớ, và sau đó tôi sẽ chèn một hàng khác, nhưng bảng này được nhóm lại, vì vậy trang ở cuối, ở đuôi của bảng, vì vậy tôi cần tìm trang đó, trang đó được đặt trong nhóm, nhóm bộ đệm, bộ nhớ, và sau đó viết vào đó, và tôi tiếp tục viết vào bộ nhớ, viết vào bộ nhớ viết của mình, và điều đó không sao vì những thay đổi này bị bẩn và tôi chưa cam kết, phải không?
8:54 Bây giờ, nếu tôi nói, nếu máy khách yêu cầu tôi cam kết, tôi sẽ lấy mọi thứ tôi có trong bộ nhớ và tôi chỉ cần xả nó vào đĩa.
9:03 Điều đó có nghĩa là tôi đang ghi đè lên cùng một vị trí nơi trang tồn tại trong tệp bằng những thay đổi của mình.
9:16 Và bạn có thể thấy nếu bạn thực hiện nhiều thay đổi, hoạt động cam kết sẽ rất chậm, đúng không?
9:23 Cách triển khai này vốn dĩ chậm, vì tất cả những thứ này nằm trong bộ nhớ của bạn và bạn cần thời gian để lưu trữ những thay đổi này vào đĩa.
9:34 Việc ghi chúng vào đĩa sẽ làm tăng thêm gánh nặng, bạn đang phải truy cập vào đĩa và ghi các trang khác nhau này, và có thể mất một khoảng thời gian để ghi tất cả những thứ này.
9:47 Vấn đề ở đây không chỉ là thời gian thực hiện của cách triển khai này. Vấn đề là gì sẽ xảy ra nếu, nếu bạn đã ghi một nửa số trang này và cơ sở dữ liệu bị sập trong quá trình cam kết của bạn?
10:03 Điều đó thật nguy hiểm.
10:07 Tại sao?
10:09 Bởi vì bạn vừa xả một phần dữ liệu và bạn đã thay đổi cách trình bày của bảng cho một giao dịch dở dang.
10:21 Nó mới chỉ được cam kết một nửa, và "cam kết" có nghĩa là gì?
10:25 Chà, nó chẳng có nghĩa gì cả.
10:27 Giao dịch đã cam kết một phần là một giao dịch bị lỗi, là một giao dịch không hợp lệ và không nên được xem xét.
10:34 Đó là quy tắc số một trong các giao dịch ACID, tính nguyên tử, đúng không?
10:40 Vì vậy, đó là một vấn đề. Cách triển khai đó thật tệ, đúng không?
10:44 Nhưng nó rất tốt vì việc ghi của tôi rất nhanh, đúng không?
10:47 Bởi vì tôi đang viết tất cả những thay đổi của mình đều nằm trong bộ nhớ, nhưng điều đó thật tệ.
10:56 Vì vậy, những gì mọi người đã làm, những gì các nhà khoa học máy tính đã làm, chúng tôi nói, được rồi, các nhà khoa học máy tính đã nói điều này, điều gì sẽ xảy ra nếu, khi tôi đang viết những thay đổi bẩn này, tôi giữ một nhật ký, một bản ghi thực tế về những gì chính xác đã thay đổi, không phải toàn bộ mọi thứ?
11:20 Bởi vì hãy nhớ rằng, khi bạn kéo một trang 6 kilobyte, trang 8 kilobyte, tùy thuộc vào kích thước SSD và kích thước trang cơ sở dữ liệu và cách chúng đồng ý về điều đó, và bạn thay đổi một byte, hoặc bạn thay đổi 32 bit hoặc bất kỳ kích thước nào bạn thay đổi của hàng, và bạn nói "xả", không có chuyện xả một byte khi nói đến đĩa.
11:49 Cho đến khi chúng ta có khả năng định địa chỉ byte trên đó, trên SSD và ổ cứng, nó không tồn tại ngày nay.
11:54 Bạn có kích thước tối thiểu được gọi là, và mọi người tranh luận về điều này, nó được gọi là một trang, tôi tin vào SSD, đôi khi nó được gọi là khối, đôi khi nó được gọi là đơn vị có thể xóa.
12:07 Trong một cơ sở dữ liệu trong trái tim, điều này được gọi là khu vực.
12:11 Có một kích thước cụ thể và chúng ta không quan tâm nó được gọi là gì vì tên không đi đến đâu để thành thật mà nói.
12:15 Đây là tôi đã ở trong ngành kinh doanh này trong một thời gian dài và mọi người đều phát minh ra một cái tên từ mông của họ, được chứ?
12:21 Vì vậy, bạn có thể phát minh ra tên riêng của mình từ mông của bạn và hài lòng với điều đó.
12:28 Nhưng những gì công nghệ không cho phép chúng ta viết một byte vì giới hạn vật lý của đĩa, được chứ?
12:36 Bởi vì không đáng để viết một byte, tôi tin rằng đó là lý do, vì vậy chúng ta viết một loạt chúng.
12:41 Vì vậy, nếu tôi thay đổi một cái gì đó mà tôi phải viết 8k ngay cả khi tôi thay đổi một thứ, phải không?
12:49 Và điều đó rất tốn kém.
12:53 Vì vậy, quay lại những gì các nhà khoa học máy tính nói, được rồi, vì chúng ta có giới hạn này và thay vì tôi thay đổi một thứ, hãy giữ một nhật ký về thứ đã thay đổi đó.
13:06 Đó là một ý tưởng hay, và hãy đảm bảo rằng nhật ký đó được lưu trữ ngay lập tức vào đĩa vì nhật ký đó, bản ghi đó là nguồn gốc của sự thật.
13:24 Bạn thay đổi điều này, hàng A trở thành B và cột 7 trong hàng 6 trở thành giá trị này và chuỗi "xin chào" trở thành từ.
13:37 Bạn thực hiện các thay đổi, bạn không thể chỉ ghi lại các thay đổi, và điều này được gọi là nhật ký ghi trước, và nó được gọi là ghi trước vì bạn đang viết trước thời hạn, gần như bạn đang dự đoán những gì sẽ thay đổi vì đó là những gì sẽ thay đổi.
14:08 Vì vậy, nếu tôi viết điều này ngay bây giờ và tôi có nhật ký này và tôi đảm bảo mọi quyền mà tôi thực hiện đối với WAL, đối với nhật ký ghi trước, đều được lưu trữ vào đĩa, thì điều đó thật tuyệt vì tôi có thể giữ các trang bẩn của mình trong bộ nhớ.
14:29 Và bây giờ, nếu tôi nói "cam kết", tôi đã viết tất cả các thay đổi vào nhật ký.
14:42 Tôi có một bản ghi về mọi thứ mà giao dịch của tôi đã thực hiện và tất cả các giao dịch khác, vì vậy tôi có thể phát lại điều này nếu tôi muốn.
14:57 Vì vậy, bây giờ hãy xem xét điều này một lần nữa.
14:59 Bạn có một bản trình bày về trang trông như thế nào hoặc bảng trông như thế nào trên đĩa.
15:07 Bạn kéo nó vào bộ nhớ và bạn bắt đầu thực hiện các thay đổi trong bộ nhớ. Bạn vẫn thực hiện các thay đổi đối với trang đó trong bộ nhớ.
15:14 Nhưng bạn cũng ghi lại những thay đổi nhỏ này, chỉ những gì đã thay đổi thành WAL này.
15:21 Vì vậy, WAL sẽ rất nhỏ gọn và nó cũng được nén và thực hiện tất cả các loại thứ cho nó, và bạn xả các thay đổi vào đĩa.
15:30 Bạn giữ chúng trong bộ nhớ. Bạn có thể nói, "Này, bạn không xả cái này."
15:36 Không sao nếu không xả nó. Chúng ta sẽ nói về nó. Cuối cùng chúng ta sẽ cần phải xả nó, nhưng không phải ngay lập tức vì chúng đắt tiền. Đây là những trang lớn.
15:46 Vì vậy, bây giờ bạn giữ tất cả những thay đổi này, và bây giờ bạn nói "cam kết", cam kết giao dịch.
15:56 Số lượng công việc tối thiểu mà cơ sở dữ liệu cần thực hiện để cam kết là bao nhiêu?
16:03 Chà, tất cả những gì tôi phải làm là chỉ cần cam kết, đảm bảo tất cả các WAL đã cam kết.
16:08 Và nếu các WAL đã cam kết, chúng ta có thể lưu trữ thực tế rằng giao dịch này đã được cam kết thành công và chúng ta có thể gặp sự cố nếu chúng ta muốn.
16:17 Bạn có thể nói tôi đang nói các trang đã cũ.
16:21 Điều đó đúng. Các trang trên đĩa vẫn ở dạng ban đầu, nhưng bộ nhớ là trang cuối cùng.
16:31 Đó là, đó là tất cả những gì chúng ta đã thực hiện các thay đổi đều nằm trong bộ nhớ.
16:35 Chúng ta không cần phải cam kết điều đó. Chúng ta có thể thử sau, nhưng chúng ta không cần phải.
16:41 Vì vậy, hãy xem xét điều này rằng tôi đã cam kết và tôi đã cam kết tất cả các thay đổi trong WAL, hoặc nhật ký ghi trước, và bùm, cơ sở dữ liệu của tôi bị sập, nhưng tôi đã cam kết.
16:54 Nó quay trở lại.
16:57 Nó phát hiện ra rằng, chà, trang bây giờ hoàn toàn không đồng bộ với WAL, phải không?
17:05 Bởi vì WAL đang ở phía trước.
17:08 Trong trường hợp này, nhật ký ghi trước thực sự đi trước các tệp dữ liệu. Các tệp dữ liệu là bản gốc cũ, vì vậy cơ sở dữ liệu biết điều này.
17:18 Làm thế nào nó biết?
17:19 Bởi vì có các bản ghi về điều này và nói, ồ, đợi một chút.
17:23 Nó bắt đầu như một oop, đợi một chút, cái này cũ rồi.
17:27 Tôi không thể để mọi người đọc cái này vì không ai đọc từ WAL.
17:33 Đó là một câu hỏi khác mà tôi nhận được từ khóa học cơ sở dữ liệu. Uh, điều gì sẽ xảy ra nếu tôi có thể đọc nó từ WAL?
17:37 Giao dịch của tôi có thể đi đến WAL và đọc nó không?
17:39 Đó là một ý tưởng tồi.
17:42 Chà, bạn có thể, đừng nói bất cứ điều gì là một ý tưởng tồi.
17:46 Chỉ là, bạn có thể nếu bạn có thể làm bất cứ điều gì bạn muốn.
17:49 Bạn sở hữu phần mềm. Nếu bạn đang xây dựng nó, bạn sở hữu phần mềm. Bạn có thể viết bất cứ điều gì bạn làm.
17:56 Bạn sở hữu nó. Bạn có thể bạn có thể quyết định, này, hãy viết từ hãy đọc từ WAL, những thay đổi.
18:02 Nhưng công việc bạn phải làm là rất lớn, và khách hàng không nhất thiết muốn làm điều đó.
18:08 Họ muốn đọc một trang được giấu kín đẹp mắt và họ chỉ muốn bẻ khóa các hàng và đọc chúng.
18:14 Họ không muốn phải tìm kiếm mọi thứ ở đây vì hãy nhớ rằng WAL chỉ chứa những thay đổi.
18:18 Bạn vẫn cần nhiều thứ hơn, vì vậy bạn sẽ phải đọc từ nhiều nơi, việc này có thể thực hiện được, nhưng rất khó.
18:26 Vì vậy, cơ sở dữ liệu bị sập và khởi động lại, và sau đó nó phát hiện ra rằng có sự cố và trang trên trang này không đồng bộ.
18:37 WAL đi trước chúng ta, đúng không?
18:42 Nhật ký ghi trước đi trước chúng ta rất nhiều.
18:45 Vì vậy, WAL đi trước.
18:49 Vậy cơ sở dữ liệu làm gì?
18:51 Lấy trang đó và sau đó đọc nó vào bộ nhớ. Nó nói, "Đợi một chút, hãy để tôi áp dụng các thay đổi trong WAL cho trang này" và sau đó bắt đầu làm lại các thay đổi vì tại một thời điểm chúng ta đã thực hiện những thay đổi đó.
19:10 Đây là một sự làm lại của những thay đổi này, vì vậy bạn bắt đầu làm lại những thay đổi này, áp dụng lại những thay đổi này vì điều này đã được thực hiện tại một thời điểm, phải không?
19:22 Nhưng chúng ta đã mất nó. Bây giờ chúng ta đang làm lại nó.
19:26 Đó là lý do tại sao WAL còn được gọi là nhật ký redo.
19:31 Vì vậy, chúng ta đang làm lại những thay đổi này, vì vậy hãy lấy trang cũ lỗi thời tuyệt đẹp đó, trang này nhất quán, bởi vì tại thời điểm đó, chúng ta đã không áp dụng tất cả những thay đổi mà giao dịch đó hoặc giao dịch khác đã thực hiện cho đến khi chúng ta hoàn thành WAL.
19:50 Và bây giờ trang đó mới bị bẩn với những thay đổi mới nhất, vì vậy tôi có thể cho phép khách hàng đọc từ trang bẩn này và tôi có thể xả trang này một cách an toàn vào đĩa, phải không?
20:10 Và bây giờ khi bạn xả trang này vào đĩa, bạn hiện đã nhất quán với hiệu ứng WAL.
20:17 Bạn có thể nói bây giờ, bây giờ đây là một điểm rất tốt, phải không?
20:23 Chúng ta đã nói về các tệp dữ liệu trên các chỉ mục và chúng ta đã nói về WAL, và tôi nên xả các tệp dữ liệu vào đĩa bao lâu một lần?
20:31 Điều đó thực sự tùy thuộc vào bạn. Tất cả điều này đều có thể định cấu hình cho bạn với tư cách là DBA.
20:39 Bạn biết đấy, có một thứ gọi là kích thước WAL, WAL có thể lớn đến mức nào.
20:43 WAL không nên, bạn nghĩ không nên đi đến vô cực, phải không?
20:50 Bởi vì một khi tôi xả những thay đổi bẩn đó, WAL có thể bị xóa, phải không?
21:02 Bởi vì những thay đổi đó đã được đồng bộ hóa với các tệp dữ liệu. Không có lý do gì để tôi giữ những WAL cũ này, tất cả các thay đổi vì những thay đổi đó đã hoàn toàn được áp dụng.
21:12 Mục đích duy nhất của WAL là trong trường hợp xảy ra sự cố, tôi có thể khôi phục và làm lại các thay đổi.
21:19 Và nếu bạn đã thực hiện chúng và tất cả các tệp dữ liệu đều được đồng bộ hóa, thì tại sao bạn lại giữ chúng xung quanh?
21:24 Nó chỉ là không gian lãng phí.
21:28 Đó là lý do tại sao WAL đôi khi cũng được trình bày dưới dạng một vòng tròn, phải không?
21:34 Bạn, bạn woa woa woa quyền của bạn thay đổi nó.
21:40 Và một khi bạn kết thúc vòng tròn, điều đó có nghĩa là đã đến lúc xả.
21:44 WAL gần như đầy, hãy đi và xả mọi tệp dữ liệu mà trang và bộ nhớ xuống đĩa.
21:53 Và nếu việc xả thành công, hãy đi và xóa WAL.
21:59 Anh ấy có thể nói anh ấy đang nói chẳng phải đây là vấn đề tương tự mà bạn đã bắt đầu ban đầu khi bạn bắt đầu chương trình này sao?
22:04 Bạn đã nói về điều gì sẽ xảy ra nếu trong khi bạn đang xả trang đó, cơ sở dữ liệu bị sập?
22:10 Điều đó không sao vì chúng ta biết, phải không?
22:14 Chúng ta biết thời điểm mà
22:18 Các trang nhất quán và chúng ta biết rằng WAL không phải là, bất cứ điều gì trong WAL là sự thật.
22:25 Vì vậy, bạn quay lại và bạn nói, được rồi, từ thời điểm này, đó là khi mọi thứ tốt đẹp.
22:31 Những thay đổi đó đều là rác, vì vậy bạn cần loại bỏ tất cả những thay đổi này và sau đó bạn phải áp dụng lại chúng.
22:41 Vì vậy, đó là một điều khác mà cơ sở dữ liệu làm.
22:44 Vì vậy, trong trường hợp xe hơi, đó là một quá trình phức tạp, phải không?
22:46 Họ chăm sóc tất cả những tình huống này.
22:51 Vì vậy, quá trình mà chúng ta đã nói về ngay bây giờ, nơi xả các trang bẩn này để chúng ta có thể loại bỏ WAL được gọi là kiểm tra điểm.
23:06 Và nó thực sự xảy ra vào thời điểm ngẫu nhiên nhất vì kiểm tra điểm, nếu bạn nghĩ về nó, là một hoạt động chuyên sâu về dữ liệu, chuyên sâu về I/O.
23:23 Bởi vì bây giờ, trong khi tôi đang thực hiện kiểm tra điểm, nó thực sự phụ thuộc vào việc triển khai cơ sở dữ liệu, nhưng tôi tin rằng mọi thứ cần phải tạm dừng trong quá trình kiểm tra điểm vì bạn thực sự cần đảm bảo rằng không có điều gì mới đến WAL khi bạn kiểm tra điểm.
23:42 Bạn có thể bạn có thể tranh luận rằng, này, tôi sẽ đặt một con tốt kiểm tra điểm trên WAL của mình.
23:46 Đây là nơi tôi đang kiểm tra điểm ngay bây giờ, phải không?
23:48 Mọi thứ xả, mọi thứ vào đĩa và sau đó có, WAL có thể tiếp tục phát triển và giao dịch có thể tiếp tục đến và bạn có thể triển khai một cái gì đó như thế, phải không?
23:58 Với một chút kỹ thuật khéo léo, tôi đoán vậy, phải không?
24:03 Uh, có, tôi tin rằng nó sẽ hơi phức tạp, nhưng hoạt động kiểm tra điểm này và Postgres cảnh báo về nó, my sequel cảnh báo về nó, mọi cơ sở dữ liệu đều cảnh báo về nó vì, này, chỉ cần xem chừng điều này vì CPU, RAM, hoạt động của đĩa sẽ tăng đột biến khi kiểm tra điểm xảy ra.
24:26 Và điều này có thể xảy ra ở những nơi ngẫu nhiên nhất.
24:28 Bạn có thể có một khối lượng công việc chuyên sâu rất cao, phải không?
24:33 Điều đó đang xảy ra đồng thời với một điểm kiểm tra và điều đó sẽ bị ảnh hưởng do đó.
24:37 Bạn có muốn chịu đựng không?
24:40 Chà, cuộc sống là đau khổ, thật không may, vì vậy tất cả chúng ta cần phải chịu đựng.
24:46 Vì vậy, có, đôi khi chúng ta không thể thoát khỏi những thứ này, nhưng bạn có thể hiểu bây giờ rằng nếu điều này xảy ra, phải không?
24:56 Điều này giải thích tại sao đôi khi truy vấn mất một phần nghìn giây, đôi khi mất 50 mili giây một cách bất ngờ, như cái này là cái gì?
25:06 Bởi vì cơ sở dữ liệu có thể đang làm điều gì đó.
25:10 Vậy bạn làm gì?
25:11 Chà, bạn cố gắng làm cho WAL càng ngắn càng tốt, phải không?
25:16 Càng nhỏ càng tốt. Nếu bạn làm cho WAL càng nhỏ càng tốt, thì kích thước điểm kiểm tra sẽ nhỏ hơn, vì vậy việc xả sẽ thường xuyên hơn, điểm kiểm tra sẽ thường xuyên hơn và trong trường hợp này, bạn chỉ xả một lượng dữ liệu nhất định tại một thời điểm nhất định và điều đó có thể chấp nhận được và nó sẽ gần như nhất quán.
25:42 Và bạn có thể tranh luận rằng hãy làm cho WAL lớn đến mức mà uh có, tôi không muốn đối phó với điểm kiểm tra cho đến khi tôi không biết một thời gian nhất định, phải không?
25:52 Nhưng nếu bạn giữ điều đó trong một thời gian dài thì nó cũng có thể phát triển thành các vấn đề khác, phải không?
26:01 Thật không may, mọi thứ đều là sự đánh đổi.
26:03 Tôi không có giải pháp cho bất kỳ thứ nào trong số này.
26:05 Chỉ là hiểu rằng điều này tồn tại và chúng ta phải đối phó với chúng tất cả vì khả năng kép trắng.
26:13 Chúng ta đang làm tất cả những điều này vì độ bền.
26:16 Chúng ta muốn bền bỉ và muốn phục hồi và nhất quán trong trường hợp xảy ra sự cố.
26:22 Nếu bạn có thể đảm bảo rằng bạn sẽ không bao giờ gặp sự cố, hãy xóa WAL.
26:28 Xóa WAL.
26:38 Một số người nói rằng các nhà khoa học máy tính đã xây dựng một WAL và các DBA đã trả tiền cho nó.
26:48 Hiểu không?
26:50 Không, đó là một trò đùa tồi.
26:53 Được rồi.
26:58 Vậy là chúng ta đã nói về nhật ký redo, đó là WAL, nhật ký ghi trước, và đi đến cấu hình của chúng, bạn sẽ thấy điều này được nhắc đến ở khắp mọi nơi.
27:08 WAL này, WAL kia, thời gian WAL, tất cả thời gian xả WAL này, hoặc bạn có muốn fsync hay không, đúng không?
27:17 Đúng vậy, hãy nói về fsync trong WAL.
27:22 Bạn thấy đấy, nếu bạn đang xây dựng cơ sở dữ liệu của mình trên một hệ điều hành, bạn có thể nghĩ tôi đang nói điều gì ngớ ngẩn vậy?
27:31 Bạn sẽ xây dựng cơ sở dữ liệu của mình trên cái gì khác?
27:35 Này, tôi phải nói rõ vì bạn có thể xây dựng hệ điều hành của riêng mình là một cơ sở dữ liệu.
27:41 Đúng vậy, bạn có thể xây dựng hệ điều hành của riêng mình là một cơ sở dữ liệu mà không cần sự phình to của hệ điều hành.
27:53 Nhưng nếu bạn quyết định, giống như bất kỳ cơ sở dữ liệu nào, xây dựng cơ sở dữ liệu của bạn trên đỉnh của sự phình to này được gọi là HĐH, mục đích chung, HĐH đúng không, thì bạn phải tuân theo các quy tắc của HĐH, đó là Linux hoặc Windows hoặc Mac hoặc Temple OS.
28:15 Đó có phải là một HĐH không?
28:20 Sau đó, có một điều mà hệ điều hành thực hiện vì mục đích chung của nó, nó không tin tưởng bất kỳ ứng dụng nào.
28:26 Nó nói, "Này, tất cả các ứng dụng đều ngu ngốc."
28:29 Vì vậy, nếu, vì vậy các ứng dụng có xu hướng thực hiện một số công việc lặp đi lặp lại.
28:38 Chúng ghi vào cùng một tệp nhiều lần trong cùng một micro giây.
28:43 Bạn biết đấy, nếu hệ điều hành cho phép quyền đó đi vào đĩa ngay lập tức, SSD của bạn sẽ chết một cách nhanh chóng, phải không?
28:54 Trong một vài năm, giả sử, phải không?
28:59 Đúng không? Bởi vì bạn viết lưu điều khiển dưới dạng bộ điều khiển bộ điều khiển bao nhiêu lần?
29:04 Hãy tưởng tượng tất cả những quyền này đi ngay lập tức, phải không?
29:08 Không.
29:10 Những gì hệ điều hành có là nó có bộ nhớ cache hệ thống tệp.
29:16 Vì vậy, nếu bạn viết một cái gì đó, nó sẽ nói, "Bạn có thực sự muốn viết nó không?"
29:19 "Hãy cứ đợi. Hãy đệm những quyền này."
29:22 Vì vậy, nó đệm những quyền này trong bộ nhớ và nó giữ chúng trong bộ nhớ trong bộ nhớ cache, hy vọng rằng nó có thể, cùng một trang sẽ nhận được nhiều quyền hơn vì cùng một vấn đề, phải không?
29:38 Bởi vì nếu tôi viết một byte, tôi phải xả toàn bộ đĩa.
29:40 Nó không đáng, không phải toàn bộ trang này, phải không?
29:43 Nó không đáng, vì vậy hãy đợi thêm nhiều quyền mà trang bẩn này hy vọng nhận được, vì vậy tôi có thể xả toàn bộ trang với các quyền bẩn phong phú.
29:58 Trang càng nhận được nhiều quyền trong bộ nhớ, thì tính kinh tế của việc viết một trang càng tốt hơn vì nếu không bạn viết, nếu bạn thay đổi một ký tự và ký tự đó ghi vào bàn làm việc và sau đó bạn thay đổi một ký tự khác và ký tự đó ghi vào đĩa, bạn đang viết 8k, 8k, 8k, 8k, 8k, 8k mỗi micro giây, mỗi mili giây bạn đang viết và điều đó là quá nhiều, phải không?
30:27 Vì vậy, hệ điều hành có bộ nhớ cache và đợi bộ nhớ cache này quay phim, sau đó xả bộ nhớ cache đó vào đĩa, phải không?
30:43 Vì vậy, đó là một vấn đề.
30:45 Chúng ta đã nói về WAL, khóa đầu bên phải, phải không?
30:48 Nếu tôi nếu tôi bảo bạn xả WAL, hãy thay đổi WAL đó, tôi muốn đảm bảo WAL thực sự tồn tại.
30:58 Đừng đặt nó vào bộ nhớ cache.
31:01 Đừng cố gắng thông minh.
31:02 Đừng cố gắng là hệ điều hành hiệu quả.
31:07 Đi đến đĩa.
31:09 Tôi muốn một cách để bỏ qua bộ nhớ cache mà bạn có, phải không?
31:15 Vì vậy, đó là lý do tại sao hầu hết các cơ sở dữ liệu trong một số hoạt động nhất định, phải không, như WAL, vì WAL rất quan trọng, phải không?
31:25 Nó nói những điều nhỏ nhặt, nhưng chúng ta cần xả chúng trực tiếp vào rủi ro và điều đó được gọi là fsync.
31:36 Rõ ràng là được gọi là liftsync.
31:39 Vì vậy, nếu nếu đồng bộ hóa được bật, đó là mặc định, tôi tin, thì không, nếu mọi thứ bị tắt, phải không, đó là mặc định, thì nó sẽ đi vào bộ nhớ cache.
31:49 Nếu nếu đồng bộ hóa được bật, thì buộc đồng bộ hóa, thực hiện thay đổi đi trực tiếp vào đĩa, bỏ qua nó, nó là một bộ nhớ cache ghi xuyên suốt, được chứ?
32:03 Đục một lỗ xuyên qua bộ nhớ cache.
32:07 Vì vậy, có, bạn có thể tắt nó nếu bạn muốn và bạn sẽ có thêm một chút tốc độ, nhưng có nguy cơ mất dữ liệu của bạn.
32:15 Tôi đã tắt tùy chọn đó trong dữ liệu thử nghiệm của mình vì tôi không quan tâm đó là dữ liệu thử nghiệm và tôi tải dữ liệu hàng ngày, vì vậy nếu có sự cố, điều này rất khó xảy ra, tôi chỉ cần sắp xếp lại và tôi thực sự không nhận thấy nhiều sự khác biệt để thành thật mà nói, nhưng không sao.
32:33 Vì vậy, cơ sở dữ liệu có điều này được bật hầu hết thời gian.
32:37 Không nhất thiết. Postgres không bật nó để đọc và ghi các trang vì chúng ta biết rằng điều đó không sao.
32:44 Hãy viết nó vào bộ nhớ cache và hoặc bộ nhớ cache hệ điều hành.
32:47 Hãy đọc nó từ bộ nhớ cache hệ điều hành và điều đó không sao.
32:53 Vì vậy, nếu bạn nghĩ về nó, Postgres có gần như hai bộ nhớ cache, bộ nhớ cache trong nhóm bộ đệm, như tôi nghĩ nó được gọi là bộ nhớ làm việc hoặc có thể nó được gọi là dạng bộ đệm.
33:03 Tôi quên mất và sau đó có chính bộ nhớ cache hệ điều hành.
33:10 Hai lớp bộ nhớ cache.
33:13 Vì vậy, có, có một cái gì đó cần phải xem chừng, phải không?
33:18 Vì vậy, có, kỹ thuật cơ sở dữ liệu rất phức tạp.
33:20 Vì vậy, điều cuối cùng chúng ta sẽ nói về là nhật ký hoàn tác.
33:27 Ai đang nói, những thay đổi của Iro, phải không?
33:34 Và nhân tiện, không phải tất cả các cơ sở dữ liệu đều có điều này và nhật ký hoàn tác.
33:39 Postgres không có vì nó thực hiện khác.
33:43 Nhật ký hoàn tác được thiết kế đặc biệt để cung cấp cho tôi trạng thái của hàng trước khi nó được thay đổi.
33:57 Tôi đang nói, cái gì, tại sao?
34:04 Chà, nếu bạn đang trong một giao dịch đang chạy, một giao dịch chạy dài, bạn đang thay đổi, thay đổi, thay đổi, phải không?
34:12 Đúng không? Bạn đang thực hiện các thay đổi trực tiếp vào trang, phải không?
34:15 Trong bộ nhớ và bạn đang viết những thay đổi bạn đã thực hiện vào WAL.
34:22 Vậy bây giờ, điều gì đã xảy ra với các giao dịch đã bắt đầu trước bạn, phải không?
34:37 Giao dịch có một thứ được gọi là mức độ cô lập.
34:40 Vì chúng bắt đầu trước khi bạn thực hiện thay đổi này và bạn vẫn chưa cam kết, phải không?
34:45 Trong hầu hết tất cả các mức độ cô lập được tăng tốc và cam kết, các giao dịch đó cần trạng thái cũ của hàng trước khi bạn thay đổi nó.
34:58 Vì vậy, nó không thể đọc từ trang bị bẩn vì nó có những thứ mới nhất.
35:03 Nó không cần những thứ liên quan.
35:07 Nó cần trạng thái cũ.
35:11 Vì vậy, những gì cơ sở dữ liệu làm là họ giữ một bản ghi về nhật ký không cần thiết, cụ thể là vai trò này trông như thế nào trong toàn bộ, phải không?
35:24 Trong một hàng cũ, trong một khu vực nhật ký cụ thể được gọi là nhật ký hoàn tác.
35:32 Oracle SQL server, tôi tin, uh tôi không chắc 100% về SQL server, nhưng my sequel và Oracle có mô hình này, đó là nhật ký hoàn tác, phải không?
35:44 Postgres không có vì nó sử dụng phiên bản.
35:48 Một trinh nữ là hàng.
35:51 Postgres thực hiện các thay đổi trong trang, phải không?
35:56 Nếu bạn thực hiện một bản cập nhật, đó là một vai trò mới trong Postgres, vì vậy hàng cũ đã tồn tại, điều này thật hoàn hảo, phải không?
36:03 Nếu bạn nghĩ kỹ thì tôi thích thiết kế này hơn nhiều.
36:08 Một lần nữa, cuối cùng thì tất cả đều là sở thích cá nhân.
36:13 Nhưng bây giờ tất cả các giao dịch muốn đọc các hàng đã bị thay đổi, các hàng đó không tồn tại trên trang, vì vậy chúng phải thực hiện thêm một chút công việc.
36:25 Họ phải đi đến nhật ký hoàn tác, mở nó ra.
36:31 Tôi không biết "mở nó ra" có nghĩa là gì.
36:33 Chỉ muốn đảm bảo rằng nó chậm hơn, đó là lý do tại sao tôi nói điều đó.
36:38 Và sau đó lấy trang, hàng từ trang và sau đó hoàn tác các thay đổi vì hàng là mới nhất, bạn muốn hoàn tác các thay đổi bạn
36:49 Muốn áp dụng các thay đổi để làm cho nó cũ hơn, nếu bạn muốn, phải không?
36:55 Vì vậy, bạn muốn hoàn tác những thay đổi này để nó quay trở lại trạng thái cũ một cách hiệu quả để bạn có thể đọc nó.
37:09 Vì vậy, thêm một chút công việc cho các giao dịch cũ hơn hoặc cho vấn đề đó, các giao dịch mới hơn, phải không?
37:21 Bởi vì vấn đề là chúng ta có một giao dịch chưa cam kết.
37:27 Chúng ta có một giao dịch chạy dài.
37:29 Đó là lý do tại sao một giao dịch chạy dài là tồi tệ nhất vì lý do hiệu suất vì chúng ta nhật ký hoàn tác sẽ tiếp tục lấp đầy và những giao dịch đó sẽ phải đi đến nhật ký và mở nó ra và áp dụng các thay đổi và hoàn tác nếu bạn muốn đọc các con đường cũ.
37:48 Nó phải thực hiện điều này mọi lúc và bạn có thể nói bạn có thể thực hiện tất cả các loại bộ nhớ cache, nhưng đây là công việc mà cơ sở dữ liệu phải thực hiện nếu bạn nghĩ về nó, phải không?
37:58 Đó là tất cả công việc.
38:00 Nói, bạn có lưu trữ nhật ký hoàn tác không?
38:04 Tôi tin rằng bạn nên, phải không?
38:07 Hãy suy nghĩ kỹ về điều này.
38:09 Bạn nên làm tương tự với nhật ký hoàn tác như bạn làm với nhật ký redo vì khóa đọc cho bạn biết trạng thái cuối cùng là gì, nhật ký hoàn tác cho bạn biết các trạng thái cũ hơn, phải không?
38:27 Và cách chính xác để thực hiện điều này là trong trường hợp xảy ra sự cố, bạn sẽ có một loạt WAL, đó là nhật ký giảm và sau đó bạn sẽ có nhật ký hoàn tác và bạn phải có trạng thái của trang như nó tồn tại trên bàn làm việc.
38:44 Vì vậy, trong trường hợp xảy ra sự cố, bạn có nhật ký hoàn tác, bạn có nhật ký redo, bạn có trang cũ, được chứ?
38:49 Vậy bạn làm gì?
38:50 Thứ tự chính xác là lấy trang đó và bất cứ thứ gì trong WAL là sự thật, áp dụng tất cả các thay đổi WAL, áp dụng tất cả chúng và sau đó vì bạn có thể đã áp dụng những thứ từ một giao dịch đã bị hoàn tác, phải không?
39:08 Đi và lấy nhật ký hoàn tác và sau đó làm lại, làm lại, hoàn tác các thay đổi cho đến thời điểm giao dịch đã bị hoàn tác.
39:22 Được rồi, vì vậy bạn sẽ đọc những gì bạn làm và sau đó hoàn tác hoàn tác hoàn tác và cho đến khi bạn đạt đến trạng thái nhất quán, phải không?
39:30 Đó là một triển khai mà tôi có thể nghĩ đến, phải không?
39:33 Bạn không thể lưu trữ nhật ký hoàn tác và chỉ áp dụng nhật ký redo cho giao dịch đã cam kết sao?
39:42 Tôi cho rằng bạn có thể, nhưng sau đó bạn phải phân biệt các giao dịch đã cam kết so với giao dịch chưa cam kết trong WAL, phải không?
39:54 Mà tôi tin rằng thông tin đó không tồn tại.
39:56 WAL có các thay đổi và nó không biết liệu điều này có phải từ giao dịch này so với giao dịch kia hay không.
40:03 Tôi cho rằng bạn có thể lưu trữ thông tin này trong một tệp dữ liệu khác chứa các giao dịch đang được cam kết, nhưng cách này dễ dàng hơn.
40:14 Tôi không biết, các bạn ạ.
40:17 Đây là một tập của chương trình kỹ thuật đảo ngược thảo luận về nhật ký của cơ sở dữ liệu và tôi khá chắc chắn rằng tôi đã bỏ lỡ một số thứ này, nhưng tôi tin rằng đó là một trong những điều quan trọng nhất, bạn biết đấy, nhật ký, nhật ký hoàn tác, WAL và nhật ký radio.
40:36 Tôi có thể thấy trong cái tiếp theo không?
40:37 Hy vọng bạn thích cái này.
40:38 Luôn tuyệt vời nhé.
40:38 Tạm biệt.
Translated At: 2025-03-14T01:59:50Z
Translate Version: 3.1 Improved translation step with full context