On 08/04/2012 01:50 PM, Rich Braun wrote:
Mark Woodward <[email protected]> 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.
OK, yea, we got caught up the No-SQL vs SQL argument.
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.
I have to say something that I don't like saying because I sound like a
jerk. Sometimes, if you need to ask a certain type of question, then
answer can't do you any good.
Seriously, in the MySQL vs PostgreSQL debate, if you know about database
theory and have some serious experience with databases other than MySQL,
you would say there is no debate, PostgreSQL is the obvious choice. If
you don't have the background or experience, then, things like MVCC,
ACID, and transactions don't mean anything to you. Worse yet, chances
are you'll see them as a problem because in a single stand-alone query,
they do add additional processing.
Compare it to the "squared circle" debate in math. If you don't
understand PI, you won't accept it.
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.
Well, it is almost assuredly impossible to start at position 0 and get
it right the first try. There is "institutional learning" involved. This
is where the development team is learning about what they are creating
as a business. This is typically the start up phase of a company or a
new product. By the time you get system up and running, the design has
almost certainly churned over several phases.
Site 2.0 is typically sold internally as the "rebuild to end all
rebuilds." It never is. It is defined as the fix to all the mistakes
that were made for all those many reasons during 1.0.
I wish I could give you some real ammunition, but it isn't about
bullets, it is about really knowing the subject matter. Anyone wanting
to defend their position will have bullets too. You need to know WHY
your bullets are better, and more importantly, you need to know why
their bullets are wrong.
I could rattle off a number of pros and cons for PostgreSQL, but it
would not help. Real knowledge is the only way to win this debate, if,
of course, it can be win. Some people's minds can not be changed no
matter what proof is given. I have had to make this argument before, and
failed because a director or CTO is "confident" that MySQL can do it
regardless of proof to the contrary. The result, the project either
fails or needs a lot of extra work. Its painful, but it happens all the
time in industry.
The only advice I can give you is this: learn why PostgreSQL is
absolutely better than MySQL, merely quoting someone else's opinion
won't help you. The subject of databases has some REAL computer science
and if you love the science, you'll love good databases because they
have it all. It may not help you in this particular situation, but it
will certainly make you better at what ever job you do.
_______________________________________________
Discuss mailing list
[email protected]
http://lists.blu.org/mailman/listinfo/discuss
