Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we built a serverless SQL database

cockroachlabs.com

Post reply on HN
Print view View original

111–120 of 122 posts

Re: How we built a serverless SQL database

#111

Post by kennethh »

infogulch wrote: post #83
psadri wrote: post #44

Earlier quoted context omitted.

Unfortunately, easy to hit that with say GraphQL where each client request can resolve to dozens of db selects vs a single hand written/tuned SQL select.

If you're using GraphQL with SQL -- postgres specifically -- I would say use Hasura, but support between Hasura & CockroachDB seems to have stalled due to missing triggers [0] [1]. CRDB supports a feature called "changefeeds" [2] which is claimed might cover some of Hasura's use-cases, but that's a proprietary extension not present in base PostgreSQL. [0]: https://github.com/hasura/graphql-engine/issues/678 [1]: http…

Any views on which to choose between Prisma, Hasura or postgraphile for GraphQL and postgres?

Re: How we built a serverless SQL database

#112

Post by _vvhw »

mjb wrote: post #40
phoboslab wrote: post #37

> If you’ve created a database before, you probably had to estimate how many servers to use based on the expected traffic. The answer is "one". If you have less than 10k req/s you shouldn't even start to think about multiple DB servers or migrating from bog-standard MySQL/MariaDB or Postgres. I will never understand this obsession with "scaling". Modern web dev seriously over-complicates so many things, it's not even…

What happens when that database fails? Are you OK losing some data, or do you want the data to be synchronously replicated off the machine and be available somewhere else after failure? Distribution isn't only about scale, it's also about availability. What happens when that database loses some data? Do you want an up-to-the second backup, or point-in-time recovery? Or are you OK restoring last night's backup? Distri…

This is probably one of the best motivations for a distributed database that I've read.

I find that it's not often that people grasp that distribution is about availability. It's obvious when you say it, but for a long time my own intuition was that distribution is about mostly durability or consensus protocols to provide total order across multiple machines. Yet these build together into availability.

In fact, I first noticed this distinction when reading Brian M. Oki's seminal 1988 paper on Viewstamped Replication, the work that would pioneer the field of consensus—a year before Paxos but with an intuitive protocol essentially identical to Raft. The surprising thing is that today many of us might have titled the paper something about "consensus" or "total order" (which it practically invented, and which was the major breakthrough, at least how to do this in the presence of network partitions) but that he titled it "Viewstamped Replication: A New Primary Copy Method to Support Highly-Available Distributed Systems".

I did a short intro talk to Viewstamped Replication (and particularly why FTP or nightly backups or manual failover are not a solution): https://www.youtube.com/watch?v=_Jlikdtm4OA

The talk is followed by interviews with Brian M. Oki and James Cowling (authors of the 1988 and 2012 papers respectively).

Re: How we built a serverless SQL database

#113

Post by mgartner »

phoboslab wrote: post #37

> If you’ve created a database before, you probably had to estimate how many servers to use based on the expected traffic. The answer is "one". If you have less than 10k req/s you shouldn't even start to think about multiple DB servers or migrating from bog-standard MySQL/MariaDB or Postgres. I will never understand this obsession with "scaling". Modern web dev seriously over-complicates so many things, it's not even…

It seems like you’re defining “scaling” as growth of a workload to the point that it cannot be handled by a single-server DB.

But with any service without a constant workload (I’d wager almost all services besides prototypes that get no users) you’re going to have to literally scale that one machine, by replacing it with a bigger machine. When you have 50 users you’re not going to be paying for some yy.24xlarge. You’ll start with something much more affordable. When the service grows to 50,000 users, you certainly won’t be at “Facebook scale”, but that t3.small isn’t going to cut it. Should your service ever decline, it’d be nice to scale that machine down to save on costs.

At a previous job, we spent many human hours continually ratcheting up the size of our Postgres machine a few times a year. Not only did this take non-trivial engineering hours and mind-space, it also caused maintenance downtime due to the limitations of traditional DBMSs.

Self-managed CockroachDB eliminates the downtime needed to scale. To handle a more intense workload, add machines. If you want to vertically scale each machine, that can be done without downtime too.

CockroachDB Serverless takes this a step further by scaling up and down to suit the demands of a highly dynamic workload, while minimizing costs.

Maybe what looks like an mega-scale obsession to you is actually a bunch of people trying to avoid the common headaches of managing a moderately sized, dynamic service.

Re: How we built a serverless SQL database

#114

Post by andydb »

