91–100 of 113 posts
A favorite resource: https://learn.microsoft.com/en-us/azure/architecture/pattern... Microsofts Azure Cloud Patterns is some of the best documentation out there. It's not Azure centric. It focuses on why you may want to do something and describes the techniques that are commonly used to solve it. It's pretty great.
Earlier quoted context omitted.
Solutions like Spanner are fantastic for some things (and within Google it's a no-brainer, since you're not paying an outrageous markup), but besides being expensive, they don't just let you drop them in as a scalable replacement for an existing usage pattern, and usually sharding starts first coming up when you're at a huge scale and already have a ton of app code and database design but have grown past what a singl…
> Consider a beefy AF bare metal SQL server, see how far that gets you. Quite far, possibly to millions of users. Case in point: StackOverflow runs on SQL Server.
Earlier quoted context omitted.
Actually it can vary "from not that" far to "all the way" (StackOverflow). It depends very much on the schema and the type of workload. But in general people really underestimate how far an RDBMS can take you.
Yes and no - I think people also underestimate how miserable running a single giant RDBMS can be. Everything gets hard and dangerous - backup/restores, upgrades, online migrations & schema changes. Adding the wrong index can easily brings the whole thing down. They are complicated beasts that get very fragile at the large end (size+throughput)
Everything becomes fragile at the large end.
And the best sharding? Doing multi-tenant. Sharding at table level is very complex and expensive. Fully give a single DB per tenant is very practical, and the reasons to do sharding (like reporting) is where you do the other fancy things (like ship events in to kafka, etc, etc). Also, most issues of scalability are dominated by a few tenants that consume most resources, and distribute the loads is more easy per-tenan…
I've been doing that as much as possible. however you're still left with availability issues, such as replicating / failover management etc. Which really are orthogonal issues to tenancy. How do you manage that ?
Availability is kinda good: You could lose one/few tenants but that not take down all the rest (if they are isolated properly).
Is MUCH worse if all the db made the fancy way get down, or worse, you get a cascade of latency and/or crashed by the interlinked nature of the "scalable architecture that is fact share-everything global singleton".
And you can get a bit fancy (not done it myself, my customers tolerate a bit of downtime) of fork the tenant and upload it another node.
Earlier quoted context omitted.
You need Citus
Citus follows a single-master architecture for replication just like standard postgres. Citus would be a good solution to add additional writable nodes via sharding tables accross multiple databases. Recently they've been acquired by Microsoft & have started to been integrated into their CosmosDB offering. Anybody have good experience with this DBaaS offering?
Earlier quoted context omitted.
> In a world where things like Dynamo/Cassandra or Spanner/Cockroach exist, manually-sharded DB solutions are pretty much entirely obsolete. Not really. Cassandra is a write optimised, slow, network and IO heavy beast thats a pain in the arse to administer. We replaced a 6 node m4.4xlarge with a single db.m4.2xlarge. on postgres. You need to pick your DB to match your data, not the otherway around.
Spanner and Cassandra really shouldn't be in the same sentence. They are optimized for very different use cases. The "obsolete" part of that quote does apply to Spanner, TiDB, and CockroachDB in my experience. I haven't used Yugabyte, but the other sharded databases, including Vitess (TiDB is what Vitess is trying to be), actually make life harder.
For most people(ie 95% of people) After putting a caching layer, paying for a bigger RDS(or equivalent) DB service is the cheapest and fastest option.
Earlier quoted context omitted.
How does cockroach compares in terms of performance to manual sharded databases ? My intuition is that a properly sharded database will perform faster-or-same as a non-sharded one in all scenarios. Whereas automatically-sharded database will actually perform worst until you start reaching critical traffic that a single instance won't handle no matter what. Am i wrong ?
[disclosure, former cockroachdb engineer] you can get expected "single shard" performance in CockroachDB by manually splitting the shards (called "ranges" in CockroachDB) along the lines of the expected single shard queries (what you call a "properly shared database"). This is easy to do with a single SQL command. (This is what we do today; we use CockroachDB for strongly consistent metadata). The difference between…
Earlier quoted context omitted.
What's the alternative as things get too big? Sharding by date? By client? How do you prevent hotspots?
Distributed databases like Yugabyte, Cockroach, TiDB, etc.
> I suppose the more fundamental question is: why are you not using a database that does sharding for you? Over the past few years the so-called “serverless” database has gotten a lot more traction. Starting with the infamous Spanner paper, many have been thinking about how running a distributed system should be native to the database itself, the foremost of which has been CockroachDB. You can even run cloud Spanner…
Earlier quoted context omitted.
It’s supposed to be MongoDB compatible (if I’m not mistaken). Last I checked, that “compatibility” run at least a couple major version behind the real MongoDB. To be fair, the same is probably also true with AWS’s DocumentDB
I think that AWS DocumentDB uses the last mongodb version that wasn't their new(ish) SSPL license and any compatibility beyond that was "clean room" backported. Its possible Azure is in a similar place.
Most obvious indicator is DocumentDB is single node write whereas Mongo is really not, coming from Aurora Postgres.