Monthly Archives: March 2015

Blazegraph 1.5.1 Released!

Blazegraph 1.5.1 is released! This is a major release of Blazegraph™. The official release is made into the Sourceforge Git repository. Releases after 1.4.0 will no longer be made into SVN.

The full feature matrix is here.


You can download the WAR (standalone), JAR (executable), or HA artifacts from sourceforge.

You can checkout this release from:

git clone -b BLAZEGRAPH_RELEASE_1_5_1 --single-branch git:// BLAZEGRAPH_RELEASE_1_5_1

Feature summary:

– Highly Available Replication Clusters (HAJournalServer [10])
– Single machine data storage to ~50B triples/quads (RWStore);
– Clustered data storage is essentially unlimited (BigdataFederation);
– Simple embedded and/or webapp deployment (NanoSparqlServer);
– Triples, quads, or triples with provenance (RDR/SIDs);
– Fast RDFS+ inference and truth maintenance;
– Fast 100% native SPARQL 1.1 evaluation;
– Integrated “analytic” query package;
– %100 Java memory manager leverages the JVM native heap (no GC);
– RDF Graph Mining Service (GASService) [12].
– Reification Done Right (RDR) support [11].
– RDF/SPARQL workbench.
– Blueprints API.

Road map [3]:

– Column-wise indexing;
– Runtime Query Optimizer for quads;
– New scale-out platform based on MapGraph (100x => 10000x faster)

Change log:

Note: Versions with (*) MAY require data migration. For details, see [9].

New features:
– BigdataSailFactory moved to client package (
– This release includes significant performance gains for property paths.
– Both correctness and performance gains for complex join group and optional patterns.
– Support for concurrent writers and group commit. This is a beta feature in 1.5.1 and must be explicitly enabled for the database. Group commit for HA is also working in master, but was not ready for the 1.5.1 QA and hence is not in the 1.5.1 release branch.


– Concurrent unisolated operations against multiple KBs on the same Journal
– Adding Optional removes solutions
– Query solutions are duplicated and increase by adding graph patterns
– Property path operator should output solutions incrementally
– Using a bound variable to refer to a graph
– NPE if remote http server fails to provide a Content-Type header
– problems with UNIONs + complex OPTIONAL groups
– Executable Jar should bundle the BuildInfo class
– SPARQL UPDATE should have nice error messages when namespace does not support named graphs
– NSS startup error: java.lang.IllegalArgumentException: URI is not hierarchical
– Data race in
– GPLv2 license header update with new contact information
– Add hook to override the DefaultOptimizerList
– startHAServices no longer respects environment variables
– Build version in SF GIT master is wrong
– needs updating for Blazegraph transition
– Optimized variable projection into subqueries/subgroups
– OSX vm_stat output has changed
– Concurrent modification problem with group commit
– ClocksNotSynchronizedException (HA, GROUP_COMMIT)
– GlobalRowStoreHelper can hold hard reference to GSR index (GROUP COMMIT)
– Code review on “instanceof Journal”
– BigdataSailFactory.connect()
– Isolation broken in NSS when groupCommit disabled
– GROUP_COMMIT environment variable
– SPARQL Federated Query uses too many HttpClient objects
– DELETE DATA must not allow blank nodes
– BigdataSailFactory? must be moved to the client package

Full release notes are here.



Blazegraph™ Selected by Wikimedia Foundation to Power the Wikidata Query Service

wikidata_logo_200pxBlazegraph™ has been selected by the Wikimedia Foundation to be the graph database platform for the Wikidata Query Service. Read the Wikidata announcement here.  Blazegraph™ was chosen over Titan, Neo4j, Graph-X, and others by Wikimedia in their evaluation.  There’s a spreadsheet link in the selection message, which has quite an interesting comparison of graph database platforms.

Wikidata acts as central storage for the structured data of its Wikimedia sister projects including Wikipedia, Wikivoyage, Wikisource, and others.  The Wikidata Query Service is a new capability being developed to allow users to be able to query and curate the knowledge base contained in Wikidata.

We’re super-psyched to be working with Wikidata and think it will be a great thing for Wikidata and Blazegraph™.


Mapgraph™ GPU Acceleration for Blazegraph™: Launch Preview

We’re going to be formally launching our GPU-based graph analytics acceleration products, Mapgraph™ Accelerator and Mapgraph™ HPC, at the NVIDIA GTC conference in San Jose the week of 16 March.   We will also be competing as one of 12 finalists for NVIDIA’s early stage competition for a $100,000 prize.  If you’re in the area, come to GTC on Wednesday, March 18 and vote for us!

MapGraph Logo_200px

Mapgraph™ Accelerator (Beta) serves as a single-GPU graph accelerator for Blazegraph™.  We believe it will provide  the world’s first and best platform for building graph applications with GPU-acceleration.   It will bridge the gap between our Blazegraph™ database platform and the GPU acceleration for graph analytics. Users of the Blazegraph™ platform will be able to leverage GPU-accelerated graph analytics via a Java Native Interface (JNI) and via predicates in SPARQL query similarly to our current RDF GAS API, which provides Breadth-First Search (BFS), Single Source Shortest Path (SSSP), Connected Components (CC), and PageRank (PR) implementations.

Mapgraph™ HPC is a new and disruptive technology for organizations that need to process very large graphs in near-real time. It uses GPU clusters to deliver High Performance Computing (HPC) for your organization’s biggest and most time critical graph challenges.

  • Up to 10,000X Faster for graph analytics than Hadoop technologies
  • 10X Price-Performance advantage over supercomputer solutions
  • Familiar Vertex-Centric Graph Programming Model
  • Demonstrated performance of 32 Billion Traversed Edges Per Second (GTEPS) using 64 NVIDIA K40s on Scale-free Graphs

We are currently enrolling Beta customers for Mapgraph™ Accelerator and Mapgraph™ HPC. Chesapeake Technologies International has already accelerated a military planning application seeing computation times drop from minutes for a single-solution to seconds for the generation of multiple scenarios.  We’re doing a session on it at GTC. Contact us if you’re interested finding out more.

Mapgraph Beta Customer Request

* indicates required