Experimenting with explaining Neo4j on a whiteboard

Been experimenting with how to best explain the advantages of Neo4j on a whiteboard. Here's my latest attempt for a user that is working in a Telecom domain. Plenty more ideas like these if you like this.

I am using my Livescribe pen to make these "pencasts". Hit the little "settings" icon to make the pencast build gradually - it's the coolest way to follow.


Obviously this is only showing a tiny little part of neo4j's value proposition - but I guess this is a start.

Let me know if you like this, and if you want more of these - feedback welcome, as always.

Cheers

Rik

Worldcup Graph!

With the World Cup now in full swing, we really want you to have fun with our amazing Neo4j World Cup Graph Database, that is open for exploration on Heroku. Lot's of cool things to explore - take a look at this video I created to see what kinds of things you can do!



Hope you enjoy!

Rik

Betweenness Centrality: who's the Dolphin Daddy?

Just wrote a graphgist on Betweenness Centrality in a social network of dolphins in the Doubtful Sound, New Zealand. I won't repeat myself here in this blog - but it is pretty fantastic. Thanks to Michael for his help, again.

Graph Local queries - revisited

Recently I had some feedback from Chuck Daniels on my blogpost on Graph Local queries. In the comment, Chuck challenged me in saying that really I should be comparing apples to apples, and that I should make sure that I was applying the same kind of locality.

Basically his question was as follows: once we go from the small dataset to the large one, shouldn't the query that we test performance for also include a richer, more complex pattern. Essentially he wanted me to compare these two queries:

match 

(eqt:EQUIPMENT_TYPE)<-[:IS_OF_TYPE]-(eq:EQUIPMENT)-[:LOCATED_AT]->(ol:OBSERVATION_LOCATION)<-[:OBSERVED_AT_LOCATION]-(o:OBSERVATION {id:1001})

return eqt.name, ol.name, o.id; 

and

match 

(eqt:EQUIPMENT_TYPE)<-[:IS_OF_TYPE]-(eq:EQUIPMENT)-[:LOCATED_AT]->(ol:OBSERVATION_LOCATION)<-[:OBSERVED_AT_LOCATION]-(o:OBSERVATION {id:1001}),

(eq)-[:USED_FOR]->(ot:OBSERVATION_TYPE)<-[:IS_OF_TYPE]-(o)

return eqt.name, ol.name, o.id; 

The second query obviously being a bit more complex, as it adds a few more "hops" to the traversal. 

So lets test this out

I have created a little gist for you to try this yourself. Look at this one for loading the data, and testing the results yourself. We start with an empty database, of course, and load the small dataset first.

Then we run the sample queries (both of them: the easier one AND the more complex one) and create the index on the OBSERVATIONS.

Next up is adding the larger dataset, and running the queries again:

And surprise surprise, the principle of graph locality and index-free adjacency still survived - the queries are still lighting fast. 

Hope this clarifies the point that Chuck raised - and reinforces the fact that graph local queries are GREAT for many different use cases!

All the best

Rik