Backends

Introduction

RRD4J uses backend objects to store actual bytes for RRD database.

Details

Each Round Robin Database object (RrdDb object) is backed with a single RrdBackend object which performs actual I/O operations on the underlying storage. The RrdBackend object is itself not created directly but through factories, that are object instanciated from RrdBackendFactory derivated classes.

RRD backend are registered and managed through the static methods RrdBackendFactory.setActiveFactories(RrdBackendFactory...) and RrdBackendFactory.addActiveFactories(RrdBackendFactory...). It defined a ordered list of used factories.

When a RRD database is created without the factory argument and the path is given as simple string, or through the RrrDbPool, it use the first factory specified with RrdBackendFactory.setActiveFactories(RrdBackendFactory...). But each factories can identify RrdDb using URI. So when a RrdDb is identify by an URI, each active factory is tried against this URI and the first one that accept this URI will handle it. It allows to have different of the same backend with different configuration. For more details, see the javadoc.

Factory classes are used to create concrete RrdBackend implementations. Each factory creates unlimited number of specific backend objects. Rrd4j supports six different backend types (backend factories) out of the box:

• FILE: objects of this class are created from the RrdFileBackendFactory class. This was the default backend used in all Rrd4j releases before 1.4.0 release. It uses java.io.* package and RandomAccessFile class to store RRD data in files on the disk. URI scheme is file.
• SAFE: objects of this class are created from the RrdSafeFileBackendFactory class. It uses java.io.* package and RandomAccessFile class to store RRD data in files on the disk. This backend is safe: it locks the underlying RRD file during update/fetch operations, and caches only static parts of a RRD file in memory. Therefore, this backend is safe to be used when RRD files should be shared between several JVMs at the same time. URI scheme is file.
• NIO: objects of this class are created from the RrdNioBackendFactory class. The backend uses java.io.* and java.nio.* classes (mapped ByteBuffer) to store RRD data in files on the disk. This is the default backend since 1.4.0 release. It can be quite heavy on memory, because of the memory mapping of files. URI scheme is file.
• MEMORY: objects of this class are created from the RrdMemoryBackendFactory class. This backend stores all data in memory. Once JVM exits, all data gets lost. The backend is extremely fast and memory hungry. URI scheme is memory.
• BERKELEY: objects of this class are created from the RrdBerkeleyDbBackendFactory class. It stores RRD data to ordinary disk files using Oracle Berkeley DB Java Edition. URI scheme is berkeley.
• MONGODB: objects of this class are created from the RrdMongoDBBackendFactory class. It stores data in a DBCollection from MongoDB. URI scheme is mongodb.

Each backend factory is identified by the scheme in the URI it can handle. Constructors are provided in the RrdDb class to create RrdDb objects (RRD databases) backed with a specific backend.

Using a custom backend

Any implementation of RrdBackend can be used directly when creating or opening a Rrdb. It's not mandatory to register it, unless if access by name is needed, like:

RrdBackendFactory factory = new CustomFactory(...);
RrdDb db = new RrdDb(path, factory);