A problem with a "probably dumb" index in a graph that I created for an experiment was the performance of getAllRelationships on that machine (it was a very large graph with all nodes being indexed).
It was a mapping from long values to nodes, my simplistic approach just chopped the long values into chunks of 3 digits and used those 3 digits as relationship-types (i.e. 1000 additional rel-types). to form a tree which pointed to the node in question at the end. Will have to investigate that further. Am 14.06.2011 um 23:43 schrieb Peter Neubauer: > Craig, > the autoindexing is one step in this direction. The other is to enable > the Spatial and other in-graph indexes like the graph-collections > (timeline etc) at all to be treated like normal index providers. When > that is done (will talk to Mattias who is coming back from vacation > tomorrow on that), we are in a position to think about more complex > autoindex providers. > > Also, the possibility to treat Neo4j Spatial and other graph > structures as index providers, would hook into the index framework and > expose things to higher level queries like Cypher and Gremlin, e.g. > combining a spatial bounding box geometry search with a graph > traversal for suitable properties that are less than 2 kilometers from > the nearest school, sorting the results, returning only price and lat > as columns, the 3 topmost hits. > > START geom = (index:spatial:'BBOX(the_geom, -90, 40, -60, 45)') > MATCH (geom)-->(fast), (fast)-[r, :NEAR]-(school) > WHERE fast.roooms>4 AND school.classes>4 AND r.length<2return > fast.pic?, fast.lon?, fast.lat? > SORT BY fast.price, fast.lat^ > SLICE 3 > > So, I think the next step is to make in-graph indexing structures plug > into the index framework, and then into autoindexing :) > > > 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 Tue, Jun 14, 2011 at 5:49 PM, Craig Taverner <cr...@amanzi.com> wrote: >> This is great news. >> >> Now I'm really curious about the next step, and that is allowing indexes >> other than lucene. For example, the RTree index in neo4j-spatial was never >> possible to wrap behind the normal index API, because that was designed only >> for properties of nodes (and relationships), but the RTree is based on >> something completely different (complete spatial geometries). However, the >> new auto-indexing feature implies that any node can be added to an index >> without the developer needing to know anything about the index API. Instead >> the index needs to know if the node is appropriate for indexing. This is >> suitable for both lucene and the RTree. >> >> So what I'd like to see is that when configuring auto-indexing in the first >> place, instead of just specifying properties to index, specify some indexer >> implementation that can be created and run internally. For example, perhaps >> you pass the classname of some class that implements some necessary >> interface, and then that is instantiated, passed config properties, and used >> to index new or modified nodes. One method I could imagine this interface >> having would be a listener for change events to be evaluated for whether or >> not the index should be activated for a node change. For the lucene property >> index, this method would return true if the property exists on that node. >> For the RTree this method would return true if the node contained the >> meta-data required for neo4j-spatial to recognize it as a spatial type? >> Alternatively just an index method that does nothing when the nodes are not >> to be indexed, and indexes when necessary? >> >> So, are we now closer to having this kind of support? >> >> On Tue, Jun 14, 2011 at 11:30 PM, Chris Gioran < >> chris.gio...@neotechnology.com> wrote: >> >>> Good news everyone, >>> >>> A request that's often come up on the mailing list is a mechanism for >>> automatically indexing properties of nodes and relationships. >>> >>> As of today's SNAPSHOT, auto-indexing is part of Neo4j which means nodes >>> and relationships can now be indexed based on convention, requiring >>> far less effort and code from the developer's point of view. >>> >>> Getting hold of an automatic index is straightforward: >>> >>> AutoIndexer<Node> nodeAutoIndexer = graphDb.index().getNodeAutoIndexer(); >>> AutoIndex<Node> nodeAutoIndex = nodeAutoIndexer.getAutoIndex(); >>> >>> Once you've got an instance of AutoIndex, you can use it as a read-only >>> Index<Node>. >>> >>> The AutoIndexer interface also supports runtime changes and >>> enabling/disabling the auto indexing functionality. >>> >>> To support the new features, there are new Config >>> options you can pass to the startup configuration map in >>> EmbeddedGraphDatabase, the most important of which are: >>> >>> Config.NODE_AUTO_INDEXING (defaults to "false") >>> Config.RELATIONSHIP_AUTO_INDEXING (defaults to "false") >>> >>> If set to "true" (independently of each other) these properties will >>> enable auto indexing functionality and at the successful finish() of >>> each transaction, all newly added properties on the primitives for which >>> auto indexing is enabled will be added to a special AutoIndex (and >>> deleted or changed properties will be updated accordingly too). >>> >>> There are options for fine grained control to determine >>> properties are indexed, default behaviors and so forth. For example, by >>> default all properties are indexed. If you want only properties "name" and >>> "age" for Nodes and "since" and "until" for Relationships >>> to be auto indexed, simply set the initial configuration as follows: >>> >>> Config.NODE_KEYS_INDEXABLE = "name, age"; >>> Config.RELATIONSHIP_KEYS_INDEXABLE="since, until"; >>> >>> For the semantics of the auto-indexing operations, constraints and more >>> detailed examples, see the documentation available at >>> >>> http://docs.neo4j.org/chunked/1.4-SNAPSHOT/auto-indexing.html >>> >>> We're pretty excited about this feature since we think it'll make your >>> lives >>> as developers much more productive in a range of use-cases. If you're >>> comfortable with using SNAPSHOT versions of Neo4j, please try it out >>> and let us know what you think - we'd really value your feedback. >>> >>> If you're happier with using packaged milestones then this feature >>> will be available from 1.4 M05 in a couple of weeks from now. >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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
