Indexing the data - Neo4j in Action - page 108

An extra hundredth of a millisecond probably won't make much difference in this case,
evenwithamillionusers,becauseit'slikelythatyou'llcreatethisusernodeoncewhenthe
user registers and then update it infrequently. But this won't be the case in all applications.
Where data is updated or created more frequently than it's read, thought should be given
to the performance trade-off between fast updates and fast finds. It's also likely that you'll
need to access your graph data in different ways, so you may have many indexes such as
ZIP code, age, and sex, and each of these will further increase the performance overhead
for inserts and updates.
In addition to the performance penalty of indexes, each index requires additional storage,
and we'll look at that very briefly next.
5.6.3. Storing the index
The process of indexing essentially involves creating small lookup tables (small compared
to the data set), which allow fast access to the right place in the graph. This means that in
addition to the performance overhead of writing out the extra index data, you'll need more
disk space to store all of this data.
5.7. Summary
In this chapter, you've seen that Neo4j provides flexible mechanisms that allow Neo4j ap-
plications to quickly focus in on the parts of the graph that are of interest. But with that
flexibility comes the need to consider trade-offs when deciding what to index and what not
to index.
This concludes part 1 of the topic, in which we described all the basic concepts and
techniques for dealing with graph data in the Neo4j database. In part 2 , we're going to
take an in-depth look at some key concepts in Neo4j. First we're going to learn about
Cypher—Neo4j's human graph query language!