System Architecture

Shared-Nothing

AllegroGraph follows shared-nothing model, adopts federation mechanism and flexible triple store architecture combine to make it easy to connect multiple stores together and treat them as one. When a user creates an AllegroGraph federated repository, a virtual index of the constituent stores is created and maintained in the client session to facilitate intelligent query processing and maximum performance.

Concurrency Control

Not Supported

No triple locking is performed by AllegroGraph. It uses snapshot isolation and it is possible that a triple that is being read in a transaction could be deleted in a concurrent transaction. It cannot guarantee write concurrency

Joins

Nested Loop Join

AllegroGraph does support join. But I cannot find the information about its implementation. I think it's likely to be index nested loop join (or hash join) because all triple attributes are indexed automatically.

Checkpoints

Blocking

While a checkpoint is operating, commits are blocked. Setting the CheckpointInterval to a longer interval reduces how often checkpoints occur, thereby reducing the impact on commits. When a checkpoint occurs, the system updates and cleans up repository information so that the respository is in a known state. When recovering from server terminations, the system starts at the most recent complete checkpoint and works through to the current (uncheckpointed) state.

Views

Not Supported

Current graph databases such as Neo4J, AllegroGraph, and InfiniteGraph do not provide a concept for view definition and maintenance.

Indexes

B+Tree Inverted Index (Full Text)

AllegroGraph builds indices automatically so that any query can find its first match in a single I/O operation. The standard seven indices are enabled when you create a triple store. What matters with an index is the sort order of the triples. Besides triple Indices, AllegroGraph can also build full-text indices of the strings of the objects associated with a set of predicates that you specify.

Isolation Levels

Snapshot Isolation

Every transaction sees a snapshot of the persistent database state as of the time when the transaction is started. During the transaction, it can change the persistent state without affecting the snapshot of others. When finishes, any updates made by concurrent transactions are visible.

Stored Procedures

Supported

Users can use Lisp or JavaScript to define stored procedures.

Logging

Logical Logging

When the commit operation of AllegroGraph returns, the database server will have written the updates made by the transaction to the transaction log and waited for the log I/O operation to finish. Transaction log files record all committed database changes (triple additions and deletions), along with some other information.

Storage Model

Custom

It shores data as the Resource Description Framework (RDF), which breaks knowledge into assertions of subject predicate object (e.g. Andy Type Human ). These assertions are called triples. AllegroGraph doesn't restrict the contents of its triples to pure RDF. In fact, we can represent any graph data-structure by treating its nodes as subjects and objects, its edges as predicates and creating a triple for every edge.

Query Compilation

Not Supported

Storage Architecture

Disk-oriented

Query Interface

SPARQL RDFS++

Users can query AllegroGraph with SPARQL, RDFS++ Reasoning or Prolog. AllegroGraph's RDFS++ reasoning supports all the RDFS predicates and some of OWL's. Prolog is an alternative query mechanism for AllegroGraph. With Prolog, you can specify queries declaratively.

Data Model

Triplestore / RDF

AllegroGraph is a closed source triplestore that is designed to store RDF triples.