On 7/23/07, Emil Eifrem <[EMAIL PROTECTED]> wrote:
When it comes to range queries, wildcard matching and full text
searches across data sets with reasonably large (several kilobytes)
individual textual records, then lucene is the way to go. But if you
want to resolve one property value (using *equality match*, not
substring, range, wildcards, etc) to exactly one node, we've had
better overall performance numbers with a specialized b-tree.
(We've actually experimented lately with building a balanced tree
utility on top of Neo. This would allow us to solve the "exact
property lookup" problem in a general way without resorting to an
auxiliary structure. Johan may be able to elaborate more on that.)
Sounds very interesting and I'm sure many would settle for that
functionality. I agree that more than that is not necessary in the
"core"
But it seems like you want "search engine-like" features such as
stemming and wildcard and so on? Then integrating lucene would be the
way to go. In essence, you'd put the property values you want to be
able to full text search on in a lucene index along with the node id,
then use lucene to look up the node ids and embeddedNeo.getNodeById()
to get the nodes. Would that work?
That would definitely work. I guess that where I'm coming from (the
relational database world), people get caught up in stuff like indexes
and asks for it and it would be good to have a "this is how we would
solve that problem" howto. I think this could be good to have
mentioned in the later parts of the "Design with Neo" guide, or?
Regards
Klas
_______________________________________________
Neo mailing list
[email protected]
http://lists.neo4j.org/mailman/listinfo/user
