Hello all

Using OrientDB 2.1.5, although this is probably unrelated to any version.

While designing my data model to make use of OrientDB's document model, I 
am conflicted between employing two alternative strategies for record 
retrieval. For me, read times are quite critical and I am trying to design 
the model for best read performance. I am required to fetch records 
individually and perform analytics against each of them. Each record is 
identified using a combination of three (potentially more) columns in the 
cluster (say userID, type of record, date and potentially more). I have 
these two options to do so:

1. Use the traditional way of employing a composite index on combination of 
these parameters on this cluster. This seems fairly straightforward.

2. Use Record IDs maps. I can keep track of each record's RID using a 
network of maps using separate document structures. I can traverse such map 
to reach any particular record using query parameters. Say

For each userID in the user cluster, I maintain a field that keeps the RID 
of associated record_type.
Each record_type record, keeps track of the RID of the nominated dates.
Each date record, keeps track of the RID of the final record.

As you can see, this creates a tree-branch sort of network. This also 
means, I will have to keep creating this map structure for each record that 
is created but I am happy to do so if this approach can speed up my read 
performance by any reasonable degree.  

Does anyone have experience using the second approach. In general, is 
fetching using RID any faster than using indexes. Any difference is seek 
times gets multiplied in my case as the number of reads are pretty high.

Finally, this probably is better done using a graph schema but 
unfortunately I do not possess the skills nor the resources to employ a 
graph schema.

thanks

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to