Virtual nodes are classes that implement datarouter storage interfaces by wrapping underlying physical nodes. For example, Caching nodes wrap a persistent node plus a cache node, making it easier to keep the cache up to date. Or Replication nodes wrap a primary database node plus zero or more replica nodes, making it easier to create all the nodes and then control which physical node serves a read request.
<dependency>
<groupId>io.datarouter</groupId>
<artifactId>datarouter-virtual-node</artifactId>
<version>0.0.126</version>
</dependency>A caching node is typically used to add a cache like memcached in front of persistent storage like mysql. After creating the memcached and mysql nodes, pass them to the CachingNode constructor along with two booleans that should usually both be true:
- cacheOnRead: if there is a cache miss and the data is found in the backing node, then store it in the cache
- cacheOnWrite: update the cached value on every write.
For some performance critical situations, it's possible to chain the virtual CachingNodes together to build a tiered cache.
The Replication node is typically used with databases performing their own replication to possibly multiple replicas. Rather than building an explicit node
for each replica and accessing them individually at runtime, you pass the primaryClientId and multiple replicaClientIds to the virtual node and it will
create all the underlying nodes for you. Then at runtime, you can use new Config().anyDelay() to notify the Replication node that you prefer to
read from a replica if one exists, presumably because you want to reduce load on the harder-to-scale primary database. The current version uses a simple round-robin
approach to pick the replica for each read which is usually fine as long as there is only one replica or the multiple replicas are keeping up on replication.
A redundant node wraps two writable nodes, reading from the first but writing to both. The primary use case is migrating a table from one place to another, usually from one database server to another, but sometimes for renaming a table on the same server or switching to a table with a different column type. To use it you:
- create the target node, wrap the source and target in the redundant node, and deploy the code
- run a migration job, usually using the CopyTableHandler, which backfills the source node's data to the destination node
- change the redundant node to read from the target node, and deploy to validate that everything works
- wait for a safe-rollback period to pass
- remove the source and redundant nodes, leaving only the target node
This library is licensed under the Apache License, Version 2.0 - see LICENSE for details.