Blazegraph (powered by bigdata) / News: Recent posts

We're very pleased to announce the the release of Blazegraph 2.1.4.  This is a maintenance release of Blazegraph.  See the full details here.

2.1.4 Release Fixes

• [BLZG-533] - Vector the query engine on the native heap
• [BLZG-2041] - BigdataSail should not locate the AbstractTripleStore until a connection is requested
• [BLZG-2053] - Blazegraph Security Reporting Instructions
• [BLZG-2050] - Fork Colt Libraries to remove hep.aida
• [BLZG-2065] - Remove Autojar and Unused Ant Scripts... read more

We're very pleased to announce the the release of Blazegraph 2.1.2.  This is a maintenance release of Blazegraph.  See the full details here.

2.1.2 Release Fixes

• [BLZG-1911] - Blazegraph 2.1 version does not work on Windows (async IO causes file lock errors)
• [BLZG-1954] - Potential Race Condition in Latched Executor
• [BLZG-1957] - PipelinedHashJoin defect in combination with VALUES clause... read more

We're very pleased to announce the the release of Blazegraph 2.1.1.  This is a maintenance release of Blazegraph.  See the full details here.

Download it, clone it, have it sent via carrier pigeon (transportation charges may apply).  Find a bug, hit JIRA.  Have a question, try the mailing list or contact-us.... read more

We're very pleased to announce the the release Blazegraph 2.1.0.  2.1.0 release is a Major release of Blazegraph.    There are some very exciting changes for GeoSpatial Searching, update to Lucene 5.5.0, support for online back-up via the REST API, JSON-LD support, and much more.... read more

We're very pleased to announce the the release Blazegraph 2.0.0.  2.0.0 release is a Major release of Blazegraph.    There are some very exciting changes for query performance, load performance, improvement deployment options, migration to maven, moving to github, and many more.   This lays the foundation for new features with Tinkerpop3 support, GPU Acceleration, etc.      Download it, clone it, have it sent via carrier pigeon (transportation charges may apply).  Find a bug, hit JIRA.  Have a question, try the mailing list or contact-us.... read more

We're very pleased to announce the Blazegraph 2.0 Release Candidate.  2.0 release is a Major release of Blazegraph.    There are some very exciting changes for query performance, load performance, improvement deployment options, migration to maven, moving to github, and many more.   This lays the foundation for new features with Tinkerpop3 support, GPU Acceleration, etc.   We wanted to give the Blazegraph community a chance to take a peak at 2.0 and give us feedback.   Download it, clone it, have it sent via carrier pigeon (transportation charges may apply), but definitely take a look at let us know your thoughts.  Find a bug, hit JIRA.  Have a question, try the mailing list or contact-us.... read more

We're very pleased to announce the release of Blazegraph 1.5.3 is now available for download.  1.5.3 is minor release of Blazegraph with some important bug fixes.   The full set of features is available on JIRA.   We recommend upgrading to this release.  If you're upgrading from prior to 1.5.2, be sure to checkout the updated documentation on SPARQL and Dr. Michael Schmidt's excellent blog posts:  [1] and [2] as well as the Wiki documentation:  Sparql Order Matters and Sparql Bottom Up Semantics.... read more

Preface: In the 1.5.2 release we’ve implemented a couple of fixes regarding issues related to SPARQL’s bottom-up evaluation approach and associated variable scoping problems. If you encounter regressions with some of your queries after upgrading to 1.5.2, this blog post may help you identify ill-designed queries that are not in line with the official SPARQL 1.1 semantics. Please consult our Wiki for a more comprehensive discussion of SPARQL's bottom-up semantics.... read more

Hello,

Based on user feedback, we've added a bigdata-bundled.jar for the 1.5.2 release. The default release had changed the naming format to bigdata-1.5.2-bundled.jar. Both files are available and they are identical.

Thanks, --Brad

We had reports of a performance slowdown for SPARQL UPDATE INSERT/DELETE WHERE queries:

DELETE {...}
INSERT {...}
WHERE {...}

For example, you can observe this using the following SPARQL UPDATE request against a data set with 100k or more instances of rdf:label.

DELETE { ?s rdf:label ?o } INSERT {?s rdf:comment ?o } WHERE { ?s rdf:label ?o }

Looking into the timing, we found that the time to insert or remove each statement was growing in proportion to the number of statements already added or removed in the connection. The actual timings are below.  In the first log output, it took 3 seconds to process 10,000 statements.  The performance is fairly flat for the next 20,000 statements. However, the latency of the operation then starts to grow very rapidly.  By the last log output it was taking 97 seconds to process 10,000 statements!

     [java] Added 10000 stmts for removal in **3 seconds** (now **10000 stmts** in total)
     [java] Added 10000 stmts for removal in 3 seconds (now 20000 stmts in total)
     [java] Added 10000 stmts for removal in 4 seconds (now 30000 stmts in total)
     [java] Added 10000 stmts for removal in 9 seconds (now 40000 stmts in total)
     [java] Added 10000 stmts for removal in 9 seconds (now 50000 stmts in total)
     [java] Added 10000 stmts for removal in 12 seconds (now 60000 stmts in total)
     [java] Added 10000 stmts for removal in 20 seconds (now 70000 stmts in total)
     [java] Added 10000 stmts for removal in 26 seconds (now 80000 stmts in total)
     [java] Added 10000 stmts for removal in 32 seconds (now 90000 stmts in total)
     [java] Added 10000 stmts for removal in 39 seconds (now 100000 stmts in total)
     [java] Added 10000 stmts for removal in 46 seconds (now 110000 stmts in total)
     [java] Added 10000 stmts for removal in 53 seconds (now 120000 stmts in total)
     [java] Added 10000 stmts for removal in 65 seconds (now 130000 stmts in total)
     [java] Added 10000 stmts for removal in 74 seconds (now 140000 stmts in total)
     [java] Added 10000 stmts for removal in 83 seconds (now 150000 stmts in total)
     [java] Added 10000 stmts for removal in 90 seconds (now 160000 stmts in total)
     [java] Added 10000 stmts for removal in **97 seconds** (now **170000** stmts in total)
     ...... [read more](/p/bigdata/news/2015/08/sparql-update-performance-gain-an-easy-win-with-the-right-data-structure/)

