NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



Graph database: All content tagged as Graph database in NoSQL databases and polyglot persistence

What's the Current State of Graph Databases?

Jim Webber1 in an interview with Srini Penchikala for InfoQ:

The graph databases are odd, because they’ve actually decided to have a much more expressive data model compared to relational databases. So I think they are an oddity compared to the other three types of NoSQL stores, which means that when a developer first comes across them there is an awful lot of head scratching—you can see this haircut was completely caused by Neo4J. So I think compared to the other NoSQL stores, the graph database community is a little bit further behind in terms of adoption and penetration because they are a bit of an odd beast when you look at them first, “What would I use graphs for, they are those things I forgot from university, with that boring old guy doing math on the whiteboard”, on the blackboard even, I’m so old we had chalk, would you believe?

It’s almost always impossible for me to disagree with Jim. Expanding a bit on the quote above, I’d speculate that a bit of head scratching before adopting a new database is good as it means you’ll not see many improper use cases.

  1. Jim Webber: Chief Scientist at Neo Technology 

Original title and link: What’s the Current State of Graph Databases? (NoSQL database©myNoSQL)


Rolling Upgrades in Upcoming Neo4j 1.8

Chris Gioran describes rolling upgrades, a new feature in the upcoming Neo4j 1.8

So the rolling upgrade, actually, works exactly as you’d expect an upgrade would work. If there are not breaking changes between versions, you normally begin with the slaves, powering down, copying the store, migrating configuration if needed, then bringing that server back up. The new version would take over, communicate with the rest of the cluster and you wouldn’t notice anything.

A rolling upgrade offers that with versions that have incompatible protocols. Each slave, as it is brought up, detects the version running in the cluster and gracefully falls back into a compatibility mode that doesn’t allow it to become master, but allows it to continue to execute transactions.

Another thing I’ve found interesting is that the time a master machine is upgraded is considered the confirmation of a completed upgrade and all machines are switching to the new protocol. Clever.

Original title and link: Rolling Upgrades in Upcoming Neo4j 1.8 (NoSQL database©myNoSQL)


An Overview of Neo4j.rb 2.0

Andreas Ronge writing about using Neo4j in embedded mode with JRuby:

The advantage of the embedded Neo4j is better performance due to the direct use of the Java API. This means you can write queries in plain Ruby! Another advantage of the embedded Neo4j is that since it’s an embedded database there is one less piece of infrastructure (the database server) to install. The embedded database is running in the same process as your (Rails) application. Since JRuby has real threads there is no need to start up several instances of the database or of the Ruby runtime since JRuby can utilize all available cores on the CPU. There is actually even no need to start the database at all as it will be started automatically when needed. Notice it’s still possible to use the REST protocol or the web admin interface from an embedded Neo4j, see the neo4j-admin gem.

So which should I choose ? Well, if you can’t use JRuby or you don’t need an Active Model compliant Neo4j binding then the Neo4j Server is a good choice, otherwise I would suggest using the embedded Neo4j.rb gem (but I’m a bit biased)

As showed also by the earlier [migrating data from Oracle to MongoDB with JRuby], JRuby proves to be an interesting beast for handling data. I’m more on the side of Python, but Jython is not (yet?) as up-to-date as JRuby.

Original title and link: An Overview of Neo4j.rb 2.0 (NoSQL database©myNoSQL)


Neo4j Data Modeling: What Question Do You Want to Answer?

Mark Needham:

Over the past few weeks I’ve been modelling ThoughtWorks project data in neo4j and I realised that the way that I’ve been doing this is by considering what question I want to answer and then building a graph to answer it.

This same principle should be applied to modeling with any NoSQL database. Thinking in terms of access patterns is one of the major differences between doing data modeling in the NoSQL space and the relational world, which is driven, at least in the first phases and theoretically, by the normalization rules.

Original title and link: Neo4j Data Modeling: What Question Do You Want to Answer? (NoSQL database©myNoSQL)


How to Import Large Graphs to Neo4j With Spring Data

In my case, I wanted to create a simple recommendation engine (the domain doesn’t matter so much). To do that, I had to import FAST 20 million nodes of one-to-many, sparse matrix data. This became a bit more complicated (and interesting) task than originally anticipated, so it became a mini-project itself.

Bulk insert is a scenario that every database should have it covered.

Original title and link: How to Import Large Graphs to Neo4j With Spring Data (NoSQL database©myNoSQL)


The Database Nirvana

Scroll to minute 16:55 of this video to watch Jim Webber explain the benefits of polyglot persistence and how starting (again) the winner-takes-it-all war is just sending us back at least 10 years from the database Nirvana.

We’ve just come from the place where one-size-fits-all and we don’t want to go back there. There is a huge wonderful ecosystem of stores. Pick the right one. Don’t just assume that the one you find the easiest or the one that shouts the loudest is the one you’re going to use. Pick the one that suits your data model.

