Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Database Clusters for the Masses

Posted by michael on Wed Apr 30, 2003 10:15 AM
from the no-slashdot-isn't-using-it dept.
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."
This discussion has been archived. No new comments can be posted.
Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • WOOHOO! (Score:2, Funny)

    by semifamous (231316) on Wednesday April 30 2003, @10:16AM (#5843210)
    (http://www.semifamous.com/)
    Wow! Can you imagine a beowulf.... oh, wait, nevermind
    • Re:WOOHOO! by phrantic (Score:2) Wednesday April 30 2003, @11:01AM
    • 1 reply beneath your current threshold.
  • Non-Java Implementations? (Score:5, Interesting)

    by the_quark (101253) * on Wednesday April 30 2003, @10:19AM (#5843247)
    (http://slashdot.org/)
    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?
  • hmmm (Score:4, Interesting)

    by the_2nd_coming (444906) on Wednesday April 30 2003, @10:20AM (#5843269)
    (http://slashdot.org/)
    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
    • Re:hmmm by zsmooth (Score:2) Wednesday April 30 2003, @10:58AM
    • Re:hmmm by poot_rootbeer (Score:2) Wednesday April 30 2003, @11:44AM
      • Re:hmmm by quantum bit (Score:2) Wednesday April 30 2003, @01:31PM
        • Re:hmmm by leandrod (Score:2) Wednesday April 30 2003, @02:08PM
          • Re:hmmm by quantum bit (Score:1) Wednesday April 30 2003, @03:09PM
            • Re:hmmm by leandrod (Score:2) Thursday May 01 2003, @12:31PM
    • Re:hmmm by Sxooter (Score:3) Wednesday April 30 2003, @12:37PM
      • 1 reply beneath your current threshold.
    • 1 reply beneath your current threshold.
  • If only replicaton was so trivial (Score:4, Insightful)

    by marcink1234 (556931) on Wednesday April 30 2003, @10:22AM (#5843283)
    (http://www.mk.w.pl/)

    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...

  • Performance? (Score:5, Interesting)

    by deranged unix nut (20524) on Wednesday April 30 2003, @10:22AM (#5843289)
    (http://www.zserf.com/)
    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...
  • Quick thru the docs... (Score:5, Informative)

    by Lysol (11150) * on Wednesday April 30 2003, @10:28AM (#5843345)
    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.
  • 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.
  • by a7244270 (592043) on Wednesday April 30 2003, @10:31AM (#5843383)
    (http://www.red82.com/ | Last Journal: Monday April 19 2004, @11:00AM)
    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.
  • How about a meta-database adapter? (Score:5, Interesting)

    by Frater 219 (1455) on Wednesday April 30 2003, @10:35AM (#5843424)
    (Last Journal: Saturday January 29 2005, @08:51PM)
    Since the article suggests the idea of applying disk-volume concepts (RAID) to databases, I thought I'd bring this up: For a while now I've been wishing there was an equivalent of NFS for databases, a way to mount a running database's tablespace into another database. This would allow one to draw together disparate databases, creating views and running joins across tables which natively reside in different databases, on different hosts.

    Here's an example of an application: I have a database-driven Web application [slashdot.org] 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.

  • More info on transactions (Score:4, Interesting)

    by binaryDigit (557647) on Wednesday April 30 2003, @10:38AM (#5843459)
    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? (Score:2, Insightful)

    by Anonymous Coward on Wednesday April 30 2003, @10:41AM (#5843474)
    Why do masses need database clusters? Does anyone apart from mid-large sized businesses need one?
    • Re:Why? by AlecC (Score:2) Wednesday April 30 2003, @11:23AM
      • 1 reply beneath your current threshold.
    • Re:Why? by grugruto (Score:2) Wednesday April 30 2003, @11:51AM
      • 1 reply beneath your current threshold.
    • Re:Why? by sharkey (Score:2) Thursday May 01 2003, @09:02AM
    • Masses don't need it by brlewis (Score:2) Thursday May 01 2003, @09:32AM
  • supposed to be at RDMS level (Score:5, Insightful)

    by Arethan (223197) on Wednesday April 30 2003, @10:44AM (#5843509)
    (Last Journal: Thursday August 23 2001, @09:23PM)
    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.
  • "Shared-Nothing Architecture" (Score:2, Insightful)

    by Anonymous Coward on Wednesday April 30 2003, @10:45AM (#5843520)
    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...
  • Slightly Offtopic.... (Score:3, Insightful)

    by frodo from middle ea (602941) on Wednesday April 30 2003, @10:45AM (#5843526)
    (http://aol.com/)
    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.
  • by snatchitup (466222) on Wednesday April 30 2003, @10:46AM (#5843541)
    (http://www.babe-test.com/ | Last Journal: Wednesday September 17 2003, @11:59AM)
    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.

  • ...does it mean that their db really works? (at least, until now..)
  • by trajano (220061) on Wednesday April 30 2003, @10:53AM (#5843622)
    (http://www.trajano.net/ | Last Journal: Thursday April 15 2004, @02:17AM)
    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.
  • by t0ny (590331) on Wednesday April 30 2003, @10:57AM (#5843657)
    Cluster of databases is no more the privilege of few high-end commercial databases, open-source solutions are striking back!

    Finally, my grandmother can have that database cluster she has been bugging me about.

  • Also new! (Score:5, Funny)

    by Dark Lord Seth (584963) on Wednesday April 30 2003, @11:06AM (#5843738)
    (Last Journal: Monday November 08 2004, @10:00AM)

    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.

    • Re:Also new! by Trygvis (Score:1) Thursday May 01 2003, @06:18AM
    • Re:Also new! by sharkey (Score:2) Thursday May 01 2003, @08:50AM
  • Limitations (Score:1, Insightful)

    by Anonymous Coward on Wednesday April 30 2003, @11:22AM (#5843925)
    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.
  • Fine-grained caching question (Score:2, Interesting)

    by code_nerd (37853) on Wednesday April 30 2003, @11:23AM (#5843936)
    The user's guide page says this about caching:

    8.7.2. Request cache

    The query cache provides query result caching. If two exact same requests are to be executed, only one is executed and the second one waits until the completion of the first one (this is the default pendingTimeout value which is 0). To prevent the second request to wait forever, a pendingTimeout value in seconds can be defined for the waiting request. If the timeout expires the request is executed in parallel of the first one.

    A request cache element is described as follows:

    The request cache granularity defines how entries are removed from the cache. noInvalidation provides a non-coherent cache and should only be used for testing purposes. table and column provide table-based and column-based invalidations, respectively. columnUnique can optimize requests that select a unique primary key (useful with EJB entity beans).

    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?
  • by FearUncertaintyDoubt (578295) on Wednesday April 30 2003, @11:36AM (#5844093)
    We've been using a similar idea for years. It's pretty much using "scaling out" with some application logic to make it useful for high-availability purposes. At one time, we had 13 subscriber databases (MS SQL 6.5) throughout the world, using transactional replication to keep them in sync. A small bit of logic in the front-end determined which server a user would connect to. In this way we could point users at the server geographically closest to them (which was configurable in a database itself).

    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.

  • by g4dget (579145) on Wednesday April 30 2003, @11:39AM (#5844127)
    C-JDBC is an open-source software that implements a new concept called RAIDb (Redundant Array of Inexpensive Databases).

    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).

  • Thorough rundown (Score:5, Informative)

    by photon317 (208409) on Wednesday April 30 2003, @11:47AM (#5844218)

    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.
  • 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.
  • by munro (265830) on Wednesday April 30 2003, @12:39PM (#5844782)
    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.
  • Not there yet... (Score:2, Insightful)

    by jfroebe (10351) on Wednesday April 30 2003, @01:00PM (#5845037)
    (http://jfroebe.livejournal.com/)
    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
  • by Jboy_24 (88864) on Wednesday April 30 2003, @01:48PM (#5845662)
    (http://www.cafepress.com/chpwn)
    Good starting block though...

    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 .... partition of the main database.

    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!

  • overrated (Score:1)

    by bobaferret (513897) on Wednesday April 30 2003, @02:27PM (#5846147)
    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.
  • ACID? (Score:1)

    by winchester (265873) on Wednesday April 30 2003, @03:41PM (#5847186)
    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.
  • I wouldn't get too excited (Score:3, Informative)

    by godofredo (198906) on Wednesday April 30 2003, @04:21PM (#5847683)
    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
  • by troy_psx (639235) on Thursday May 01 2003, @06:50AM (#5851406)
    I was tested where(in Brazil) in work very well, i tried 3 machines with postgresql and work veeerryyy well...
  • Re:Nothing beats Oracle RAC (Score:1, Funny)

    by Anonymous Coward on Wednesday April 30 2003, @10:22AM (#5843281)
    Is RAC the new name for OPS? If now how do they differ?
    [ Parent ]
  • Re:That's nice... (Score:1)

    by Usquebaugh (230216) on Wednesday April 30 2003, @10:39AM (#5843467)
    No,
    a beowulf will just allow you to disperese workload. Either at the process or at the thread with MOSIX.

    In fact a HPC like MOSIX can result in reduced uptimes. If a machine has a 1% failure rate then what is the failure rate of 100 machines in parrallel?

    The question all boils down to how granular your recovery process is. For a desktop you need very fine granularity and few current systems provide this. I think Tandem provides this by using special hardware and kernel patches for NT.
    [ Parent ]
    • Re:That's nice... by the_2nd_coming (Score:1) Wednesday April 30 2003, @10:47AM
    • Nope. by mindstrm (Score:1) Wednesday April 30 2003, @06:06PM
      • Re:Nope. by Usquebaugh (Score:2) Wednesday April 30 2003, @09:26PM
    • 1 reply beneath your current threshold.
  • Re:I'm 100% Confident (Score:2, Informative)

    by grugruto (530141) on Wednesday April 30 2003, @10:42AM (#5843488)
    (http://www.objectweb.org/)
    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!
    [ Parent ]
  • Re:Hehehe... (Score:1)

    by Anonymous Coward on Wednesday April 30 2003, @10:45AM (#5843525)
    Perl Bigot
    + Clueless
    --------------
    Script Kiddy

    How did this post ever even get a score of 2?
    [ Parent ]
  • Re:Hehehe... (Score:2, Funny)

    by mobiGeek (201274) on Wednesday April 30 2003, @10:46AM (#5843536)
    MySQL - not a database
    Your comments - Not a post

    *laughter*

    [ Parent ]
  • Re:Hehehe... (Score:1)

    by Anonymous Coward on Wednesday April 30 2003, @11:09AM (#5843782)
    ::clearing tears away from eyes::

    That was a great post. Good stuff.
    [ Parent ]
  • 12 replies beneath your current threshold.