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

Re: possible ozone 0.6 bug?

On Thu, 11 Jan 2001, Steve Tinney wrote:
> Jeff Kowalczyk wrote:
> > 
> > > > I am getting pessimistic about loading my 15Mb of
> > > > botanical descriptions in Ozone on my 64Mb Linux machine.
> > > 64Mb is probably not enough. Do you really need all
> > > the data in one XML document?
> > 
> > ...
> > If you have 10K contact items in one doc, and a separate xml document for
> > their appointments and a third for to-do assignments, how well is Ozone
> > going to handle joined XPath queries? One sees ref/id techniques, but is the
> > Ozone DOM going to support that? It seems like DOM Level2 stuff.
> > 
> > It almost seems like we need to know what's in the future for XQL or
> > something equivalent before we can really know what a 'relational' select in
> > multiple XML docs will practical. Ozone's potential seems directly tied to a
> > way to work with multiple xml docs.

There are several very tricky problems with ozoneXML. Basically, with ozone we
wanted to provide a way to work with inherently persistent Java objects. To be
really useful this needs a transactional environment. Both, "persistent" and
"transactional" sounds like "database". So ozone was called an OODBMS. In fact
there are huge differences between "traditionally" database systems, like
RDBMSs, and ozone. One is that RDBMSs are designed to search in huge amounts of
uniform data that are stored on the disk. ozone is a runtime environment for
objects and does not care that much about the organization of the data on disk.

Now there is XML. Since there is an object model for it ozone is able to handle
XML data. But ozone is still not able to search in huge amounts of XML data
on disk PER SE! Some additional software has to add these features.

Just to bring the whole picture into the discussion ;) It seems that history
and background of ozone are very important for all those ozone/XML related
discussions.

> 
> I think it is Prowler that answers the issues raised here (please
> correct me if I am wrong, someone).

Yes, I'm in the same opinion.

> 
> Prowler provides the means to integrate arbitrary numbers of individual
> XML files under a single document root.  So, you can have a single
> superdocument that is composed of many individual XML documents.  This
> superdocument can be queried using XPath (and eventually I expect XQL)
> as if it were a single organic unit.
> 
> A frequent confusion is between document size and database size. 
> Loading a single 15MB document may stress a machine's memory, but the
> quantity of data does not necessary stress Ozone or Prowler as
> database/content management systems.   A document that large probably
> has natural divisions (perhaps thousands of descriptions, each of them
> relatively small).  Lots of XML data fits that profile.  The solution is
> simply to split the data up into thousands of files, and load them into
> Prowler.  Some file systems (e.g., Linux's ReiserFS) are designed to
> deal efficiently with hundreds of thousands of small files,
> incidentally.
> 
>  Steve


Falko
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com