16.4 Keeping the Graph in Oracle Database Synchronized with the Graph Server
You can use the FlashbackSynchronizer
API to automatically apply changes made to graph in the database to the corresponding PgxGraph
object in memory, thus keeping both synchronized.
This API uses Oracle's Flashback
Technology to fetch the changes in the
database since the last fetch and then push those
changes into the graph server using the
ChangeSet
API. After the changes
are applied, the usual snapshot semantics of the
graph server apply: each delta fetch application
creates a new in-memory snapshot. Any queries or
algorithms that are executing concurrently to
snapshot creation are unaffected by the changes
until the corresponding session refreshes its
PgxGraph
object to the latest
state by calling the
session.setSnapshot(graph,
PgxSession.LATEST_SNAPSHOT)
procedure.
Also, if the changes from the previous fetch
operation no longer exist, then the synchronizer will throw an
exception. This occurs if the previous fetch duration is longer than
the UNDO_RETENTION
parameter setting in the database.
To avoid this exception, ensure to fetch the changes at intervals less
than the UNDO_RETENTION
parameter value. The default
setting for the UNDO_RETENTION
parameter is
900
seconds. See Oracle Database
Reference for more
information.
Prerequisites for Synchronizing
The Oracle database must have Flashback enabled and the database user that you use to perform synchronization must have:
- Read access to all tables which need to be kept synchronized.
- Permission to use flashback APIs. For example:
GRANT EXECUTE ON DBMS_FLASHBACK TO <user>
The database must also be configured to retain changes for the amount of time needed by your use case.
Types of graphs that can be synchronized
Not all PgxGraph
objects in PGX can be synchronized. The following limitations apply:
-
Only the original creator of the graph can synchronize it. That is, the current user must have the MANAGE permission of the graph.
- Only graphs loaded from database tables (PGQL property graphs and SQL property graphs) can be synchronized. Graphs created from other formats or graphs created via the graph builder API or PGQL property graphs created from database views cannot be synchronized.
- Only the latest snapshot of a graph can be synchronized.
Types of changes that can be synchronized
The synchronizer supports keeping the in-memory graph snapshot in sync with the following database-side modifications:
- insertion of new vertices and edges
- removal of existing vertices and edges
- update of property values of any vertex or edge
The synchronizer does not support schema-level changes to the input graph, such as:
- alteration of the list of input vertex or edge tables
- alteration of any columns of any input tables (vertex or edge tables)
Furthermore, the synchronizer does not support updates to vertex and edge keys.
For a detailed example, see the following topic:
- Synchronizing a SQL Property Graph
You can synchronize a SQL property graph that is loaded into the graph server (PGX) with the changes made to the graph data in the database. - Synchronizing a PGQL Property Graph
You can synchronize a PGQL property graph loaded into the graph server (PGX) with the changes made to the graph data in the database. - Synchronizing a Published Graph
You can synchronize a published graph by configuring the Flashback Synchronizer with aPartitionedGraphConfig
object containing the graph schema along with the database connection details.
Parent topic: Developing Applications with Graph Analytics
16.4.1 Synchronizing a SQL Property Graph
You can synchronize a SQL property graph that is loaded into the graph server (PGX) with the changes made to the graph data in the database.
16.4.2 Synchronizing a PGQL Property Graph
You can synchronize a PGQL property graph loaded into the graph server (PGX) with the changes made to the graph data in the database.
16.4.3 Synchronizing a Published Graph
You can synchronize a published graph by configuring the Flashback
Synchronizer with a PartitionedGraphConfig
object containing the graph
schema along with the database connection details.
PartitionedGraphConfig
object can be created either
through the PartitionedGraphConfigBuilder
API or by reading the graph
configuration from a JSON file.
Though synchronization of graphs created via graph configuration objects is supported in general, the following few limitations apply:
- Only partitioned graph configurations with all providers being database tables are supported.
- Each edge or vertex provider or both must specify the owner of the
table by setting the username field. For example, if user
SCOTT
owns the table, then set the user name accordingly for the providers. - Snapshot source must be set to
CHANGE_SET
. - It is highly recommended to optimize the graph for update operations in order to avoid memory exhaustion when creating many snapshots.
The following example shows the sample configuration for creating
the PartitionedGraphConfig
object:
{
...
"optimized_for": "updates",
"vertex_providers": [
...
"username":"<username>",
...
],
"edge_providers": [
...
"username":"<username>",
...
],
"loading": {
"snapshots_source": "change_set"
}
}
GraphConfig cfg = GraphConfigBuilder.forPartitioned()
…
.setUsername("<username>")
.setSnapshotsSource(SnapshotsSource.CHANGE_SET)
.setOptimizedFor(GraphOptimizedFor.UPDATES)
...
.build();
opg4j> var graph = session.readGraphWithProperties("<path_to_json_config_file>")
graph ==> PgxGraph[name=bank_graph_analytics_fb,N=999,E=4993,created=1664310157103]
opg4j> graph.publishWithSnapshots()
PgxGraph graph = session.readGraphWithProperties("<path_to_json_config_file>");
graph.publishWithSnapshots();
>>> graph = session.read_graph_with_properties("<path_to_json_config_file>")
>>> graph.publish_with_snapshots()
You can now perform the following steps to synchronize the published graph using a graph configuration object which is built from a JSON file.