On 26/07/16 19:39, Guyren Howe wrote:
Honestly, I've never heard of anyone doing that. But it sounds like they had
good reasons.
https://eng.uber.com/mysql-migration/
Thoughts?
1. Open the page
2. Press Cmd-F on Mac, Ctrl-F on Linux/Windows. (Find on page)
3. Type "transaction" in the search field, without the quotes
4. Scroll through the article and look for the highlights
There are 17 highlights. I count 2 in the MySQL part. Chances are good
that the rest 15 are in the PostgreSQL part.
It tells a lot.
When I am told that MySQL supports transactions I face the fact that the
word "transaction" must have at least two meanings and no matter what I
do I know only one of them.
Every time I had to work with MySQL I felt overwhelming sloppiness. I
can’t (or don’t want to) deal with accepting 0 as NULL but only once,
auto typecasting pianos to cats (take it as a metaphor), committing a
"transaction" (in MySQL terms), without sending commit, on client
disconnect. (Older version).
One can say it can’t be that bad as Facebook and now Uber are using it.
The same logic tells that junk food is the best for humans.
In the last few years I tried out more or less every hyped schemaless
databases. Not for their main feature as my data like like the rest of
the data in the Universe can be put in a schema. I did it because faced
some of the issues mentioned in the article and other issues that aren’t
mentioned, even on smaller scale, that’s why. (Smaller scale means
smaller company, less resources, less people. At the end it hurts the
same way.)
I still don’t see how I could live without transactions, and not only
because a simple and intentional rollback saved me from much coding and
complexity with one the most important features of my application. But
having a single update statement modified about the 70% of the records
before Cassandra crashed is not for me. It tried to repair about 1000
records, using 3 nodes, for 1 or 2 hours before I deleted the test cluster.
Maybe I did it wrong. Or probably. It can’t be that bad. People at Uber
probably know more about the internals than I ever will. I also know
that a few big companies had about 1 day long downtimes thanx to MongoDB
and CouchDB.
Since I know that people who are way more professional than me decide to
use a database engine in production that doesn’t tell you whether it
could store your data or not, I don’t care who is doing what and what is
on his business card.
And yes, I hate upgrading PostgreSQL especially on FreeBSD where
pg_upgrade isn’t really an option.
Sometimes the answer is manual or full vacuum, no matter what the manual
says. (And yes, the downtime does hurt.)
On the other hand, if there was a stable and officially integrated
logical replication that supports multi-master setups, many of the
issues would just be gone. Upgrades wouldn’t be painful anymore,
timeline and pg_rewind bugs wouldn’t matter, and the DBA could remove
the bloat form the masters one by one by doing that thing in the night
when no one sees it. (Until the full-vacuum-police would find him and come.)
M.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
