On Fri, Oct 16, 2009 at 2:25 PM, Rickard Öberg <[email protected]> wrote: > On 2009-10-16 12.25, Niclas Hedhman wrote: >> >> Isn't this the equivalent of "Loading Policy" in JDO/JPA ?? > > Pretty much, yes I think so. Except aren't those on structural rather than > usecase level? I.e. regardless of usecase "if you load property1 always load > property2,property3 at the same time".
IIRC, they are (or can be) established "per session". > I think there are two issues: one is the expense per lookup, and one is that > with more key->value mappings the database is going to be bigger, so will > consume more disk space. The indices will also be bigger and thus slower. Agree. Once this whole topic is picked into pieces there are probably a lot other factors surfacing. > What would be interesting is to have the store work on two levels: one is > the identity lookup, and then the next level would be property(/association) > lookup. If one index can have only identity lookup and another has the > per-property lookup, it should be much faster. Not totally sure what you mean here. Two-level index? > The remaining question is whether having only a id->blob mapping like today > is fine, or whether introducing extra fragmentation would be useful. I think we need to measure before having any conclusive opinion on what makes sense or not. But such performance testing is tedious and perhaps the "Delayed Property creation" is a reasonable first step, before we have effort available to do more elaborate things. >> I think it is a complex area, with room for significant speed >> improvements in large entities, but I also think that the answers will >> surprise us once we start measuring. > > Any hints on what the surprise might be? Well, for local stores there is the O/S that will pre-load buffers and stuff like that, so for benchmarking it may show that big blobs doesn't make a difference, because the O/S will manage to keep 500MB of data in OS-level caches. Such thing would not happen in network based ones, but there we have latency vs bandwidth to consider as well. But, it could be anything... Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
