I am using only one relationship type in my index tree, and made traversal decisions based on properties of the tree nodes, but have considered an 'optimization' based on embedding the index keys into the relationship types, which I think is what you did. However, I am not convinced it will work well because I suspect there will be losses if the total number of relationship types gets very high. I think this is a separate issue to the total number of relationships, but might affect all traversers, since there must exist a hashmap of all relationship types.
Still it is very cool what Peter says below, because if all these 'experiments' with in-graph indexes can get put behind the standard index API, then we can get much more testing of this approach, and hopefully learn what we need to make this a viable solution for wide use. On Wed, Jun 15, 2011 at 4:56 AM, Michael Hunger < michael.hun...@neotechnology.com> wrote: > 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 > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
