Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Rob Conery's critique of MySQL?



On Sat, 2012-08-04 at 10:50 -0700, Rich Braun wrote:
> Mark Woodward <markw at mohawksoft.com> observed:
> > My favorite example is facebook. Yes, they are a big data show case.
> > OMFG they have a lot of data and a lot of computational requirements.
> > They did not start out dreaming of big data. It started small and grew.
> > I believe that this inadvertent strategy helped them greatly. By
> > focusing on the site and what it did and *not* how to make it scale
> > until scalability was needed they were able to be attractive to more
> > users more quickly.
> >
> > Opinions?
> 
> Being the one who kicked off this thread, my original goal was to get specific
> technical arguments (plus a couple of business arguments like the ratio of
> MySQL-experienced DBAs to PostgreSQL DBAs available on the job market) to
> present to decision-makers who control what technology to use on new projects.
> 
> So far at work I've got MyWay or the HiWay from the bosses: thou shalt use
> MySQL.  Period.  Suits me OK because I already know its quirks well, but it
> looks to me like more than ever the alternative of PostgreSQL (and no other
> FOSS product) is viable for small and large companies alike.
> 
> But the thrashing of this discussion thread has given me nothing to send off
> to the senior tech architects at my office.  Not one of the postings here has
> been phrased in a way that would grab such a person by the throat and persuade
> them to read further.
> 
> Your argument above, Mark, is what I hear all the time both here and at my
> last employer:  "We're Agile, so we can start off doing things wrong and fix
> them later."  About $15 million and 20 months into a $6 million/9-month
> project (hah), at my last job we recognized that what the software team had
> built was a bug-ridden replacement of the previous unsupportable bug-ridden
> software, and most of the new software's developers quit--leaving the
> replacement equally unsupportable.  But hey, the new one had lots of fancy
> stored-procs and took advantage of all of MySQL 5.1's nifty features.
> 
> So if it were /my/ $15 million, I'm not so sure I'd take the position that I
> should focus mainly on the software features.  But of course, I'm an infra guy
> so I'm biased:  the infra goes in (2 of everying, HA from the get-go) before
> the first feature gets crafted.  It's cheap enough to do these days, though it
> hasn't gotten much easier.  If PostgreSQL makes it easier to set up HA, and
> recover from failures, than MySQL--I'd love to make that case.  But going back
> to the Facebook startup argument--let's build this cool web page and see if
> people like it--then the HA argument doesn't even get considered.
> 
> Another example is firewall security:  if you've got this cool new web site
> running, and later decide to add firewalls:  it'll be a lot more effort, and
> probably more outage-prone, trying to figure out on the fly which TCP ports
> and IP addresses should be opened up, and how to pull apart portions of the
> app to run on back-end servers with layered security.
> 
> So, that's why I like to include robustness as part of Iteration Zero in the
> agile framework.
> 
> -rich

First - IANADBA.

The only time I had to make the call between PostgreSQL and MySQL was in
1998.  We had spoken to Oracle sales and it was clear that they wanted
to hold us by the ankles and shake and let us keep what didn't hit the
floor.  We were an unfunded start-up, there was nothing in our pockets
to begin with.

Back to MySQL vs PostgreSQL,,,  it was a no-brainer.  Most of it was on
issues of TRANSACTION support and behavior with respect to the SQL
standard or things like NULL enforcement (see Conery's post - it's been
a problem for 15 years).  Um, VIEWs...  when did MySQL get CREATE VIEW?
Version 5?   PostgreSQL also had cool stuff like advanced data types and
table inheritance.  Version 6.x even had all this GIS stuff that's since
been discarded.  Worked well for our application.  We crashed.  I went
off to do other things...


I've spent the most recent 7 years in a PostgreSQL shop.  We've sharded
our database so that we can support metadata management for 400 million
objects per node over 40 nodes.  We have the metadata for every object
on at least two nodes but no one node has the metadata for everything,
giving us mondo multi-petabyte scale.  If we lose a node we're able to
quickly make sure the required number of copies are available.  The more
nodes you have, the more copies of the database, the more resilient we
are.


I see the distinction this way: data management and business logic
belong on different planes.  For many applications, this is best
accomplished using an object database or minimally an RDBMS behind an
ORM (I like Django)... for other applications this is best accomplished
by an object layer that is relation-friendly since the data flow of the
business logic is well modeled by tabular state.  In each case you are
using a database abstraction because you want the database layer to
provide you with certain assurances.  

The whole thing about SQL is that you should be able to declare the
invariants of your data and forget about it.  You try to insert bad data
you handle an exception from the data layer.

Perhaps you don't need the assurances that MySQL is unable to provide -
or at least your application does not need them *today*.  Good for you,
knock yourself out.  Maybe you do need them and you're OK being the
400,000th application stack that's had to have special code to provide
it...  yay! job security.  I'm personally risk-averse in this area.  To
me it's like keeping your backups on site.

If I'm using a "SQL" platform, I want it to do SQL.  Apparently for
MySQL this has been too much to ask.


Now for the kicker.  This whole discussion suffers from the "Blub
Paradox" http://www.paulgraham.com/avg.html  A MySQL user who has never
done a major project in PostgreSQL will never know what they don't know.


ccb







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org