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."
As slashdot only accepts conspiracies for posting this has never really be disseminated:
The NZX (ex NZSE) runs the Computershare ASTS trading system for their equities and bond trading. They have done so for 4 years.
This system runs under Linux (Redhat) on Compaq machines.
That they aggregated some of their databases and achieved better performance is non news but the increase in performance stated is worth a conspiracy post!
This caught my eye:
I'm not disputing this, but would the savings really be that big? Consider:
On the hardware side, a major shift to Linux wouldn't reduce the number of niche hardware platforms that they'd have to support; indeed, it should increase it. Linux, as open source, will naturally be ported to a huge number of architectures, even more than it has been already. The presence of popular OS would help these architectures go more mainstream, and Poof! Oracle ends up working with even more architectures than it has to now.
The major benefit would be in operating systems, but they don't have too many to work with now. Their choices are basically
All the Windows versions use the same set of APIs, and the differences between the Unices aren't too bad.
Yes, it would be easier for Oracle, but not *that* much.
Right?
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.
What the Oracle guy said was key, that if a software company can target a restricted range of kit, rather than every possible third party gizmo and buggy driver that can be installed under Windows, they've got a vastly easier job.
For some software applications it makes sense to refuse to ship the software on its own and insist on giving away free hardware with the deal, with the operating system of your choice (it isn't really going to matter which operating system) fully configured and installed. That way you know what the client is running your software on, you've tested it, and you've got an identical setup back in the lab to research problems on, and you know it isn't going to crash because the client's box is running some crap driver you've never heard of.
"CREATE INDEX"
It's amazing what you can do to optimise a query or two...
Advice to the sarcasm-impared: do not take this posting literally.
thats because Slashdot moderators are very compassionate with their fellow AC-s ...
.. although im pretty sure it'll be the start of ww3
making moderation non-anonymous would be a nice feature
"There is nothing more frightful than ignorance in action." Johann Wolfgang von Goethe
Well I see no reason why a database server ought to need patching in a situation like this. The DB servers ought to be on a private, firewalled, network and only the DB should be accessable and only from trusted systems. This is just better for so many reasons.
Plus, if you are going to go for an expensive OS, why not go for Solaris? Oracle likes Solaris and plays quite well on it. For that matter, Oracle on Solaris on Sparc hardware would probably be a good idea. Much more reliable than normal x86 hardware, not to mention 64-bit (which makes a difference for large databases).
I mean either way, the OS should matter much. You either do it on comoddity x86 hardware, but lots of it, getting redundancy through numbers, or you do it on higher grade hardware, getting relibility through design (and also probably some numbers too). Regardless of platform, you stick it behind a firewall that blocks everything but that which is necessary and even then only from systems you trust.
When you want a real entierprise DB server, it's just reliability (meaning avoiding unscheduled downtime) but availability (meaning avoiding scheduled downtime). Well the biggest way to achieve that (once you have the hardware/software to do it) is to ensure it's secure so you aren't patching it often.
Any OS you would run it on (except maybe zOS) is going to have security holes from time to time. Well you do not want to worry about time being a factor in patching, since the patch could possibly cause instability problems (not likely, but possible). You want time to test it, and then roll it out. Or maybe, you just don't want to patch. System works, system is secure, no need to patch.
I know most geeks have a negative reaction to this sort of thing, since we are used to having systems on the 'net, and relying only on a firewall for security is, well, stupid. However in enterprise situations, it's easy to engineer the security outside of the system. You have all your DB servers on a physically seperate private network. It's only connection to the outside is through a firewall, and that firewall allows only connections to the DB (the systems probably aren't running anything else anyhow, you do management with a console server/kvm, not SSH). Those systems that access it then have two interfaces, if they are even on the net at all. One goes to a physically private network that connects to the firewall (that then goes to the other physically private network for the DB). Those systems on the Internet are then firewalled, and patched regularly.
In a setup like that, the patch status of the DB systems isn't relivant. You just can't get at them, without compramising one of the gatekeeper systems (which might be a webserver or something) and even then you aren't likely to get anything since all you can do is poke at the DB. There might even be another layer in there, so something like: Internet -> firewall -> webserver -> firewall -> request processor -> firewall -> DB servers. Also firewall in this context usually means a device that does more than just filter ports, they often are thigns that require computers to actually log in to them to allow connections through.
I was working on a large project where we tested platforms for Oracle. We ran two servers with similar hardware. One on Solaris+Oracle and one on NT+Oracle.
After serveral months, it became obvious there wes no comparison in performance. The Solaris-based server out-performed the NT-based box easily by a factor of 4-to-1.
More importantly, the NT system has to be routinely rebooted in order to remain stable. I actually had to schedule reboots just to keep the system from running out of resources!
That was more than four years ago. Since then, the NT server was repurposed into a workstation; the Solaris Oracle server is still running with an uptime of more than two years.