Data Access and Replication

How Does NuoDB Work?

The Catalog Atoms are key to how NuoDB works.

A catalog contains both relationship and runtime information.

  • The relationship data is the relationship between objects in the domain - what tables belong to the database, what rows and indexes do the tables have and so on

    • The red arrows in the diagrams below are the relationship information.

  • The runtime information holds keeps track of which engine (TE or SM) holds a copy of a given atom - these processes are termed the atom’s peers.

When a TE starts up, it loads the Master Catalog and its relationship data allows it to find all the schemas, sequences and tables in the database..

Master Catalog Atom
Figure 1. Master Catalog Atom

When the TE receives a SQL query:

  • It loads the Table atom(s) and corresponding Catalog(s) for the table(s) in the query.

    Database Catalog Atom
    Figure 2. Database Catalog Atom
  • The runtime information in a table’s Catalog atom tells the TE where (if at all) any of the other atoms for this table can be found.

  • Using this data, the TE can request the atoms it needs to fulfil the query (rows from the table, index structures) either from other TEs or an SM.

  • As it loads atoms, the TE becomes a peer for those atoms and is added to the runtime information for the relevant Catalogs.

  • After the first time, these atoms are cached and do not need to be refetched for subsequent queries.

New data is fetched in a similar way. This diagram shows the simple case of fetching a Data Atom in order to access some more rows from a table.

TE Fetching Data
Figure 3. TE Fetching Data

In general a TE is more likely to get data from another TE rather than from an SM because using the SM might involve a disk read.

Replicating changes