‫We talked about a tomasetti, we talked about isolation.
‫We talked about what it's really a transaction, which is really the most important thing here to understand
‫before jumping into these properties.
‫And then we really need to talk about consistency, which is one of the properties there were that were
‫traded off in different platforms.
‫When I say different database platform, I mean, not equal versus a relational versus graph consistency
‫played a lot of role there.
‫So some databases sacrifice consistency for speed and performance and scalability.
‫I'm not going to talk about all that stuff, but consistency, really.
‫What do we mean by consistency?
‫And you are understand that really consistency.
‫Already, two folds, there is what I call consistency in the data itself, which represent the state
‫of the data that is currently persisted.
‫OK, so what do you what do you have actually in disk is what you have in disk?
‫Consistent with with the data model that you have and we're going to talk about what does does that
‫mean?
‫And there is another consistency.
‫What I also call consistency and read.
‫So your data might be consistent on this, but the reading of the data is becomes inconsistent because
‫you have multiple instances and they are slightly out of sync.
‫So this applies to the system as a whole.
‫So if you have like money shards or many partitions of many, many, many, many database instances,
‫right, this is that applied to the system as a whole as I use it.
‫I don't care what database A-listers I have.
‫I'm just issuing a read that read better.
‫Be consistent and consistent in data is in a given cluster in a given data instance.
‫What is going on?
‫There is my data even consistent at that level, right?
‫And let's take some examples.
‫Let's talk about consistency and data.
‫This is really defined by the user.
‫This is something that the user defines and by the user.
‫I mean, the DBA, really, or whomever builds out the data model and the database, right?
‫And it really comes down to most of the time of enforcing referential integrity and and foreign keys
‫in the database, right?
‫I know some people coming from NoSQL don't have this concept, but believe it or not, you do have referential
‫integrity.
‫Whether you like it or not, you might have a document here that is referring to another document and
‫the moment there is a referential.
‫There must be integrity in this reference.
‫Effectively, all this example that clarifies what that really means and what also ensures consistency
‫in the data is, I guess, what I tell my city.
‫If we had a crash while we debated one account and then restarted the database and that account remains
‫debited half right, we just lost $100 in the thin air.
‫That's an inconsistency in data.
‫The data is just persistent, wrong.
‫It's corrupt.
‫As as we call it, in junior, there is corruption.
‫Effectively, you corrupted your database effectively.
‫That's a pretty bad.
‫Isolation also can result in inconsistency of data because you could.
‫And we talked about that in the isolation lecture where you can issue a read and you get a bunch of
‫data back, right?
‫But then you issue another read and you get different results based on your isolation level, and that
‫leads to inconsistent result.
‫So, yeah, your data might be correct, but it is changing, consistently changing.
‫And this change is giving you a different view as a result of your view of the consistency is getting
‫wrong.
‫Here's an example.
‫Let's assume you're building some sovereign Instagram data model here, so you have the picture stable,
‫you have an ID of a blob of the picture minority, a large objects and the number of likes that this
‫picture got.
‫And then we have a tracking table that says, OK, John have liked picture one and Edmund had like also
‫picture one, and John also liked Picture two.
‫So you have a certain referential integrity is here.
‫What is that?
‫And this is defined by you as as the DBA, whoever build this, because the number of likes here better
‫be equal to the sum of these guys.
‫Right?
‫Because if you do a select count from this table where a picture ID equal one, I better get two likes
‫and this should be equal.
‫And this is basically the consistency in data.
‫If this is inconsistent, then bad things can happen.
‫Who cares about if you're out of sync or the number of likes?
‫People give that up because really, nobody cares.
‫Nobody's going to browse.
‫Kylie Jenner is one point eight million like pictures.
‫Nobody's going to there, but you get the point.
‫This is this is one example.
‫Another example is if you have the few seen like an entry here to a picture that doesn't exist anymore.
‫Right?
‫That's also an inconsistency, right?
‫And this is what do we really mean when we talk about consistency in acid transactions, right?
‫We're talking about the acid consistency here, talking about the acid consistency here.
‫So, uh, I'll give you a few moments here to spot the inconsistencies and inconsistencies in this data
‫model.
‫Take a look.
‫So you might have already spotted a one of five likes, but if you actually query that, like, stable,
‫you can see that picture one only got two likes, so something got out of sync.
‫This is an inconsistent, referential integrity.
‫Another referential integrity, inconsistent data is you have Edmond Lake in picture four.
‫But if you actually want to get the actual picture in in the picture, stable picture four doesn't even
‫exist.
‫So that's also an inconsistent result.
‫So someone deleted this picture, but they didn't have a cascading event to delete the likes picture,
‫effectively leaving those effectively orphaned.
‫All right.
‫And you can have the database do this constraint or you can have it do it at the application level.
‫It's really up to you.
‫But this is what do you mean by inconsistency here?
‫Is that what it is?
‫No, really.
‫Consistency and read is is another thing that can happen, right?
‫Let's take an example.
‫You have a database system.
‫You?
‫And you can look at this as a single database or multiple doesn't matter, but you're assuming you're
‫talking to one reverse proxy of activity that proxies that request to the.
‫So you're updating Value X. And now that the the database passes the value X and now the next read after
‫this thing commits must give you the value X.
‫That's why it means by consistency in rates, you might say I was saying that's just obvious.
‫Well, not all the time.
‫Let's take an example.
‫If a transaction committed a change, will a new transaction immediately see the change?
‫That's what really boils down to, right?
‫If if I committed a change to a database and then I sure it immediately and I don't see that change.
‫Then you are inconsistent effectively because you just read something that is not really the value that
‫is supposed to you are supposed to get.
‫And it affects the system as a whole.
‫And what is an example that can get you is basically is when you have a master or a mean replica primary
‫database and they have a multiple worker database, right?
‫And you're sinking the changes to the back.
‫And I have an entire section talking about replication.
‫So check that out when you finish with this lecture.
‫But effectively, as you write to the primary, the primary will sink back at the changes to the replica.
‫And if that time, if you read in the replica, you might get an old value and that's what we mean by
‫inconsistency here.
‫So that's why it affects the system as a whole.
‫Relational and no sequel databases suffer from this kind of consistency and even not equal support for
‫the first time.
‫If you think think about it right, it still doesn't have this idea of inconsistent result in the persisted
‫model.
‫If you don't ensure variation on declarative between your, I don't know MongoDB documents, you're
‫going to get the same exact problem, right?
‫Right.
‫If you have users and followers less than one, I don't know how.
‫What do you do?
‫You have to ensure the referential integrity a factor that you set, the rules that you built.
‫And then we come back to this marketing term that is called eventual consistency.
‫The consistency releases.
‫OK, well, which is really what means is, hey, I'm not consistent, but I'm eventually going to be
‫consistent.
‫Am
‫I kind of turn on this term, to be honest?
‫I'll give my thoughts in another lecture.
‫But in a nutshell, most of the things that are currently not consistent will get eventually consistent.
‫But that is that is that is very important to understand because in the consistency of data, if your
‫data is corrupt and referential, integrity is broken.
‫There is no eventual consistency coming out of that, right?
‫Because, hey, the data is just corrupt.
‫You got you have five likes, but only two records that that represent the likes.
‫That is no eventual consistency coming from them unless you have some sort of a repair post batch job
‫that fixes that button.
‫That's what we mean by eventual consistency is only really to the reads, because if you continue issuing
‫a lead, you're going to get old values, but eventually you're going to get the correct value.
‫That's what they mean by Evangel consistency, and there is in many terms, your eventual strong consistency
‫and eventual weak consistency.
‫And there is there is so much stuff you can go into this.
‫I can't really make an entire course, just talk about evangelical students.
‫So it is valid in certain cases, but it's been invented to kind of differentiate between the corruption
‫that can happen to your data effectively.
‫So in summary, consistency are two types consistent in the data which are enforced by the referential
‫integrity, right?
‫Things that have persisted in the data.
‫And there is no eventual consistency coming out of that because the data will become kind of corrupted
‫based on what you define by corruption here.
‫And the different type is consistency and rhythm.
‫The consistency in readers when you update the value and then a transaction tries to read that value
‫after it was committed, you get the old version and that's an inconsistent result, right?
‫So it was.
‫Most databases heal from this kind of inconsistency by eventual consistency.
‫So that means as their their application process completes them, you will eventually get the final
‫result effectively from that raid, right?
‫And this can be enforced by by something called synchronous replication, which I believe I talked about
‫in this course.
‫Yeah, synchronous replication versus asynchronous replication one is slower than the other, but one
‫give you a strong consistency on the other.
‫Give you a virtual because this is different.
‫At the end of the day, it's all comes down to what really you want effectively.
‫And eventual consistency is something both relational databases and null sequel suffer from.
‫So that's was basically a summary of the consistency.
‫How about we jump to the final lecture durability of.
‫My favorite.