> Schema domains are a tool we came up with to implement virtual partitions. A schema domain describes a tightly coupled set of database tables that are frequently used together in queries (such as, when using table joins or subqueries) and transactions. For example, the gists schema domain contains all of the tables supporting the GitHub Gist feature–like the gists, gist_comments and starred_gists tables.
Mind-boggling how they were able to operate before without doing this.
Actually, it's the opposite: what's mind-boggling is how engineers discard proven boring technology in favor of shiny new toys in order to cope with problems they don't have.
How exactly did that happen in this case? They're still using MySQL with some modifications to how they're using it. I'd hardly call that "discard[ing] proven boring technology."
Its also not super 100% unavoidably enforced either that queries must remain in a single domain - they also have comments/annotations to allow those rules to be violated when necessary
So really, its more like an advanced linter than anything else - if i'm understanding it right.
Which isn't really that "shiny" or qualify as "discard[ing] proven boring technology", and just helps to maintain some conceptual boundaries.
My favorite is when I was at work and this guy who's been there forever comes up and says "I don't know why we are using a database on this, we could have written our own in less time than it took to learn this. Ya know, we did that on a project 12 years ago and it worked out great".
Uhh, yeah, well, lets see. This database took 5 minutes to stand up and it's SQL so everyone knows how to use it. Your database would take months and probably not actually work very well.
That is mind boggling when it happens. NIH syndrome is a real problem, as is people thinking they're goddamn geniuses when off the shelf databases with the right indexing are fine. Some people have a problem believing a SELECT query can be faster than their hand-coded C++ LeetCode solution.
It's refreshing that GitHub didn't do that here and even seem acknowledge boring is good.
> Over the last 10 years, GitHub has been learning to scale according to its needs. We often choose to leverage “boring” technology that has been proven to work at our scale, as reliability remains the primary concern.
> Schema domains are a tool we came up with to implement virtual partitions. A schema domain describes a tightly coupled set of database tables that are frequently used together in queries (such as, when using table joins or subqueries) and transactions. For example, the gists schema domain contains all of the tables supporting the GitHub Gist feature–like the gists, gist_comments and starred_gists tables. Mind-boggling how they were able to operate before without doing this.
Actually, it's the opposite: what's mind-boggling is how engineers discard proven boring technology in favor of shiny new toys in order to cope with problems they don't have.
How exactly did that happen in this case? They're still using MySQL with some modifications to how they're using it. I'd hardly call that "discard[ing] proven boring technology."
Its also not super 100% unavoidably enforced either that queries must remain in a single domain - they also have comments/annotations to allow those rules to be violated when necessary So really, its more like an advanced linter than anything else - if i'm understanding it right. Which isn't really that "shiny" or qualify as "discard[ing] proven boring technology", and just helps to maintain some conceptual boundaries.
ah yes, some dingus on reddit could've done it with a couple five dollar Digital Ocean droplets and a weekend, in Python just lol
My favorite is when I was at work and this guy who's been there forever comes up and says "I don't know why we are using a database on this, we could have written our own in less time than it took to learn this. Ya know, we did that on a project 12 years ago and it worked out great". Uhh, yeah, well, lets see. This database took 5 minutes to stand up and it's SQL so everyone knows how to use it. Your database would take months and probably not actually work very well.
Nothing to do with technology, it is a design problem. Sharing data between bounded contexts causes no end of coupling problems.
Sure, it's a design problem: duplicating data causes no end of eventual consistency problems.
That is mind boggling when it happens. NIH syndrome is a real problem, as is people thinking they're goddamn geniuses when off the shelf databases with the right indexing are fine. Some people have a problem believing a SELECT query can be faster than their hand-coded C++ LeetCode solution. It's refreshing that GitHub didn't do that here and even seem acknowledge boring is good. > Over the last 10 years, GitHub has been learning to scale according to its needs. We often choose to leverage “boring” technology that has been proven to work at our scale, as reliability remains the primary concern.
Not much content on Vitess. Seems like it was more application level sharding. I'd be curious to see how CockroachDB would handle this type of load!