NoSQLBench is a large project. It has a few basic layers of functionality which nest together like a system of modules and interfaces:
- Core APIs
- Annotations and Processors
- Core Runtime
- Virtual Data Subsystem
- Extensions and Plugins
- Driver Adapters
SPI and Modules
Nearly all of the functionality in NoSQLBench is wired together at runtime through a service discovery mechanism. This allows modules to be bundled within the project and packaged together as needed. At runtime, when a particular set of components is called up to be used together, the runtime uses Java's SPI mechanism to discover and map them by a name, called a selector.
You will see this throughout the project in the form of a
@Service(...) annotation. Any
component withing the code base which needs to be realized at runtime must have this. The
built-in annotation processors do the packing work to put these into the standard service manifest
If you are building a driver adapter, you don't need to understand the whole project structure. You simply need to implement the DriverAdapter interface. You only need the adapters-api module as an upstream dependency.
Insert Module Graph Here
This will be a visual of all the core modules.
(Java) Package Naming
All of the modules in the project follow a minimum structural standard. The internal package
names must have the prefix
io.nosqlbench.[module-name] where the module name has its
non-words replaced with package boundaries.
This means that module named
adapter-diag lives in a directory under the main project of the
same name. It has a package named
io.nosqlbench.adapter.diag in which all of its driver code
This makes it easy to know what module any package is part of simply from the name.