A remote backend lets a graph neural network train when its graph is too large to hold in memory. Rather than preprocess and load the whole dataset before training, PyTorch Geometric (PyG) samples mini-batches from storage and processes them as training proceeds. The interface is designed to work with different storage systems. section 7.9
A PyG remote-backend pipeline has four practical parts:
- Remote data sources hold the graph structure and node features. A graph database and a key-value store are recommended options, respectively. section 7.9
- A GraphStore supplies edge indices for node sampling; a FeatureStore supplies node features. Custom implementations must connect reliably to their databases and handle the stored data. section 7.9 section 7.9.1
- A sampler selects the data needed for each batch, and a NodeLoader brings the stores and sampler into the training loop. section 7.9 section 7.9.1
Listing 7.3 Loader object using remote backend
loader = NodeLoader(
data=(feature_store, graph_store),
node_sampler=node_sampler,
batch_size=20,
input_nodes='paper',
)
for batch in loader:
<training loop>
The loader example passes a FeatureStore and GraphStore together as `data`, supplies a node sampler, and iterates over batches in a training loop. section 7.9
A graph that will not fit in memory
For a large traffic graph, Neo4J can hold graph structure while RocksDB holds node features such as location type and historical traffic. Getting to training still requires loading and validating the databases, implementing both stores, testing a sampling strategy, and tuning the loader to limit I/O delays. section 7.9.1
The payoff is that dataset size is bounded by storage capacity rather than training memory. The costs are I/O latency, setup and maintenance work, and a more complex system to debug. At the time described, PyG remote backends supported node features but not edge features. section 7.9 section 7.3.1
