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 | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

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

Re: MySQL -- was mysql backup quesiton

 dear mark, 

it's interesting, because I have the opposite story. I was forced to switch 
back to mysql after pgsql crashed when it hit millions of records. well, 
probably I did not tune it right ;) 

then again, they're just another tools.. 


On Jan 5, 2008 1:02 PM, <[hidden email]> wrote: 

> > On Jan 5, 2008 10:00 AM, Fred at 
> > <[hidden email]> wrote: 
> >> I strongly recommended knowing well all the mysqldump options. Very 
> >> powerful tool in the right hands. 
> >> 
> >> -Fred 
> > 
> > I suspect that is why so many people do not like MySQL.  They don't 
> > know how to use it properly.  If people would take the time to learn 
> > MySQL they would see it's very powerful and can do anything they need 
> > when used properly and tuned. 
> > 
> > -- 
> > -matt 
> While I know that this is sort of off topic with regard to backup, but I 
> think on topic with regards to why people do not like MySQL. 
> I find that people who really like MySQL tend not to know much about 
> databases, I know that this is a generalization that sounds like flame 
> bait, but it is my observation, feel free to disagree. 
> The problems with MySQL primarily stem from the fact that it is not a well 
> designed database and only marginally supports full SQL. 
> My latest fiasco with MySQL was about a year ago. I was working as a 
> consultant for a LARGE internet company you may have yodeled too. I wrote 
> a huge infrastructure analysis tool that could pin-point divisions or 
> groups for upgrade or resource reduction to reduce costs. This company had 
> close to 100,000 computers at the time. It would actively collect 
> cpu/IO/memory history of *all* the machines on 5 minute samples. It would 
> keep a weeks worth of data at that scale, and reduce over time. 
> At the start of the project, I said I needed something like PostgreSQL or 
> Oracle. They said that Oracle was a possibility, but that I could use 
> PostgreSQL for development until they get production set up. 
> After months of working on PostgreSQL, and nearing the time of production, 
> managers changed and decisions were re-evaluated. They didn't want to 
> support Linux -- they are primarily a FreeBSD shop, so Oracle was out. 
> They did not have any internal support for PostgreSQL, so PostgreSQL was 
> out. So I had to use MySQL. 
> MySQL was a DISASTER, creating and dropping indexes would nuke the machine 
> for hours. PostgreSQL would work perfectly while creating new indexes or 
> dropping old ones. MySQL could not keep up with all the parallel data 
> collection processes running. While the collection processes were running, 
> the OLAP queries barely did. A query on PostgreSQL that took a few 
> seconds, took 20 minutes on MySQL. 
> And, no, don't say that standard: "You just didn't tune it right," or what 
> ever. This company has some *real* MySQL experts, and I worked with them 
> extensively. Oracle, DB2, PostgreSQL, even MSSQL would not have any of the 
> problems that MySQL had. 
> If you have an opportunity, study SQL and some good database theory. Then 
> take a look at Oracle, DB2, or PostgreSQL. (PostgreSQL is free too!). 
> You'll see that many of the things that make these systems seem bigger or 
> more complicated, actually make them much easier to use. 
> OK, that's my $0.02 
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner, and is 
> believed to be clean. 
> _______________________________________________ 
> Discuss mailing list 
> [hidden email] 

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 /