>> I would go for the auto-configuring software, though it is not trivial.
>> I would replicate data sets on at least three nodes, so that when one
>> node goes down, two others can still serve the request.
>>
>>
> You have come close to describing the MySQL Ndb/cluster product, except
> that partitioning is user/dba specified by hash, range, or discrete values.
>
> It is not a wildly successful product. There are use cases where it is
> a very good fit, but they are rare and far between outside of the telco
> market.

It depends... if you look all those dynamic cache software, they try to
keep object clusters on one node. Therefore I would conclude that all
applications that can live with distributed cache can also live with
such databases.

Also, from my personal experience, when I do the O/R mapping, I
artificially cut the object navigation paths to prevent O/R from loading
the whole database into JVM (lazy loading is many cases does not work,
since we need to send the object tree to another layer, at that time
database transaction is already gone). So, in reality, I define the data
clusters, which will be loaded at once from the database and kept in
cache for a while.

And funny enough, the best performance optimization in this case is to
fetch all data, if possible, at once - as result of one select with many
master-detail joins instead of select-per-table approach. O/R mapper
then reconstructs the object tree in memory. So, strictly speaking, I
use a single "virtual" table in 1st normal form.

Roman