Seriously? Because I'm actually a bit surprised someone would choose Oracle for data at that scale!
Not that it's impossible, but as far as I know, while Oracle does support partitioning, it doesn't have any direct support for situating partitions on different servers, i.e. it doesn't provide support for sharding. Not that a database must support sharding, because you can do it in the application layer. But there are databases that do it for you and don't push that onto the application layer, and Oracle isn't one of them.
Yes, there is RAC, but fundamentally isn't that a cluster where all nodes share ownership of the same set of data?
Meanwhile, other systems do exist that handle this more gracefully. Just from a quick glance, it appears that Apache HBase (the Hadoop database) is a more natural fit than Oracle for really large databases in the exabyte league.
If your requirement is scale + strict consistency, I'd think HBase would do the job for you. That said, if I were you, I'd review http://hbase.apache.org/book.html#quickstart and send any follow-up questions to . The HBase community is great.
"HBase" is a very weird name for a class. I understand what you're doing and why you chose it, but ysk that HBase is already a thing and seeing that particular name in code with that specific capitalization will cause a lot of people to make an automatic (albeit incorrect) association. It's strange and distracting.
@posix4e "Apache HBase (TM) is not an ACID compliant database." - first line on the Apache HBase semantics page
A great deal of work had to be done in order to provide ACID compliance in Hive on HBase, and that work has only recently been done, and is even now, still in progress. Owen O'Malley is the architect at Hortonworks in charge of that project, and the source of my information.
Splice uses Derby and their own code to make their database ACID compliant. My source there is the Splice website.
Vote as you wish, but my information is accurate.