[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

scaling object databases

Can anyone on this list give me a coherent explanation (or pointer to same)
of how the process of designing for scalability differs in the ODB paradigm
from the RDB paradigm? Network setup, clustering servers, that sort of stuff
as opposed to writing the code efficiently.

I was talking today -- in my day job incarnation -- to a rep and a
technician from ObjectDesign (www.objectdesign.com, obnoxious flash) about
their ObjectStore ODB. I was attempting to get some sort of a handle on the
differences between it, Castor and Ozone insofar as designing a high-traffic
system goes & they and their white papers weren't being too clear. They had
never heard of Castor, and I had never heard of the persistance layer-like
proprietary code they were holding up as an example of type. Just different
worlds, I guess :)

I have some ground-level ideas on how to implement master-slave replication
in Ozone; a question would be whether it is sensible to tackle that sort of
problem at this stage in Ozone development when I need a product in six
months. Is Ozone stable enough in a high-traffic environment to make it
worthwhile instituting mySQL-style pyramid master-slave clusters of Ozone
servers (or similar)? I'd rather end up with a better Ozone -- or other open
source ODB of choice in which I get the speed of putting the business logic
inside the server -- than either a) paying for proprietary code that does
the job right now, or b) implementing a persistance layer that translates to
SQL. I'd like to hear thoughts on the realism of such a project from
existing developers, however...