AgensGraph has been developed based on PostgreSQL from the beginning. What does “based on PostgreSQL” mean? For AgensGraph, it means that the existing SQL parser in PostgreSQL is able to parse a graph query language, i.e. Cypher, so that SQL and Cypher can be mixed in a query and there are also some modifications to the planner, optimizer, and executor in PostgreSQL in order to plan, optimize, and execute graph specific queries which are not properly expressed through existing functionalities.
On the other hand, there are some graph databases which just use appropriate backend storages and implement a graph layer that executes graph queries over one of those storages. Since they heavily depend on the functionalities of a backend storage, their feature set also depends on the backend storage. Moreover, it is hard to optimize query plans and get performance gain because they don’t have control over such backend storages from the inside.
AgensGraph supports graphid, vertex, edge, and graphpath type as its base type. Actually, they are implemented by using the composite type of PostgreSQL except graphid. Vertex can have 0 or 1 label and edge must have 1 label. However, a vertex(edge) label can inherit another vertex(edge) label. Like any other graph databases, AgensGraph also supports properties on vertices and edges. For more details on the data model of AgensGraph, Click here (https://bitnine.net/blog-agens-solution/data-model-of-agensgraph/).
In the next section, we will look into why multi-label is not supported and how label hierarchy can be made.
AgensGraph uses heap storage, i.e. table, to store vertices and edges. A vertex is stored into a table as a (id graphid, properties jsonb) record. An edge is stored into a table as a (id graphid, start graphid, end graphid, properties jsonb) record. This is the reason why a vertex or an edge cannot have multiple labels because such tables are labels. However, AgensGraph uses PostgreSQL’s table inheritance to support label inheritance. So, we can replace some kind of multi-label to label inheritance depending on the data domain. This architecture has a benefit if a user wants to retrieve vertices(edges) of a specific label. In this case, it is sufficient to scan a table for that label instead of maintaining label-vertex mapping information to get vertices of that label.
In addition, since AgensGraph uses jsonb type to store properties, a user can store nested property values.
AgensGraph uses B-tree indices built on (start, end) and (end, start) columns of edge labels to traverse a graph. Although those indices take more storage space, it has performance advantage either. When traversing edges of a vertex, those edges are read sequentially from the storage because index records of those edges are stored in a sorted manner. If those edges are scattered and there is no index, many random read will occur.
Since AgensGraph is based on PostgreSQL, it makes use of existing MVCC and transaction layer. So, read queries and update queries can be executed concurrently without losing too much performance. An user can execute long running transactions which update vertices and edges because of MVCC.
AgensGraph is fairly new to the graph database market. But it is continuously evolving to improve the query performance and usability and make it comparable with existing graph databases. Therefore, the architecture might change in the near future.
BITNINE GLOBAL INC., THE COMPANY SPECIALIZING IN GRAPH DATABASE
비트나인, 그래프 데이터베이스 전문 기업