Transcript
Shapira: In my previous life, when I was still traveling, giving talks, I gave a talk in QCon, San Francisco in 2018. It was about the evolution of microservices. The last part was the future of microservices. I said that, serverless looks like an interesting step and an evolution. You have all those functions, which are very small serverless. It's not clear how all those functions can interact with databases. Where do they store data? How do they set their state? Things were extremely unclear. When you looked around then like, which were serverless databases to match those serverless functions, it was like, we don't really have many of them. There was Amazon DynamoDB. Snowflake was technically serverless in some respects back then, but nobody thought of it as serverless. Then there weren't really a lot of other options. Fast forward to today, I only fit a partial list into this slide. Obviously, there is a lot of systems that say, we're a serverless database. We were built for serverless workloads. We're a database for the cloud. All those things are now all over the place. Obviously, in the last five years except other than the epidemic, other stuff has changed as well. Why is that? Why did we go from almost no serverless databases to now we have a lot of them? The cynical answer is to say it's a buzzword, anyone who can put serverless in front of whatever they're doing, goes and put serverless in front of whatever they're doing. This is not incorrect but I think there is a lot more to it than that. This presentation will basically go through the reasons that serverless is happening right now.
Context
We'll start with, one reason we have serverless right now is because we can. We are getting better at distributed systems. We have better guarantees, better algorithms, better foundations. We learned how to tame a lot of the issues that really made distributed databases a serious challenge, even just five years ago. We're going to talk in detail about those different architectures that make serverless databases possible. The other side is because it's worth it, because there is now a lot of workloads that actually benefit from running on a serverless database, as opposed to something a bit more traditional. I'm going to talk about in what cases is it worth it, and in what cases you should just stay exactly where you are, and nothing changed for you. The last point is because serverless in the form of Function as a Service is a big deal. Those are new workloads. They do have fundamentally different requirements. They do need data somewhere. We'll talk about what the force that Function as a Service apply toward our data architectures. I'll give some examples of data architectures that, I think, are particularly good for serverless functions.
I'm going to spend about half the talk talking about the internals of a bunch of serverless databases. Why am I going to tell you how to build a serverless database when clearly the vast majority of you are not going to go back and tell your boss, "I'm building a serverless database now." I think you guys are in a position to choose technologies for yourself, for your teams, for your companies. This is what senior developers and architects do. Knowing and understanding the internals and the tradeoffs that were involved in creating those systems will allow you to make really good choices. This is the goal, to equip you in making good choices. If people here listening to my talk would say, "Until today, I thought that serverless is marketing BS. Now that I understand really what's going on and the tradeoffs and the benefits, I think I may look a bit more into it." If that's what you say then, I've done my job.
Background
Until about a year and a half ago, I was leading cloud native Kafka for Confluent. I led this team of amazing engineers. Our goal was to build serverless Kafka experience for Confluent Cloud, when we said that we want serverless Kafka experience. Confluent marketing was very responsible, they never said serverless, we only said that internally. It was our vision, is that our users will only give us their workload, and the credit card, and that's it. We will take care of everything else. You need more resources, you need something optimized, you need to move partition around, you need a different configuration, don't worry about it, produce, consume, send us data, we will figure out the rest. When I say serverless, this is my mental model. As a vendor, it obviously meant that there was a lot on us. The usual, we have to be highly available, we had to never lose anyone's data. Then we had to provide elasticity. Because they're giving us a workload, we don't know how much of it will be, and when it will show up. We need to be able to scale clusters up and down. It's even more than just autoscale. Elasticity for me means being able to resolve hotspots, resolve noisy neighbors, really making sure that every part of the workload always has optimal performance at all times. It was a lot of smart people investing a lot in this. Fast forward a year and a half later, I'm building a new database with a much smaller team of amazing engineers. Because we're building a new database, I get to rethink ideas about a lot of those architectures. This database is not quite ready yet. You cannot go to the website and start using it. It does mean that I've spent the last year and a half rethinking about how to build a modern database from first principles, looking at every bit of architecture, what works, what doesn't, in what situation.
Architecture of Serverless DBs
Let's talk about those architectures. As I mentioned before, the big problem that we're trying to solve when we talk about serverless databases is elasticity. As the vendor, it behooves us to accept every bit of workload, and to make sure it works well. Otherwise, a workload that we have to reject is a workload we cannot charge someone for. It means that we need to take these systems and make them a lot more flexible than they were before. Typically, elasticity means that things have to autoscale. That's interesting. From zero to basically whatever people usually measure, and so the cloud has no limits. It behooves you to have no limits. You want to do it in small increments, because people prefer to pay at small increments. I have one extra bite, now I have to buy this big extra machine that's not exactly serverless. You want the resources you pay for to match what you're actually doing. It has to be almost instantaneous. It used to be that scaling, I think, Aurora Serverless used to take 20 minutes until you get more resources. This thing is no longer acceptable. It has to be in response to load and utilization as opposed to someone clicking, I want more data button. In order to build all that, it's a lot of difficult decisions and a lot of tradeoffs. Nobody does all those five elasticity requirements that I mentioned. We're going to go over some of those decisions and really see how different decisions carry with them other different decisions. If you choose to have big multi-tenancy, there is a bunch of things you have to do. If you choose to have local storage, there's a bunch of things you have to do. Those shape the systems that you're looking at. If you're looking at one type of database, you will see something very different because of the architecture. The thing that makes Amazon Aurora different from CockroachDB, different from DynamoDB, very different from Snowflake is, in many ways, those deep architectural decisions.
Shared-Nothing Architecture
Let's start with one big architecture decision, the shared-nothing architecture. This should be at least slightly familiar, for the reasons that this is the old school architecture. Many people would say, this is not cloud native, or yes, some of the older cloud systems do it. It's not really that. Systems that do it would be DynamoDB, Vitess, Yugabyte. Kafka and Confluent Cloud was one of those. There are successful systems built in this architecture, which is why I hate discounting it is not cloud native. DynamoDB did it, who knows if it's not cloud native? The way the system is built is the essence you have data nodes. Data nodes own compute and local storage. This is obviously great if you believe that local storage is actually faster and more reliable than the storage clusters otherwise available. It's obviously good as long as all the computation is local. There is a query router, usually routers whose job is to distribute the queries, and sometimes also consolidate the results. You try to minimize how much data is going in between the nodes, as much as possible. You try to keep every node independent. This also means making data modeling decisions. If you go and look at the Vitess documentation, they'll have a big section on how to model data so it will work well in that model. Similarly, for DynamoDB and other systems.
You have this system, how do you scale it? That's what a system means, first of all, you need to move things in and out. All the data in each of the data nodes is in the form of small partitions. You move them around, basically. You're at the last node, you move partitions around, some of the partitions become highly loaded, you try to move them to a better place. The main solution is scale those data nodes out. Obviously, you can add query routers, you can add more metadata nodes. Transaction coordinator is the one that is actually much harder to scale out, in general. Usually, when those systems have scalability issues, it's because you're bottlenecking on transaction coordination in some way. Know that the key thing here, the ability to scale the whole thing is built on the fact that partitions are fairly small, and therefore you can move them around with fairly low latency, very little issues, even while the system can be quite loaded. This is how you resolve hotspots. In order to keep the partitions small enough, remember, people are reading and writing data all the time, how do you keep them small? Two main techniques. One of them is that you split them. Partition got above a certain size, it now becomes two partitions.
Again, very old technique. I don't think I'm saying something new here, but still used in DynamoDB. It's great if your partitioning scheme is hash partitioned or range partitions, these kinds of things work quite well. The other solution is what is also known as tiering, this is what Kafka did. The insight here is that you look at a partition and say, actually, only this small chunk at the top is valuable. Remember that Kafka is a log. Most of the reads and writes are on the top of the log. The top 10% get 90% of the load. This means that in order to keep it small, you can take the tail of the log and shove it into slower storage like S3. This keeps the main hot partition much smaller and allows you to move it around.
The other key part of the system is the rebalancing algorithms. The idea is that you have a lot of metrics about the load on the node level below the partition level. You have a process that continuously looks at all those metrics and says, this node is getting a bit loaded. It doesn't have enough capacity. Let's take some of the partitions and move them somewhere else where it makes sense. Or if there is no place where it makes sense and things are getting loaded, you need to actually add capacity. Those are really challenging. We had a lot of smart people spend a lot of time trying to get it right. Because we don't want to move data too much, it takes resources, and those resources could be better used for something else. On the other hand, you do need sufficient spare capacity on every node to allow things to burst and to give you headroom to handle all kinds of situations. One of the things we learned is that you really want to aim at a lot of local decisions with some safeguards. You don't want to come up with this amazing global plan for the entire cluster with the perfect placement for everything, because it takes a lot of time to compute this plan, in a large cluster it can be hours. As a result, by the time you finish computing and finish moving everything, the situation changed, cloud moves very fast, workloads change all the time. Don't do that. Look for signal that things are getting highly loaded, like the 60-ish percent CPU, and start moving some things to a less loaded node, it will keep things, more or less, in balance over time. Obviously, if you find out that you move things between two nodes, or the same partition a lot, then you need to flag that something is off here, and maybe we're doing useless work.
Compute-Storage Separation
The other big algorithm, compute-storage separation. This is the one that's considered more cloud like. The Snowflake paper, I think, circa 2011, says, in the cloud, the architecture that takes the best advantage of the cloud system in order to provide elasticity and flexibility for the users is the compute-storage separation. Everyone looked and said, that looks like a good idea. A lot of those architectures showed up. The main idea is that you're now running two clusters. You have a storage cluster, where the data is just, think about it as dumb blocks. S3 is a good example, or even EBS, you just have chunks of data stored in there. Any machine can reach out to anywhere in the storage cluster to grab any set of blocks. The responsibility of the storage cluster is basically, don't lose blocks, and be available. That's the main thing. Also, you can push more down into it and ask it to do a bit more. Compute nodes are the ones that do the majority of whatever you need your system to be: filters, joins, aggregates, whatever you need from your compute layer, this is where it's happening. The key to this system's performance is that you want things in the compute node to be logically cohesive so you can take good advantage of caching, because remember the storage node, you have to reach out to another cluster. Then joins require obviously a lot of data locality. You are looking for ways to get everything you need for specific workload on one compute node. If you go to Snowflake, they will ask you to define multiple data warehouses. Those data warehouses are essentially compute nodes. If you need more compute, you will buy additional data warehouses.
Aurora/Snowflake Scaling
How do you scale those? There is basically two methods of scaling them. We'll start with the Aurora/Snowflake type of scaling. Storage cluster is easy. It's, again, a cluster of bytes of data. You add additional nodes, they will replicate things over, stuff will move over. In many ways, the storage cluster still acts like shared-nothing cluster, except it's a storage cluster. The compute nodes on the other hand, in the Aurora model, they don't scale out, they scale up, meaning that every compute node is essentially a database. This has amazing advantages because it means that you can look at it like it's a normal database. You don't have to think hard about how do I partition data correctly. You don't have to think about, some of my data is not local, and if I have transactions, I have to do some logs and they take extra time. You basically use it normally. If and when things get loaded, they have nice ways to take the container with the database, with its entire state, with all the connections, with all of everything, and either give it more space on the spot, which is I think fairly easy with modern containers. Or if the entire physical node is busy, they can move it. It should be transparent. In reality, you will see a blip in your latency graph when this happens. It's not as transparent as many want it to be.
With this model, it has two interesting benefits on what you get from it. One of them is that the compute-storage separation means that you can do nice things like spin up another compute node, and point it at the same storage and set up Copy-on-Write. This essentially just created a branch of your database. Delphix did it ages ago. This is obviously much easier because you just do a click. You don't have to actually run the whole thing. It's Aurora, it runs in the cloud. This situation is nice. Obviously, it has limits on how much it can scale up that are a bit harder to solve. Back in the day when we were all in data centers, there was this thing where everyone used those big storage clusters, like EMC and stuff. Then there was always this big Oracle database that whenever it took its weekly full backup, usually on Friday at 3 a.m., everything else would grind to a halt. It doesn't happen quite that badly on Aurora, but you definitely sometimes notice that the storage cluster that you're on is a bit busier than normal. You see some noise from that as well.
Spanner/CockroachDB
The other approach to compute-storage separation is the one that was started with the Spanner paper, and CockroachDB has this system. Which is that you separate compute and storage, but you also scale out the compute nodes. How do you maintain things like transactional integrity when you have compute nodes, every one of them handling their own workloads and their own transactions? This is where things get pretty complex. They use things like Raft and Paxos to maintain transaction logs. You have to get consensus on transactions, so all the compute nodes, basically. The storage cluster is not just write data, it is, maintain transaction guarantees. It has to log all the transaction guarantees. Both Spanner and Cockroach, they're at global scale. Things like Raft and Paxos are extremely efficient in a data center. The moment you start trying to make them global, they actually lose a lot of their efficiencies. They're a bit too chatty for a lot of back and forth. In those cases, it's common to have two-phase commit to the other side of the globe. You need to be aware that you cannot really stop doing transactions. If you're on Spanner or Cockroach, you're there because you want transaction guarantees, like most normal engineers who discover that they actually want to know what the data is at the end of the day. You have to remember that, in this scenario, you can scale out impressively. There will be slowdowns related to transaction if they cross the globe.
Key Lessons
The big lesson is that there is no free lunch. You have to understand the tradeoffs. If I go with Aurora, I have to not think about some things, I have to think about other things. Transactions are not an issue. Cold start is an issue, minimum payment may be an issue. If I go with something like DynamoDB, then things are perfect, but I have a key-value store. There's all kinds of things to take into consideration and make sure that you understand what each system is actually capable of delivering. The one thing to note is that while you will have to make tradeoffs, if you decide you want a very elastic system, look at the situation. It does not require changing the whole way you ever use the database. Meaning if you like key-value stores, there will be several for you to choose from. If you like relational, there will be a bunch. If you like specific type of relational, and MySQL fans will be. If you like Postgres, there are going to be. You don't have to change a lot about your worldview. This is not the same case if you try serverless functions, which is, learn a whole new way to write code and manage code and so on, because I'm still trying to wrap my head around how to build functionality from a lot of small independent functions. The other thing is that every rubric has different latency tradeoffs. Aurora would have the spikes and a bit of noise. If you have the systems that move stuff around, you might notice the changes in performance as stuff moves around. The vendor may do maintenance at times. This will have an impact that you may notice in the graph. You need to understand what you're getting. You need to also understand your alternatives. This is the important thing. I've seen a lot of cases where people are looking and saying, "I can't use it, because I cannot afford any performance spikes." Those performance spikes happen when we scale up, which means that the machine that you already have is not big enough. What happens to you today when the machine you have is not big enough? You have bad performance anyway, except this one goes away after a few seconds, and the other one actually gets worse and stuff queue up. I've seen situations where performance requirements were unrealistic, even for a provisioned system with the best engineers in the world trying to make it work, or was extremely cost prohibitive, and the customer was very clear that the cost is not going to work for them.
At the end of the day, the cloud is just someone else's computer. A lot of people imagine that problems will be magically solved if we move workloads to the cloud. I think a lot of cloud vendors encourage the magical thinking around it. At the end of the day, it is computers and databases run by the best experts in the world with a lot of time and money to make it happen. There are some requirements that even the best in the world cannot really do. Think long and hard about, if I'm not using this, what will be the alternative. Will I actually get what I need in other situations? The other thing about low latency in general, testing and more testing. These things are dependent on the cloud vendor and the region that you're in. If you're on U.S.-East-1, the chances of noise are a lot higher than if you are in a small cluster in the South East Pacific. It obviously depends on your workload. If you're connection heavy, it will be very different than if you are doing huge computations than if you're reading massive amounts of data, throughput, IOPS, all those things, test and test. You don't even know what is the low latency and how inconsistent things are, until you try them out.
When Do You Need Serverless DBs?
With that in mind, all these does not matter if you don't actually need a serverless database. Let's talk about this. I'm going to talk about a bunch of scenarios. Let's start with the easy one. You're a small company. You have one workload, and it's pretty stable. You're still not growing that much or that fast, or maybe you're growing pretty fast, but because it's one workload, you can plan a trajectory ahead. This is great. Life is good. Just figure out how much space you need for a one server workload and move on with your life. Maybe putting something in your calendar once every three months to take a look to check if it's ok again. Some things are not broken, enjoy them. Now, as stuff get bigger, usually you start having multiple workloads, but sometimes all of them are fine. This is harder. You still have to understand how they interact with each other. You still have to worry about having enough space for this one crazy guy who may do something. Planning capacity is harder. Tuning can be a lot harder because those workloads may actually conflict and require different things. Because they're fairly stable, it's almost a one-time investment. You do it for every one of your workloads, and they don't change much, and you can move on with your life. This is still ok. If you have enough people to do it, your life is still fine.
Where things get hairy, when you have a lot of variability. Variability can be in a day, it can be in a month, it can be this time of year when stuff start jumping. All of those can be variability. It can be more predictable variability. It can also be very unpredictable variability. The fact is that if your workload is very variable, you need a lot of spare capacity. Otherwise, when you hit the peak, it will not work, flat and simple. The problem with having a lot of spare capacity, is that if you look at how much your company's customers pay, how much value your company derives from the database, it's actually along the lines of the average. Your customers don't get value when there is no workload, essentially. There is a big gap, especially this day and age. I've been through the 2000 recession. I've been through the 2008 recession. Here we are today, executives ask a lot of questions. Why do we need all those databases that are only at 20% capacity? Why can't we put them all together and have something at 80% capacity? We all know the answer. It's, in general, a lot of conversations that is amazingly pleasant to have. Even more along, if it's a relatively small system, 70% spare capacity sounds like a lot, but it actually may not be that much in actual workload. It may be just a few extra megabytes. In this situation, that's where actually moving to serverless cluster, from a cloud vendor, is very reasonable. Why? Because that's the whole point of the serverless cost model is that you're paying for what you use. The executives will be happy because they are finally paying for the value delivered. You will not have to think about how to capacity plan for the peak of demand, that who knows how high it will be and then get paged when you didn't plan enough. You will not have to sit through meetings of, am I provisioning too much or too little? Because, who knows? How do you even know? This is exactly when it makes a lot of sense to push the problem to someone else.
There is an even more fun situation. If you work for a place that is especially crazy, you may have a lot of workloads that are highly variable. This is true, especially if you're working for a larger company, especially one that does good business across the globe. Then, you have the peaks for the IPL in India versus Thanksgiving in the U.S., and all those things have to come together. This is a nightmare if you're trying to manage it. I've been there a few times, it was always a gigantic headache. If you set up a serverless system yourself, it puts you in a position where you can be your own cloud provider in a way. If instead of giving every workload its own machine, you can actually create large clusters that those workloads can be elastic inside. It means that you can have a lot lower spare capacity, but because it's spread out across many machines, it's actually a lot more capacity in practice. Twenty percent spare capacity on a very large cluster can be 10 and more times bigger than 70% spare capacity on a small cluster. Mathematics. It does mean that you need one of those solutions, moving stuff around, or offloading things to S3, or all of the above. It really means that you can get the benefits of this elasticity in your data center, which is extremely cool. To summarize, basically, the more tenants you have, and the more variability you have in your workloads, the more serverless would make sense for you, from both economic perspective and from lack of headache perspective. You don't have to capacity plan for the unplannable, is the main point here. I know that many times people think that serverless DBs may be like, yes, maybe in some situations. I think it may make more sense than you believe, and worthwhile checking if you could benefit from cost savings and less time spent trying to predict the future.
Function as a Service (FaaS)
The last point is, how does Function as a Service fit in, and the force that it applies on a database? Serverless databases are useful, even if you don't use Function as a Service. If you do use Function as a Service, you absolutely need a serverless database. How many of you use Function as a Service? The main point is that the more your workload is variable, the more risk it poses to your database. Function as a Service, by definition, is the most variable workload possible. It can burst from zero to hundreds and thousands of connections and requests per second in an eyeblink. It can and has killed very large clusters, because it's essentially a tool for self DDoS. It's impossible to capacity plan for something that can scale from zero to thousands without blinking. This is obviously a big concern. There are other concerns. There is no local state, it means that there is no connection pooling. We will have to start connections. It will mean that it will have to read all the data it needs from the database as fast as possible when it starts. Obviously, people who are running it are paying for execution time, so they will get extremely upset when it takes a long time to gather data from database to do a thing.
Two common architectures for this situation, the simple one and then the one that actually works. The simple one is basically, have all the functions connect directly to the database. It works. It works in some situations. The database, first of all, has to make it extremely cheap to start new connections. This is true for every serverless database out there, they add a proxy, or they make modifications to the protocol, they make modifications to the database itself. They have to make it cheap. This is important. Not true for every database that was not built to be serverless, especially if you have MySQL, Postgres, you may know, every connection is an entire process. You have to be very careful about things that show up, start the connection, run a single query, and disappear. The other situation where it makes sense, obviously, is databases have to be extremely elastic, because you don't know if it will be one function right now, and in two seconds, it will be a thousand of them. You want it to be very close geographically to the functions. Again, not bad in the cloud, if you have databases in a lot of places. It's important, because, again, time is money in serverless world, and getting data over larger distances take longer than getting data over shorter distances. Remember that they have no state, they're never going to cache anything. Forget about, the application will cache stuff, which we've all gotten used to over the last 30 years of doing databases and backends.
The ones that I think works in most situations, even though it's a bit more effort, is to have something between those functions in the database. This something can be a lot of things. It can be a backend, because as much as I love Function as a Service, I still don't believe that our entire business logic will ever be managed in tiny independent functions out there in the cloud. I think we will always do some stuff maybe in those functions, but most of the core business logic will be in an actual backend with actual services. Functions will connect to the backend, the backend can have stable database connections that will bring some stability to the thing. The other option is to have a proxy, which will make connections. Again, it will provide a stable connection pool. If you can throw in a cache, so much better, because it means that functions don't have to wait for the database, essentially. I'm putting it like as a three-tier architecture here, partially for space and familiarity, but know that you can have as many layers of this as you want and need. Think about it like a CPU, L1 cache, L2 cache, L3 cache, all those things. Have one cache very close to the database, have one very close to the functions. Have some logic in between. It's actually not trivial to manage. Again, at the very least, having one layer that is backend business logic, and caching, and provides this permanent connection pool, I think makes a lot of sense in almost every situation.
Summary
If you're going to use serverless, dig very deeply into the architecture and the tradeoffs, because not all serverless are made the same. There is higher likelihood than you think that you are going to benefit from a serverless database, because they take off a lot of the capacity planning, picking a machine, tuning things, and then scale-in, scale-out as needed, and they can save you some money. If you use Function as a Service, you need a serverless database, and you probably need a bunch of layers in between as well.
Questions and Answers
I think there's a lot of challenges in sharding your database, East Coast, West Coast, in general. This one is actually fairly reasonable. DNS does allow you to have locality, and AWS does have services that tell you, route connections to the lower latency location.
Participant 1: Does that mean that when I do sharding I'm required to keep the code on both data.
Shapira: Is that the expensive option? Usually, you say, we have some customers in the East Coast and their data is in the East Coast. Especially important, if you have customers in Europe, it's really important for them that their data will be only in Europe. Nothing that I said solves data locality for you, which is a lot more complex than just performance. Because you have regulations, where is data allowed to live? How long can you keep it in each location, and so on?
Participant 2: You mentioned the two types of architectures, mainly two types. One is storage-compute separation, and the other is shared-nothing. I feel that even both of these have some kind of storage, though. Even in the shared-nothing architecture, your computing is still as far as you know it. I think there's still some similarities in scaling like the storage unit of the two types of architectures. Is that correct?
Shapira: It's absolutely correct. I think it depends, like there's always a lot of [inaudible 00:41:40]. Because for example, if you take your compute nodes, and the storage is actually EBS, you already have a storage cluster. It's a bit too limited. It doesn't let you share it, essentially, so you can't use it as shared storage for the entire cluster, for the data cluster, but it is a cluster. This was very true up to maybe a year or two ago. Even the highest tier EBS is not the same performance as you get from local SSDs with some NVMe running, and all that. In some cases, when we talk about keeping compute and storage together, I'm mostly talking about places where you really keep them physically together on the same box, like the way we used to sell Hadoop, back in the day, essentially. There's a lot of benefits for bringing compute and storage together. Reading from storage, for example, is way faster, higher bandwidth, and so on. You have less bottlenecks in between, which are a lot of times a problem if you have the separation. If you are going to put compute resources together, put them really together, otherwise, you definitely don't get the full benefits of putting them together. If you separate them out, then you need to separate them out to storage that actually gives you the capabilities that you need. There's a lot of in-betweens. If that was Snowflake, they use S3 as their offline storage that can be shared. The data nodes because they are long lasting, and they don't scale out and so on, they actually store a lot of data locally. It's just that the local data they call it cache. It's cache sitting right there on SSDs, and has more space. They call it cache because if you lose the entire machine, they can rehydrate. I showed it as like either this or that, but there's actually a lot of variations in between.
Participant 2: Actually, there's maybe a hybrid model of shared-nothing, and the storage and compute separate model. Some of the analytical databases normally complain that they don't work with both models. I think maybe StarRocks is one of those. They claim that if you want high performance, you need to import the data from cloud storage to their own storage. I think probably at that time, they may do some compute and storage bundled together. You can also just read data remotely from cloud storage. What do you think about this model?
Shapira: I would go as far as I say that everything there is a continuum. I think there's very little in the pure coupled compute and storage and there's very little in the fully decoupled, and having more models that allow you to place yourself in this continuum. Because the whole goal is to optimize performance in certain situations, and to allow for scale-out in other situations. The hybrid model, which is, say, you have virtually unlimited storage, because it's all on a big storage cluster, but you also get the high performance because you're loading things into a local machine. I think this is what almost everyone is doing behind the scenes. For me, it's more, do you want to have this control over what you're building in, or do you prefer your vendor to more automatically do it based on what they think they'll control, and they'll have their own cache policies. It sounds like it's maybe more about control and maybe this model gives you amazing performance for your situation. Then some people would prefer slightly less control and it may work for them.
See more presentations with transcripts
