Hello I have a class UserTrace with 2 fields, an Id and a LinkList. The linklist field has around 200 references to documents of different classes. For example one document in the class UserTrace looks like:
<https://lh3.googleusercontent.com/-cxiIv0LkOcY/V09rJHdZh1I/AAAAAAAAEaM/bpYAbktpVScpHj4f2WhnEYS6em073wfBACLcB/s1600/Screenshot%2Bfrom%2B2016-06-01%2B16%253A06%253A18.png> I would like to recover all (or a number) of documents on UserTrace with the references in the linklist field exploded. I do not want to recover #173:0 but the object of class TraceTravel living in cluster #173. Same with all the elements of the linklist. Each class has 4 cluster assigned (because server is a quadcore). so I execute queries like the list below using java API on OrientDb 2.1.15 and 2.1.19. Database is remote with 8gb of heap running in a quadcore and client has 2gb of heap. When the number of elements is big, it takes a lot of time to recover each document. Example: when I recover 1000 docs, it takes 1.97 milliseconds to recover each one, but if I try to recover 5000, then 13.81 milliseconds are needed for each document. Is it possible to improve the performance at least to have lineal times? For example 3 milliseconds to load each document with limit 1000, 10000, 10000000? Using any combination of PARALLEL and FETCHPLAN has not effect. *select from UserTrace limit ${limit} fetchplan *:-1* Retrieve 1 documents in 36 millis 36.00 millis/record Retrieve 10 documents in 69 millis 6.90 millis/record Retrieve 100 documents in 256 millis 2.56 millis/record Retrieve 1000 documents in 1970 millis 1.97 millis/record why time jumped from 1.97 to 18.19 millis? Retrieve 2000 documents in 36385 millis 18.19 millis/record Retrieve 5000 documents in 69031 millis 13.81 millis/record *select from UserTrace limit ${limit} fetchplan *:-1* Retrieve 5000 records in 98997 millis 19.80 millis/record Retrieve 2000 records in 34128 millis 17.06 millis/record Retrieve 1000 records in 2211 millis 2.21 millis/record Retrieve 100 records in 220 millis 2.20 millis/record Retrieve 100 records in 218 millis 2.18 millis/record Retrieve 10 records in 25 millis 2.50 millis/record Retrieve 1 records in 4 millis 4.00 millis/record *SELECT * FROM UserTrace limit $n* Retrieved 1 documents in 25 millis 25.00 millis/record Retrieved 10 documents in 277 millis 27.70 millis/record Retrieved 100 documents in 287 millis 2.87 millis/record Retrieved 100 documents in 232 millis 2.32 millis/record Retrieved 1000 documents in 7097 millis 7.10 millis/record Retrieved 10000 documents in 202104 millis 20.21 millis/record *SELECT * FROM UserTrace limit $n fetchplan *:-1* Retrieved 1 documents in 39 millis 39.00 millis/record Retrieved 10 documents in 168 millis 16.80 millis/record Retrieved 100 documents in 262 millis 2.62 millis/record Retrieved 100 documents in 229 millis 2.29 millis/record Retrieved 1000 documents in 18448 millis 18.45 millis/record *SELECT * FROM UserTrace limit $n fetchplan *:-1 parallel* Retrieved 1 documents in 40 millis 40.00 millis/record Retrieved 10 documents in 372 millis 37.20 millis/record Retrieved 100 documents in 279 millis 2.79 millis/record Retrieved 100 documents in 222 millis 2.22 millis/record Retrieved 1000 documents in 17230 millis 17.23 millis/record Retrieved 10000 documents in 195747 millis 19.57 millis/record *SELECT * FROM UserTrace limit $n parallel* Retrieved 1 documents in 34 millis 34.00 millis/record Retrieved 10 documents in 56 millis 5.60 millis/record Retrieved 100 documents in 664 millis 6.64 millis/record Retrieved 100 documents in 202 millis 2.02 millis/record Retrieved 1000 documents in 15727 millis 15.73 millis/record Retrieved 10000 documents in 188009 millis 18.80 millis/record -- --- 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.
