Saving Expenses

If the stored network is huge, running a query with an arbitrarily long chain of relations will usually take too long; limiting this to two or three levels saves a huge amount of time. What's more, if the database does not have to look forever for a suitable starting point for a route, your queries will run faster. For example, if the starting node for the search is already defined, a directive such as:

START n=node:router_index(name='guest')

can define the starting point for the match command. The prerequisite for this step is that the start router has been stored previously in a Neo4j index under the specified key (name).

Listing 2 does this in lines 35 and 36 with the add_entry() method. For simpler applications, the Neo4j Server offers an autoindex option; it determines which attributes to index automatically.

In Figure 5, the query first finds all wireless routers that have a wireless attribute set to 1. The example network has only one, although a more complex installation will probably have many more, increasing the number of routes found leading to the Internet. Using this information, you could, for example, periodically run automatic security checks that prevent a network packet from a wireless network reaching a protected internal network because of a configuration error.

Figure 5: The single wireless router is only connected to the modem via a path that does not use the internal network.

Two-Sided Anchors

The search pattern for the match statement can use more complex anchors. The query in Figure 6 searches the entire network for any router, n, that is used as a gateway on both sides. To do this, you need to compose a query with three router variables (here, m, n, and o) with a relation from left to right between the first two routers and another relation from right to left between the router at the end and the router in the middle. ASCII art makes this possible.

Figure 6: This query looks for two nodes in the graph that forward packets to the same gateway.

Neo4j tries to find such a constellation and outputs the results: The router merger matches the queried pattern. The two results have the same paths as equivalents with opposite orientation.

Finding the Edge

In the search to determine which devices on the network forward packets to the Internet, Listing 3 uses Perl to dispatch a Cypher query and anchors the match pattern to end at the router belonging to the DSL modem. The CPAN REST::Neo4p::query module runs the query and uses the fetch() method, which takes the results trickling in from the server in JSON format and returns them as paths. The latter consist of two lists, one with nodes and one with the intermediate relations.

The nodes() and relationships() methods dig the nodes and relations out of the path objects. The only task remaining for the for loop at the end is to extract the names of the devices by means of get_property() and output the sole matching result route by using arrows as symbols:

guest->merger->modem

Queries of this type happen quickly and are obviously easy to formulate.

As Figure 7 demonstrates, you can easily install the Neo4j server on Ubuntu and other Debian derivatives using the Debian repository server, as described on neo4j.org. Following this, the daemon starts automatically, as a call to curl http://localhost:7474 confirms by returning the server status in JSON format.

Figure 7: The apt-get package manager installing the Neo4j server on Ubuntu.