[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: Fw: Ozone and XPATH
On Fri, 23 Feb 2001, you wrote:
> Hi Falko,
> > ozone supports XPath. It employs third party packages like Xt or Xalan for
> > that. The default is Xt which is included in CVS. Xt is pretty
> > fast. If the
> > working set of data fits in memory, then Xt works on persistent
> > DOM (ozone)
> > nearly as fast as on transient DOM.
> > The is the drawback of the current architecture of ozone/XML.
> > Which is very
> > flexible and works with each products that uses DOM (Xt, Xalan,
> > SAXON, ...) but
> > on the other hand need enough memory to hold the working set of
> > data in memory.
> So the important thing is, that everything should be in Memory. That`s no
> problem since the rules for the Content Management part could sort out
> the articles i (eh, some script) wish to check out.
> So, could i build a smaller working set of the overall database on the fly
> The system`s rules could easily get the Article IDs (all Download-News for
> last 29 Days or so). Would that ID list be suitable to build a working set?
The problem is not to _identify_ the working set of data. ozones LRU cache and
cluster management automatically finds out about the LRU data and keeps it in
the cache. But the problem is to actually get the data in memory (which means
building the highly structured object graph of a DOM from the flat serialized
form on disk)
> The main question is, if it makes sense in these days to store XML data
> in the file system (which is fast if you`re using RAID and/or Reiser FS)
> and parse the content from there or if it is a better solution to use a
> suitable database. Ozone seems to be suitable.
Basically ozone/XML provides two things over the filesystem solution:
- management of concurrent access to the same data (locks, transactions)
- transactions ("do ot all or nothing")
- management of an in-memory cache od last rcently used data (DOM nodes)
> Another solution is to use a database like mySQL as "structured main memory"
> and then let the parser look into a text field of the database.
> I do not like to start a flame war here. There are good reasons to follow
> path and i guess i would have to check them all out to be sure.
I definitely agree. All solutions have advantages and disadvantages. Please
keep us posted about the findings of your tests!
Falko Braeutigam mailto:email@example.com
SMB GmbH http://www.smb-tec.com