yla92 wrote: post #92
andydb wrote: post #2

To any who might see this, I'm the author of the blog post, and led the engineering team that built CockroachDB Serverless. I'll be monitoring this thread in case there are any questions you'd like to ask me about it.

> Each node runs in its own K8s pod, which is not much more than a Docker container with a virtualized network and a bounded CPU and memory capacity. Dig down deeper, and you’ll discover a Linux cgroup that can reliably limit the CPU and memory consumption for the processes. This allows us to easily meter and limit SQL resource consumption on a per-tenant basis. Nice use of K8s here and overall a great post! This is…

We haven't run into that so far, but thank you for pointing it out as something to watch out for.

Re: How we built a serverless SQL database

#115

Post by andydb »

amitkgupta84 wrote: post #95
andydb wrote: post #2

To any who might see this, I'm the author of the blog post, and led the engineering team that built CockroachDB Serverless. I'll be monitoring this thread in case there are any questions you'd like to ask me about it.

How will you handle PrivateLink and VPC Peering connections into customer VPCs/Vnets with the multitenant architecture?

We're still discussing options there, so I don't have an answer on how we might handle them. We do recognize that many business customers will have such requirements.

Re: How we built a serverless SQL database

#116

Post by lumost »

mdekkers wrote: post #79
lumost wrote: post #58

Earlier quoted context omitted.

The answer is unfortunately less clear cut. Particularly if you assume that whoever is tasked with scaling this hypothetical DB doesn't know what they are doing a-priori. The following questions are likely to come up 1) My t3.xl DB is down, how much bigger can I make it? 2) My r3.24xl DB can only handle 100 TPS and now my site is down, what can I do? 3) My 2x r3.24xl DB cluster costs a lot of money, Are other solutio…

> The answer is unfortunately less clear cut. Particularly if you assume that whoever is tasked with scaling this hypothetical DB doesn't know what they are doing a-priori. The answer is very clear-cut: Work with professionals.

The number of professionals who know and care about scaling who also want to work on small scale applications is relatively small. Hiring them will pose a challenge.

Re: How we built a serverless SQL database

#117

Post by webmaven »

andydb wrote: post #8
rabaut wrote: post #5

Does CockroachDB Serverless expose an HTTP api? This sounds like a great fit for use with Cloudflare Workers, but that requires an http api.

Great question. We recognize how important this is and are actively working on it.

Is it possible to use PostgREST in front of CRDB to solve this use case?: https://postgrest.org/

Re: How we built a serverless SQL database

#118

Post by anamax »

Tanjreeve wrote: post #110
anamax wrote: post #87

Earlier quoted context omitted.

All bridges have a capacity limit. "Doesn't scale" doesn't imply "inadequate." Overbuilding is waste.

Software isn't bridges though. If you run into scaling issues if you're lucky it's just a case of swapping out a database for a bigger one. More likely it isn't just that though and being able to do things like scale up distributed workers coherently with a change of a config file requires upfront thought and design that YAGNI would say isn't necessary. People just breezily saying "we can optimise it later" for a sca…

No, software isn't bridges. When bridges fail, people die. When reddit crashes, people take a piss and pet the cat.

I don't know the relevant details about reddit but the assumption that the early reddit people could have easily built something more scalable yet there are tech reasons why the later people, with far more resources, can't.

As to the assumption that one knows the important bottlenecks 2-3 orders of magnitude in advance, that's just wrong.

"late answers are wrong answers" isn't just for real-time. That applies to products as well as signals.

Technical debt is not necessarily a bad thing.

Re: How we built a serverless SQL database

#119

Post by andydb »

webmaven wrote: post #117
andydb wrote: post #8

Earlier quoted context omitted.

Great question. We recognize how important this is and are actively working on it.

Is it possible to use PostgREST in front of CRDB to solve this use case?: https://postgrest.org/

We're working on enabling PostgREST. There is some small-ish functionality that we need do in CockroachDB for it to fully work.

Re: How we built a serverless SQL database

#120

Post by psadri »

aaaaaaaaaaab wrote: post #60
psadri wrote: post #44

Earlier quoted context omitted.

Unfortunately, easy to hit that with say GraphQL where each client request can resolve to dozens of db selects vs a single hand written/tuned SQL select.

Maybe that's a good reason to avoid GraphQL then?

In theory the graphql server could be smart enough to assemble a single SQL select to satisfy the query. Does anyone know of an implementation that does this?
Post reply on HN