Hi Michael, thanks for your comments that's very helpful. So by 5-bytes,
does that mean if I keep the number of labels < 32 I would avoid that
indirection?
For some reason I was thinking searching by label would be faster than
searching by property, so I was avoiding that, also it makes the queries a
tiny bit more complicated to search by property, but I guess its not too bad
(SuperLabel)-->()
vs.
(Label {is_super:true})-->()
Thanks,
Dan
On Sunday, June 7, 2015 at 4:30:53 PM UTC-4, Michael Hunger wrote:
>
>
> Am 07.06.2015 um 20:57 schrieb Dan R <nic...@gmail.com <javascript:>>:
>
> Hello, I am attempting to implement a specific object model that has a lot
> of inheritance (Up to 12 or 13 levels in some cases). I was wondering if
> there are any performance penalties associated with having a large number
> of labels on a node. Here's an example:
>
> CREATE (n:Label1:Label2:Label3:Label4:Label5:Label6..)
>
> But in most cases we'd just be querying with
>
> MATCH (n:Label1)
>
> but have the freedom to match further up the chain if we want.
>
>
> Yes there is some penalty, if you have more labels than fit into the
> node-record (5-bytes) they are stored in a separate indirection file which
> costs additional accesses if you accesses on of those nodes as it has to
> deserialize all labels.
>
> I think that's something that will be more efficient in 2.3
>
> Perhaps for the time being it might be easier to separate the additional
> hierarchy either into a separate node or just into node-properties? So you
> have a basic "entity" label and the main labels on your nodes and for
> higher level queries you'd use the entity label and check in the property?
>
> But best is to just test it how it fares for your use-case.
>
>
> So is there anything wrong with this? Just wanted to check since I'm not
> sure about the underlying file structures of the graph.
>
> I was also planning on doing something similar with properties:
>
> CREATE (n)-[r:REL1]-(p)
>
> MATCH (n)-[r:REL1|REL2|REL3|REL4|REL5|REL6|REL7]-(p)
>
> I'd assume this one would have more of a penalty in the match clause since
> it's probably just a for loop underneath searching for each relationship
> but I'm not sure of how bad of a penalty it would be.
>
>
> For properties the same indirection as mentioned above will kick in, even
> more so if you have longer strings as properties.
> So you either encode you additional hierarchies as numbers or as short
> strings, which are stored more efficiently only one indirection away.
> Alternatively you might also be able to just create a different
> relationship-type that includes the other hierarchy levels or additional
> rels for the other hierarchies?
> HTH
> Michael
>
>
> Thanks for any insights,
> Dan
>
> --
> 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 neo4j+un...@googlegroups.com <javascript:>.
> For more options, visit 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 neo4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
