Neo4j in production - Neo4j in Action - page 297

• Physical storage —What kind and how much of it will be needed?
• Memory —Howmuchmemory(RAM)andCPUsarerequiredtosupportefficient
and performant running of the application and database?
• Scalability and redundancy —What's required to ensure Neo4j can scale to ac-
commodate a growing load, to ensure that it's highly available (or available
enough), and to ensure it can be properly backed up and restored in the event of
failure?
Working backward, recovery and backups are covered in section 11.3 , HA is covered in
section 11.2 , and the memory- and CPU-related questions in section 11.1.4 . First up, we'll
tackle the question of storage and disks, which leads us neatly to our starting point at the
bottom of Neo4j's architectural stack.
11.1.2. Disks
At the bottom of the architectural stack are the physical disks where Neo4j actually stores
the graph data.
What kind of disks should be used?
Neo4j doesn't dictate what kind of disks should be used, but it goes without saying that
faster disks will lead to faster performance whenever physical disk IO is required. Making
useofdisksthatprovidelowerseektimes(suchassolidstatedrives,a.k.a.SSDs)willgen-
erallyprovidearead-performanceboostof10to20timesthatoftraditionalspinningdisks.
As you'll learn in section 11.1.4 , you should aim to keep as much of the graph in memory
as possible, as this reduces disk IO, which helps enable Neo4j to perform at its best. At
some point, however, your application or database will need to go to disk to read data. At
the very least, this will occur when you initially start up your database and begin to access
cold parts of the graph. It may also occur if your graph is simply too big to fit into memory
(see section 11.2.4 on cache sharding).
Avoiding disk IO is one of the key factors in maximizing Neo4j performance, and having
speedy disks for the times when this IO can't be avoided can make quite a difference.