Vineet Sinha wrote:
>
>>> This is probably indeed a limitation of the current native store -
>>> Arjohn can comment on this in more detail (I'll ask him about it as soon
>>> as he checks in today) as he designed the native store's indexes, but
>>> IIRC we limited the number and type of indexes in the native store to
>>> speed up upload, at the cost of bad performance on some query patterns
>>> (which were uncommon patterns in the use cases we had in mind for the
>>> native store).
>
>
> Jeen, if you can get me pointers in the code as to how to do this, I
> would be up for implementing it.
Class org.openrdf.sesame.sailimpl.nativerdf.TripleStore takes care of
storing and searching (subj,pred,obj) triples. At this level, the values
are represented by IDs (integers). Translating values to IDs and
vice-versa is done at a higher level so this is of no concern to you.
TripleStore currently has one on-disk B-Tree that it stores in a file
with the name "triples.dat". The triples are stored as arrays of 13
bytes: 3 x 4 bytes for subject, predicate and object, 1 byte for
additional flags. The last byte is currently used to store a flag that
indicates whether the triple is explicit. Because there are no
inferencers for the native sail yet, this flag is always true.
All of the above is reusable as-is for additional indexes. All that
matters is how the B-Tree compares/orders the values that are stored
in it. This can be controlled by a BTreeValueComparator. The current
SPO-index uses a comparator that compares the first 12 bytes in their
original order. An OPS-index can be realized by first comparing bytes
8-11, then bytes 4-7 and finally bytes 0-3. It's as simple as that!
(fingers crossed, we never tried this before :-) )
Please keep me posted on progress/findings/bugs. Feel free to ask if you
require more info.
--
Arjohn
PS: As your implementation will require more than one comparator now,
you might consider renaming the current inner class "TripleComparator"
to "SPOComparator".
Received on Wed Sep 07 2005 - 13:19:27 EDT