Socrates: The New SQL Server in the Cloud
Antonopoulos, Panagiotis
Budovski, Alex
Diaconu, Cristian
Hernandez, Alejandro
Hu, Jack
Kodavalla, Hanuma
Kossmann, Donald
Minhas, Umar Farooq
Prakash, Naveen
et al.
The database-as-a-service paradigm in the cloud (DBaaS) is becoming increasingly popular. Organizations adopt this paradigm because they expect higher security, higher availability, and lower and more flexible cost with high performance. It has become clear, however, that these expectations cannot be met in the cloud with the traditional, monolithic database architecture. This paper presents a novel DBaaS architecture, called Socrates. Socrates has been implemented in Microsoft SQL Server and is available in Azure as SQL DB Hyperscale. This paper describes the key ideas and features of Socrates, and it compares the performance of Socrates with the previous SQL DB offering in Azure.
 My name is Christian, by the way. Happy 4th of July to all Americans and Americans at heart. Now it's hard to be here. Thank you for coming. Okay, so Socrates project originated when SQL Engine and its joint collaboration with MSR. And what this project is a new architecture for the SQL server cloud offering. We have several members in the audience that you'll be able to reach out to after the talk. If you have questions, please do. So what are we going to be talking about? First I'm going to try to draw kind of a contour of the focus of the conversation because putting a product like this in and we went general availability in May has a lot of surface that is not germane to this conversation. So I'm going to try to draw the boundaries. And then I'm going to kind of describe the service overall, the characteristics and what the current architecture is, what the drawbacks are and why we're trying to make this change. Then I'm going to go through the principles of Socrates and how what we used to build it as the top level guiding principles. And then we're going to go through an exercise of building in real time with PowerPoint. It's going to be fun. Then I'm going to finish with insights, a handful of insights that I picked at random pretty much that I have gathered personally from building the system. These are a conference special. They are not in the paper because there has to be a benefit for being here. So we left a lot out of the paper. There's just not enough room. And a lot of these, I just put the word cloud. It could have been a lot bigger. Things like orchestration, connectivity, resource governance, security, VPN injection, networking, things like Spanner Aurora, things that other people are doing that are kind of similar, putting databases out in the cloud. Heterogeneous hardware on and on. So I guess I'm pointing out that the problem is a lot more complex. And there are gems of complexity here that if you're an enterprising researcher wants to go, there are plenty of areas here. But we're going to focus narrowly on how we change the engine to make this possible. This is kind of the current DB, SQL DB service. It was announced in 2009, shipped in 2010. Current architecture dates from 2014. There has a bunch of offerings at different price points. It has worldwide availability in more than 40 regions, so widely distributed, millions of database management, and a bunch of flavors of utilization. And the surface benefits from the long legacy of SQL service, a mature product. And easily one of the largest things hosted in Azure, period. And part of the reason I'm putting this out is to explain that there's a large friction when somebody proposes to change this. It's simply a complex problem that has to be solved at scale. So in order to solve it, we have to show, and that's what we're showing this slide, we have to show that we remove important limitations from the service, and we go from the current solution to Socrates and make significant progress while doing so. That's the only way we're going to be able to motivate to our management that, hey, this is worthwhile. And I'm not going to go point by point through this, mostly because I'm going to return to this slide towards the end of the presentation. But what I wanted to point out is that Socrates is at the intersection of two ideas. And from those two ideas, everything here kind of gets derived. One is the familiar kind of separation of compute and storage to which we add the flavor of separating log out. And I think it's an important flavor to call out. And the second idea is, and you're going to see when I present briefly the current architecture, we're moving from a direct attach storage to a shared storage. And if you were in the morning presentation for Aurora, you heard a great introduction as to why that's necessary. And otherwise, I'm going to come back to these points towards the end. Now to be fair, we're not 100% there on these goals. I mean, if you go there and you, Socrates, G8, and May, and you create the Socrates debits, you're not going to get these properties simply where on that roadmap. But we are on that roadmap. And we have a credible path towards these improvements. OK, so what's the current headrun of what we call the current offering, right, that is in the cloud, the one that we're trying to replace? It looks kind of like this. It's a typical replicate state machine, right? Basically we are trying to solve the problem of losing data, right, by replicating data four ways. And it's replicated through log. You have a primary and the log pipeline that replicates the log to all the other three secondaries. One is read, write. The other ones are read only. And there are two functions that I want to draw attention to. There's a log flush function, right, which is the function that achieves quorum by writing log to four replicas before acknowledging back to the user. And the second function is the log apply function, which takes this log that got applied to the secondaries. I don't know why it does that. And applies it to each of the private replicas of all the secondary nodes. OK, so this is the current architecture. What is the problem with this current architecture? We no longer lose data, right, because you're losing four nodes in order to do that. But obviously storage footprint has quadrupled, right? You pay for 4x the storage cost. Not good. Network is in the middle because the log has to be propagated through the network, so there's a scalability problem there. Quorum is also problematic. In order for you to achieve quorum, you have to pay 4x the number of cores that you pay on the primary. So that's problematic. But the worst problem is the fact that data being directly attached means you're limited database size to the size of what a VM can hold, which in our case in Azure is about four terabytes. And that makes size of data operations be prevalent. When you try to see the new node, you have to move this four terabytes to another node, right? So that's a big problem. So we followed this particular cookbook to create Socrates, right? I already talked about separating availability from durability or compute from storage, right? And moving from direct to share storage. But the other three rules is we are going to place the source of truth, the data ultimately is in Azure standard storage. Azure standard storage is cheap bottomless storage that Azure supports. And it has support for snapshots. It's very important, right? So that's the third rule. I picked carefully the icons here. You see a floppy drive because that's about how fast that is. But it's not fast, but it gives us what we need. So I'm not complaining. I'm just saying it's something we need to account for. And we're accounted by using tiered caches everywhere. And the other final rule here is preserve 100% compatibility, right? So those are the guiding principles. So now we're going to use those guiding principles to build Socrates real-time. So let's start with the replicase team machine that I showed before, the previous architecture. Now we're going to pick up the data file, right? We just take the data file and we pick it up from the original architecture. No log yet, right? Just the data file. Then to this data file, we add a particular capability, which is where this whatever tree is. And this is in a paper in VLDB 2019 in LA, but it's online available now. So basically what we did, we added a version store inside of the database, right? We had a SQL server had a versioning support for a long time, 14 years or so. But now we added it in the database. And as we did this, two capabilities derived from this. I'm not going to go in detail, go and read the paper. But the two capabilities, the transactions can read back versions back in time even after a crash. And equally important, we get accelerated database recovery, meaning that we have changed the Aries recovery protocol to give us constant time recovery, right? So then we cut this new file, new enhanced file, and equal size segments, right? And it's a physical cut, right? No regard for content. And we place these segments in Azure standard storage blobs. And we create multiple of these for availability, but from here on out, I'm going to show a single copy just to simplify the cluttering of slides, right? And once we've done this, we can get rid of the file, the original file. We have no use for it anymore. And then remember I said that Azure blobs have this property of having snapshots. So we start the timer and we start taking snapshots, right? Every 10 minutes or so, independent, each blob, right? And okay, so let's stop for a second. What do we have so far if we've done all of these steps, right? What we have is a large, right? Because now it's horizontally partitioned, a large, you read only the database because we didn't bring any log or any writer, right? With support for snapshots, but snapshots are very close to actually having backups support. And snapshots are constant time, so they really take no resources, right? So we've made some progress towards solving some of the original replicase-stain-machine problem. It's horizontally partitioned. So because the remote storage is very slow, we're going to, in this compute node that we're trying to use to access this database, we're going to put a cache, right? To cache the most recent pages to accelerate things a little bit. We're going to make this cache resilient to crashes, right? We're going to, in order for us to recover quickly, right? We don't want the storm of pages to have to be read from the slow remote storage on recovery. So we make this cache resilient, right? And now we have this large-scale read-only database. Great. What do we do with that? How do we add multiple readers now in compute, right? Well, to add another reader in compute, we have to introduce a wrapper process around these blobs because in the future, we're going to start modifying these blobs. And you cannot access a blob that's being modified from two compute nodes without having some sort of wrapper process to negotiate this shared access, right? We call this, we use SQL Server for this process because we reuse all the componentry and we add a GetPage API to this process such that pages can be read directly from the page servers, right? Through a NIO virtualization API embedded in compute right below the bottom of the compute layer. And we call these new things page servers and now we're ready to support readable secondaries. Just like in compute, we had the cache to accelerate access to remote, to data, keep data remote. We had a cache in page servers for exactly the same reason. The difference between the two caches is that in page servers, it's a covering cache, meaning every page in the database exists in the cache in the storage tier. Whereas in compute, obviously, we cannot store every page in the database because the database is really large. Okay, stop again for a second. What do we have right now? We have a large database with fast read access. It's still a read-only database, but we have fast read access because all the data pages are at most a hop away from the compute that needs them. And some subset of pages is right there in compute, right? So it's a fast read-only database. So let's make it read right, right? We pick up the fastest possible device that money can buy, right? We don't care about cost. Let's put it there. And we're going to send the log from the primary compute to that log device, right? Note that this is the same log flush function that I called originally in the original architecture. And log Ios go directly to this device with no interception, meaning that we capture the lowest possible latency the system can give us, right? And once we've done this, we have a database that can write, cannot yet apply the log, but can write the log as fast as possible, right? Now we don't pay an arm and a leg for this. So what we're going to do is we're going to shrink this device to a small size. We're going to call it a landing zone, and we're going to write to it in a circular manner, right? And before we overwrite previous content, we make sure that we destage it to slow, cheap storage, right? And this way we control for cost. And we take advantage of the particular of log access, right? Because tail of log is accessed all the time and it's hot, whereas the old log is almost never accessed, right? So this two-tier thing helps us control cost. Okay, so now we introduce an asynchronous log consumption relationship between all the other consumers, right? And this log device, right? So this dotted line is asynchronous. And we give each one of these log consumers the log apply function. If you remember from the original slide, we have the log flush and the log apply. It's exactly the same function. I'm going to be running out of time. Okay, so, and in the final step, we simply put some memory buffer in front. We call this a broker in front of the distribution in order to avoid hitting this log device from too many readers, right? And that's it. So we're done. That's the architecture, right? What do we get? We get fast log writes. We get fast remote data reads, right? Everything's only one hop away. Fast local data reads because we have these persistent caches in compute. Fast recovery from the non-covering cache and fast-rep creation because we rely on shared storage and the XR database recovery, right? So those are the solutions. Now I'm going to have to skip because I'm going to be running out of time and you won't have time for questions. So. Okay.
 My name is Christian, by the way.  Happy 4th of July to all Americans and Americans at heart.  Now it's hard to be here.  Thank you for coming.  Okay, so Socrates project originated when SQL Engine and its joint collaboration with  MSR.  And what this project is a new architecture for the SQL server cloud offering.  We have several members in the audience that you'll be able to reach out to after the talk.  If you have questions, please do.  So what are we going to be talking about?  First I'm going to try to draw kind of a contour of the focus of the conversation because  putting a product like this in and we went general availability in May has a lot of surface  that is not germane to this conversation.  So I'm going to try to draw the boundaries.  And then I'm going to kind of describe the service overall, the characteristics and what  the current architecture is, what the drawbacks are and why we're trying to make this change.  Then I'm going to go through the principles of Socrates and how what we used to build  it as the top level guiding principles.  And then we're going to go through an exercise of building in real time with PowerPoint.  It's going to be fun.  Then I'm going to finish with insights, a handful of insights that I picked at random  pretty much that I have gathered personally from building the system.  These are a conference special.  They are not in the paper because there has to be a benefit for being here.  So we left a lot out of the paper.  There's just not enough room.  And a lot of these, I just put the word cloud.  It could have been a lot bigger.  Things like orchestration, connectivity, resource governance, security, VPN injection,  networking, things like Spanner Aurora, things that other people are doing that are kind  of similar, putting databases out in the cloud.  Heterogeneous hardware on and on.  So I guess I'm pointing out that the problem is a lot more complex.  And there are gems of complexity here that if you're an enterprising researcher wants  to go, there are plenty of areas here.  But we're going to focus narrowly on how we change the engine to make this possible.  This is kind of the current DB, SQL DB service.  It was announced in 2009, shipped in 2010.  Current architecture dates from 2014.  There has a bunch of offerings at different price points.  It has worldwide availability in more than 40 regions, so widely distributed, millions  of database management, and a bunch of flavors of utilization.  And the surface benefits from the long legacy of SQL service, a mature product.  And easily one of the largest things hosted in Azure, period.  And part of the reason I'm putting this out is to explain that there's a large friction  when somebody proposes to change this.  It's simply a complex problem that has to be solved at scale.  So in order to solve it, we have to show, and that's what we're showing this slide,  we have to show that we remove important limitations from the service, and we go from the current  solution to Socrates and make significant progress while doing so.  That's the only way we're going to be able to motivate to our management that, hey, this  is worthwhile.  And I'm not going to go point by point through this, mostly because I'm going to return to  this slide towards the end of the presentation.  But what I wanted to point out is that Socrates is at the intersection of two ideas.  And from those two ideas, everything here kind of gets derived.  One is the familiar kind of separation of compute and storage to which we add the flavor  of separating log out.  And I think it's an important flavor to call out.  And the second idea is, and you're going to see when I present briefly the current architecture,  we're moving from a direct attach storage to a shared storage.  And if you were in the morning presentation for Aurora, you heard a great introduction  as to why that's necessary.  And otherwise, I'm going to come back to these points towards the end.  Now to be fair, we're not 100% there on these goals.  I mean, if you go there and you, Socrates, G8, and May, and you create the Socrates debits,  you're not going to get these properties simply where on that roadmap.  But we are on that roadmap.  And we have a credible path towards these improvements.  OK, so what's the current headrun of what we call the current offering, right, that  is in the cloud, the one that we're trying to replace?  It looks kind of like this.  It's a typical replicate state machine, right?  Basically we are trying to solve the problem of losing data, right, by replicating data  four ways.  And it's replicated through log.  You have a primary and the log pipeline that replicates the log to all the other three  secondaries.  One is read, write.  The other ones are read only.  And there are two functions that I want to draw attention to.  There's a log flush function, right, which is the function that achieves quorum by writing  log to four replicas before acknowledging back to the user.  And the second function is the log apply function, which takes this log that got applied to the  secondaries.  I don't know why it does that.  And applies it to each of the private replicas of all the secondary nodes.  OK, so this is the current architecture.  What is the problem with this current architecture?  We no longer lose data, right, because you're losing four nodes in order to do that.  But obviously storage footprint has quadrupled, right?  You pay for 4x the storage cost.  Not good.  Network is in the middle because the log has to be propagated through the network, so there's  a scalability problem there.  Quorum is also problematic.  In order for you to achieve quorum, you have to pay 4x the number of cores that you pay  on the primary.  So that's problematic.  But the worst problem is the fact that data being directly attached means you're limited  database size to the size of what a VM can hold, which in our case in Azure is about  four terabytes.  And that makes size of data operations be prevalent.  When you try to see the new node, you have to move this four terabytes to another node,  right?  So that's a big problem.  So we followed this particular cookbook to create Socrates, right?  I already talked about separating availability from durability or compute from storage,  right?  And moving from direct to share storage.  But the other three rules is we are going to place the source of truth, the data ultimately  is in Azure standard storage.  Azure standard storage is cheap bottomless storage that Azure supports.  And it has support for snapshots.  It's very important, right?  So that's the third rule.  I picked carefully the icons here.  You see a floppy drive because that's about how fast that is.  But it's not fast, but it gives us what we need.  So I'm not complaining.  I'm just saying it's something we need to account for.  And we're accounted by using tiered caches everywhere.  And the other final rule here is preserve 100% compatibility, right?  So those are the guiding principles.  So now we're going to use those guiding principles to build Socrates real-time.  So let's start with the replicase team machine that I showed before, the previous architecture.  Now we're going to pick up the data file, right?  We just take the data file and we pick it up from the original architecture.  No log yet, right?  Just the data file.  Then to this data file, we add a particular capability, which is where this whatever tree  is.  And this is in a paper in VLDB 2019 in LA, but it's online available now.  So basically what we did, we added a version store inside of the database, right?  We had a SQL server had a versioning support for a long time, 14 years or so.  But now we added it in the database.  And as we did this, two capabilities derived from this.  I'm not going to go in detail, go and read the paper.  But the two capabilities, the transactions can read back versions back in time even after  a crash.  And equally important, we get accelerated database recovery, meaning that we have changed  the Aries recovery protocol to give us constant time recovery, right?  So then we cut this new file, new enhanced file, and equal size segments, right?  And it's a physical cut, right?  No regard for content.  And we place these segments in Azure standard storage blobs.  And we create multiple of these for availability, but from here on out, I'm going to show a  single copy just to simplify the cluttering of slides, right?  And once we've done this, we can get rid of the file, the original file.  We have no use for it anymore.  And then remember I said that Azure blobs have this property of having snapshots.  So we start the timer and we start taking snapshots, right?  Every 10 minutes or so, independent, each blob, right?  And okay, so let's stop for a second.  What do we have so far if we've done all of these steps, right?  What we have is a large, right?  Because now it's horizontally partitioned, a large, you read only the database because  we didn't bring any log or any writer, right?  With support for snapshots, but snapshots are very close to actually having backups support.  And snapshots are constant time, so they really take no resources, right?  So we've made some progress towards solving some of the original replicase-stain-machine  problem.  It's horizontally partitioned.  So because the remote storage is very slow, we're going to, in this compute node that  we're trying to use to access this database, we're going to put a cache, right?  To cache the most recent pages to accelerate things a little bit.  We're going to make this cache resilient to crashes, right?  We're going to, in order for us to recover quickly, right?  We don't want the storm of pages to have to be read from the slow remote storage on recovery.  So we make this cache resilient, right?  And now we have this large-scale read-only database.  Great.  What do we do with that?  How do we add multiple readers now in compute, right?  Well, to add another reader in compute, we have to introduce a wrapper process around  these blobs because in the future, we're going to start modifying these blobs.  And you cannot access a blob that's being modified from two compute nodes without having  some sort of wrapper process to negotiate this shared access, right?  We call this, we use SQL Server for this process because we reuse all the componentry and we  add a GetPage API to this process such that pages can be read directly from the page servers,  right?  Through a NIO virtualization API embedded in compute right below the bottom of the compute  layer.  And we call these new things page servers and now we're ready to support readable secondaries.  Just like in compute, we had the cache to accelerate access to remote, to data, keep  data remote.  We had a cache in page servers for exactly the same reason.  The difference between the two caches is that in page servers, it's a covering cache,  meaning every page in the database exists in the cache in the storage tier.  Whereas in compute, obviously, we cannot store every page in the database because the database  is really large.  Okay, stop again for a second.  What do we have right now?  We have a large database with fast read access.  It's still a read-only database, but we have fast read access because all the data pages  are at most a hop away from the compute that needs them.  And some subset of pages is right there in compute, right?  So it's a fast read-only database.  So let's make it read right, right?  We pick up the fastest possible device that money can buy, right?  We don't care about cost.  Let's put it there.  And we're going to send the log from the primary compute to that log device, right?  Note that this is the same log flush function that I called originally in the original  architecture.  And log Ios go directly to this device with no interception, meaning that we capture the  lowest possible latency the system can give us, right?  And once we've done this, we have a database that can write, cannot yet apply the log,  but can write the log as fast as possible, right?  Now we don't pay an arm and a leg for this.  So what we're going to do is we're going to shrink this device to a small size.  We're going to call it a landing zone, and we're going to write to it in a circular manner,  right?  And before we overwrite previous content, we make sure that we destage it to slow, cheap  storage, right?  And this way we control for cost.  And we take advantage of the particular of log access, right?  Because tail of log is accessed all the time and it's hot, whereas the old log is almost  never accessed, right?  So this two-tier thing helps us control cost.  Okay, so now we introduce an asynchronous log consumption relationship between all the  other consumers, right?  And this log device, right?  So this dotted line is asynchronous.  And we give each one of these log consumers the log apply function.  If you remember from the original slide, we have the log flush and the log apply.  It's exactly the same function.  I'm going to be running out of time.  Okay, so, and in the final step, we simply put some memory buffer in front.  We call this a broker in front of the distribution in order to avoid hitting this log device  from too many readers, right?  And that's it.  So we're done.  That's the architecture, right?  What do we get?  We get fast log writes.  We get fast remote data reads, right?  Everything's only one hop away.  Fast local data reads because we have these persistent caches in compute.  Fast recovery from the non-covering cache and fast-rep creation because we rely on shared  storage and the XR database recovery, right?  So those are the solutions.  Now I'm going to have to skip because I'm going to be running out of time and you won't  have time for questions.  So.  Okay.
Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_0_155.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_156_239.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_240_647.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_648_911.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_912_983.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_984_1031.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_1032_1211.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_1212_2507.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_2508_6611.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_6612_6671.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_6672_6827.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_6828_7871.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_7872_9479.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_9480_10883.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_10884_11159.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_11160_11243.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_11244_12323.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_12324_13451.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_13452_21227.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_21228_21671.png Antonopoulos_Budovski_Diaconu_Hernandez_Hu_Kodavalla_Kossmann_21672_21820.png
My name is Christian, by the way. Happy 4th of July to all Americans and Americans at heart. Now it's hard to be here. Thank you for coming. Okay, so Socrates project originated when SQL Engine and its joint collaboration with MSR. And what this project is a new architecture for the SQL server cloud offering. We have several members in the audience that you'll be able to reach out to after the talk. If you have questions, please do. So what are we going to be talking about? First I'm going to try to draw kind of a contour of the focus of the conversation because putting a product like this in and we went general availability in May has a lot of surface that is not germane to this conversation. So I'm going to try to draw the boundaries. And then I'm going to kind of describe the service overall, the characteristics and what the current architecture is, what the drawbacks are and why we're trying to make this change. Then I'm going to go through the principles of Socrates and how what we used to build it as the top level guiding principles. And then we're going to go through an exercise of building in real time with PowerPoint. It's going to be fun. Then I'm going to finish with insights, a handful of insights that I picked at random pretty much that I have gathered personally from building the system. These are a conference special. They are not in the paper because there has to be a benefit for being here. So we left a lot out of the paper. There's just not enough room. And a lot of these, I just put the word cloud. It could have been a lot bigger. Things like orchestration, connectivity, resource governance, security, VPN injection, networking, things like Spanner Aurora, things that other people are doing that are kind of similar, putting databases out in the cloud. Heterogeneous hardware on and on. So I guess I'm pointing out that the problem is a lot more complex. And there are gems of complexity here that if you're an enterprising researcher wants to go, there are plenty of areas here. But we're going to focus narrowly on how we change the engine to make this possible. This is kind of the current DB, SQL DB service. It was announced in 2009, shipped in 2010. Current architecture dates from 2014. There has a bunch of offerings at different price points. It has worldwide availability in more than 40 regions, so widely distributed, millions of database management, and a bunch of flavors of utilization. And the surface benefits from the long legacy of SQL service, a mature product. And easily one of the largest things hosted in Azure, period. And part of the reason I'm putting this out is to explain that there's a large friction when somebody proposes to change this. It's simply a complex problem that has to be solved at scale. So in order to solve it, we have to show, and that's what we're showing this slide, we have to show that we remove important limitations from the service, and we go from the current solution to Socrates and make significant progress while doing so. That's the only way we're going to be able to motivate to our management that, hey, this is worthwhile. And I'm not going to go point by point through this, mostly because I'm going to return to this slide towards the end of the presentation. But what I wanted to point out is that Socrates is at the intersection of two ideas. And from those two ideas, everything here kind of gets derived. One is the familiar kind of separation of compute and storage to which we add the flavor of separating log out. And I think it's an important flavor to call out. And the second idea is, and you're going to see when I present briefly the current architecture, we're moving from a direct attach storage to a shared storage. And if you were in the morning presentation for Aurora, you heard a great introduction as to why that's necessary. And otherwise, I'm going to come back to these points towards the end. Now to be fair, we're not 100% there on these goals. I mean, if you go there and you, Socrates, G8, and May, and you create the Socrates debits, you're not going to get these properties simply where on that roadmap. But we are on that roadmap. And we have a credible path towards these improvements. OK, so what's the current headrun of what we call the current offering, right, that is in the cloud, the one that we're trying to replace? It looks kind of like this. It's a typical replicate state machine, right? Basically we are trying to solve the problem of losing data, right, by replicating data four ways. And it's replicated through log. You have a primary and the log pipeline that replicates the log to all the other three secondaries. One is read, write. The other ones are read only. And there are two functions that I want to draw attention to. There's a log flush function, right, which is the function that achieves quorum by writing log to four replicas before acknowledging back to the user. And the second function is the log apply function, which takes this log that got applied to the secondaries. I don't know why it does that. And applies it to each of the private replicas of all the secondary nodes. OK, so this is the current architecture. What is the problem with this current architecture? We no longer lose data, right, because you're losing four nodes in order to do that. But obviously storage footprint has quadrupled, right? You pay for 4x the storage cost. Not good. Network is in the middle because the log has to be propagated through the network, so there's a scalability problem there. Quorum is also problematic. In order for you to achieve quorum, you have to pay 4x the number of cores that you pay on the primary. So that's problematic. But the worst problem is the fact that data being directly attached means you're limited database size to the size of what a VM can hold, which in our case in Azure is about four terabytes. And that makes size of data operations be prevalent. When you try to see the new node, you have to move this four terabytes to another node, right? So that's a big problem. So we followed this particular cookbook to create Socrates, right? I already talked about separating availability from durability or compute from storage, right? And moving from direct to share storage. But the other three rules is we are going to place the source of truth, the data ultimately is in Azure standard storage. Azure standard storage is cheap bottomless storage that Azure supports. And it has support for snapshots. It's very important, right? So that's the third rule. I picked carefully the icons here. You see a floppy drive because that's about how fast that is. But it's not fast, but it gives us what we need. So I'm not complaining. I'm just saying it's something we need to account for. And we're accounted by using tiered caches everywhere. And the other final rule here is preserve 100% compatibility, right? So those are the guiding principles. So now we're going to use those guiding principles to build Socrates real-time. So let's start with the replicase team machine that I showed before, the previous architecture. Now we're going to pick up the data file, right? We just take the data file and we pick it up from the original architecture. No log yet, right? Just the data file. Then to this data file, we add a particular capability, which is where this whatever tree is. And this is in a paper in VLDB 2019 in LA, but it's online available now. So basically what we did, we added a version store inside of the database, right? We had a SQL server had a versioning support for a long time, 14 years or so. But now we added it in the database. And as we did this, two capabilities derived from this. I'm not going to go in detail, go and read the paper. But the two capabilities, the transactions can read back versions back in time even after a crash. And equally important, we get accelerated database recovery, meaning that we have changed the Aries recovery protocol to give us constant time recovery, right? So then we cut this new file, new enhanced file, and equal size segments, right? And it's a physical cut, right? No regard for content. And we place these segments in Azure standard storage blobs. And we create multiple of these for availability, but from here on out, I'm going to show a single copy just to simplify the cluttering of slides, right? And once we've done this, we can get rid of the file, the original file. We have no use for it anymore. And then remember I said that Azure blobs have this property of having snapshots. So we start the timer and we start taking snapshots, right? Every 10 minutes or so, independent, each blob, right? And okay, so let's stop for a second. What do we have so far if we've done all of these steps, right? What we have is a large, right? Because now it's horizontally partitioned, a large, you read only the database because we didn't bring any log or any writer, right? With support for snapshots, but snapshots are very close to actually having backups support. And snapshots are constant time, so they really take no resources, right? So we've made some progress towards solving some of the original replicase-stain-machine problem. It's horizontally partitioned. So because the remote storage is very slow, we're going to, in this compute node that we're trying to use to access this database, we're going to put a cache, right? To cache the most recent pages to accelerate things a little bit. We're going to make this cache resilient to crashes, right? We're going to, in order for us to recover quickly, right? We don't want the storm of pages to have to be read from the slow remote storage on recovery. So we make this cache resilient, right? And now we have this large-scale read-only database. Great. What do we do with that? How do we add multiple readers now in compute, right? Well, to add another reader in compute, we have to introduce a wrapper process around these blobs because in the future, we're going to start modifying these blobs. And you cannot access a blob that's being modified from two compute nodes without having some sort of wrapper process to negotiate this shared access, right? We call this, we use SQL Server for this process because we reuse all the componentry and we add a GetPage API to this process such that pages can be read directly from the page servers, right? Through a NIO virtualization API embedded in compute right below the bottom of the compute layer. And we call these new things page servers and now we're ready to support readable secondaries. Just like in compute, we had the cache to accelerate access to remote, to data, keep data remote. We had a cache in page servers for exactly the same reason. The difference between the two caches is that in page servers, it's a covering cache, meaning every page in the database exists in the cache in the storage tier. Whereas in compute, obviously, we cannot store every page in the database because the database is really large. Okay, stop again for a second. What do we have right now? We have a large database with fast read access. It's still a read-only database, but we have fast read access because all the data pages are at most a hop away from the compute that needs them. And some subset of pages is right there in compute, right? So it's a fast read-only database. So let's make it read right, right? We pick up the fastest possible device that money can buy, right? We don't care about cost. Let's put it there. And we're going to send the log from the primary compute to that log device, right? Note that this is the same log flush function that I called originally in the original architecture. And log Ios go directly to this device with no interception, meaning that we capture the lowest possible latency the system can give us, right? And once we've done this, we have a database that can write, cannot yet apply the log, but can write the log as fast as possible, right? Now we don't pay an arm and a leg for this. So what we're going to do is we're going to shrink this device to a small size. We're going to call it a landing zone, and we're going to write to it in a circular manner, right? And before we overwrite previous content, we make sure that we destage it to slow, cheap storage, right? And this way we control for cost. And we take advantage of the particular of log access, right? Because tail of log is accessed all the time and it's hot, whereas the old log is almost never accessed, right? So this two-tier thing helps us control cost. Okay, so now we introduce an asynchronous log consumption relationship between all the other consumers, right? And this log device, right? So this dotted line is asynchronous. And we give each one of these log consumers the log apply function. If you remember from the original slide, we have the log flush and the log apply. It's exactly the same function. I'm going to be running out of time. Okay, so, and in the final step, we simply put some memory buffer in front. We call this a broker in front of the distribution in order to avoid hitting this log device from too many readers, right? And that's it. So we're done. That's the architecture, right? What do we get? We get fast log writes. We get fast remote data reads, right? Everything's only one hop away. Fast local data reads because we have these persistent caches in compute. Fast recovery from the non-covering cache and fast-rep creation because we rely on shared storage and the XR database recovery, right? So those are the solutions. Now I'm going to have to skip because I'm going to be running out of time and you won't have time for questions. So. Okay.
the principles of Socrates and how what we used to be fun. Then I'm going to finish with possible. This is kind of the current DB, SQL DB points. It has worldwide availability in more offering, right, that is in the cloud, the one the previous architecture. Now we're going to for content. And we place these segments in Azure this database, we're going to put a cache, right? Server for this process because we reuse all the cost. Let's put it there. And we're going to send