Hi Andrey, I'm totally agree with you, it's not a benchmark, moreover it's a real test case either. What I'm trying to do is 1. Get skills to work with particular DB. With Orient in this case. 2. To compare it with others, doing the same things with all of them.
I forgot to mention, but I was really looking for an optimal number of documents to commit (definitely 1000000 docs are way to many). Depending on my results it's about 25K docs per commit. Also, 500000 edges between 2 vertices doesn't look like real world, but I warned about it when posted my results. It's just the easiest way to implement it :) My next goal to try it with indices and in a distributed mode (as soon as you'll respond my posts regarding issues with distributed mode). I would love to see your performance test project. However, I don't really understand the concept of vertices without properties? Could you please explain how you store data there? Quick overlook of our use-case. We need a DB to handle 40K/sec insertion rate (Vertices and Edges). We need 2 properties for a Vertex and no properties for Edges, we can use different Classes for them. This insertion rate should be achievable in a distributed mode. We might have up to 40 nodes in cluster (I mean h/w cluster). On Sunday, February 9, 2014 2:27:19 PM UTC-5, Andrey Lomakin wrote: > > Hi Andrey, > I started benchmark on my side and while it is running I investigated it. > I think that I should note that this benchmark does not reproduce real > test cases (dunno what performance data you get on other DBs). > > I mean what this benchmark does. > Lets suppose that we have to insert 1 000 000 documents vertexes and edges. > Then it creates 500 000 vertexes and then takes 2 of them, and creates 500 > 000 edges between them. > And everything in one transaction. > > So we have graph database with 499 998 unconnected vertexes and 2 vertexes > which have 500 000 edges and everything is committed in single transaction. > Did I miss something ? > > I mean that I think you do not suppose users to commit such data structure > and commit it using single transaction. > Usually data structures are way different and changes are committed in > following way users load data, change them, commit them. > > It is my personal opinion but may be you will be interested in performance > test which loads real wikipedia data by loading and committing them by > small batches ? > Also this tests uses index which is very typical for db usage. > > We used such test case so I can change and publish it as maven project and > because it is tinkerpop based you can test all dbs which you are interested > in. > Our load test does not have properties on vertexes only relations and > index by page key,but it is simple to add additional properties. > > What do you think ? > > > > On Sun, Feb 9, 2014 at 5:59 PM, Andrey Yesyev > <[email protected]<javascript:> > > wrote: > >> Please post your results! >> >> Again, any comments regarding source code are very welcome! >> >> >> On Sunday, February 9, 2014 10:50:34 AM UTC-5, Andrey Lomakin wrote: >> >>> Andrey, >>> I do not see any commits in project. https://github.com/ >>> ayesyev/graphdb-tests/commits/master >>> Did you push them ? >>> >>> >>> On Sun, Feb 9, 2014 at 5:47 PM, Andrey Lomakin <[email protected]>wrote: >>> >>>> Got it ! )) >>>> >>>> >>>> On Sun, Feb 9, 2014 at 5:44 PM, Andrey Lomakin <[email protected]>wrote: >>>> >>>>> Hi Andrey, >>>>> >>>>> Could you provide instructions how to run these tests to see statistic >>>>> results ? >>>>> >>>>> >>>>> On Sun, Feb 9, 2014 at 4:59 PM, Andrey Yesyev <[email protected]>wrote: >>>>> >>>>>> Ok, here we go! >>>>>> >>>>>> I added all Andrey's tips to the project. >>>>>> >>>>>> storage.diskCache.bufferSize set to 14336 >>>>>> >>>>>> All edges have appropriate number of properties and added this way >>>>>> >>>>>> protected OrientEdge createEdge(Vertex v1, Vertex v2) { >>>>>> Map<String, String> properties = new HashMap<String, >>>>>> String>(); >>>>>> for (int i = 0; i < numberOfProperties; i++) >>>>>> properties.put("property" + i, "value" + i); >>>>>> OrientEdge e = ((OrientVertex)v1).addEdge(null, >>>>>> (OrientVertex)v2, "E", null, properties); >>>>>> e.save(); >>>>>> >>>>>> return e; >>>>>> } >>>>>> >>>>>> Results are attached for remote and embedded (both using plocal >>>>>> storage type). >>>>>> On Monday I'll try to make my conclusions. >>>>>> >>>>>> All changes are committed to github project. >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> --- >>>>>> 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/groups/opt_out. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Andrey Lomakin. >>>>> >>>>> Orient Technologies >>>>> the Company behind OrientDB >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Andrey Lomakin. >>>> >>>> Orient Technologies >>>> the Company behind OrientDB >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Andrey Lomakin. >>> >>> Orient Technologies >>> the Company behind OrientDB >>> >>> -- >> >> --- >> 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] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > Best regards, > Andrey Lomakin. > > Orient Technologies > the Company behind OrientDB > > -- --- 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/groups/opt_out.
