It's basically BerkeleyDB Java edition, probably BDB High Availability (HA) Edition with some layers on top.
They're doing pre-sharding with ranges mapped onto replica groups, which are probably BDB HA instances. Since BDB supports transactions, they claim transaction support. But it only works if your keys fall in the same replica group (see other comment in thread). (Nothing wrong with that.)
There's no mention of shard migration, so they probably don't support it right now. (Shard migration is hard to get right.)
It's Java only.
BDB HA uses something which is said to be like Paxos, so they're claiming that (although they only mention it for master election), but they also have other consistency modes, which is interesting.
Looking at the plots:
Running on 32 replica groups (96 nodes) they were able to get 350K insert/sec, which is ~10K/s per replica group, with 1K values that is 10M/s per replica group. That means the local BDB instances just wrote everything to the log files, good luck with that. That's assuming they were running BDB in transactional mode, which is the only mode that actually keeps your database intact in case of a crash.
According to the 10M/s figure, it should have taken them 1.8 hours to load the data. According to the latency number, it should have taken 91 hours, so one of them is wrong. Probably the latency numbers, they were probably batching ~100 inserts and that's what the latency numbers are for.
In my NoSQL startup, our first product used BDB as the disk backend. In our second product iteration, getting rid of BDB was one of the major driving forces. I wouldn't touch it with a ten foot pole.
Our in-house solution uses InnoDB (via MySQL even, not directly) and find it to be much more stable and performant than BDB for a number of key/value workloads.
Oracle NoSQL Database, Community Edition
The Community Edition is licensed under an open source
license. Please see the license file in the downloaded
release for details.
Okay, I can read the license agreement once I download it. Let's download...
Oracle NoSQL Database, Enterprise Edition
You must accept the OTN License Agreement to download this
software.
( ) Accept License Agreement | ( ) Decline License Agreement
To download the license I have to agree to it without reading.
Download files to be available soon. Please check back in mid-
October.
I find this kind of amusing
1. May 2011 Oracle writes a white paper on why NoSQL is not reliable and future proof for serious business [1]
2. Removes the original the document [2]
3. Releases their own own NoSQL db
Calling your key-value store "NoSQL Database" is like calling your high-speed train "Non-Car Transportation." (It could also describe boats, planes, zeppelins, buses depending on whether you think they count as cars or not...) This post, as well as that other post about why you shouldn't use a NoSQL database, suggests that Oracle as a whole is completely missing the point of NoSQL.
I don't really understand why calling a key-value database a "NoSQL database" is incorrect in your opinion. It's one of the many data models (or lack of) that falls under this umbrella term in 2011.
Oracle is purposely hijacking the NoSQL term. Anyone who Googles for NoSQL will now find that it's an actual Oracle product, giving the appearance that every other 'NoSQL' DB is simply a knock-off. Pretty evil, IMHO.
Well, for a long time, "database" was synonymous with "SQL," with a few exceptions such as DBM-type systems, largely because there were a lot of them out there and they could do a lot of stuff. Two of the reasons the whole "NoSQL movement" got started are:
- RDBMSes were being used to do a lot of things that the relational algebra-based data model wasn't really designed for, like storing objects.
- A lot of the things that people were using RDBMSes for could be done more efficiently in a more specialized, somewhat lower-level product.
You can kind of compare "NoSQL" to using public and shared transportation instead of personal automobiles. Boats, buses, trains, and planes can't all do everything (at least, not efficiently), but the things they do well, they can do more efficiently than a car can.
So, basically NoSQL is about "relational databases aren't always the best choice, so use something that works well with your particular use-case." Though I usually prefer the term "non-relational" - the way "NoSQL" is used now suggests that they are some united front against relational DBs, but that's really not the case at all.
"Download files to be available soon. Please check back in mid-October. "
just as i wanted to ask whether anybody knows was it developed by Oracle or bought from outside. I guess the correct answer - they will buy it as soon as somebody develops a scalable transactional key-value store with replication, failover and transparent partitioning support. Btw, how about making some good money by hacking such a store in the next 2 weeks :)
"Oracle NoSQL Database supports the ability to bundle a collection of operations together using the execute method, providing transactional semantics across multiple updates on records with the same Major Key Path."
In other words, ot supports transactions as long as the key-values are on the same replica group (as they call it). That's easy for them, since they just run a BerkeleyDB HA instance per replica group, and that supports transactions.
Random sidenote: I haven't downloaded but if this is a community version of Oracle Coherence (nee Tangasol) it might be reasonably badass. As an ex-oracle employee, I've heard the insider view from friends that unlike most oracle in-house or acquired software, Coherence is the real deal, scales as advertised, and except for the $100k per enterprise box price-tag, should have taken the storage world by storm.
No it's not a successor to BDB. According to http://www.oracle.com/technetwork/database/nosqldb/learnmore... it's based on BDB-JE High Availability (HA). BDB-JE HA is a separate product that has been around for awhile. Basically it's a multiple node cluster where each node runs BDB-JE.
It sounds like they are just rebranding BDB-JE HA, adding a couple features, and calling it NoSQL.
It's basically BerkeleyDB Java edition, probably BDB High Availability (HA) Edition with some layers on top.
They're doing pre-sharding with ranges mapped onto replica groups, which are probably BDB HA instances. Since BDB supports transactions, they claim transaction support. But it only works if your keys fall in the same replica group (see other comment in thread). (Nothing wrong with that.)
There's no mention of shard migration, so they probably don't support it right now. (Shard migration is hard to get right.)
It's Java only.
BDB HA uses something which is said to be like Paxos, so they're claiming that (although they only mention it for master election), but they also have other consistency modes, which is interesting.
Looking at the plots:
Running on 32 replica groups (96 nodes) they were able to get 350K insert/sec, which is ~10K/s per replica group, with 1K values that is 10M/s per replica group. That means the local BDB instances just wrote everything to the log files, good luck with that. That's assuming they were running BDB in transactional mode, which is the only mode that actually keeps your database intact in case of a crash.
According to the 10M/s figure, it should have taken them 1.8 hours to load the data. According to the latency number, it should have taken 91 hours, so one of them is wrong. Probably the latency numbers, they were probably batching ~100 inserts and that's what the latency numbers are for.
In my NoSQL startup, our first product used BDB as the disk backend. In our second product iteration, getting rid of BDB was one of the major driving forces. I wouldn't touch it with a ten foot pole.