fault tolerance and to maintain excellent performance when the memory-to-disk ratio is lopsided. But cache sharding allows Neo4j to aggregate the RAM of individual instances by consistently routing like queries to the same database endpoint. In the typical case where a server supports multiple concurrent clients, access patterns tend to be noisy at first glance, approximating all of the random walks of the graph overall. Yet even at large scale randomness is never truly dominant.
Amazon Web Services – Running Neo4j Graph Databases on AWS Page 13 After all, since the graph is structured it makes sense that queries would be structured, too. With multiple concurrent clients, it’s possible to discern commonality between them. Whether by geography, username, or other application-specific feature, it’s almost always possible to discern a coarse feature of the access pattern on the wire so that like requests can be consistently routed to the same server instance. The solution architecture for this setup is shown in Figure 4. The technique of consistent routing has been implemented by high-volume web properties for a long time, and it is simple to implement, scales well, and is very robust. The strategy we use to implement consistent routing will typically vary by domain. Sometimes it’s fine just to use session affinity (commonly called “sticky sessions”) implemented by the Elastic Load Balancing. At other times we’ll want to route based on the characteristics of the data set. A simple strategy is that the instance that first serves requests for a particular user will serve subsequent requests. By doing this, there is a greater chance that a warm cache will process the requests. Other domain-specific approaches will also work. For example, in a geographical data system we can route requests about particular locations to specific database instances that will be warm for that location.