Slashdot Mirror
NZX Moves To Oracle On Linux
sn00ker writes "In this story in The New Zealand Herald, we learn that the NZX stock exchange has moved their database systems to Oracle running on RedHat Linux, running on commodity Intel-based hardware. What's really impressive are the performance numbers they're claiming. Quoth the article, "One key query - searching the data on historical trades to identify maximum trade values - has been cut from 36 seconds to 0.03 seconds." An improvement of over 1000 times is spectacular in anybody's books, and is one hell of a boost for the proponents of Linux at the back-end of the financial world."
Oh come on! They consolidated 21 databases and moved to Oracle. That's why it is 1000 times faster. The move to Linux is a footnote as far as the performance issue is concerned -- as stated in the article, the move to Linux was for cost. I'm sure Solaris or god help me, Windows Server 2003 would have given similar performance results. Now if they had moved to MySQL...
Dr. Rick
- "It's such a fine line between clever and stupid" (Nigel Tufnel)
- Zort! (Pinky)
Obviously a much-needed index was added during the migration...
A 1000 fold improvement in performance, just by moving to linux. Incredible. Unbelievable even.
Comon guys. What kind of idiots do you take us for?
I'm no windows sympathizer, but in the world of enterprise software, only optimizations at the database layer (or reworking badly written networking layer) can yield those kind of results.
Sounds like they data warehoused and redesigned the schema/indexes to better match usage.
"We went for Linux, not just because we hated Microsoft, but because the cost was compelling," Phillips said.
(Insert funny remark here because I'm unfunny)
Financial organizations are very conservative but even Deutsche Bank are migrating to Linux some of their less important processes.
In all the cases the future of the financial industry is in cheap linux clusters.
I'm inclined to think that having a request suddenly run 1000 times faster might be due to something a DBA has done, rather than a change of OS.
Yeah. My call would be that they were operating an RAM-starved server. I've seen similar numbers doing basic PC upgrades!
I remember on case (this was a few years ago) where somebody with a customer information database of about 400,000 records came to me because generating a list from a query would often take several minutes.
They were using a Pentium-90 with 32 MB of RAM. I set them up with a (then) top-of-the-line PIII 600 with 256 MB RAM. Query time dropped to 1 second.
No matter what O/S you run, you're going to get JACK for performance if your running your app in swap.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
According to the artcle, they built a cluster using Oracle Real Application Cluster, (I guess Beowulf is just for toy apps :P) which allowed them to spread the core DB over multiple machines (!).
autopr0n is like, down and stuff.
The improvement is impressive - but I would credit the overall architecture, rather than some single specific factors - like Oracle10g+Redhat or DBA or systems consolidation.
I mean, every part of the architecture has its role.
Some other contributing factors not mentioned, I suspect, would includes - focused performance requirements, specific purpose optimised query framework.
Can someone point to some public material on the architecture? It would be a interesting read.
Sunset over the lake, cool mist over the bridge; A leave upon the ripples, the snow reflects its glow.
I doubt they're your garden variety "OMG BillG iz teh debil" Loonix fanbois, friend.
They are a serious enterprise, and there must be a reason something as provocative as " not just because we hated Microsoft" would come out in an interview.
IOW - It's likley that Microsoft's products and/or policies have left a very, very bad impression with these people, and they're glad that they have a compeditor with which to smack Microsoft in the head with.
Soko
"Depression is merely anger without enthusiasm." - Anonymous
C'mon, it ain't nice to call NZ that!
Unless specifics about the query and the physical database model are comparable in both systems this isn't really impressive.
Comparable - not equal - since each database engines optimizer has it's individual quirks and strength.
Assuming that you have large joins on huge tables a couple of good indexes, which make the optimizer happy can reduce execution time from hours to seconds.
Table scans are expensive in database speak.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
I have achieved increases of 10^4 and 10^6 in production systems by recoding a small critical part of an application (usually less than a page of code).
Most of the time the problem is stupid code or operational ignorance. Rarely is hardware, O/S or data base software changes the sole or main solution in performance problems. Hardware is only a factor when the system is underspecified to save money.
Given that they consolidated 21 databases into a single database the problem could simply have been network latency between separate physical servers.
The simplest way to get performance problems is to test on developers personal machines with tiny test databases and implement without full scale testing.
For those of you who wish to ensure that Microsoft SQL server is slow, invoke a user defined function as part of the where clause that the optimizer cannot recognize as a determinate function when joining two tables. This will ensure a nested loop join that will take an eternity.
When I was young, I had to rub sticks together to compute.
I've discovered that Oracle is pretty much OS agnostic because it pretty much takes over the system it is installed on. That aside, when a server is pure anything, the OS really isn't relivant. When all it does is run one app, the performance is pretty much tied to that app. All modren OSes provide good disk, memory, network, etc services. Now you can argue specifics till you are blue in the face, but when running one app, it doesn't much matter.
Where an OS can shine is if you are running lots of stuff (eg webserver, scripts, database server, media server all on one box) and espically when you are screwing around and hence likely to cause problems. However when you do a DB install and run nothing but that, the OS is just a helper. It talks to the hardware and provides some simple APIs. Which OS it is isn't of much consequence to performance.
The cost thing makes me curious too. We tried Solaris on Linux. The DBA couldn't get it to work, and neither could I. Then I looked at the requirements. We are trying SUSE, since that was listed... Well, sorta. It didn't run on normal SUSE, just SUSE Enterprise Server. Likewise not RedHat, but RHEL, and also UnitedLinux. In otherwords, high dollar server Linuxes. Oracle tech support wouldn't even talk to us unless we used a supported OS. We ended up option for Windows XP Pro, since it was supported. As I said, OS didn't much matter, just that it ran Oracle.
Now while I'm sure (or at least pretty sure) Oracle could be made to run on a non-enterprise Linux, what would be the point? They wouldn't support you and support is one of the big reasons to buy Oracle (not cheap in case you were wondering).