Looking under the hood at Amazon Neptune
A few weeks back, my Big on Data bro George Anadiotis provided the deep dive on why graph platforms may become the next database in your portfolio, regardless of whether you know what they are. At its simplest, graph databases excel in representing the many-to-many relationships that are difficult, if not impossible, to model in relational and NoSQL databases.
What makes the case for graph databases so compelling is that they model the real world the way it actually exists. Outside of transaction systems, people tend to be interconnected in multiple social tribes that may or may not be interlocking. Product catalogs are typically composed of families of SKUs that mix and match different grab bags of features. Cyber threats often arise from a multitude of players that may or may not be interrelated, with characteristics that can often betray lineage. You could model these in a relational database, if you don’t mind databases with hundreds of tables (or more) and queries requiring dozens or even hundreds of joins.
Welcome to the graph database. They are designed for representing the tangled webs of relations that often exist in real life.
Not surprisingly, virtually every data platform household name has added graph support to its portfolio. Recently, Amazon Web Services joined the fray by announcing the public preview of Amazon Neptune late last year at its re:Invent conference. Now four months into its public preview, AWS is aiming for general release later this year. We had a chance this week to sit down with AWS and get a peek under the covers on how Neptune works while gaining some insights on early adoption.
A distinguishing feature of Neptune is that, unlike most graph data platforms, it supports both Resource Description Framework (RDF) graphs and property graphs. AWS cites different use cases for each form. Customers engaging in standardized data interchange prefer the more definitely structured RDF triples; this is especially useful when using data sources, such as knowledge graphs or clinical data stores, that lend themselves well to the triple model. Conversely, when contending with variably structured data sources such as social media, property graphs can be more practical.
Amazon Neptune allows you to make the choice, by declaring which model to use, but at this point, property graph and RDF data is not interoperable. That is, you can’t form a single query that would span both types of data. We wouldn’t be surprised if some form of federated query capability could bridge this gap in the future.
