Slashdot Mirror
First Look: Oracle NoSQL Database
snydeq writes "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.'"
Oracle NoSQL might not offer the heady fun and "just build it" experimentation of many of the pure open source NoSQL projects
Oracle databases aren’t about fun, they are about pain. Severe pain. The kind of pain where you scream so loud in your mind at night that it wakes you up. Pain which you only endure if you need the power they offer over all the much more palatable alternatives available, or need support and/or the perception of not using “some freeware database” in the case of large bureaucratic enterprise.
All that said, this actually sounds like a good idea, and from what the article describes, it sounds like a good product. It will of course be painful to use, but I can see this catching on in the “serious performance/reliability” and “large enterprise with compulsive need to spend” groups, especially as NoSQL becomes a buzzword.
I know that a lot of submissions are inevitably going to be based on press releases (it's straight from the horses mouth so to speak), but do they have to be so blatantly biased? Could we have some sort of editorial? The last sentence of this post make me want to vomit.
But that's when you turn back to Oracle to buy a real database. They know what they're doing.
Table-ized A.I.
Slashdot uses the NoComment database. Comments are passe.
Table-ized A.I.
Anybody know how broad Google's map/reduce patents are?
It's been said that the whole reason Oracle bought Sun was to clobber Google with the Java patents so they could cross-license the map/reduce patents and get back to an Oracle database that could scale.
Regardless, corporations should just release their software and fight it out in court later (sorry, real people, you can't play) but now that this is out, things might get more interesting in the patent wars.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
We're looking for Oracle NoSQL DBAs with 10 years of experience --recruiter
So Sayeth Litchfield:
http://seclists.org/bugtraq/2005/Oct/56
'nuff said
help me i've cloned myself and can't remember which one I am
This just made my day.
BDB is an in-process key-value store. It's limited to being accessed by a single process, and has much more limited replication ability.
This is a server based product ; your client communicates with servers using a driver. It's "eventually consistent", meaning that changes take time to propagate across the replication axis, so not all clients see the same picture (although with this one, you can influence the ACID-ity of atoms of data by grouping them on "major" keys).
The advantage is mostly scalability. You can throw more servers at it to provide more capacity, and the software will do a lot of the work to ensure that this works. If you want more capacity on BDB, you need to throw a bigger chunk of iron at it.
The other major difference ; the open-source license (Sleepycat) for BerkeleyDB is copyleft. Despite the name, it's not released under a Berkely Software Distribution style license - Oracle dual license it and you have to pay a commercial license fee to distribute products based on it without releasing your own sources.
The Community Editor license file for Oracle NoSQL from the distribution lists a number of licenses, all of them BSD-style - new BSD and Apache 2.0 ; in certain quarters this will be greeted with a great deal more enthusiasm. The only difference between the Community and paid editions is the support.
The serious part of Oracle NoSQL is a practical approximation of ACID compliance, the standard that SQL databases like to offer.
If this claim holds up, then its easy to see where Oracle could come out ahead of other NoSQL databases. TFA mentions that this practical approximation is dealt with by arranging the cluster machines in two axes: the replication axis and the sharding axis. Along the sharding axis, each major key is guaranteed to be tied to a single machine. Since there is only one record to be updated, there is no "eventual consistency" problem. The replication axis is responsible for making multiple copies of that data. If full ACID compliance is desired, even along the replication axis, there are plenty of options for ensuring that the write is complete before calling the transaction complete: the master node is updated, a majority of replicated nodes are updated, or all replicated nodes are updated.
This approach seems to take the best of both worlds in the NoSQL arena: sharding, which is the approach used by MySQL cluster, and replication, as used by pretty much every other NoSQL store available. Of course, if you have a fuck-ton of data, you'll also need a fuck-ton of machines. This is not a server you will be testing without considerable resources at your disposal.
"Please describe the scientific nature of the 'whammy'" - Agent Scully
How about: "Not suitable for High-school kids looking to write their first database application"
or
"Not for mere morons"
or
"Not suitable for enthusiasts"
It seems like of silly. For playing around with K/V based systems, on the low end, you can throw something together with bubblegum and gumption without much concern about reliability, concurrency, or scaling. If you are a large project with a non-trivial set of requirements, the learning curve on a solution should be far less important than the effective output of the system in production. Now I've never used Oracle's NoDB solution (or any NoSQL solutions for that matter) but I'd reserve judgement until its actually in your hands to see how it works with your development practices.
Personally, I was obsessed with the concept of NoSQL in development until I realized just how much heavy work systems like Oracle do for effectively free using relatively simple SQL expressions. Maybe if I ever work on huge volume or huge scale systems, my tone may change, but in my typical enterprise scale systems (tables under 10mil rows) I haven't seen the need for anything else.
Bye!
I cannot understand why MapReduce has been turned into such a holy creation. The idea could not be simpler: you have a big dataset? Break it apart into pieces that are free of external dependencies, process the pieces in parallel and then aggregate the matches from the processed pieces.
This is not Hadoop, with its elaborate application plumbing or CouchDB with its curious use of MapReduce as part of its querying system.
MapReduce is too simple for all acclaim. It's too obvious.