RonFrank
Contributor
lamont:My only counter-point is that Oracle-done-right is generally expensive, while MySQL+Linux/FreeBSD is the cost of the hardware and the expertise... You don't take a $20B company and put its most important financial data onto MySQL, but it should work fine as an architecture for scubaboard...
Oh, actually another thing is that one cheap way to beat Oracle is to use statically chewed data and serve it out of apache.... you can hit 10,000+ transactions per second on $3k of hardware... Of course you can get the best of both worlds by using this as a read-only cache sitting in front of Oracle... The best solution is generally not going to one or the other but a mixture of both... So when you say this:
We are talking about data volumes for the apps I work on that are staggering, and the amount of hardware we run on is in the 10's of millions of dollars. Imagine pulling EVERY switch in a global network, and the samples are taken every five minutes.
In fact we do front end our Oracle DB's with hashing... WAY to much hashing. We just don't put enough time into our design to make it easy to maintain or grow gracefully which is a HUGE issue. Imagine trying to add 1000 square feet of space to a store that resides on the ground floor of a NY city building with adjacent property that is NOT available on all sides. This is kinda what it's like attempting to add to our software in many cases, and believe you me, after we are done cramming the 1000 square feet of STUFF into an already crowded showroom, things suffer.
Cache, and hashing solutions work, what do you think is in the guts of Oracle? But overuse of this amounts to so much complex inhouse code that it becomes a house of cards, and visibility into what is going on at a low level is next to impossible. Visibility and user access to provide for the changing reporting requirements is also a real issue. Restarting, and recovery suffers, and as we implement more and more of this type of solution, we start to look more and more like a DB, with all the complexity, and none of the tools or expertise.
For Scubaboard I agree there are a LOT of viable solutions. Unfortunately I'm not sure they have the manpower to retool. I'm also no expert on what is available in Can solutions that may hook directly into the existing DB. Unfortunately like so many software solutions, once you realize that the direction you have chosen is not working, it's kinda like trying to build a plane why flying it!
It would appear the SB will become more stable as they fine tune the new hardware. However throwing hardware Only and patches at a problem is generally NOT going to buy long term stability or scaleability.