No, things are not failing, it is just that in big insertion scenarios the index lookup when joining nodes together into relationships, there is often just an exact index needed in order to do that. We have good experiences with Lucene, but when importing e.g. big OpenStreetMap datasets, we need to run lookups during insertion, and we experience Lucene taking a lot of time in these cases.
That is why I think exact lookups, like K/V stores, would be interesting in these scenarios, as an alternative. They _should_ perform better then Lucene. Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://startupbootcamp.org/ - Öresund - Innovation happens HERE. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Fri, Mar 11, 2011 at 10:27 AM, Massimo Lusetti <mluse...@gmail.com> wrote: > On Fri, Mar 11, 2011 at 10:12 AM, Peter Neubauer > <peter.neuba...@neotechnology.com> wrote: > >> Nice Ashwin, >> sounds like a great ac, will definitily keep track of it. If I do a >> Neo4j Index provider for JDBM2, would you be able to help me to tweak >> it to behave good? > > Did it really fail Lucene with big index? I got Lucene index with > millions of entries and it run smoothly... I'm talking of "pure" > Lucene's index not the Neo4j implementation. > > In fact I got issues with Lucene index within Neo4j and as soon as I > started to use an external managed index (Chenillekit Lucene module) I > got no issue with big index. > > Curious about this thread. > > Cheers > -- > Massimo > http://meridio.blogspot.com > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
