Hi, I can comment on the spatial side. The neo4j-spatial<https://github.com/neo4j/neo4j-spatial>library provides some tools for doing spatial analysis on your data. I do not know exactly what you plan to do, but since you mention user and place locations, I guess you are likely to be asking the database for proximity searches (users near me, or places of interest near me), in which case the SimplePointLayer<https://github.com/neo4j/neo4j-spatial/blob/master/src/main/java/org/neo4j/gis/spatial/SimplePointLayer.java>class should provide you what you need. Read the code (linked above), it is simple. Or read the related blog "Neo4j Spatial, Part1: Finding things close to other things<http://blog.neo4j.org/2011/03/neo4j-spatial-part1-finding-things.html>". You also do not need to include neo4j-spatial from the beginning. Just model your graph in a way suiting your domain, and when you want to enable spatial searches, include neo4j-spatial dependencies in your pom and start using it. If you happen to conform to one of the expected spatial structures, you can add you nodes to the spatial index directly, otherwise implement a GeometryEncoder and things should work from there. What I think you might find interesting is that you can edit the search mechanism to filter on both spatial and domain specific characteristics in the same pass. There are various options for this, so we can discuss that later, should you wish.
Regards, Craig On Mon, Jun 27, 2011 at 3:49 PM, Aliabbas Petiwala <aliabba...@gmail.com>wrote: > thanks for the informative reply , to add more , the social networking > website will be geo aware and some spatial info also needs to be > stored like the coordinates of the user node or the coordinates of > the location\place how can we add more also will neo4j alone + spatial > suffice ? can there be multiple masters for load balancing and how > about splitting the graph in the design itself like designing in terms > of multiple graphs which are mapped to a glue graph? > hats off for building such a pioneering technology! > > regards, > Aliabbas > > On 6/26/11, Jim Webber <j...@neotechnology.com> wrote: > > Hi Aliabbas, > > > > It's difficult to make pronouncements about your solution design without > > knowing about it, but here are some heuristics that can help you to plan > > whether you go with a native Neo4j solution or mix it up with other > stores. > > All of these are only ideas and you should test first to ensure they make > > sense in your domain. > > > > 1. Document/record size. If each node is likely to contain a lot of data > > (e.g. many megabytes) then you may choose to hold that outside of Neo4j > > (e.g. file system, KV store). Otherwise Neo4j. > > > > 2. Length of individual fields. If they're small enough to fit within our > > short-string parameters (optimised around post codes, telephone numbers > etc) > > then you get a performance boost compared to longer strings (which live > in a > > separate store file in Neo4j). If your individual fields are really > really > > long (See above, many megabytes), then consider moving them outside > Neo4j. > > If you can slice up your fields into shorter strings then you'll get a > good > > performance and footprint boost. > > > > 3. Many machines. Neo4j has master/slave replication so write performance > is > > asymptotically limited by the IO performance of the master (while reads > > scale horizontally, pretty much). The number of nodes you have is not a > > problem for Neo4j, so what is critical is whether a single master can > handle > > the write load you want to throw at it. Since modern buses are fast, and > > since graph data structures are often less write-heavy than equivalents > in > > other data stores*, I'd suggest that you might be well served by Neo4j > here. > > > > But my overriding advice is to spike something with Neo4j and then, only > if > > you find something that doesn't work in your context, to think about > adding > > another data store. > > > > Jim > > > > * I'll be blogging about this shortly since it's a common enough > > misconception that 1000 writes in a relational/other NOSQL database > implies > > 1000 writes in a graph, whereas often it's a single write meaning graphs > can > > be 1000 times better for the same workload. > > _______________________________________________ > > Neo4j mailing list > > User@lists.neo4j.org > > https://lists.neo4j.org/mailman/listinfo/user > > > > > -- > Aliabbas Petiwala > M.Tech CSE > _______________________________________________ > 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
