GraphDB-Enterprise Release Notes

compared with
Current by Nikola Petrov
on Apr 09, 2015 17:47.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (3)

View Page History
{toc}

h1. GraphDB 6.1-SP3
This Service Pack 3 build addresses some reported problems with 6.1

h2. GraphDB Engine 6.1-b4371143

* OWLIM-1888 Better inference performance for datasets with big number of classes and onProperty restrictions
* Fixed a problem where queries containing UNION and BIND were under certain circumstances returning incorrect results
* New merge command for the storage tool
* OWLIM-1932 Count from graph http://www.ontotext.com/count does not work for describe queries
* OWLIM-1934 Removed some old and unwanted namespaces that were included by default
* OWLIM-1928 Added reversed numeric and date literal indices for better performance
* OWLIM-1990 Worker data is deleted when a plugin fails to initialize
* Using store-backed queue to keep transaction operations on the master - this should prevent out of memory errors when importing huge files


h2. GraphDB Workbench 6.4.1
- See all the release notes here: [https://confluence.ontotext.com/display/GraphDB6/GraphDB-Workbench+Release+Notes]


h2. GraphDB Connectors 3.1.4
- See all the release notes here: [https://confluence.ontotext.com/display/GraphDB6/GraphDB+Connectors+Release+notes]


h1. GraphDB 6.1-SP1
This Service Pack 1 build addresses consistency issue with the GraphDB Storage. The cluster's backup/restore functionality is also fixed.

h2. GraphDB 6.1.8410
- extended new cluster backup/restore to support multiple named backups. Important note: the backup now uses a name instead of an absolute folder
- fixes for the master URL parameter (autodetected in most cases, thus no need to specify manually)
- minor cluster improvements (shutdown on OOM during sync; worker: handling multiple initializations and no reporting of missing fingerprints on init; fixed race condition in replication; new internal URIs (not URLs) for replication)
- fixed: [owlim-1853] LoadRDF under Windows sometimes does not include statements in the PSO index and the indexes are incosistent;
- Added a check/warning to see if there is enough memory for the entity pool when it gets restored from persistence (-Xmx - cache-memory should be >= entity pool size * 1.25, i.e. 25% overhead is left for the datatype index and other in-memory structures included in the entity pool and for other purposes, e.g. for running queries)
- Constraint validation and support for multiple rulesets is out of its experimental stage and now in production. See the docs here: [https://confluence.ontotext.com/display/GraphDB6/GraphDB+Constraint+Validation]

h2. GraphDB Workbench 6.3.2
- See all the release notes here: [https://confluence.ontotext.com/display/GraphDB6/GraphDB-Workbench+Release+Notes]


h1. GraphDB - 6.1.8316
This is an Enterprise release only.

h2. Improvements (replication cluster):
- Tx Log stability improvements & fixes - scrapped optimistic join procedure; scrapped shared horizon & completed queue; fixed status patching base
- Improved logging detail
- Updates are dispatched to the other peers immediately once accepted and enqueued
- dedicated peer dispatch threads
- fixed split-brain recovery
- Client API: Changed the master retry policy (do not check every master too often; but still make sure that when previously unavailable master becomes available we detect that)

h2. Replication improvements:
- cleanup target directory on accepting replication data
- 60s timeout in replication client
- limited retries in the replication server
- replication client startup delay patch
- retry serving replication data on failure
- exposed exceptions thrown from the replication server

h2. Other improvements:
- The inferencer debug statistics were not displayed at shutdown because we used the SwitchableInferencer's ones instead of those in currentInferencer that did the job
- Created StorageTool app, used to Scan/Rebuild indexes in case of missing statements

h3. Fixes:
- [OWLIM-1838] Custom NTriples/NQuads parser: ArrayOutOfBoundsException can be thrown on empty lines while parsing and then NPE while trying to process t.getMessage() which may be null
- [OWLIM-1834] Fixed: LoadRDF Tool doesn't work with GraphDB Enterprise
- [W-44] Introduced a parameter 'in-clause-max-members' (defaults to 16) which limits the number of entities specified in the IN clause. If the IN clause contains more elements then it won't be optimized to a UNION query
- [W-55] Fixed the ASC/DESC issue in ORDER BY clause when the variable in the ORDER BY is in an OPTIONAL clause (the issue was different number of results returned in ASC/DESC cases).


h1. GraphDB version 6.1-RC1

- *Various stability fixes to the cluster*, including proper master shutdown sequence error handling, error-resilient synchronization threads, safe saving of configuration properties of the cluster config. The repository fingerprint now also reflects the number of statements and there is better handling of stress events which happen during transactions & dirty shutdowns (e.g. out of disk space)

- *Much faster write transactions* for small insert/update/delete operations on large repositories. Results on LDBC [Semantic Publishing Benchmark|http://ldbcouncil.org/developer/spb] (SPB) at 50M went up from 32 read and 12 write queries per second in ver. 6.0 to 37 40 reads/s and 28 31 writes/s in ver. 6.1. The improvement gets even more visible and SPB at 1B scale: from 10 reads/s and 2 writes/s in ver. 6.0 to 11 reads/s and 10 writes/s in ver. 6.1. In summary, GraphDB 6.1 is able to handle twice more updates at 50M scale and 5 times more updates at scale of 1 billion statements. This way GraphDB 6.1 is already capable to deal with true Dynamic Semantic Publishing scenario, like the one of [BBC|http://www.bbc.co.uk/blogs/legacy/bbcinternet/2012/04/sports_dynamic_semantic.html], at a scale of 1 billion statements and higher.
See more: http://www.ontotext.com/graphdb-benchmark-results/

- *Improved load capabilities for large new datasets in live databases* instances. Scenario description: there is a production cluster with average load - running LDBC-50m (SPB) with 4 reading threads (doing select queries) and 1 writing thread (doing update queries). We need to add a large dataset (e.g. DBPedia) with hundreds of millions statements -- as fast as possible, but without disrupting the overall cluster speed too much (not introducing write latency of more than 1-2s). The data set doesn't need inference, so it is loaded with the empty rule set.