Hi, that's one potential option.
If you can make sure that you don't query across the feature nodes, it doesn't matter a lot if your feature nodes are supernodes. Ie. get the feature nodes first and then check from the product node if it has connections to the feature node. Only if you query across the feature nodes, you'll get that exponential explosion. Another option would be to just not use supernodes for those features but to store the feature on the node either as label or property. It depends on your use-case queries across your product hierarchy. Cheers, Michael > Am 05.03.2015 um 00:10 schrieb Iazel <[email protected]>: > > Hello, > I'm still learning neo4j and graph dbs; I've read the two suggested books. > Now, suppose to have a different set of products and each one can have a > different set of features. It's possible for a particular feature to be > present in nearly all products, making it a good candidate to be a > "supernode" - embedding it directly into the product's node is not an option. > We are interested in displaying all the features for any given product, but > however we have the slightly more frequent search of products by a given > feature. > I know that the general purpose approach to supernodes is the fan-out > technique, but I was wandering if we can use a more simpler version: just > make a node that manage all the edges. Something like this: > > (product)<--[COMPOSE]--(supernode)<--[GUARD]--(feature) > > The `supernode` will potentially have millions of connections, but the > `feature` node will have only the `GUARD` edge instead. > Now, let's say, given a product, I want all of its features (high frequency > query). I think the algorithm will find the right product through an index, > follow the [COMPOSE], hit the supernode and go through the [GUARD], arriving > at the necessary feature. > I've read that the persisted representation doesn't have a way to group the > various kind of edges, but the in memory representation should, hence I'm > supposing the search is O(n). > This also let me think that the major issues with this workflow is when the > data doesn't fit in memory, but with a warm cache and eventually a good > (tricky) partitioning, the problem could be overlooked? > > When we need all the products that have a feature, we have to follow all > `COMPOSE` edge in any case, hence no solution is better than having all of > them in one place, doesn't it? > > So, I'm evaluating it correctly or I'm missing something? > > Thanks! > > -- > 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 [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
