Database Reference
In-Depth Information
The fixed record size also plays an important part in providing a quick mechanism for cal-
culatingwhereinthefileacontiguousblockofrecordsisstored;thisisusedbythefilesys-
tem cache (see
section 11.1.4
)
to load portions of the store files into cache.
Therearetwokeyfeaturesthatyoushouldbeawareofwhenitcomestothestorefilestruc-
ture.
The first is that these fixed record sizes can be used to help estimate the amount of space
that the core graph files will take up on disk, and thus how big your disks may need to be
(see
section 11.1.2
)
.
The second is that these store records have a direct 1:1 mapping when it comes to the
filesystemcacheandhowitworks.Cachingiscoveredinthenextsection,butbasically,the
filesystem cache is responsible for loading portions of the store files into available RAM
for fast access. Paying close attention to the size of these store file records is an important
factor in being able to calculate what your memory and caching requirements may be.
11.1.4. Neo4j caches
Even with super-fast disks and Neo4j's efficient storage structure, a latency penalty will
always be incurred whenever processing requires a trip from the CPU to disk. This latency
penalty can be dramatically reduced if the data to be accessed can be held in memory
(RAMofsomesort)wherediskIOisreducedoreveneliminated.Neo4joperatesoptimally
when data is cached in memory.
So what does
in memory
mean, as far as Neo4j is concerned? Neo4j makes use of a two-
tiered caching strategy: the filesystem cache and object cache. These caches, as well as
where they live within the overall memory of a single server, are illustrated in
figure 11.2
.
