91–100 of 135 posts
Speak for yourself. I love my schemas.
This article is also 100% fluff, and zero actual information. Obviously I won’t sign up to anything without an ounce of information being provided up front.
Can someone please explain how Vitess works, in plain English? How does it magically make MySQL scale? And then what does PlanetScale add on top of Vitess hosted anywhere else? Sorry, the linked blog post is both very abstract and assumes a high level of preexisting knowledge about database scaling.
Vitess is an additional layer on top of MySQL which all queries pass though. Among other things, it implements its own query parser which can then do stuff like split a query across shards and join results etc. I wouldn't say there's too much "magic" in there, but it does a lot of known difficult things (schema management, sharding/resharding, connection pooling, query optimization, DB administration, monitoring, bac…
Earlier quoted context omitted.
IME the answer to "how did they make [hard to scale thing] easily scalable?" is usually that they introduce limitations in how you can use [hard to scale thing] so you can't use it in ways that are hard to scale, then automate scaling it in well-known ways for use cases that are so-limited. Vitesse's site mentions that it relies on horizontal sharding, so right off the bat, my guess is that you can't use it in ways t…
The "ease" we used to refer to in Vitess primarily relates to its interaction with the application side, where it basically presents itself as "one big MySQL datastore". It uses a standard MySQL connector, and in general, once you have the infrastructure up and running with a compatible schema design, there's not too much to worry about from a coding standpoint. Sharding happens transparently to the application code,…
Isn’t that the same for a normal sharded MySQL database though?
Amy I the only person reading this who doesn’t think that the marketing line in the middle about not managing a schema is super scary? > Developers want the durability, stability, and scalability of a SQL database but do not want to be constrained by managing a schema. It has been our goal to give both, not compromising on the power of your datastore but making changes feel as easy as deploying code. Sorry. There’s a…
> Developers want the durability, stability, and scalability of a SQL database but do not want to be constrained by managing a schema Speak for yourself. I love my schemas. This article is also 100% fluff, and zero actual information. Obviously I won’t sign up to anything without an ounce of information being provided up front.
Before GitHub launched, I built some large eCommerce sites, and for a vcs we used CVS, and then Subversion. We had a person on our team with the title of release manager, because branching in Subversion, and merging back to make releases, was a specialist effort that took time, patience, and managing a tremendous amount of fighting between teams of what features and fixes could even be merged together in order to shi…
Earlier quoted context omitted.
The "ease" we used to refer to in Vitess primarily relates to its interaction with the application side, where it basically presents itself as "one big MySQL datastore". It uses a standard MySQL connector, and in general, once you have the infrastructure up and running with a compatible schema design, there's not too much to worry about from a coding standpoint. Sharding happens transparently to the application code,…
> once you have the infrastructure up and running with a compatible schema design, there's not too much to worry about from a coding standpoint Isn’t that the same for a normal sharded MySQL database though?
EDIT: To clarify, sharding is not a standard feature included in Community Edition MySQL. Over the years, there have been various Oracle-initiated attempts at providing it as an enterprise scaling strategy through MySQL (NDB) Cluster, MySQL Fabric, etc., but these have either ended up having limited applicability outside very specific use cases and are not widely in use.
Most large MySQL users (e.g. Facebook or YouTube) ended up rolling their own frameworks, like Vitess, which has since been open sourced and adapted to more diverse environments. Until that became more accessible, though, the rest of the world mostly made do with wobbly multi-master setups relying on circular replication, behind some kind of proxy, or had to implement the sharding logic itself into their application code.
> Developers want the durability, stability, and scalability of a SQL database but do not want to be constrained by managing a schema Speak for yourself. I love my schemas. This article is also 100% fluff, and zero actual information. Obviously I won’t sign up to anything without an ounce of information being provided up front.
Indeed, you either manage a schema or get managed by it.
Earlier quoted context omitted.
To be clear, this is not a Vitess/PlanetScale-specific opinion or choice. Foreign key constraints are a bit of a controversial topic in large-scale MySQL environments in general, which is the greater context in which this design decision was made by the Vitess team. PlanetScale's (and Vitess') non-blocking schema changes rely on open source tools for MySQL like pt-online-schema-change and gh-ost, which are widely use…
Do you know if foreign keys tend to be a problem on postgresql as well?
Earlier quoted context omitted.
Indeed, you either manage a schema or get managed by it.
This is MySQL. There is a schema. We just make it super easy to manage.