Database Reference
In-Depth Information
on disk (or how large you expect them to become), and trying to reserve an appropriate
amount of RAM for each one.
Supposeyouhaveatop-levelNeo4jdatabasedirectorythatoccupiesapproximately2.2GB
of data, made up of the following store files and sizes:
20M neostore.nodestore.db
60M neostore.propertystore.db
1.2G neostore.propertystore.db.strings
900M neostore.relationshipstore.db
The following snippet shows a configuration that will ensure that the whole of the graph
can fit into the memory allocated to the filesystem cache. The settings shown in this con-
figuration file reserve approximately 2.5 GB of RAM, which allows for about 10% data
growth:
neostore.nodestore.db.mapped_memory=22M
neostore.propertystore.db.mapped_memory=66M
neostore.propertystore.db.strings.mapped_memory=1.4G
neostore.relationshipstore.db.mapped_memory=1.0G
neostore.propertystore.db.arrays.mapped_memory=0M
WhenrunningNeo4jinservermode,thesesettingsarespecifiedintheneo4j.propertiesfile
found under the conf directory.
For an embedded setup, the configuration settings can be passed in when the graph data-
base is constructed, either via a reference to a neo4j.properties file, accessible from some-
where on the classpath, or directly within Java via a
Map
.
You'll have noticed that there's a 1:1 mapping between the configuration settings and the
physical store files on disk. Within the broader filesystem cache memory area, Neo4j en-
sures that separate, individual file buffer caches are maintained for each store file, and thus
allows cache configuration on a per store basis as well. This makes it is possible to config-
ure how much of each store file should be loaded into RAM independently of one another.
Different applications will have different usage patterns, and being able to independently
tune these cache areas enables you to ensure that the app can perform as well as possible,
especially if there isn't enough free RAM available to load the whole graph into memory.
