A Graph Database Management System (DBMS) is a database system optimised for managing highly-related data. An obvious example is the Facebook social network of people and their activities. But relationships between things are a key part of any data management - and the more data we store, the greater the number and nature of relationships we need to make sense of.
"But isn't that what Relational Databases like Oracle and MySQL are for?" you might ask. The truth is that these products aren't relational stores at all - they're a collection of flat tables with a relational query language (SQL) tacked on. So when it comes to working with highly-related data, a Graph DBMS can be thousands of times faster.
What's more, the Relational DBMS puts a straight-jacket over your database. You need to create a "schema" to define your data and its relationships and that schema makes it impossible to adapt to your changing data needs without complete re-engineering.
There is a better way. A good Graph DBMS is a faster, more flexible and future-proof way to manage more data.Traditionally, however, Graph Database implimentations have had problems that limit their usefulness...
GraphBase is the first Graph DBMS to properly address each of these issues with its graph-focused query and transaction models, its rich tool set, its support for hybrid data stores, and its many other Enterprise-focused features.
You Should Use A Graph DBMS If...
On a more technical note, you should consider a Graph DBMS if...
When NOT to use a Graph DBMS
Go to any other vendor, read any other discussion on graph stores and you'll be told that working with a large graph is all about traversals. You need to "think like a vertex", they'll say.
Sure, this works for large graphs, but only if their structure is simple. Working with complex graph structures this way will make your head explode. This is a serious shortcoming - because complex structures are where a Graph Database is most useful.
When you work with GraphBase, you work with graphs. GraphBase stores data as one large graph. Data is delivered to GraphBase as small graphs, a query to GraphBase returns data as a graph and the smallest transactional unit is a graph.
Even at the application level, it often makes sense to work with graphs, rather than objects. A graph can carry much richer information about the chunk of data you're working with.
GraphBase graph-manipulation tools also mean that data in graph form can be manipulated with dramatically-less code than is required for objects, "rows" and other traditional application data structures.
You can, for example, and() your graphs. Or you can turn them into a list of objects with a single method. Take a quick look at the Java API to see just now much simpler working with graphs can be.
Oh, and you can ditch that bloated ORM or other mapping layer - it's no longer required.
In traditional Database Management Systems you need to define a "schema". The schema is...
A database (physical) schema is also a straightjacket. Fill your database and you're locked into the structures defined by that schema. The only way to make significant change is to "migrate" your data. Imagine giant flocks of birds taking wing for a two-month-long journey from one end of the globe to the other. Data migration is no less an undertaking.
NoSQL databases are less-structured. The maps and constraints are basic or non-existent - and this includes the other graph databases. "No Schema" is touted as a positive feature of these database systems, but in truth you end up writing the schema in your application instead. That's not good practice - particularly for enterprise, where many applications and developers across many departments may be using the same DBMS.
GraphBase is different, and it's also unique amongst Graph Databases. We give you powerful maps and we also give you structures to impose the constraints you need. We do this with what we call "Frameworks". A framework is a graph that you "attach" to your data. Typically, the framework graph is a shallow tree of labels used to describe key vertices within your super-graph. Unlike a schema, you can add to or otherwise change a framework without impacting the existing data.
What's more, with GraphBase, there is no limit to the number of frameworks you can apply. And there's little to no performance cost when providing multiple rich frameworks. You can have one tree of labels for your stakeholders, another for your customers, another for the accounts department - and they can all provide a different "view" of the same data.
Simple label-trees are just the start. Your frameworks can also be...
The GraphBase Semantic Framework is one example of a large and rich framework. It's a graph of 80,000 concepts representing more than one million English words. Rich frameworks like this can give your data unprecedented searchability. You can see this framework put to good use in the FactNexus EKG knowledge graph toolset.
GraphBase also uses special frameworks to control access and to impose constraints when you need them. All the power of a schema, but without the pain.
There is no "standard" when it comes to building data graphs. Stores that support RDF (Semantic Web) and Property Graphs are most common, but these have failed to gain universal acceptance because they're not broadly-useful.
These first-generation graph stores have some impressive capabilities, but they don't do the basics well. First and foremost, a Graph DBMS has to be great at managing data. It has to be as easy-to-use as a traditional database and loaded with the features that Enterprise users expect. It also has to be highly-searchable, and fast.
These basic requirements heavily influenced our search for a base graph structure. But we also wanted a simplified preferred structure to meet these additional goals...
Graph Simple Form or GSF is that preferred structure. It helps us meet all our core and higher goals. GSF is a variation of what's referred to as a simple mixed-graph. This is what it looks like.
Each vertex or node has...
Its arcs, edges or connections have these rules...
With GSF you can model any data structure. You can then build massive future-proof data graphs that are a pleasure to work with.