Slashdot Mirror
Database Clusters for the Masses
grugruto writes "Cluster of databases is no more the privilege of few high-end commercial databases, open-source solutions are striking back! ObjectWeb, an Apache-like group, has announced the availability of Clustered JDBC (or C-JDBC). C-JDBC is an open-source software that implements a new concept called RAIDb (Redundant Array of Inexpensive Databases). It is simple: take a bunch of MySQL or PostgreSQL boxes, choose your RAIDb level (partitioning, replication, ...) and you obtain a scalable and fault tolerant database cluster."
Wow! Can you imagine a beowulf.... oh, wait, nevermind
Just started looking at the site. I've wanted this for years. I was ecstatic with what load-balancing cheap Apache boxes did for the cost of web hosting. Unfortunately, reliability has still required hundreds of thousands of dollars of high-end equipement and software for databases. I've been hoping the open-source community would make headway on this front.
So, the question is - is anyone working on anything like this for Perl, C, or generic implmentations?
now if only MySQL or PosgreSQL can get the reputation that Oracle has mabye we will start to see Oracle DBs go away in favor of the cheaper solutions using RAIDb
I am the Alpha and the Omega-3
Is RAC the new name for OPS? If now how do they differ?
Running many databases is easy. Organizing and serializing replication is hard. Even if one have distributed transactions handy - not present in this case. But let's read their code...
...but what about my desktop? I want to run my company on xterms connected to a large cluster. Problem, nobody has yet to provide High Availability for Linux or X. Not your heartbeat type stuff or MOSIX etc. But a cluster that I can hotswap entire machines and nobdoy loses uptime. Bits and pieces are there but not everything.
/. but it's still waiting to be posted, only been there since Feb.
Yes I submistted an Ask
Hmm, interesting idea. I didn't see performance listed as a feature.
I wonder how much slower my query will be when the data is spread across several machines. I'd imagine that a few complex queries that aren't correctly optimized would bring this system to it's knees rather quickly.
This is a major threat to the big vendors. In fact I would say it is even more of a threat to Oracle than it is to MS! After all MS can continue to go after the midrange market that are are already locked into them for the OS.
But Oracle shops are dealing with expensive boxes they would love to replace, not to mention expensive Oracle licenses. Often the only reason they use Oracle (other than Oracle salesmen licking their buttholes) is because only Oracle has the horsepower to meet their requirements. Give them a cheaper alternative with the same capabilities and they will bail out faster than you can say 'Geronimo'.
Expect Larry Ellison to start talking about the dangers of using Open Source software now...
- -
Are you an SF Fan? Are you a Tru-Fan?
So a few things come up just reading the docs on this:
;)
1. A Controller. It looks as tho a single controller is used by the clients to communicate to the various RAID'd dbs. I'm sure there can be multiple controllers since there would be little point to make some db's redundant, yet the access to them not. Still looking into this.
2. And also, it looks as tho the default port is 1099 - RMI. If you have, for a web app, your EJBs and web app local to that containter, that might not be a problem. However, I happen to have my EJB server on its own box and this might very well cause probs. I think it said you could specify our own ports, but I haven't seen any examples in the docs yet of this being the case. Also, still looking.
A few other things exist as well which are in the docs as known limitations:
* XAConnections
* Blobs
* batch updates
* callable statements
These could be serious issues for some. My last project used CLOBs/BLOBs, batch updates and callable statements, so this would rule that out. Of course, all the db stuff was strictly tied to Oracle, so I think that would rule this all regardless.
All in all tho, this looks like a good start. As my current project progresses, clustered dbs will become more and more of an issue. I've looked into some other projects out there for Postgres, but nothing yet really satisfactory. I think this is a good step in the right direction - for Java developers. It'll be interesting to watch.
MySQL - not a database
+ Java - *laughter*
-------
My god, someone actually BUILT a cluster-f***.
... dont forget the XML!
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
Off I go to starting coding a FORTRAN port...
Then this wouldn't be so necessary. Of course this must also perform load balancing which you do not get for free with replication, but it would be nice. After all, you can always use a load balancing solution between you and the databases if your replication is actually worth using.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I looked at the diagram, and it looks very nice, but they seem to be very light on the details.
Supposedly, This new version has been successfully tested with Tomcat, JOnAS, MySQL and PostgreSQL. Excellent results have been obtained with the TPC-W and RUBiS benchmarks.
Don't get me wrong, I like the idea, and I have been wanting something like this for years, but I sure would like to _see_ the test results, even if they are preliminary.
Here's an example of an application: I have a database-driven Web application that allows my onsite clients to register network services for openings in the firewall. Another software component probes the registered hosts for daemon version information and records it in the database, so that we can send out alerts when security holes are discovered in particular versions. I use PostgreSQL on Debian and Solaris. Independently of my work, our networking office has a Microsoft SQL Server database of IP addresses, MAC addresses, and physical switch ports and jack numbers.
What I'd like to do is mount both my database and the networking office's database into some sort of "meta-database" -- analogous to mounting filesystems from two different hosts via NFS -- and run SQL queries that span both data sets. I wouldn't expect to be able to write to this conjoined database -- locking would be a nightmare -- but being able to SELECT across the two sets would be incredibly valuable.
it'll put some of those high-dollar Oracle admins out of business. Oracle has been in the business of changing the entire support method of their database every revision, and releasing numerous revisions, to keep their dba's in business. I've been waiting for something that can do what oracle can do that doesn't come with such a pricetag. This is awesome!
Maybe I missed it but there info is pretty sparse on how they handle updates (i.e. adds/deletes/updates). Does it do two phase commit so if I'm stripping data and one of the updates fail then everything fails? If they are replicating, will they automatically update replication servers if they are down at the time of the update? If one of the databases in the RAIDb doesn't support online backups and it's backing up, what will their system do? After all, this would be the true grunt work, without these features then what they have isn't a big deal at all. Does anyone have more info?
Why do masses need database clusters? Does anyone apart from mid-large sized businesses need one?
What you missed is that this thing only forwards SQL requests. Therefore you can also build clusters of Oracle if you want. You will not miss any Oracle feature this way.
When you look at Oracle pricing policy, you can have Oracle RAC for the price of just Oracle (+ a free RAIDb), which is already a 50% discount!
Isn't clustering supposed to be a function of the database system, not the software you use to access it?
I mean, this is neat and all, but I really don't want to have to use this interface just so that I can cluster my database. You're much better off placing clustering functions within the database itself. Then you can access the data by any method (ODBC, native libraries, hell even with the provided command line interface).
Take a look at how MS SQL Server performs clustering sometime. Everything (and I mean EVERYTHING) is performed via triggers and tsql. All the clustering setup does is set up a bunch of known working trigger scripts to propagate the data. You can even edit them to your liking afterwards if you wish. Now I'm not saying that MS's solution for clustering is the cat's ass. Personally, I think it is kind of hackish, but then again I believe that clustering should be something you simply turn on, and shouldn't be able to fuss with. Realistically, I can't think of any good reason to change the cookie cutter tsql scripts that perform the clustering, so I only see the ability to modify them as a potential way to fsck it up (that being an obviously bad thing).
Clustering really isn't that hard to implement. I'm pretty surprised that MySQL and Postgres don't have better support for it. Especially Postgres, since transaction support is really the one big key that makes clustering possible. Maybe no one has really had an itch to make it heppen yet. Hopefully it will happen soon, since I'd love clustering to be another argument for why OSS databases can play with the big kids just as easily.
The commercial databases that have been doing this for years are DB2, Informix, and Teradata.
Know what? There are a ton of deep issues beyond just making the different partitions transparent to the application level. Think about joins across partitions for sec...
But , Seriously do you see Oracle/DB2 etc customers suddenly jumping over this ?
My view is that it may be difficult to migrate OSes or even hardware, but its almost darm impossible to migrate existing Databases.
A Database is the most fundamental and most cared about aspect of a major business. There is a lot of time and effort and MONEY spent to incorporate it in to the company.
Lots and lots of critical business applications are written using the propritory extenstions of these vendors. Is it very easy to migrate this code ?
May be interesting for a future pilot project, but if expect business to change their database vendors.. that's not going to happen very soon.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
Just curious.
How do you join one table to another when they are on two separate boxes?
Well. I know how to actually use SQL to join two tables from two separate databases. But what is actually happening inside the RDBMS at the low lever. Does one just bring over the entire other table. How does it use indexes.
Seems to me this really is doing at best, a reference implementation that may actually degrade performance.
Well, some of the top level domain controlers (at least .org I think) use PosgreSQL.
Well.... umm..... Isn't it good that you found some piss-poor code that needed correcting.
...does it mean that their db really works? (at least, until now..)
-- There are two kind of sysadmins: Paranoids and Losers. (adapted from D. Bach)
It would be nice if C-JDBC was built into the J2EE spec so all J2EE containers can support this facility.
It may also have the advantage of using the transactional, load balancing and clustering facilities of the J2EE container as well.
Archie - CIO-for-hire
Finally, my grandmother can have that database cluster she has been bugging me about.
Manipulate the moderator system! Mod someone as "overrated" today.
RAID -- Redundant Array of Inexpensive Developers
RAID 0
Multiple developers work on the same project but none of them has any idea what the other is doing at the same time. One developer failing (caffeine dehydration, severe electrostatic shock, sex, etc) will cause the entire project to screw up and become a mess.
RAID 1
Extreme Programming.
RAID 2
Inefficient way to keep track of what developers are doing. For every 10 developers, 4 are needed to keep track of them and recover any error by the aforementioned 10 while they don't work together at all. Level of efficienty comparable to a modern goverment.
RAID 3
Equal to RAID 2, except all responsibility for checking the code is now granted to one person. The rest has been budget-cutted away. A bite more effective but considering people still don't cooperate, not too good.
RAID 4
Equal to RAID 3, escept people are finally working together now. Kinda efficient and fast, except it all still relies on that one person who checks the data.
RAID 5
Everyone knows what everyone else is doing, they all work perfectly together and they can easily miss one person because of that.
Hate me!
Poor me; I have to implement it in COBOL :-(
Karma whorin' since 1999
It's a good start - but not ready for prime time yet... Stored proc support is essential in a production setting.
4.4. Current limitations
The C-JDBC driver currently does not support the following features:
* XAConnections,
* updatable ResultSets,
* callable statements (stored procedures),
* Blobs,
* batch updates,
* multiple controller failover is subject to controller support for distributed virtual databases,
* JDBC 3.0 features.
Can someone who understands C-JDBC better than I do explain what this might mean? Sounds to me like they are replacing a feature of CMP by doing this, which is not necessarily something that would be "useful with EJB entity beans" if I understand it right (unless maybe they are referring to folks using EJB 1.0?). That is, the container already handles cache-invalidation at a fine-grained level. Perhaps there is a scenario I am not imagining where it would be useful to have this at the database level also... thoughts?
See DBD::Multiplex.
This simply isn't true. Oracle's clustered database solution (9i Real Application Clusters) are designed to increase the ability to gracefully recover from individual node failures. Additionally, they can scale the performance of your database application by increasing the number of CPUs with access to shared storage. For CPU bound database applications, this technology provides near linear scalability!
Don't forget transparent client switchover when the primary being replicated goes down.
Replication safeguards the data, the client switchover on the fly provides high availability.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
Essentially, this seems to be that front-end piece which abstracts the calling app from which server it is connecting to, and can dynamically point that app at another server. I'm sure it will be a handy module for anyone who doesn't want to write their own logic for dynamically determining a connection to a database.
However, the cost of writing that bit of code is much lower than the overhead of maintaining all those database servers (heterogenous replication? ugh). So sure, this is helpful, but anyone with enough wherewithal to set up and maintain a set of synchronized database servers probably has enough sense to be able to set up application logic to utilize those servers anyway.
It's good that these are becoming available in open source form, but the concept is not new at all. IBM and Oracle both have had commercial versions for a while (I suppose the "inexpensive" part is new).
Just out of curiosity, how do you load balance Apache servers? Not counting round robin DNS.
The Whitespace port is already complete:
After actually reading the documentation, here's my informed take on this:
1) In it's current incarnation, it's only useful for very very simple database access. No transactions, no blobs, etc. Basically if you're just storing some simple weblication tables and doing single-statements against them for selects/updates (no big cross-table transactions), you can use it.
2) It's JDBC only. Perhaps someone could port the concept to ODBC though.
3) There's a new middle tier between the JDBC driver and the database itself, which is the bulk of their code. This tier actually re-implements some database constructs like recovery logging, query caching, etc. Of course this is neccesary, as trying to do replication from the client-code side alone would be impossible (what do you do when one of 3 DB mirrors goes offline for an hour? have every jdbc client cache the requests and replay them later, hoping those clients are even stilla round later?)
For some applications and some companies, in it's current state this is a godsend - but it's not a general solution yet. Making it ODBC (or even better, having the front of it emulate a native postgresql or mysql listener) would broaden it's applicability.
Supporting transactions would be a big win too, although I'm not sure how feasible this is - I think at that point they may as well just write their own new database engine which is parallel from the start, seeing as they'll be re-implementing in their cluster tier almost everything the database server does except for actual physical storage.
Still, it's nice to see that someone did this and made it work - and for a lot of simple databases behind java apps it's all you really need.
PostgreSQL has all the transaction support in place already, so of all the free DBs out there it would seem they have the best shot at doing their own native parallelism, if they would just get it done someday.
11*43+456^2
I once worked for an opensourced company that tried creating something like this in Perl. We did so to try and lure customers from oracle and prove that open source could handle massive databases. But... we found many problems when trying to sell this to expirenced customers over oracle.
1st... multiple points of failure. By increasing the number or databases your increasing the potential points of failure. What features are there to automatically backup data? If the data is spread randomly across the dbs and one of the drives or servers dies, what failover is there? Will the other databases take over? In a cost/risk analysis, is this really the cheapest way?
2nd...Is any speed increase from multiple databases going to be more then the speed increase from just upgrading the database server? More/faster disks, more processors etc. Sticking to one machine allows you to use the fault tolerance built into the RAID controller or the server itself. You could argue that once you got to the fastest hardware you need to go with more machines, but at that point you might need to look at your application. Quad Xeon 2.2Ghz with GBs of memory and an NetApp disk array is going to powerful enough for alot of apps.
3rd... Is this really faster? With simple SQL queries it might, but what about complex joins etc? Since this lies infront of the dbs, what about stored procedures etc?
The only really application that I could see this for is a small ecommerce website that needs to have millions of potential products to sell. (Electronics supply store etc). Something where the data needing replicating is static and is imported.
And as far as eliminating the need for a high priced Oracle DBA, someone able to support an array of 8-10 mysql databases using this technology is going to be both high price and hard to find.
More or less - it's a reworking of Oracle Parallel Server. It handles failover reliably, scales reliably, etc. Like everything Oracle, wait 'til the 2nd iteration of a product has matured, *then* buy it. I have a multiple 2 and 4-node RAC-on-Intel (RHAS2.1) systems running at the moment. Even OEM and OMS have come along far enough that useable.
to bad the licensing for those cpus is exponential
I am the Alpha and the Omega-3
A while back, on a slow day at work, some friends of mine idly discussed making a system along these lines that would run as a separate process.
Our idea was to write it in C, and make it proxy connections to mysql, postgres etc. In otherwords it would speak and understand the wire protocols of each database it supported. It would apply replication (etc) logic as it passed messages through to the real databases.
We imagined a type of pipeline which you could configure, and messages would move though that pipeline being processed by different modules... ie you could enable replication, logging, and perhaps various other types of processing, as options for each user/db or something like that.
Such a system would be useful for any client without modification (such as PHP, perl, C programs and of course the relevant JDBC drivers).
Well we didn't go very far with the idea... Ok we didn't go anywhere with it... But I still I felt like sharing.
I beat all of you, my Whitespace implementation is below:
It's 10 PM. Do you know if you're un-American?
2 node AMD Opteron Beowulf Cluster giveaway!
s
http://www.linuxhpc.org/pages.php?page=PSSC_Lab
Worth a shot!
While, I commend their efforts, what they are offering is little more than a poor man's High Availability cluster.
The shared disk array (RAID, etc.) is just a part of implementating HA.
My recommendation is for the developers to take a look at how it is implemented in the enterprise DBMSs (Sybase, Oracle, MS SQL Server, DB2) first.
jason
No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil
On slashdotter commented that it was missing callable statements, which I believe are necessary for certain types of stored procedures.
-Michael
"Moving to Postgres from Oracle would be asking someone to accept more risk in return for thousands and thousands of dollars. For some companies that's the difference between being a 3 man shop and a 4 man shop."
1-All companies revolve around their database, from SOHOs to multinational. You'll find that movement harder than you think. As far as your 3 vs 4, that's more an argument to hire you than for a company watching the bottom-line hard enough that they'll jump to another DB solution.
"The business world existed and got along quite nicely with paper records for quite some time. Paper records got lost all the time and business went along nicely. The same can be said today, if we were to lose 8-24 hours worth of data it would be bad, but not catastrophic. Insurance against such an even would probably cost a hell of a lot less than Oracle licensing."
Uh, no it can not. The world back then isn't the same world now, and applying outdated metrics is being disingenuous. There's also some things that insurance will never mend.
"Not every database needs to be 12TB and accessible by 2 million users 24/7."
No, not every, but you'll find that those who need a Oracle calibar solution, also have big databases and need them 24/7.
"The implicit argument for Oracle is that cost is no matter. Well then, I suggest you hire 12 people to each independently carve your data into stone as data loss there would be minimal."
Um no. The implicit argument is that when you have business requirements that require something of Oracle's calibar, then that's going to cost.
You'll see a decline when someone comes out with comparable offers, at a lower cost. And so far there aren't that many.
...if it is done well. I don't remember exact details, my ex-coworker was doing a PhD thesis on distributed databases. The idea is that each of the databases executes a part of the query, and results are merged. If it is possible to do that, then performance increases. Especialy with complex queries with subqueries and etc. I don't know how much brain you have to put into query engine that distributes the load, and how to merge the results though. Lots if area to expore here.
Oh, and I also agree that JDBC driver layer is not the right place to do clustering. I wish there were e.g. subprojects of PostgreSQL working on this issue.
--Coder
Good starting block though...
.... partition of the main database.
First, they should move more and more features of the DB to the controller layer. The goal should be that you can call plain SQL statements and complex joins directly. Later, you could even have stored procedures execute there and use the cluster as if it were one db.
Then, they should try and work it so that you make low level calls to the DB layer, this would save time in having the seperate DBs compile the SQL statements.
Next, make some kernal mods ala Tux to make the DB calls faster to execute, ie make the DB machines pure DB handlers.
Once you do that, you might want to consider moving the seperate dbs into one rack, maybe making them share power supplies, disk arrays to cut down the points of failure.
As well, have one handler computer handle all incoming connections which would appear to be a stand alone Database. Thus every database instance would apear to be a
It would be powerful to separate the hardware/database tie to allow the Admin to manage which servers would have which partitions, letting them span a partition accross a new server if it got too big. And let the partitions automatically move away from bad servers using parity information stored on a seperate server.
Once you finish developing all that... you should realize that's what Oracle already does. Oracle isn't some MIcrosoftish company that developed a product absent any competition so quailty, reliability and performance wasn't job #1. Oracle has long competed against IBM, Sybase, Microsoft etc and pretty much has the DB thing down.
The only use I could see for this tech, is in a small ecommerce web site that needed to search millions of records (electronics supply store). This would be for when a MYSQL table would start to bog down due to too many records. Even then, having multiple machines should be the very last resort.
Take it up to the next level and make that connector p2p based using JXTA and autodiscovery
to handle all the traffic.
Now that would be COOL!
Got Code?
I wrote a jdbc wrapper that allowed me to use multiple jdbc drivers simultaneously. This seems ver y very similar. The load balancing was nice. But the replication really fely like it should be down at the db level, and not at the driver level. Syncing to databases after one went down was a pain.
Spliting up tables across db's seems a little rough, esp since you have to run the query on more than one db and then merge the results into a single result set. This means that you have to do your own sort. It gets even more fun if you use limit and offset in your query. It just gets wierd after a while. I say wait for postgres-R, it'll be much more of a kick in the pants for Oracle.
Ok, how about a couple of real-world examples?
#1 - how do you deal with data that spans partitions? Ex: a customer database is partitioned by geographic location, but inventory applies across all partitions. How do you keep this unique and replicated across partitions? Or - do you decide to leave it on just a single partition, and then have all other partitions join to it when they need that data.
#2 - how do you deal with queries across all partitions? Ex: ok, how many widgets were sold this month, totaled by geographic location. Do you run the query on each box then pull 50 state-level result sets together into a single one? Or does the application aggregate them (oh boy).
#3 - how do you handle changes to partition size over time? So what do you do when you want to consolidate a handful of small states (Wy, Ne, ND, SD, HA, etc) onto a single server, and then distribute CA across the freed-up six servers.
These are typical issues that come up all the time in a share-nothing environment. And for which DB2, Informix, and Teradata has very specific features to assist with rebalancing, localization, etc.
Delivery of this function without addressing these tough features simply results in a poor product - that can't compete with these commecial alternatives.
Okay, so I am supposed to believe that this software is better at being ACID than almost all relational database systems?
Sure, I love clustering boxes as much as the next guy, but the overhead is tremendous if the rdbms doesn't support it, let alone the data integrity questions it brings up.
There are many problems with this design, some have already been mentioned. There are serious issues with performing atomic updates. Modern databases use locking to allow high levels of concurrency. Foreign key constraint checking is one thing that would be very hard to implement in this design, as it is generally implemented in the indexes themselves. Likewise, to get all databases in a "RAIDb 0" group to reflect the same state, operations such as concurrent delete and insert must be completely serialized to assure consistency...serialized across all clients, not just from one source.
Furthermore, to scale up systems generally take advantage of stripping. At the IO level that means striping across multiple disks (modern convention is to stripe across all!). In a parallel database one usually stripes a single table across multiple nodes for parallel query processing. While it is possible with C_JDBC to put table X on node A, table Y on node B I don't see any provision for striping the data. It will be very difficult to use your hardware efficiently in this scenario.
If you are going to go through the trouble of implementing a complete query processor (that can handle jobs larger than ram), a full update/query scheduler (lock manager), and a journalling mechanism that can (somehow) even maintain atomic transactions (even in the face of multiple failures) then why not just build your own database. This system might be useful in certain rare cases but I wouldn't use it except possibly for replication.
JJ
can one of the nodes be shut off without loss of any data? if not, it isnt a clustered database.
can ms sql server drop a node in it's 'clusters' without losing any data? if not, it isnt a cluster, just a distributed / 'federated' database.
Ok... you lost me. Are you still talking about MySQL, or what are you talking about?
-1 Uncomfortable Truth
If a node with a guest task crashes in mosix, the task is re-dispatched to another node; it doesn't crash.
Only if the originating node crashes does the task fail. So if there is one master node in your cluster, your failure rate is the same as if you had one machine.
main difference between ops and rac is that ops used files for global lock management and rac does it in memory, iirc. rac works much better. You can try a demo on a single node. It's pretty cool to have multiple database instances but only a single database. You log into one db, perform some DML, then log into another db and there it is, instantly!
f.y.i: a cluster is a multi-node single database. You can lose one node without losing data, for example by sharing all data on a san.
A distributed database is a series of databases that are connected via the network. If you lose one node, you lose data.
a replicated database is a series of databases that have copies of data on multiple nodes. You can lose a node and potentially not lose data, but the overhead of replicating has performance and state limitations.
... as part of the closed-source project but the 19yr old asshole running the company did not recognize the potential.
Deploy your JDBC code inside a J2EE app server, whose default protocol is RMI-IIOP.
(JBoss for you open source zealots)
Hey presto, your non-java clients can access your code through CORBA!
You get transparent switchover for free with load balancing if your replication is good enough, and your load balancing is at least decent.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I was tested where(in Brazil) in work very well, i tried 3 machines with postgresql and work veeerryyy well...
For queries involving multiple tables, the database itself will be able to optimize better than any RAIDb controller. Full replication will always be better. Each individual db server has direct access to all tables and can formulate a good query plan.
The only situation where partial replication would speed things up would be a large number of write-intensive tables. I expect most apps would have one, two or possibly three write-intensive tables. I don't know if TPC-W is realistic.
For individuals and small businesses content with 99% uptime, a project like this is overkill. It's still interesting though.
The problem is that you need a lot of cooperation between the RDBMS and the host OS. It is very hard even for Oracle as they have to solve the problem for eash host OS that they support except for Oracle/RDB, which only supports OpenVMS and Tru64. Oracle/RDB was bought from Digital whilst iit was having financial problems. It was engineered to work well on Digital's cluster technology. Oracle attempoted to strip mine Oracle/RDB for the technology and the customers but this seem not to have worked. The technology was too specific to the OS and many of the customers didn't want to move.
What does this mean here. Well, with Linux we have OS source. We have the source code of MySQL and Postgress, so it would be relatively easy to build some cluster services into the OS and to build the support in to the RDMBS.
What Digital did was to build a cluster wide file-system, where storage could be attached to any node (or more than one node and would be served transparently to the rest of the cluster). For this, you needed a distributed lock manager to synchronize access.. This is also pretty vital for the relational database management system and Digital created an OS level 2PC service as well, again kernel integration helped speed up the prepare-to-commit/commit type transactions. Fast cluster comms are also useful, but these alreadz exist for Linux from a number of vendors.
It *will* happen for the opensource databases, people have the sources and eventually because of the ability to integrate the kernel support, it will probably work better than with 3P databases.
See my journal, I write things there
I wrote a nastier response to the first comment like this, but since you used polite terms, I will also.
In my original post I indicated that clusters are "typically" used for avaliability and not perfomance; this doesn't mean you can't use a cluster for performance, it just means that most clusters are put in place primarilly for the avaliability functionality and performance is a secondary concern if one at all.
This is evidenced by the most prominent clustering software avaliable for databases. Both Microsoft and Oracle provide an avaliability-enhancing cluster software (MSCS for microsoft and Oracles is called Fail Safe if I remember correctly) as a standard component of the database servers, and only Oracles Paralell Server (an expensive add-on) will enhance PERFORMANCE through clustering.
I guess my point wasn't to say you CAN'T enhance performance through clustering, it just not the primary motivation for most of the clustering that I've seen.
second society
Personally, I expect we'll see folks abandon oracle when the process of moving applications from Oracle to Postgress is VERY seemless for at least some class of application.