This release will provide GA for the scale-out architecture.
- BLZG-277 HA MDS/DS
- BLZG-278 HA TXS
- BLZG-196 Support HDFS for highly available shard storage
- BLZG-27 Simplify scale-out configuration and deployment
- BLZG-3 Decouple the bulk loader configuration from the main bigdata configuration file.
- BLZG-2 Change the default cluster logging setup to use service local logging rather than log aggregation.
- BLZG-80 Enable scale-out tests in CI
- BLZG-1226 Enable BigdataEmbeddedFederationSparqlTest tests in CI.
BLZG-120 Enable full text index for scale-out (Roadmap : Provide reasonable integration with external full text index (ElasticSearch, etc. requires alternative search service and data write pipeline)).
BLZG-253 Refactor the bulk loader to run on the DS nodes (vs CS nodes) and modify it to buffer writes per target DS rather than per target shard. This will improve scaling significantly (I would like to go for 10x). It will also mean that we do not have to waste nodes on the CS for bulk load. However, bulk load puts a lot of strain on the Java heap, so we need to get those buffers off the managed object heap and onto the native heap.
BLZG-246 Separate data flow from message flow in the scale-out API. Note that Java 7 supports IB using NIO zero copy. See http://www.infoq.com/articles/Java-7-Sockets-Direct-Protocol. java -Dcom.sun.sdp.conf=sdp.conf -Djava.net.preferIPv4Stack=true ...
- BLZG-420 Refactor native long tx id to thin object.
- BLZG-775 GRS index split causes failure on concurrent GRS scan.
BLZG-501 RMI/NIO should use versioned data structures or pure interfaces to support rolling updates
BLZG-592 Optimize read-historical range counts on cluster.
BLZG-593 Parallelize aggregation operators on cluster.
BLZG-607 NIO solution set interchange on the cluster
BLZG-609 Vector query engine messages per node.
BLZG-608 The query controller should be discoverable.
The main risk factors are:
- Java FileChannel IO interrupt semantics.
- Can written data be read back by the same JVM without a sync/close? If not, then we need to fully buffer the write set in memory up to the commit.
- Atomic file append and file length reporting iff we write the root blocks on the end of the WORM store.
This work is being performed in the blazeraph-hdfs branch (https://github.com/SYSTAP/bigdata/tree/blazegraph_hdfs/blazeraph-hdfs).
|3.||Support HDFS for highly available shard storage||Open||Unassigned|
|4.||Simplify scale-out configuration and deployment||In Progress|
|5.||Decouple the bulk loader configuration from the main bigdata configuration file||In Progress|
|6.||Change the default cluster logging setup to use service local logging rather than log aggregation.||In Progress|
|8.||Enable BigdataEmbeddedFederationSparqlTest tests in CI||Open|
|Enable full text index in cluster||Done|
|Refactor the async write API to buffer per target DS, not per target shard||Done||Unassigned|
|Separate data flow from message flow in the scale-out API.||Done||Unassigned|
|12.||GRS index split causes failure on concurrent GRS scan.||Reopened|
|13.||Scale-out engine for vertex programs||In Progress|
|14.||Update wiki with examples for scale-out usage||Open|