Hi,
I think there is a misunderstanding:
My problem occurs in EMBEDDED mode, when I do 8000 UPDATES within a
TRANSACTION using the DOCUMENT API.
The save()s are performed in a reasonable amount of time (around 2-3 secs.).
But when the COMMIT is performed, it takes between 3 and 20 seconds
I am able to do 2 vertex per second but its in inmemory db , Dont know
how I can use this inmemory data from the class to the downstream system?
when I am doing a select to the class to which the ETL json loaded the data
it shows 0 records.
+ extracted 996,523 rows (20,043 rows/sec) -
Also, there used to be a bug, not sure if it's still present, but if you
dropped data from a table it would make the database run real slow
thereafter. Try running your insert on a freshly created database. Then
drop some data, run it again.
On Wednesday, February 18, 2015 at 10:14:37 PM
Hi Simon,
Thanks for the feedback.
My e-mail address is: markus.men...@axxelia.com
The thing that worries me, is the fact that the times are inconsistent.
Sometimes the commit takes 2-3 secs, sometimes around 20secs.
Also, during the commit, other DB accesses seem to wait until it's
Hello, we find that we can do 15,000 in 6 seconds or so, the orientdb guys
were able to get it down to 2-3 seconds. If you've got an email address I
can forward you their code perhaps tease apart how they did it. Also, if
you've got a quorum of 2 then obviously it has to wait for the 2nd one to
Any idea anybody?
Thanks,
Markus
--
---
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 orient-database+unsubscr...@googlegroups.com.
For more options, visit
This is by the way the structure of the class:
Class: Schedule
Default cluster..: schedule (id=16)
Supported cluster ids: [16]
Cluster selection: round-robin
PROPERTIES
