Hi Chris, Your use case sounds fascinating and certainly a good fit for a graph database. Making your own KD-tree in-graph is also pretty cool. I've played with in-graph index structures a few times before, and it certainly worked for me. One project was the 'Neo4j Spatial' library which builds an RTree in-graph for spatial queries on complex geometries. You might be interested in taking a look at that. Either to use it, or for inspiration for ideas for your own models.
https://github.com/neo4j-contrib/spatial The 'cookie cutter' description was not completely clear to me, and perhaps I would need a more concrete example before I can comment. It sounded a bit like you had a pattern you wanted to find anywhere. For example, a star with 5 arms. This would be quite expensive, as it would have to search the whole graph. If you had some limiting factor, for example only starting with a central node matching some criterial (name, key, location, proximity, etc.) then it can be made fast again by first searching for that part and then the rest of the pattern. Regards, Craig On Mon, Jan 11, 2016 at 12:31 PM, Chris Moses <[email protected]> wrote: > I'm trying to wrap my head around how to structure some data. And then > execute queries that return a subset of the data (which, obviously, matches > some criteria.) > > For example, say I am a utility company that manages sewer and cable > lines. I have a DB of 500K homes, 2000K other residencies, substations, > etc. I also have connections going from home to home, home to buildings, > ...to substations, etc... > > Now, I need to be able to find all occurrences in the DB where 4 homes are > in a (near) exact spatial relationship to each other (indicating one type > of connection cable was probably used) and within a certain distance > another (but different) exact configuration of things exists. > > Ideally, I would to be able to cover as much as possible of the space with > these various "Cookie-cutter" patterns. > > Does that use-case make sense? > I have ways of brute forcing such things in SQL, but it is ugly. It seems > like Graph DBs would be a much better fit: distances can easily be a > property on an edge, KD tree and other data structures could coexist with > other structures, explorattory models could be spun up and down as needed... > > If anyone could point me in the right direction I would really appreciate > it. > Thanks > Chris Moses > > -- > 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. > -- 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.
