‫What is going on, guys?
‫My name is Hussein, and this is an old bug gold article, Uber Engineering switched from postscripts
‫to my school and this article was published on July 26, 2016.
‫And this article explains why Uber moved from postcrisis to my school back in the days.
‫I remember that this article got a lot of backlash from the Postgres community and actually the whole
‫database community, to be honest, because of of how the language used in this article severely criticized
‫Posterous as if it's a bad database.
‫Right.
‫They don't even mention that thing.
‫That is a hey, by the way, guys, this is just didn't work for us.
‫Doesn't mean it won't work for you.
‫So that's that's was then that was the main reason this article was heavily criticized.
‫I'm going to reference this article and the Hacker News.
‫A thread that explains that you're going to have a lot of discussions as some discussions go into the
‫deep, some of the discussions kind of point the flaws of this article.
‫But what I want to do in this video podcast is going to go through this article and through the main
‫pain point that Obama had and then discuss them.
‫Give you my personal opinion, whether I think you moving from postscripts they did.
‫They have to move from post goes to my school or not, all of that stuff.
‫How about we jump into it, guys?
‫So, guys, first they explained that their architecture right here, they have the monolithic back
‫in application written in Python that used Postgres for data persistence and they are moving again.
‫This is 2016.
‫Things change and change, but they are moving to a micro services architecture and surprisingly to
‫a new system using schema lists, synovial database, sharding layer built on top of my school.
‫So we're going to talk about that a little bit.
‫That that just that is a little bit of flak.
‫You might you might you might say, Hosain, why schema list and MySQL.
‫That doesn't make any sense.
‫Right, exactly.
‫That's a lot of people confused a lot.
‫Oh, OK.
‫Why would you pick my school?
‫For let's just go with with Cassandre Cockroach DB.
‫I don't think Cockroach TV was born back then, but.
‫But Farnam.
‫Mango, right?
‫Anything but, yeah, again, they have their own reasons.
‫And that's another article.
‫But what I want to focus in here is the architecture of Bosco's, as they claim.
‫So is the for the people listening.
‫We're reading now the architecture of Postgres.
‫And I'm going to read the article, The Five Most Pain Point that led UBA to move from Bosco's to my
‫school.
‫So.
‫So this is this is the article now we encountered many Posterous limitations.
‫The first one in inefficient architecture for rights, the second one efficient data application, the
‫third one issue with table corruption issues with table corruption issues, not issue and is poor.
‫The fourth one, poor replica NBCC multiverses and concurrently control support.
‫And the fifth one is the final one difficulty upgrading to new releases.
‫I can agree with some of them because I use postcrisis and I know how painful is to upgrade both postscripts
‫so I can relate it to that.
‫I understand that this is a little bit easier process right now.
‫But nevertheless, how about we.
‫I don't agree with all the points, by the way, but I'm just reading to you.
‫I agree with some of them.
‫Some of them is just to me, preposterous.
‫So how about we jump into it?
‫So they look through the limitation and they decide to move to a MySQL because it solves most of these
‫problems.
‫So how about we jump into one point, one point after another?
‫So the first point here, that's called the on disk format.
‫And they are describing in this article in this section that that on disk format of Postgres that implements
‫a multi version concurrency controller.
‫And we talked about it many times on this channel, how the actual indexes are stored, how secondary
‫and indexes are stored and postscripts.
‫How do they implement the multi version concurrency controller using the transaction ID?
‫That's the idea.
‫Right.
‫And then Max Idee and Maniatty.
‫And how are you how a role becomes visible?
‫My transaction, once I go out of scope of the transaction, I need to do a vacuum to clean up those
‫rows that need no longer seem by any other transaction.
‫So that's all it comes down to the isolation and all that stuff that we talked about many times, this
‫channel.
‫So check out the ASADA video here to learn about isolation, ASADA Tomasetti.
‫I'm not going to explain it right here.
‫So that's that's why I explain here.
‫So the what they are going through here is they have a table called users and they showing you how postscripts
‫works so well for the people listening on the podcast.
‫We're looking at the table with four columns.
‫I'd first, last and Bourdier.
‫So first name, last name and then birthday.
‫And then there is an ID is a number.
‫First name is obviously starting last names, a strength character and then Boissiere and they show
‫you how this is on disk and there is a seated which is which, which is a transaction ID that is stored.
‫That's basically the tuple reference on the disk.
‫And this is very, very important.
‫So these tables are ABCDE, PFG and so on.
‫And so the primary key, they have an index on the primary key, which is the ID.
‫They have a secondary index on the first, last and birth year.
‫So they have indexes on all of them.
‫And again, this is just an example.
‫They didn't show us there with their architecture for security reasons, probably.
‫So they don't they don't show us their scheme.
‫I'm nothing like that.
‫But from this example that tells me that they have a lot of indexes, so pay attention to that.
‫So PostgreSQL and their primary key and secondary, he always points to the tuple ID, which is the
‫physical representation on disk.
‫And here's here's here's how PostScript works.
‫So if you now go ahead and update a row, any role in this table, what we do is we essentially insult
‫insert a duplicate role within you to pull it this time.
‫And now that we have a new idea, we need to point the indexes.
‫The secondary indexes and pretty much everything they use is the stability to the new representation.
‫Right.
‫And that takes a finite amount of time, a finite amount of rights.
‫Finally, I want to work for progress to do right, because everything points directly to the desk,
‫just like my eye, my isaam I and in my skull, that's exactly the same architecture where everything
‫points directly to the desk.
‫And you might say, what's bad about this?
‫There is good and bad.
‫The bad thing is what they are explaining.
‫Explaining here is this.
‫Hey, the moment we touch any role, I, I have to update all the indexes, including the primary key,
‫because now all these indexes have a new the those entries have a new I.D. that I need to pick up tuple
‫ID.
‫So I have to update that.
‫And that obviously takes a ripple effect.
‫It's called they called it.
‫Right.
‫Amplification and the coming slides.
‫Right.
‫And this logical writer, I updated a single field in a single row, yet it results on five, six,
‫seven, write physical rights to disk because you're updating the secondary index, the secondary and
‫the second.
‫If you have a lot of indexes, this even gets slower and slower and slower.
‫Right.
‫So bear with me.
‫Here is this is just explaining their point now.
‫So there they go through all of that's exactly what I said.
‫And that as a result.
‫Slows things down because first of all, rights are not just right, are not sloper, say, because
‫you do flush right.
‫You have a lot of rights to do and then you do all of them at once.
‫But the side effect of the rights, we're going to explain it in a minute.
‫It's like one single thing translate to a lot of physical rights.
‫Have to update this index is index this.
‫This isn't the right to log, which is which is something we're going to explain in this article.
‫A lot gets large when you when you want to apply these changes.
‫So that's the first thing on this.
‫They go through the on desk representation of PostgreSQL.
‫Then they explain.
‫The second point is replication and replication gear.
‫Guys, as I discussed, the right ahead log is basically if I do an uncertified one, an update.
‫This statement is translated into physical changes.
‫They go to this block and change this location and and replace this value with this value.
‫Right.
‫Or go to this index and change this value to this value.
‫Go to this index on this position changes.
‫These changes are written in the right ahead log as actual disc changes.
‫OK, so this is a very, very, very important thing to know.
‫Now, this is the right to head.
‫Look, we have this and also the head log is has its its own structure.
‫Right.
‫It's somewhere else and it's being maintained.
‫So that's also the right ahead log.
‫Also has a physical representation on disk when you translate it into and this is the right.
‫So there is a lot that's going on.
‫So now when you come to your application, which we talked about right here, guys, and also discussed
‫in my course introduction to Derivs Engineering, the idea of having a primary database except the rights
‫and stand by her application for reads that that you can they can take reads.
‫You need to push these changes and the way you push them as you push them to right ahead log, which
‫is a very consistent thing, down the standby databases so they can get up to date.
‫Right.
‫That sounds simple, you know.
‫And what what what what they explain in that application format.
‫And this is where kind of their point about the limitation of postcrisis.
‫You guys have this.
‫First of all, you have this war or I Tadlock, which is quite large.
‫Why?
‫Because a single update statement translated into multiple rights and these rights are made its way
‫to the right ahead log.
‫Hmm.
‫So the the right to log doesn't have to update the stable.
‫It's not like a statement based replication despite Moscow's support statement based application through
‫a third party.
‫I believe the my school have both supported both that statement based application and also right based
‫application.
‫There is, again, pros and cons for both.
‫So now when when we try to apply that came back, that dog was barking.
‫All right.
‫So the master.
‫Database pushes the wall, changes down to the standby databases so they can get updated, but you might
‫say, Hosain, what if the standby is actually executing a query?
‫Do this, just do we just stop this query?
‫Right.
‫I see a McSweeny query in the standby to read something that happened to be deleted in the master,
‫and it's being written directly.
‫So I stop there.
‫Do I stop the query.
‫Do I wait.
‫All these questions are going to get answered in a minute and as a result it will shape their decision
‫to move to my school.
‫I'm going to just get them to explain it to you now.
‫So now they have we talked about the underscore and the underscore presentation.
‫We talked about our application and now we're going to talk about the consequences of Posterous design.
‫That's that third point here where the problems of Bosco's.
‫So let's enjoy this reading is the first problem is right.
‫Amplification and write amplification is apparently something.
‫It is in SSD where a single right that you think it's logical translate to many, many, many physical
‫rights, especially A.D.s, as he does his own thing.
‫So when you update versus insert eses deed does a little bit different thing is this D love to insert
‫new things, you have to like to logically just insert new things and create new pages.
‫SSD does not do well with updates because the goal of SSD is to have a page and flush it.
‫In order to update an existing page.
‫You have to invalidate that existing page.
‫You take it and then you copy it, change it and then write it.
‫So there is a little bit more work when it comes to an update versus an instance, which is faster.
‫So that's just that's just that's all the reason why Google invented the level DB database and then
‫why Facebook invented Rock CDB.
‫On top of that, I think that to to take advantage of SSD and they built a completely different structure
‫called the log structured military, where it's it's optimized for inserts and instead of updates,
‫everything is an insert almost in their log structure.
‫Mircera So so that's that's the idea of right.
‫Amplification.
‫This is now take that and amplify it at the Bosphorus level.
‫I that a client I'm doing a single update statement to my table and if I have like 700 indexers, I
‫just made 700 updates, physical updates.
‫As a result of my single logical update.
‫So that this 700 update also at the highest level, translate to many, many physical amplified as the
‫updates because you going writes and pages and this is deeper thing, they have a limited shelf life.
‫So if you have if you have a limited shelf life, it is as you can only write so much.
‫I think there is a number that varies between a disc and another.
‫But in general it's essentially I think 12000 times or something like that.
‫That's most of them.
‫So so they explain this here.
‫I just summarized it to you.
‫Right.
‫Amplification is a problem for them.
‫So there is is this getting is getting their life span of us is getting lower and lower because of the
‫right amplification, because those guys have hundreds and hundreds of indexes.
‫Why would you have this much indexes?
‫Beats me.
‫Do you really carry on all of them?
‫Do you really query on first name, right or last name?
‫That's why adding indexes great.
‫Adding too much indexes is just a bad idea.
‫So that's the right amplification problem.
‫The second problem they want to discuss here is the replication problem, guys, take the same thing
‫that we did.
‫We did a single update that translated to lots of update to all the indexes because all of the indexes
‫point to the row directly.
‫So and the rotch idea changes.
‫So we have to make them aware of this row of changes.
‫So all of these indexes point to the role directly.
‫So these changes are just amplified.
‫Now, these changes translate to walk to a wall, right?
‫Right.
‫TADLOCK Hey, update.
‫This was a goddess and this index and this second and this, this.
‫And by the way, there is a rule here change this is to do this and it is earned it it's all physical
‫right to the desk.
‫What they complain about in their applications is this wall.
‫Translate to a large.
‫Big sized bandwidth when it comes to to their to their master.
‫Walker or stand by or application, and those are interstate, they have their application leprechaun's
‫across states, across different countries, so they had to buy expensive bandwidth to kind of transmit
‫their wall changes from this replica to this replica.
‫And I believe they have also child, grandchild, their applications.
‫So take that into consideration.
‫So the will change as they grow large, the bandwidth becomes expensive because they are very large
‫and they are not making small updates.
‫They're making large updates.
‫Which devices are even larger.
‫So that's that that's the limitation problem here.
‫In case I'm going to read this this section for you guys so so you can learn more about it in case one
‫more prosperous replication happens purely within a single data center.
‫The replication bandwidth may not be a problem.
‫Modern network equipment and switches can handle a large amount of bandwidth, and many host providers
‫offer free or cheap data center bandwidth.
‫Right.
‫If you're internally, I can transfer one gig of all sizes easily.
‫However, when replication must happen between data centers, issues can quickly escalate.
‫For instance, Gober originally used a physical servers in Coolac colocation space.
‫I don't know what the heck is a colocation colocation space on the West Coast for disaster recovery
‫purposes.
‫We added servers in the Second East Coast, colocation space and this design.
‫We had a Master Bosco's instance plus replicas in Western datacenter and set of replication is so that
‫that kind of the constraint you can see from east to west just just did not scare off all of them.
‫Right, because of the C one, how one single problem can lead to a lot of bigger problems can lead
‫to another problem.
‫You see the pattern, guys.
‫Rights are big because they have a lot of indexes.
‫That's where you should start.
‫Why do you have this much Texas?
‫You might say, hey, Hussein, I cannot live.
‫I have to have 350 indexes on all my fields because I query against the.
‫Well, in this case, I say, OK, maybe that's not a choice for you then, but try to avoid that in
‫the first.
‫But that's that's why that's what I didn't see.
‫And that's why people are pissed.
‫It's like, wow, Kent didn't did you really didn't you explain why do you guys have a lot of indexes?
‫Can you explain why do you need I bet if you go into the actual architecture, most thing don't need
‫this much indexes.
‫As a result, you will not translate to a huge right amplification consequences.
‫You will not have that because you'll not have a lot of of indexes to update.
‫Right.
‫But well, we're not on board, so we don't know their architecture, but that might be a valid use.
‫So let's go to the data corruption.
‫This is this is the most dumb section in this whole article.
‫I'll save you some time.
‫What they say here as hey, during that application, we Postgres two had a bug in it and our tableware
‫was corrupted as a result.
‫Seriously, seriously over.
‫What software doesn't have bugs, you're adding a bug as a result to move from postscripts to a MySQL
‫like my cycle's perfect.
‫That's just odd.
‫That's just to me.
‫I'm sorry.
‫That's just odd.
‫So they said during during their application process, the replicas were not in sync for some reason.
‫And as a result, when you query for a unique value, let's say select start from users, what I'd call
‫for you should get one.
‫They were getting two.
‫They were getting the old retired row for some for some reason.
‫And that causes their application to fall down and fall apart.
‫So they had to add defensive programming and to catch for the stuff.
‫But it's a bug Bosca's immediately if they notified police his name, they would immediately have fixed
‫it and fix that bug immediately.
‫But that's a good bug.
‫But I don't see bugs as a reason to move from as a show stopper, in my opinion.
‫So that's why they talk about that and they talk about here.
‫One section is the brief rebalancing, which is, by the way, by the way, B3 three rebalancing adds
‫to the right amplification.
‫I just they don't mention that, but it's just implied because a lot of people know that when you start
‫to grow and you have a lot of indexes, you keep updating those indexes naturally if you if your value
‫touches that index.
‫Right.
‫However, as a result of inserting that might the B3 structure might need to rebalance itself and when
‫it needs to rebalance itself.
‫It actually doesn't update physical update to the three and updates or updates, not inserts, right.
‫So updates translate to word to actual SSD.
‫Right.
‫Amplifications, because this is the do not like updates.
‫So that's that's another thing that can amplify the rights.
‫I'm talking if you go to the millions of euros.
‫Right.
‫Obviously.
‫Right.
‫Let's move to the next one.
‫Replica MVC.
‫All right.
‫Replica NBCC or replica multi version.
‫Concurrency Control says Bosco's does not have true replica of NBCC.
‫Well, why?
‫Because the fact that replicas apply will updates directly meant because if you think about it, Posterous
‫by default, again, by FISA, by default, takes the undiscussable presentation of the wall changes
‫and that's what gets transmitted.
‫So it's often higher bandwidth, but it's if you think about it, it's faster.
‫Right.
‫The alternative is just a statement based replication.
‫Right.
‫Where when instead of sending the results of the execution of the queries, send the queries themself
‫like, hey, I just didn't insert I just did an update.
‫I just didn't.
‫So the actual strength of the statements, these SQL statement, just send them to the replica.
‫This will be way slower, right.
‫Because, yeah, the bandwidth of transmitting these wall changes as as a form of statement is smaller
‫than the actual physical changes that happen.
‫However, applying them to the replica now you have to actually insert are not straightforward and such
‫might be OK.
‫But what if you do an update, for example, an update, could scan, could touch.
‫The index actually does work.
‫So you did double the work technically.
‫Right, because you did the work to execute the statement on the master, you now we're doing the same
‫work.
‫Exactly.
‫And that statement is expensive.
‫Are you going to take the same costs on the server and the destination?
‫So there is a problem calls for using both, but they are complaining here that.
‫Polska has.
‫Wall update is just doesn't give them NVCA support, that's clear that so let's see if I am if I am
‫in a replica, stand by and I'm executing a query and one of my wall changes.
‫A fact that query that is being executed on the stand by.
‫So, again, I a master, I am.
‫I deleted the thing.
‫I deleted a table that's just a little bit harsh.
‫But let's say deleted furors.
‫Right.
‫And now on the on the stand by, I'm actually querying those rules that is being deleted on the master,
‫I am on a different replica.
‫So now I am pushing the master, pushing the wall, changes to the to the stand by while that Quarrie
‫that squaring those deleted rows is being executed.
‫What should Posterous do you.
‫You tell me as the viewer listener, what should what do you think should happen here?
‫Should the post office immediately cancel the query?
‫Right and right, the changes.
‫Or should the should the rule changes be paused until the query finishes?
‫If you think about there are no other choices, right, you have to pause it.
‫Obviously you're not pausing all wool changes.
‫You're only pausing changes that affect running transaction.
‫And that's another thing to worry about.
‫How the heck do I know that the query that being executed actually affects my wall changes?
‫Building databases is not easy.
‫Guys, look at all this complexity.
‫So they are complaining here that you guys don't have any VC support because what you're doing is.
‫What Baucus does effectively is essentially having a timeout, says, hey, we're going to we're going
‫to block the wall changes for a given time, and they give you this time configurable.
‫If the query didn't finish in this amount of time, we are sorry, we're going to cancel those changes.
‫We're going to cancel that query that is actually querying its reading.
‫And while we're applying, we're going to force applying the changes.
‫Why?
‫Because Polska is designed to favor eventual consistency over, let's say, just reading queries in
‫this case.
‫So I'd rather be eventually consistent.
‫Remember, if this is a ventriloquist as well.
‫So stop saying that Norse equals the only database has evangelic assistance.
‫Every database has it as long as between replicas.
‫Right.
‫Relational doesn't in the same thing.
‫Same instance.
‫Yet it's completely consistent.
‫But across replicas there is always this idea of eventual consistency.
‫So what this does is actually kills the transaction and they did not like that.
‫So let's read this a little bit.
‫I kind of don't don't agree with the statement, but the design means that replicas can retain routinely
‫lagged seconds behind master, obviously, and therefore it is easy to write code that results in transactions.
‫Hmm.
‫What does that mean?
‫This problem might not be apparent to the application developer writing code, that obscure word, the
‫transactions on them, for instance, say a developer has some code that has to email received to a
‫user.
‫Depending on how it's written, the code may implicitly have a database transaction that helds open
‫until the email finishes.
‫That's just a bad idea, right?
‫You don't have you don't held you don't hold a transaction open and you do stuff has nothing to do with
‫the transaction itself.
‫Try to avoid that as much as possible.
‫So I was just that's just a best practice.
‫While it's always bad form to let your code hold open that obvious transaction while performing unrelated
‫walking out, OK.
‫Thankfully, they mention that the reality is the most enduring are not database expert and may not
‫always understand this problem.
‫I have to disagree with this one again, guys.
‫If you if you if you have if you have a few, if you know me from this channel or the podcast, you
‫know that war as an engineer, you have to take your pride of your work and the thing that you interface
‫with.
‫I believe that you have to understand what you're communicating with.
‫So, yeah, engineers are not database expert, but this does not qualify as a database expert.
‫This is just basic transaction management, in my opinion.
‫And I believe engineers have to understand this.
‫Right.
‫And engineers have to understand, you know, you might be not as radical as as me.
‫I don't like to work with anything that I don't understand.
‫If it's black box, I don't like to work with it.
‫Before I pick a tool, I have to understand fully how it actually works fully, fully from zero to 100
‫percent.
‫If I'm if I'm working on it, if I'm connecting with it, if I'm interfering with it, it's OK if I
‫understand 80, 70 percent of the tool.
‫But again, I'm not going to understand every single thing in that case.
‫Right.
‫But that's just me.
‫You might have a different opinion polls because upgrades.
‫So I kind of agree with them on this one.
‫I, I try to upgrade this many times.
‫I always didn't find the right tutorial or it was so complicated that I gave up.
‫Right.
‫And they kind of reiterate the same problem.
‫So I had to agree with them 100 percent in this Polska subject is really painful, really painful.
‫I've been there, I've been there from nine three to nine for nine four to nine five.
‫I then just gives up.
‫I just rather recreate my database's from scratch after that.
‫Obviously I'm running a test database here but but yet I didn't run a production database that I had
‫to upgrade it.
‫But what I'm going to do in this case is just obviously there is a way, but.
‫Apparently this way sometimes works, sometimes it doesn't.
‫So there is a there is there is also the PJI logical way of right.
‫There is there are some tools that allow you to do upgrades.
‫Right.
‫And guys, if you if you know any of that stuff, if you have ever upgraded Postgres database smoothly,
‫let me know in the comments section below.
‫I'd love to know how to do it.
‫I tried twice, I believe, and I gave up and says, you know, this is not straightforward at all.
‫And I didn't have I wasn't forced to do it.
‫So I took that.
‫He's got out of recreating my dad's OK, the architecture of my school and UTB and whatever we talked
‫about, I'd have you guys check out the video right here if you want to learn more about it.
‫But maybe what?
‫So they go now through their own describers in compared to a podcast.
‫So A.B..
‫Or just miscalled in general.
‫My sexual energy in general, that's the right voice, saying you have the primary key and the primary
‫has a pointer to the roar directly to the physical database on the scroll, all the indexes that you
‫create points back to the primary key.
‫And that's the powerful thing here for them, because now if I update anything on on the on the row,
‫only the primary key needs to be updated to know the new kind of rule ID and even that.
‫Right.
‫It's a little bit different, but I don't have to touch my secondary indexes.
‫Right.
‫That being said, guys, they didn't.
‫That's not always true if you're updating a field that has no index.
‫Then.
‫Right.
‫You get it, not touch, only the primary key, but if you updated a feel that has an index, you got
‫to touch both.
‫So they didn't mention that, but.
‫Yeah, right, because it's very defensive architecture article, right, bicycle's perfect.
‫Yeah, if you did that, the actual field that has a secondary index, you have to operate like an index.
‫You just updated a value.
‫So you have to go to your index and change the tree.
‫So that includes this value, right.
‫So, yeah, you touch a lot of fields.
‫Right.
‫And if you touch a lot of fields, then you have to update all the indexes.
‫Right.
‫It's just bydesign it's less if you have a lot of indexes, you have less changes and general.
‫Right.
‫So as a result, this translates to obviously less, less raw wall changes because they don't have as
‫much changes, logical to physical translation.
‫And now they talk about the rollback mechanism here that might be called they have this concept of rollback
‫segments.
‫So instead of inserting a raw in the heap itself.
‫When you updated data, Arau and upholsterers, you insert a row in the heap, it's on the table itself,
‫right?
‫Musical, A.B. does it differently.
‫It's just the the copy that on to some other place called the undo the rollback segments.
‫The undo logs.
‫Right.
‫And they keep it all there.
‫And then based on that, they point to that location and roll back segments.
‫All right.
‫So so it's a little bit different architecture.
‫So if you query now, if you want the latest, the latest is always there.
‫So that's the beautiful thing.
‫But based on your transaction idea, if you are coming from the past, you're counting on the past.
‫You want all the results.
‫You have to do the jump to go back to to get the all this jump doesn't exist in Polska.
‫So queries that that are concurrent are fast on Postgres.
‫They are technically slower and in my school because now you have to jump back and going through different
‫places to do it, to do the query.
‫Right.
‫And and vice versa.
‫So they explain the haziq under indexes point to the primary index and the primary.
‫Next point to the desk.
‫This is for people listening on the podcast.
‫Were listening.
‫Were what?
‫What is it?
‫We're looking at a picture of secondary index pointing to the primary index and then primary index pointing
‫to the disk.
‫That's just an extra layer.
‫And then they claim that they say here that the application section of MySQL supports multiple replication
‫statement based and.
‫Wool changes and the moment you if you implement if you implement any of these, but if you implement
‫statements based replication, you have true MVC support because now the statement, the wool changes,
‫the coming that is coming to you from the master to the stand by is just another right to consider it
‫another transaction trying to be executed.
‫So it will have truly true and support.
‫And that case will not be blocking.
‫Right.
‫Because you can technically query and right at the same time.
‫And now as a result, you can implement the same exact thing that you're doing because you have a logical
‫view of what is changing.
‫As a result, the database is aware of the change it can implement and VXI at the higher level.
‫All right.
‫Even through replication.
‫Postgres, the support that there is a third party that you can install and does exactly that you can
‫do that is just they just didn't mention that.
‫Oh, and this is an old article.
‫So things can change, obviously, right.
‫In my article.
‫And and they say that, oh, by the way, even the wall the wall says the wall sizes are so small because
‫we're changing, which you do very few things.
‫You know, they go through all of that stuff.
‫I'm not going to go through that, but that's essentially their advantage.
‫They go through another advantage of my school saying that a buffer pool, the buffer pool is the caching
‫mechanism.
‫And PostgreSQL, compared to the buffer pool, is the caching mechanism in.
‫And my sequel, compared to the Cachay Mechanism, Postgres, which is which is basically the RSS memory.
‫Right.
‫And they explaining the difference here.
‫They they they claim that Posterous, using it, uses a different operating operating system, calls
‫like they are using two calls instead of one.
‫I don't know much about that, to be honest.
‫I'm not an expert in operating systems, but a lot of people say that here you have to use a one call
‫to seek and read at the same time instead of seeking and reading.
‫I don't know, maybe Polska actually changes a lot of people here listening and watching this channel.
‫Some some people actually are experts in this thing and might correct that bar, but I'm not aware of
‫that as a result.
‫So I can't comment more much on that part.
‫There is then the energy storage engine implements the least recently used buffer pool and which you
‫can apparently control.
‫I'm surprised that you cannot control them.
‫Cache size and Postgres.
‫I need to read more about that a little bit.
‫But that's another thing that they said.
‫Oh, there's another advantage of MySQL.
‫When another thing says the connection handling MySQL, there's a thread per connection GCP connection
‫to you.
‫Open to my school is a thread on the server side.
‫However, Postgres it's an actual process.
‫So technically now they claim obviously not enough.
‫A thread is cheaper to spin off than a process.
‫I read I read that this is no longer true because the process is almost identical now, but could be
‫back in the days.
‫Could be that was true.
‫But now if you think about it to scale 10000 connections right now, if you think about it.
‫Opening, opening a lot of TCP connections is just a bad idea.
‫So that's why we have the idea of connection pooling, right?
‫We build our application so that it uses a pool.
‫Reserve a pool or of reserve a connection from the pool, execute the transaction and then return it
‫to the pool.
‫And if you're doing a single atomic statement that executed, you can just execute on the pool directly,
‫said, hey, pick any pool, any illnesses in the pool, execute and then return, return.
‫And immediately this reserve and release is also back to their careers if they have a case that spans
‫three, four, five, seven minutes.
‫And.
‫Again, nothing wrong with a query that that transaction, it stands long if you're actually doing all
‫database works, some some some transactions, I've seen transaction that takes 30 minutes.
‫Just because it does a lot of work, it changes a lot.
‫Then these changes, it has to be atomic, right?
‫Yeah, you can argue that you can break it even that you have to break this transaction to smaller and
‫smaller, small, small, small pieces so that each piece can be executed in its own.
‫Atomic Waagner, right, so he can minimize the transaction.
‫So this this also results in if you have a long running transactions, then you have to really think
‫about how deep the reservation and connection pooling works.
‫Right.
‫So the number of connection.
‫Right.
‫Think about it.
‫So that if not if the client's not not using a connection, then don't let them open a connection and
‫just have it open.
‫You just connection Pawling.
‫And they say they use a I believe PJI bouncer's that they're using some some service that actually does
‫that that connection pulling.
‫But a lot of application do it.
‫Even if you don't, you can build your own layer on top.
‫And I show the connection pulling on Polska as many times in this channel, right through this idea,
‫guys, and hopefully, hopefully in the future.
‫And we're all at the end of the article, obviously, guys.
‫Right.
‫Or the end of the article, but hopefully when it comes to connection polling, I really hope that quick
‫as a protocol.
‫And mask, I believe they're just working on a new protocol right now, skull mask that will allows
‫you to kind of stream multiple open multiple streams on a given TCP connection or UDP connection in
‫case of quick.
‫That represents your.
‫You're in your database connection so that if if my sequel or Polska supported Quake and I don't see
‫a reason why not, then the clients can open a single and remember, the clients always observe or something
‫like that to open a single connection and have up to 200.
‫Even more than that streams concurrently in a single Disneyfication.
‫The only trick here is the database has to understand ideastream.
‫So that's a lot of work.
‫But I believe is going to be.
‫Really lucrative for a data base to implement a protocol like that, just like I don't really need TCP
‫anymore, right?
‫A single Tsipi, just a wasteful thing to have a single TCP connection for a given client or connection
‫borling.
‫This has to go away and we have to move to a model where we multiplex.
‫Queries in a single DCP connection using this protocol, whether whether it was even if they implemented
‫their own, they don't have you as quick, just implement and your own protocol that supports multiplexing
‫through multiplexing so that every request, every session, every channel has its own logical representation
‫in that DCP connection that you open.
‫So this you don't have to open.
‫Many can actually.
‫You just have to open one or a few of them.
‫And each one of them has basically some limit.
‫Obviously, that doesn't come with it for free because now you just increase the CPU size at the back
‫end and the front end, because now you have to assemble these channels and streams.
‫That's the problem which DeVita and Quick People start.
‫Lucas Purdue and and what's his name?
‫Chris Wood.
‫And people working on the quick protocol.
‫They're trying to solve this problem with the CPU usage because CPU usage now you have you just not
‫working with just stream of content coming from TCP socket.
‫No, you have to actually look at the data and then arrange the packets so they are in logical streams
‫or channels and then then deliver to the app.
‫So the operating system or the application.
‫Wherever this thing lives, doing extra work, so again, I'm sorry about that Segway, but I want to
‫discuss that a little bit, think I think that's just an idea.
‫That is just great conclusion.
‫Obviously, they say, hey, Polska Sevda served us well in the early days of Uber, but we ran into
‫significant problems scaling Postgres with our growth.
‫Today we have some legacy Postgres instances, but the bulk of our databases are either on top of my
‫cycle, typically using our ski months later.
‫That's another point.
‫You have no schema less.
‫You have schema lists and using MySQL, maybe there is something I'm missing here, but it does not
‫seem natural to me.
‫A lot of people use this podcast as a schema lists where they put a hunk of Jason in a single field
‫as Jason B. And they they they work on that.
‫But maybe that that's just the way for war, because if they have a lot of fields and they have a lot
‫of indexes on those fields, maybe that's the way to go.
‫Who knows?
‫Right.
‫Again, guys, what do you think?
‫What do you think about all this stuff?
‫Let me know in the comments section below.
‫I'm going to see you in the next one.
‫Hope you enjoyed this video.
‫Give it a like if you do and share with your friends.
‫I'm going to see you in the next one.
‫Thank you.
‫Even kill tasers.
‫Kill, kill to keep a staff engineer.
‫And overengineer.
‫This is a great article again.
‫Yeah.
‫And things things have been changing a lot in the Uber ward.
‫But this is again, this is this is a historical article that goes in the years and years.
‫And we had to discuss it, so.
‫Thank you so much.
‫Appreciate you, I'm going to see in the next one.
‫You guys stay awesome.