Re:Oracle Announces an In-Memory Technology, At an Ungodly S...
by capkutay on Tuesday September 24, 2013 @01:22AM
(#6436151)
"Just like mainframes, appliances don’t fit in the new world where customers think in terms of nodes in data centers, availability zones, and geographically distributed storage and compute. The new world is being built on distributed systems."
Oh yes...mainframes that have been developed over decades catering specifically to enterprise needs are far less superior than what a group of 20-something engineers at a social media company came up with.
Excuse the sarcasm, there are certainly places where distributed in-memory data stores on commodity hardware are a fine solution. That does not mean its taking over mainframe computing because that solves a completely different class of problems.
Re:Oracle Announces an In-Memory Technology, At an Ungodly S...
by justinsb on Tuesday September 24, 2013 @01:52AM
(#6436252)
I think that mainframes are the solution to the problem that some applications run well only on a single machine. Most software has been cluster-fied, but there's one big one that is left: databases.
Mainframes are more expensive per-CPU-unit or per-IOPS. Google has shown that, with the right distributed software, a cluster of cheap machines can be more reliable because you avoid putting all your eggs in the mainframe basket. (The tradeoff is that your software is more complicated and likely introduces new failure scenarios).
So, although mainframes are indeed optimal for today's database, the NewSQL hypothesis is that different database software will be able to run on multiple machines, and so the mainframe will no longer be the optimal solution. This (hypothesized) database would run on a cluster of commodity machines, and should therefore be cheaper and hopefully more reliable. Moreover, just as Google's clusters beat Altavista's mainframe approach, a clustered database should scale to much bigger workloads than the biggest mainframe.
Of course, this relies on a new breed of database.
Re:Oracle Announces an In-Memory Technology, At an Ungodly S...
by capkutay on Tuesday September 24, 2013 @02:04AM
(#6436292)
Very interesting points.
'Google has shown that, with the right distributed software, a cluster of cheap machines can be more reliable because you avoid putting all your eggs in the mainframe basket.'
'Moreover, just as Google's clusters beat Altavista's mainframe approach, a clustered database should scale to much bigger workloads than the biggest mainframe.'
My one comment on those points is that distributed computing solved Google's problem, and of course applies to what many software companies are trying to do (amazon, yahoo, etc.) But do they have an answer for the set of problems where 100% ACID compliance and high-availability is a requirement?
Re:Oracle Announces an In-Memory Technology, At an Ungodly S...
by haimez on Tuesday September 24, 2013 @02:37AM
(#6436370)
ACID compliance is not ever a strict requirement, it's an abstraction guarantee. If you have a fully ACID compliant database with a sufficiently expressive query interface, then the complexity of the datastore is a perfect abstraction.
The ATM machines people use every day to exchange money are not fully ACID compliant, and they do not use "transactions". It's a calculated choice on the design of the system to account for the guarantees in different ways and balance discrepancies that occur after the fact.
If you need full ACID compliance and need to operate at "Google scale", you reorganize the problem so that you don't need the compliance.
Re:Oracle Announces an In-Memory Technology, At an Ungodly S...
by justinsb on Tuesday September 24, 2013 @12:58PM
(#6439104)
I believe NewSQL will deliver 100% ACID and high-availability on distributed systems. Not 100% availability, because CAP tells us that's theoretically impossible. But availability as good as any _real-world_ non-consistent database _implementation_.
The CAP conjecture has certainly been a major barrier to progress in this area ;-)
Re:Oracle Announces an In-Memory Technology, At an Ungodly S...
by joshuaellinger on Thursday September 26, 2013 @10:56PM
(#6454998)
Some HP Vertica and some Actian Vectorwise. Vertica scales to multiple nodes better and HP is a much more accepted vendor. I've got friends who are doing a lot of Redshift (which is repackaged ParAccel). Start with Redshift if you are new to columnar.
If you can afford it, Microsoft's new PDW looks like a much richer functionality columnar store.
Re:Oracle Announces an In-Memory Technology, At an Ungodly S...
by joshuaellinger on Thursday September 26, 2013 @11:03PM
(#6455021)
The mighty Curt Monash reads HackerNews? Who knew?
Howdy. I like how you hold no punches on your blog but normally you are good about backing them up with data. I hope to meet you some day.
The precise quote from my client that uses TeraData is "I.T. charges me $1M for each TB I use". I know that's very different from what it costs the business but it is still a very damning number. That's basically a fully loaded cost to an end business unit.
Re:Oracle Announces an In-Memory Technology, At an Ungodly S...
by CurtMonash on Friday September 27, 2013 @09:47PM
(#6460551)
OK, maybe it's his IT department that's arithmetically challenged. :)
If costs are CLOSE to being that high, then data volumes are a very poor metric for cost allocation. 2+ people per terabyte are being counted in, so either there are a huge number of tables, or they're including BI developers, or something.
E.g., doubling the size of every table, if nothing else changed, might only take those costs up 10%, give or take a factor of 2.
Re:Oracle Announces an In-Memory Technology, At an Ungodly S...
by jjoe on Tuesday September 24, 2013 @12:37AM
(#6436008)
Does anyone remember their acquisition of TimesTen? I've used it in production (HF trading) but it didn't seem to gain that much broad traction. Is this just TimesTen in a SPARC-packaged bundle? Perhaps IBM's plan to sell / phase out its POWER server business has something to do with the re-branding of TimesTen to this. [1]
Re:Oracle Announces an In-Memory Technology, At an Ungodly S...
by bigchewy on Tuesday September 24, 2013 @12:22AM
(#6435949)
Source?
Talk to Judy at Epic and you get a different opinion. Actually, talk to almost anybody I've ever met in my 10 years in healthcare and you'd get a different opinion.
Re:Oracle Announces an In-Memory Technology, At an Ungodly S...
by twic on Tuesday September 24, 2013 @09:06AM
(#6437595)
There is a similar vibe in the bits of blue-chip eCommerce i worked in (online operations for big bricks-and-mortar retailers). If you'd proposed a site where the database was MySQL, you would have got a funny look and the door held open for you.
Re:Oracle Announces an In-Memory Technology, At an Ungodly S...
by NKCSS on Tuesday September 24, 2013 @03:40AM
(#6436561)
The article mentions Fusion IO drives for $2k/TB; any idea who sells them at that price? If I check [1], it's a lot more expencive. At $2k/TB, it would be worth it to buy and compare it to our Netezza. If it can compete, awesome, if not, I can beef up one of our normal SQL servers.
Re:Oracle Announces an In-Memory Technology, At an Ungodly S...
by NKCSS on Tuesday September 24, 2013 @03:58AM
(#6436616)
But that's still more for resellers or large quantity buyers. I wasn't planning on getting 100TB; I was just looking for 1-2TB to load a demo set and compare to some of the stuff we do on our netezza. It's too bad there is no Microsoft Technology Center near where I could take this for a test drive...
Re:Oracle Announces an In-Memory Technology, At an Ungodly S...
by threeseed on Monday September 23, 2013 @11:04PM
(#6435664)
Lots of reasons. It supports SQL, you can gradually move data to the in-memory stores, DBAs/Operations teams already know how to manage it and it is well supported. Plus it would destroy both DynamoDB and MongoDB in certain use cases.
Oh yes...mainframes that have been developed over decades catering specifically to enterprise needs are far less superior than what a group of 20-something engineers at a social media company came up with.
Excuse the sarcasm, there are certainly places where distributed in-memory data stores on commodity hardware are a fine solution. That does not mean its taking over mainframe computing because that solves a completely different class of problems.
Mainframes are more expensive per-CPU-unit or per-IOPS. Google has shown that, with the right distributed software, a cluster of cheap machines can be more reliable because you avoid putting all your eggs in the mainframe basket. (The tradeoff is that your software is more complicated and likely introduces new failure scenarios).
So, although mainframes are indeed optimal for today's database, the NewSQL hypothesis is that different database software will be able to run on multiple machines, and so the mainframe will no longer be the optimal solution. This (hypothesized) database would run on a cluster of commodity machines, and should therefore be cheaper and hopefully more reliable. Moreover, just as Google's clusters beat Altavista's mainframe approach, a clustered database should scale to much bigger workloads than the biggest mainframe.
Of course, this relies on a new breed of database.
'Google has shown that, with the right distributed software, a cluster of cheap machines can be more reliable because you avoid putting all your eggs in the mainframe basket.'
'Moreover, just as Google's clusters beat Altavista's mainframe approach, a clustered database should scale to much bigger workloads than the biggest mainframe.'
My one comment on those points is that distributed computing solved Google's problem, and of course applies to what many software companies are trying to do (amazon, yahoo, etc.) But do they have an answer for the set of problems where 100% ACID compliance and high-availability is a requirement?
The ATM machines people use every day to exchange money are not fully ACID compliant, and they do not use "transactions". It's a calculated choice on the design of the system to account for the guarantees in different ways and balance discrepancies that occur after the fact.
If you need full ACID compliance and need to operate at "Google scale", you reorganize the problem so that you don't need the compliance.
The CAP conjecture has certainly been a major barrier to progress in this area ;-)
The columnar store I use are in the $10K/TB range running on $10-25K servers.
I think Oracle is going to have trouble with this space.
If you can afford it, Microsoft's new PDW looks like a much richer functionality columnar store.
Howdy. I like how you hold no punches on your blog but normally you are good about backing them up with data. I hope to meet you some day.
The precise quote from my client that uses TeraData is "I.T. charges me $1M for each TB I use". I know that's very different from what it costs the business but it is still a very damning number. That's basically a fully loaded cost to an end business unit.
If costs are CLOSE to being that high, then data volumes are a very poor metric for cost allocation. 2+ people per terabyte are being counted in, so either there are a huge number of tables, or they're including BI developers, or something.
E.g., doubling the size of every table, if nothing else changed, might only take those costs up 10%, give or take a factor of 2.
http://www.oracle.com/technetwork/products/timesten/overview...
And remember that you go with Oracle for more than just technology.
Can you explain this? In my experience, you used to go with Oracle for technology but that was about 15 years ago.
In the heath care industry, it doesn't matter what you make, it doesn't matter how good it is, and it doesn't matter how proven it is.
If you don't say the word "Oracle", you don't get the contract.
Talk to Judy at Epic and you get a different opinion. Actually, talk to almost anybody I've ever met in my 10 years in healthcare and you'd get a different opinion.
[1] http://www.solidstateworks.com/ioDrive-Octal.asp
And $1/Gb is coming soon
If you're just starting out, however, Oracle is rarely close to being cost-effective.