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 |
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 | |
We also thank MIT for the use of their facilities. |