Common usage

The GDS library usage pattern is typically split in two phases: development and production. In the development phase the goal is to establish a workflow of useful algorithms. In order to do this, the system must be configured, graph projections must be defined, and algorithms must be selected. It is typical to make use of the memory estimation features of the library. This enables you to successfully configure your system to handle the amount of data to be processed. There are two kinds of resources to keep in mind: the projected graph and the algorithm data structures.

In the production phase, the system would be configured appropriately to successfully run the desired algorithms. The sequence of operations would normally be to project a graph, run one or more algorithms on it, and consume results.

The below image illustrates an overview of standard operation of the GDS library:

projected graph model

The GDS library runs its procedures greedily in terms of system resources. That means that each procedure will try to use:

  • as much memory as it needs (see Memory estimation)

  • as many CPU cores as it needs (not exceeding the limits of the concurrency it’s configured to run with)

Concurrently running procedures share the resources of the system hosting the DBMS and as such may affect each other’s performance. To get an overview of the status of the system you can use the System monitor procedure.

The more detail on each individual operation, see the corresponding section:

  1. Graph Catalog

  2. Projecting graphs

  3. Running algorithms

In this chapter, we will go through these aspects and guide you towards the most useful operations.

This chapter is divided into the following sections: