Choosing a NoSQL Database
Andrew Oliver, president and founder of Open Software Integrators, gives a guide to the new database types: key-value pairs, column family/big table, document, and graph databases. On graph database, he writes:
Graph databases are really less about the volume of data or availability and more about how your data is related and what calculations you’re attempting to perform. As Philip Rathle, senior director of product engineering at Neo Technologies (makers of Neo4j), told me, graph databases are especially useful when “the data set is fundamentally interconnected and non-tabular. The primary data access pattern is transactional, i.e., OLTP/system of record vs. batch… bearing in mind that graph databases allow relatedness operations to occur transactionally that, in an RDBMS world, would need to take place in batch.”
This flies in the face of most NoSQL marketing: A specific reason for a graph database is that you need a transaction that is more correct for your data structure than what is offered by a relational database.
Common uses for graph databases include geospatial problems, recommendation engines, network/cloud analysis, and bioinformatics — basically, anywhere that the relationship between the data is just as important as the data itself. This is also an important technology in various financial analysis functions. If you want to find out how vulnerable a company is to a bit of “bad news” for another company, the directness of the relationship can be a critical calculation. Querying this in several SQL statements takes a lot of code and won’t be fast, but a graph database excels at this task.