I agree with the comments. Graph model would have suited this use-case perfectly well but I was not in-favor of going far as this particular use-case is for the analytics portion of my solution alone. I was not willing to modify my data model to just suit the analytical workload requirement. Although, I am paranoid about the performance as this job can eat up quite a bit of server resources. I have decided to go with plain old indexing mechanism, turns out OrientDB's SB-TREE indexing can ease up the analytical burden quite a bit.
thanks a lot Chandra On Saturday, November 28, 2015 at 1:01:25 PM UTC+5:30, Chandra wrote: > > 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.
