Guest post by InfoWorld’s Peter Wayner takes a first look at Oracle NoSQL Database, the company’s take on the distributed key-value data store for the enterprise. ‘There are dozens of small ways in which the tool is more thorough and sophisticated than the simpler NoSQL projects. You get a number of different options for increasing the durability in the face of a node crash or trading that durability for speed,’ Wayner writes. ‘Oracle NoSQL might not offer the heady fun and “just build it” experimentation of many of the pure open source NoSQL projects, but that’s not really its role. Oracle borrowed the best ideas from these groups and built something that will deliver good performance to the sweet spot of the enterprise market.’
Rather ironic that Oracle’s NoSQL database for very large systems is based on Berkeley DB, their acquired database for very small (embedded) systems.
Like the author of the piece, I have no doubt Oracle Corp’s NoSQL database will be a fine product from a company that really understands database technology. My concern is that Oracle is almost cornering the DBMS market: they own Oracle, TimesTen, RDB (from DEC), MySQL, Berkeley DB… All they have to do is acquire PostgreSQL and the open source database movement is over.
Not really. You still have Firebird and MariaDB, for example. Both are quite good.
Don’t forget Drizzle. Also, last time I checked mysql is still dual licensed proprietary / GPL as it always has been…
The systems you mention — Drizzle, MariaDB, and Firebird — don’t even appear in the typical DBMS market share piechart. Oracle’s control of MySQL and Berkeley DB is huge to IT departments who like FOSS databases.
“All they have to do is acquire PostgreSQL and the open source database movement is over.”
You do realize that PostgreSQL is not a company and cannot be acquired? PostgreSQL core developers refuse to work for a single company considering their past basically to ensure they are above any single organization. Same with Samba.
They don’t refuse, per se, but:
A) it’s impractical
B) they just don’t
MySQL has had a BerkeleyDB backend more than 5, maybe even 10 years ago, although it is/was not as much used.
Are you serious?
Unfounded claims are all over the place. He failed to compare Oracle NoSQL to any of the real alternatives. MongoDB, Redis and Tokyo come to mind.
The overall theme is that Oracle is serious and that if you do Serious Business, you go Oracle!
I’m not saying that the product itself is bad, I’m just saying that the article is bad. I haven’t read one thing the makes Oracle NoSQL special, apart from the fact that it comes from Oracle.
The article ends with:
“I would trade SQL joins for simpler installation any day.”
Some things are really not easy to solve with noSQL.
In the light of an article that is all about serious business it is an even dumber statement.
This article basically reads “Oracle made a key/value database and it is great because it’s Oracle. Oh, and in a single, mostly undocumented test it also beat one of the competing offerings”.
If I want to read crap like this I can read some random blog. I thought traditional media was all about the awesome journalism, research and integrity? What happened?
Edited 2011-11-17 01:10 UTC
I Agree this is a terribly written article. The author has no apparent clue about other ‘NoSQL’ solutions.
All the ‘oracle-seriousness’ the author is talking about is quite common and standard in most solutions.
The only thing you can say is that Oracle lies better about it… oeps did I say lie ? i mean marketing ofcourse
Atomic guarantee for data in the same record ? MongoDB has this if I’m not mistaking you can do this with Redis as well… and probably a lot of others.
Configurable write consistency, defining how many nodes must have written the data before returning to the application, MongoDB has this, Cassandra has this, probably a lot of others as well.
And we can go on-and-on…
He also forgets to mention that it’s written in Java and that (as far as I can see) it’s only available for Java.
So actually the use cases for this product are severely limited compared to other products out there.
IMHO any datastore that locks you into a vendor language is bad practice to begin with.