Hi Mattias, thanks for the update. We are really struggling with this one, because we are at a performance with Neo4j at about 4 sec and a comparable query in a MariaDB SQL instance of 0.17 sec.
On Wednesday, 19 March 2014 14:32:28 UTC+1, Mattias Persson wrote: > > This issue has been fixed and will be included in the next milestone. > > 2014-03-08 19:29 GMT+01:00 Tom Zeppenfeldt <tomzepp...@gmail.com<javascript:> > >: > >> And yes.. it happens with other queries as well .. >> >> and query times are a lot longer then expected with a db of this size, >> although I indexed the crucial parts. >> >> neo4j-sh (?)$ schema >> >> Indexes >> ON :Person(id) ONLINE (for uniqueness constraint) >> ON :Term(id) ONLINE >> ON :instantie(id) ONLINE >> ON :jurt(jurt_id) ONLINE >> ON :rechter(id) ONLINE >> >> Constraints >> ON (person:Person) ASSERT person.id IS UNIQUE >> >> On Saturday, 8 March 2014 18:34:17 UTC+1, Michael Hunger wrote: >> >>> Hi Tom, >>> >>> does this happen with any database? I.e. imported by your load-csv >>> script? >>> >>> I asked my colleagues to look into it. Perhaps related to some changes >>> in the relationship-store in Neo4j 2.1 >>> >>> Do you see similar behavior also for other queries? >>> >>> Cheers, >>> >>> Michael >>> >>> ---- >>> (michael <http://twitter.com/mesirii>}-[:SUPPORTS]->(*YOU*)-[:USE]->( >>> Neo4j <http://neo4j.org>) >>> Learn Online <http://neo4j.org/learn/online_course>, >>> Offline<http://www.neo4j.org/events> or >>> Read a Book <http://graphdatabases.com> (in Deutsch<http://bit.ly/das-buch> >>> ) >>> We're trading T-shirts for cool GraphGist Models<http://bit.ly/graphgist> >>> >>> >>> >>> >>> >>> Am 07.03.2014 um 23:02 schrieb Tom Zeppenfeldt <tomzepp...@gmail.com>: >>> >>> I have a graph db with about 10000 docs (:jurt) and about 12000 terms >>> (t:Term) from a vocabulary. There are about 1.2M relationships of type >>> (j:jurt)-[:HAS_TERM]->(t:Term) >>> >>> To find out which documents are similar to a given document, based on a >>> count of common terms, I use this query >>> >>> match (j1:jurt)-[:HAS_TERM]->(t:Term)<-[:HAS_TERM]-(j2:jurt) >>> where NOT (id(j1)=id(j2)) AND j1.jurt_id = 'J75312' >>> with j1,j2,count(t) as commonterms >>> return j1.jurt_id,j2.jurt_id,commonterms >>> order by commonterms desc >>> limit 3 >>> >>> What I notice is that the first time the query is run, the results are >>> different from the next times... from the second time onwards, the results >>> are the same. In between, there are no other processes running.. >>> Whether I run the queries from the browser, the shell or the REST API, >>> they all show the same phenomenon. >>> >>> neo4j-sh (?)$ match (j1:jurt)-[:HAS_TERM]->(t:Term)<-[:HAS_TERM]-(j2:jurt) >>> where NOT (id(j1)=id(j2)) AND j1.jurt_id = 'J72887' with j1,j2,count(t) as >>> commonterms return j1.jurt_id,j2.jurt_id,commonterms order by >>> commonterms desc limit 3; >>> >>> +---------------------------------------+ >>> >>> | j1.jurt_id | j2.jurt_id | commonterms | >>> >>> +---------------------------------------+ >>> >>> | "J72887" | "J70059" | 226 | >>> >>> | "J72887" | "J75312" | 220 | >>> >>> | "J72887" | "J77444" | 215 | >>> >>> +---------------------------------------+ >>> >>> 3 rows >>> >>> 6288 ms >>> >>> neo4j-sh (?)$ match (j1:jurt)-[:HAS_TERM]->(t:Term)<-[:HAS_TERM]-(j2:jurt) >>> where NOT (id(j1)=id(j2)) AND j1.jurt_id = 'J72887' with j1,j2,count(t) as >>> commonterms return j1.jurt_id,j2.jurt_id,commonterms order by >>> commonterms desc limit 3; >>> >>> +---------------------------------------+ >>> >>> | j1.jurt_id | j2.jurt_id | commonterms | >>> >>> +---------------------------------------+ >>> >>> | "J72887" | "J70059" | 227 | >>> >>> | "J72887" | "J75312" | 220 | >>> >>> | "J72887" | "J77444" | 219 | >>> >>> +---------------------------------------+ >>> >>> 3 rows >>> >>> 6299 ms >>> >>> neo4j-sh (?)$ match (j1:jurt)-[:HAS_TERM]->(t:Term)<-[:HAS_TERM]-(j2:jurt) >>> where NOT (id(j1)=id(j2)) AND j1.jurt_id = 'J72887' with j1,j2,count(t) as >>> commonterms return j1.jurt_id,j2.jurt_id,commonterms order by >>> commonterms desc limit 3; >>> >>> +---------------------------------------+ >>> >>> | j1.jurt_id | j2.jurt_id | commonterms | >>> >>> +---------------------------------------+ >>> >>> | "J72887" | "J70059" | 227 | >>> >>> | "J72887" | "J75312" | 220 | >>> >>> | "J72887" | "J77444" | 219 | >>> >>> +---------------------------------------+ >>> >>> 3 rows >>> >>> 6354 ms >>> >>> neo4j-sh (?)$ match (j1:jurt)-[:HAS_TERM]->(t:Term)<-[:HAS_TERM]-(j2:jurt) >>> where NOT (id(j1)=id(j2)) AND j1.jurt_id = 'J72887' with j1,j2,count(t) as >>> commonterms return j1.jurt_id,j2.jurt_id,commonterms order by >>> commonterms desc limit 3; >>> >>> +---------------------------------------+ >>> >>> | j1.jurt_id | j2.jurt_id | commonterms | >>> >>> +---------------------------------------+ >>> >>> | "J72887" | "J70059" | 227 | >>> >>> | "J72887" | "J75312" | 220 | >>> >>> | "J72887" | "J77444" | 219 | >>> >>> +---------------------------------------+ >>> >>> 3 rows >>> >>> 6108 ms >>> >>> >>> What may cause this ? >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Neo4j" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to neo4j+un...@googlegroups.com. >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Neo4j" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to neo4j+un...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Mattias Persson, [mat...@neotechnology.com <javascript:>] > Hacker, Neo Technology > www.neotechnology.com > -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to neo4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