It doesn’t matter what flavor of relational or NoSQL database you prefer or have experience with or if a small or large database vendor is paying your bills. You really need to get this right as otherwise we’re just going to destroy a lot of valuable options we’ve added to our toolboxes.

Original title and link: The Database Nirvana (NoSQL database©myNoSQL)

Neo4j REST API Tutorial

A detailed language agnostic intro to the Neo4j REST API:

In the above examples we have seen how nodes, relationships, and properties can be created, edited, updated, and deleted from the Neo4j HTTP terminal.

Original title and link: Neo4j REST API Tutorial (NoSQL database©myNoSQL)


Intro to Neo4j Cypher Query Language

Very good slidedeck from Max de Marzi introducing Neo4j’s Cypher query language. While you’ll have to go through the 50 slides yourself to get the details, I’ve extracted a couple of interesting bits:

  1. Cypher was created because Neo4j Java API was too verbose and Gremlin is too prescriptive
  2. SPARQL was designed for a different data model and doesn’t work very well with a graph database
  3. Cypher design decisions:
    • declarative
    • ASCII-art patterns (nb: when first sawing Cypher I haven’t thought of this, but it is cool)
    • pattern-matching
    • external DSL
    • closures
    • SQL familiarity (nb: as much as it’s possible with a radically different data model and processing model)

AlchemyDB: An Integrated GraphDB + RDBMS + KV Store + Document Store

I recently added a fairly feature rich Graph Database to AlchemyDB (called it LuaGraphDB) and it took roughly 10 days to prototype. I implemented the graph traversal logic in Lua (embedded in AlchemyDB) and used AlchemyDB’s RDBMS to index the data. The API for the GraphDB is modeled after the very advanced GraphDB Neo4j. Another recently added functionality in AlchemyDB, a column type that stores a Lua Table (called it LuaTable), led me to mix Lua-function-call-syntax into every part of SQL I could fit it into (effectively tacking on Document-Store functionality to AlchemyDB). Being able to call lua functions from any place in SQL and being able to call lua functions (that can call into the data-store) directly from the client, made building a GraphDB on top of AlchemyDB possible as a library, i.e. it didn’t require any new core functionality.

Two reasons for posting about it:

  1. relaxing contraints of the relational model can make a RDBMS partially adapt to other models (nb: this is just re-inforcing an old strategy used by)
  2. usually dismissed for the lack of portability in the RDBMS world, server side scripting support is an extremely powerful tool. Having processing close to data (i.e. data locality) is a well known advantage, but as shown in this post and in creating reliable queues with Redis Lua scripting it can open the doors to completely new features.

Original title and link: AlchemyDB: An Integrated GraphDB + RDBMS + KV Store + Document Store (NoSQL database©myNoSQL)


The Richness of the Graph Model: The Sky Is the Limit

Marco A. Rodriguez in Exploring Wikipedia with Gremlin Graph Traversals:

There are numerous ways in which Wikipedia can be represented as a graph. The articles and the href hyperlinks between them is one way. This type of graph is known a single-relational graph because all the edges have the same meaning — a hyperlink. A more complex rendering could represent the people discussed in the articles as “people-vertices” who know other “people-vertices” and that live in particular “city-vertices” and work for various “company-vertices” — so forth and so on until what emerges is a multi-relational concept graph. For the purpose of this post, a middle ground representation is used. The vertices are Wikipedia articles and Wikipedia categories. The edges are hyperlinks between articles as well as taxonomical relations amongst the categories.

Imagine the reachness of the model you’d achieve when every piece of data and metadata would become a vertex or an edge. It’s not just the wealth of data but also the connectivity. Time would be the only missing dimension.

Original title and link: The Richness of the Graph Model: The Sky Is the Limit (NoSQL database©myNoSQL)

NoSQL Hosting Services

Michael Hausenblas put together a list of hosted NoSQL solutions including Amazon DynamoDB and SimpleDB, Google App Engine, Riak, Cassandra, CouchDB, MongoDB, Neo4j, and OrientDB. If you go through my posts on NoSQL hosting , you’ll find a couple more.

Original title and link: NoSQL Hosting Services (NoSQL database©myNoSQL)


How Can Graphs Apply to IT Operations

Being it IT, devops, or no-ops, operations are a critical part of every fairly sized system with real, expressed or not, SLAs. John E. Vincent’s post is an interesting look at what he feels is missing to make system operations more managable:

What I feel like we’re missing is a way to express those relationships and then trigger on them all the way up and down the chain as needed. We’re starting to get into graph territory here.

We must we be able to express and act on changes at the micro level (I changed a config, I must restart nginx) and even at the intranode level (something changed in my app tier, need to tell my load balancer) but now we need a way handle it at that macro level. Not only do we need a way to handle it but we must also be able to calculate what is impacted by that change.

Original title and link: How Can Graphs Apply to IT Operations (NoSQL database©myNoSQL)