We're very pleased to announce the release of Blazegraph 1.5.2 is now available for download. This is a significant release of Blazegraph featuring a large number of performance improvements and new features. The full set of features is available on JIRA. Highlights are below:

• In SPARQL, Order Matters: Faster query performance and bug fixes with a substantial refactoring of the Query Plan Generator in close collaboration with our partner, Metaphacts.
• External SOLR Search Integration: Use the SPARQL Service keyword to search content externally stored in SOLR.
• Updated User's Manual and Github Repository for Code Sampleswith our partner, MagInfo.
• Online backup for non-HA, Blueprints and Sesame embedded client fixes, and much more.... read more

Blazegraph™ is our ultra high-performance graph database supporting Blueprints and RDF/SPARQL APIs. It supports up to 50 Billion edges on a single machine and has a High Availability and Scale-out architecture. It is in production use for Fortune 500 customers such as EMC, Autodesk, and many others.

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.... read more

One common mistake made when writing SPARQL queries is the implicit assumption that, within SPARQL join groups, the order in which components of the group are specified does not matter. The point here is that, by definition, SPARQL follows a sequential semantics when evaluating join groups and, although in many cases the order of evaluating patterns does not change the outcome of the query , there are some situations where the order is crucial to get the expected query result.... read more

While graph databases are a perfect fit for storing and querying structured data, they are not primarily designed to deal efficiently with unstructured data and keyword queries. Therefore, such unstructured data is often kept in dedicated systems that are laid out to tackle the specific challenges for evaluating keyword queries in an efficient way — including advanced techniques such as stemming, TF-IDF indexing, support for complex keyword search requests, scoring, etc.... read more

Blazegraph 1.5.2 Release Preview

We're in the final stages of the Blazegraph 1.5.2 release.    This is major release for Blazegraph and brings both exciting new features as well as important performance and query optimizations.  You can see the full set of tickets for the release here (it's our first one since we've migrated to JIRA).... read more

All, we have finally completed the migration from trac to jira. Please visit and use the new jira instance for Blazegraph.

Many thanks to Brad for making this happen!

Note: trac will remain online in a read-only mode. A cross-walk of trac to jira tickets is available.

All trac tickets have been updated with a comment containing the link to the corresponding JIRA ticket.... read more

Have you ever wondered what to pair with Veuve Clicquot and your Big Data graph challenge? The 2015 Big Data Innovations Summit has the answer:  Blazegraph and Mapgraph.   We won the Big Data Startup Award at the 2015 Big Data Innovations Summit in San Jose.

... read more

Bryan and I were chatting back on the train from NYC on CPU memory bandwidth. Here's a quick write-up of the discussion.

15 years ago database researchers recognized that CPU memory bandwidth was the limiting factor for relational database performance. This observation was made in the context of relatively wide tables in RDBMS platforms that were heavily oriented to key range scan on a primary key. The resulting architectures are similar to the structure of array (SOA) pattern used by the high performance computing community and within our Mapgraph platform.... read more

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.... read more

Blazegraph™ 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.... read more

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!... read more

Starting with 1.5.1, BlazeGraph supports task-oriented concurrent writers. This support is based on the pre-existing support for task-based concurrency control in BlazeGraph. Those mechanisms were previously used only in the scale-out architecture. They are now incorporated into the REST API and can even be used by aware embedded applications.

This is a beta feature -- make backups!

There are two primary benefits from group commit. ... read more

"Hello BlazeGraph™ for big graphs." was the first tweet from @blazegraph as SYSTAP announced the release of it’s Blazegraph™ platform. SYSTAP was started with a very clear vision -- to build high quality, highly scalable, open-source software solutions for big graphs. Since 2006, SYSTAP’s graph database platform has been Bigdata® at systap.com.

However, you may have noticed that the rest of the world has discovered "big data"!... read more

We are changing the source code repository from SVN [1] to GIT [2].

Thanks,
Bryan

[1] https://sourceforge.net/p/bigdata/code/ (SVN)
[2] https://sourceforge.net/p/bigdata/git/ (GIT)

This is a major release of bigdata(R).

Bigdata is a horizontally-scaled, open-source architecture for indexed data with an emphasis on RDF capable of loading 1B triples in under one hour on a 15 node cluster. Bigdata operates in both a single machine mode (Journal), highly available replication cluster mode (HAJournalServer), and a horizontally sharded cluster mode (BigdataFederation). The Journal provides fast scalable ACID indexed storage for very large data sets, up to 50 billion triples / quads. The HAJournalServer adds replication, online backup, horizontal scaling of query, and high availability. The federation provides fast scalable shard-wise parallel indexed storage using dynamic sharding and shard-wise ACID updates and incremental cluster size growth. Both platforms support fully concurrent readers with snapshot isolation.... read more