GraphDB-SE Configuration

compared with
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (5)

View Page History
This section gives an overview of configuring an a GraphDB-SE repository. Also covered are the contents of the GraphDB-SE distribution and a description of the 'getting-started' application that is included. This sample application serves as an example for integrating GraphDB-SE in to other systems. For a detailed step-by-step guide for installing and setting-up GraphDB-SE, see the [installation section|GraphDB-SE Installation].

| {{lib}} | Contains the binary executable version of GraphDB-SE as a JAR (Java library) file |
| {{lubm}} | Scripts and configuration files to run the LUBM \[16\] benchmarks documented in section 11. |
| {{templates}} | Contains an a GraphDB-SE repository template file (.ttl) used by the Sesame 2 framework for creating new repositories. |

The distribution contains the following files in the root directory of the zip file:
h2. Making a back-up

The export features of getting-started allow a reasonable back-up of an a GraphDB database to be made.

h2. Sample Configuration

There follows an example configuration (in Turtle RDF format) of a Sesame 2 repository that uses an a GraphDB-SE sail implementation:

{noformat}@prefix rdfs: <>.
h1. Memory Requirements

Apart from the I/O buffers used for caching, GraphDB-SE keeps in memory the indexes from the nodes in the RDF graph. This is a design decision in order to improve the overall performance of the repository. Each I/O buffer (page) is exactly 64kb and the indexing information per node in the graph is 12 bytes. So, depending on the dataset, memory requirements per repository may vary. To ease the calculation for the amount of Java heap memory required for an a GraphDB-SE repository an excel spreadsheet is included in the distribution -- {{owlim-se-configurator.xls}}.
The page cache is organised in two sets of buffers, read-only and dirty. Each page is first loaded in to the read-only cache. When this gets full, a page (if dirty) is moved to the dirty cache, where it can be later written to the storage.