91–100 of 148 posts
Earlier quoted context omitted.
The problem is not mvcc but postgres’ implementation details of it.
In what way? I didn't see anything obviously improper when I learned how serialization isolation worked.
Earlier quoted context omitted.
> A non-trivial component to MySQL popularity was that easy installation ...Along with replication and being joined with the hip to PHP. As to installation, there was a point in time in the early 2000s where you could sudo to root, type 'mysql' and be talking to a live MySQL on most Linux distros that I used. No wonder a lot of people defaulted to it.
Replication came later - but the fact that you could do sudo apt-get install mysql-server mysql-client sudo -i mysql and be logged in as admin into mysql database was indeed a huge reason for defaulting to it. EDIT: Of course, at that time, there was no Ubuntu teaching everyone to sudo all the time, so drop all instances of sudo and add a su - at start ;)
Earlier quoted context omitted.
i mean, sort of? There is some subtly lost in this oft-repeated advice. i've worked at 3 companies now that were initially based on a single RDBMS but have outgrown the scale of what is reasonable to serve off that architecture. They are consumer scale (10s of mill) users, but not hyperscale (IMHO 100m+). The amount of engineering cost to migrate a complicated growing company/product off a mono-db architecture is ast…
Of course subtlety matters, but as you start scaling and noticing pain points, that is when you start working towards fixing them. First you just throw hardware at the problem and that tends to scale really really well for a really long time. It's pretty rare, even at very large scale that you MUST move off of PG, there are plenty of well tested scaling solutions, if you have the $$$'s to spend. 10+ years of dev work…
Nevermind the other aspect the pat advice doesn’t mention - managing a massive single RDMS is a goddamn nightmare. At a very large scale they are fragile, temperamental beasts. Backups, restores, upgrades all become hard. Migrations become a dark art , often taking down the db despite your best understanding. Errant queries stalling the whole server, tiny subtleties in index semantics doing the same. Yes it’s all solvable with a lot of skill, but it ain’t a free lunch that’s for sure. And tends to become a HUGE drag on innovation, as any change to the db becomes risky.
To your other point yes, replicating data “like for like” into another RDBMS can be cheap. But in my experience this domain data extraction is often taken as an opportunity to move it onto a non RDBMS data store that gives you specific advantages that match that domain, so you don’t have scaling problems again. That takes significantly longer. But yes I am perhaps unfairly including all the domain separation and “datastore flavor change” work in those numbers
I must admit as a web practitioner since 1994 I have a bit of an issue with this: > In the 2000s, the conventional wisdom selected MySQL because rising tech stars like Google and Facebook were using it. Then in the 2010s, it was MongoDB because non-durable writes made it “webscale“. In the last five years, PostgreSQL has become the Internet’s darling DBMS. And for good reasons! Different DB's, different strengths and…
did google even use mysql? certainly if they did they never talked about it publicly in the early 02000s, and of course facebook didn't even exist then
lj, though, they used the fuck out of mysql
/. originally didn't use a database; i (an ordinary user) accidentally posted an article by trying to post a comment on an article that didn't exist yet; i guess they got appended to the same file. but when it did switch to a database (i don't know, about the time google was founded?) it was of course mysql
Can the MVCC implementation be swapped via Postgres extensions?
No. It would be a major surgery on the internals. See the article for my comment at the attempt to do this with the Zheap project: https://wiki.postgresql.org/wiki/Zheap
As an aside, Andy Pavlo (one the authors here) has his CMU database course videos up on YouTube and they are tremendous. I’ve spent 2 decades developing web applications but am not exaggerating when I say that I’m 10x more knowledgable on databases having watched his courses during Covid.
Earlier quoted context omitted.
> A non-trivial component to MySQL popularity was that easy installation ...Along with replication and being joined with the hip to PHP. As to installation, there was a point in time in the early 2000s where you could sudo to root, type 'mysql' and be talking to a live MySQL on most Linux distros that I used. No wonder a lot of people defaulted to it.
Replication came later - but the fact that you could do sudo apt-get install mysql-server mysql-client sudo -i mysql and be logged in as admin into mysql database was indeed a huge reason for defaulting to it. EDIT: Of course, at that time, there was no Ubuntu teaching everyone to sudo all the time, so drop all instances of sudo and add a su - at start ;)
Maybe that's why I am used to logging in as root rather than a user. I started in 1999 and have been surprised how few users now do
Earlier quoted context omitted.
In what way? I didn't see anything obviously improper when I learned how serialization isolation worked.
TFA covers its issues? It’s specifically compares postgres’ to other implementations’ (oracle and mysql).
As an aside, Andy Pavlo (one the authors here) has his CMU database course videos up on YouTube and they are tremendous. I’ve spent 2 decades developing web applications but am not exaggerating when I say that I’m 10x more knowledgable on databases having watched his courses during Covid.
Could you share the links?