|
|
|
| Authored by: kjs on Monday, April 16 2012 @ 02:30 PM EDT |
that's the pity! PostgreSQL would deserve the glory but MySQL just had the
better marketing hype.
P-SQL just gets better and better and used a lot but MySQL made it into a lot of
start-up bubbles people talk about.
>kjs
---
not f'd, you won't find me on farcebook[ Reply to This | Parent | # ]
|
| |
| Authored by: cybervegan on Monday, April 16 2012 @ 03:35 PM EDT |
No-one can really tell exactly why MySQL won over PosrgreSQL - it probably
wasn't just one thing. I'm not sure it was "hype" so much as being in
the right place at the right time, so to speak.[
This isn't meant to be a fan-boy troll about MySQL, nor a highly technical
discussion on the pro's and con's of each platform. I don't personally think
that MySQL *is* the best of the bunch, although it historically shone in areas
that PostgreSQL didn't - a lot of that has changed now, with both getting better
in areas where the other excelled. I'm currently working with Sqlite3, and
looking more into NoSQL databases such as Couchbase and Hyperdex.
A number of factors at the time I started learning MySQL included, so from my
perspective it came down to. I'm probably wrong about some of the following,
too:
1. Light-weight and fast - because of it's threading architecture, which means
that new client connections are note computationally costly, and it's
"dumb" no-frills database engine, which is particularly efficient on
I/O, meanikng it worked OK on cheap IDE disks without a RAID controller and
cache memory. PostgreSQl's ACID compliance, referential integrity and highly
granular security model all take their toll in terms of resources and CPU
utilisation.
2. Easy to maintain due to it's simplified (and thus feature-light)
"pseudo-sql" command structure and it's easy-to-use task-based
documentation. PostgreSQl's documentation was always far more thorough and
detailed, but it lacked the easy accessibility of the MySQL.
3. Easy, efficient, uncomplicated backup and restore. Having used Oracle's RMAN
backup a bit at a former employer, I can testify to the big descision of which
way to do it being a really confusing issue. MySQLdump only did backups one way,
and it was relatively fast and you ended up with a backup file you could
manipulate with awk/sed/vi. I've not had much experience with pgdump (or
whatever it's called) but the first time I looked at it, I thought "that's
a lot like RMAN". I believe it does do SQL dumps, but may not have done
back in the 2002-2003 period when I first looked at it.
4. Master-slave replication for scaling out relatively easily, and later NDB
clustering to allow scaling up, with some semblance of convergence. PostgreSQL
had "slony", which was not even loved by PG fan-boys; I have run
several medium sized MySQL replication systems, and barring the usual breakages
due to resource or connectivity problems, it's always performed really well, and
the slaves have always been pretty much in sync (within a few seconds).
5. Being the default database server in several major Linux distro's - Red Hat
and Debian, for instance, undoubtedly gave it a big leg-up. This probably has
more to do with politics than technical merit.
To further invalidte my opinion, I'll admit, I'm not a hard-core DBA. :-)
-cybervegan
---
Software source code is a bit like underwear - you only want to show it off in
public if it's clean and tidy. Refusal could be due to embarrassment or shame...[ Reply to This | Parent | # ]
|
|
|
|
|
