Oracle Announces an In-Memory Technology, At an Ungodly Speed And Cost(blog.memsql.com)
blog.memsql.com
Oracle Announces an In-Memory Technology, At an Ungodly Speed And Cost
http://blog.memsql.com/oracle-announces-an-in-memory-technology-at-an-ungodly-speed-and-cost/
7 comments
Which columnar store do you use?
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.
If you can afford it, Microsoft's new PDW looks like a much richer functionality columnar store.
that could reflect software licensing and PSO. Oracle's $100k/TB is just the cost of the hardware before software.
Whoever told you that about Teradata was very bad at arithmetic.
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.
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.
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.
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.
What is the good use for a this vs a standard key value store like DynamoDB or a document db like MongoDB?
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.
Looks like it is designed to compete with the likes of SAP HANA.
And remember that you go with Oracle for more than just technology.
And remember that you go with Oracle for more than just technology.
> 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.
Can you explain this? In my experience, you used to go with Oracle for technology but that was about 15 years ago.
Industry acceptance too.
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.
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.
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.
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.
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.
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]
http://www.oracle.com/technetwork/products/timesten/overview...
http://www.oracle.com/technetwork/products/timesten/overview...
IBM are not selling or phasing out Power. They are investing $1bn in Linux on Power and opening up the platform.
"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.
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.
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.
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.
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?
'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?
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.
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.
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 ;-)
The CAP conjecture has certainly been a major barrier to progress in this area ;-)
As per http://www.dbms2.com/2013/09/23/thoughts-on-in-memory-column..., this new technology makes a lot of sense if you're committed to Oracle, and have the huge IT budgets to make such a commitment possible.
If you're just starting out, however, Oracle is rarely close to being cost-effective.
If you're just starting out, however, Oracle is rarely close to being cost-effective.
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.
[1] http://www.solidstateworks.com/ioDrive-Octal.asp
[1] http://www.solidstateworks.com/ioDrive-Octal.asp
http://www.storagepricing.org/fusion-io-pricing-at-ces-with-...
And $1/Gb is coming soon
And $1/Gb is coming soon
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...
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.