independent benchmark sql results

nahdoic

Are there any on independent benchmark sql results out there?

I'd be interested in finding out the real strengths and weaknesses of the different SQLs out there - espcially mySQL, PostgreSQL and Oracle. Trying to decide which one would best suit the needs of the project.

There's going to be a lot of very basic inserts, like a date, an integer and and a char. And it's just going to need to count the entries, and add the integers up - very simple.

Nothing at all complex that will need triggers, sub-selects, or roll-backs. Just want something that is lightning fast to do an awful lot of very, very basic operations.

From the different, (very biased) views out there on the web, from what I can gather. On a server that isn't going to have a lot of ram, and performing very basic SQL operations mySQL would be the fastest. Would this be correct?

Or is there something else I should be considering?

bonkey

Originally posted by nahdoic
Just want something that is lightning fast to do an awful lot of very, very basic operations.

OK...define "an awful lot" here? Are we talking of hundreds of ops per second, or what?

On a server that isn't going to have a lot of ram, and performing very basic SQL operations mySQL would be the fastest. Would this be correct?

What you consider "a lot of RAM". I wouldnt run a desktop with less than 512MB of RAM, nor a server with less than 1GB. To me, "a lot of RAM" would be far in excess of this.

Also, for me, an awful lot of operations is > 500/second, maintainable indefinitely.

When you get to these scales, I would be considering scalability issues as well as performance. How will your database handle having a table with millions of rows? Tens of millions? What about failover? Uptime? Backups/restores? Disk performance? Disk Space?

Absolute performance is only part of the story. You need to question stability, scalability, etc. You need to quantify your data-storage and throughput requirements. Backup and Restore are issues, as is acceptable downtime. If they're not, then the question of throughput is moot, because otherwise youre saying "the system must be fast when its available, but we dont care how available it is".

You wont find benchmarks to tell you the right answer until you ask more detailed questions.

I'm not trying to knock you here, but there really is no honest answer to your question, and you wont find one on the net. Try specifying your requirements exactly, then you can find a product which is the best fit. Alternately, try specifying them here, and see if ppl can offer pros/cons of various systems.

jc

nahdoic

cheers for replying bonkey.

OK...define "an awful lot" here? Are we talking of hundreds of ops per second, or what?

Like what you said, an awful lot would be in excess of 1GB of ram. My budget would be able to stretch to about a 1GB of ram.

Also, for me, an awful lot of operations is > 500/second, maintainable indefinitely.

Not quite 500 a second. Peak times, 50/second. Non-peak times maybe 10/second.

When you get to these scales, I would be considering scalability issues as well as performance. How will your database handle having a table with millions of rows? Tens of millions? What about failover? Uptime? Backups/restores? Disk performance? Disk Space?

That's what I'm really worried about. I couldn't find any independent benchmarks on how each DBMS handles tables with tens of millions of rows.

My budget is not going to stretch to have a failover solution. It sure would be nice to have a 2nd server as backup when the first one fails. But I just couldn't afford it.

Daily backups would be adequate. A loss of one day's data would be undesirable but it wouldn't be catastrophic. It's not a banking system.

Disk performance. What should I be considering here?

Disk space isn't a problem. The entire database wouldn't even come close to a gig.

I guess the best way to find out, is to set up a basic system, and then make some scripts to test it, and see how far it can go before it breaks, and see why and how it breaks and when it starts to slow down. And decide what I'll use from that.

"the system must be fast when its available, but we dont care how available it is".

It would have to be as close to 100% uptime as possible.

You wont find benchmarks to tell you the right answer until you ask more detailed questions.

I couldn't actually find any independent benchmarks, though. They were all biased.

I'm not trying to knock you here, but there really is no honest answer to your question, and you wont find one on the net. Try specifying your requirements exactly, then you can find a product which is the best fit. Alternately, try specifying them here, and see if ppl can offer pros/cons of various systems.

Don't worry, I take constructive criticism very well. Cheers for your help.

dahamsta

We've had a MySQL V Postgres debate before. Well, a flamewar, but amp seemed to enjoy it, so...

http://boards.ie/vbulletin/showthread.php?threadid=36781

To cut it down to basics though: MySQL has always been optimised for speed first, and features second. Postgres is the other way around. Oracle is an enterprise level RDBMS, and very resource intensive. Given your requirements, I think you should try MySQL first and see how you find it, but the only real answer is: benchmark baby.

adam

nahdoic

Originally posted by dahamsta
but the only real answer is: benchmark baby

heh. That's what I was thinking. I'm just going to have benchmark the 3 of them, to see who performs the best.

Oh joy.

Talliesin

Some things can't be measured as easily as others. A real ACIDic SQL database will have much more reliability and fault-tolerance than MySQL, but MySQL is faster precisely because of it's optomistic (some would say foolhardy) behaviour. That isn't something you can easily measure, but it is something that completely disqualifies MySQL from a lot of projects (you must decide if the risk of half-completed transactions is worth the efficiency).