Envelope Storage
Starting with version 3.3.0, Xbus provides a more efficient way to store the envelopes in the database. This new storage is not enabled by default.
A typical post-3.3.0 migration configuration would be:
storage:
envelope:
impl: sql-ng
fallback: sql
cache:
enabled: true
max-size: 1G
Primary Storage
Setting the primary storage, ie the storage for new envelopes, is done with the
option storage.envelope.impl. It can take one of the following values:
sql(default). The historical envelope storage. It stores the envelope content in different tables, allowing an access to the envelope inner data.The tables used are:
envelope: store the envelope metadataevent: store the message metadata (id, sum…)item: store data chunks of the messages
This storage has some performances issues, as it has to split then rebuild the fragments all the time.
sql-ng. This storage stores directly the serialized envelope fragments, allowing a much faster read and write.It uses the following tables:
envelope_storagestores the envelope metadataenvelope_storage_datastores the fragments
Fallback storage
As there is no way to migrate envelopes from a storage to another, a mechanism of fallback storage is provided.
It allows to specify a secondary storage, which will be used for reading envelopes that are not found in the primary storage.
The setting is storage.envelope.fallback, and the possible values are the
same as storage.envelope.impl.
Cache
A cache can be enabled on top of the chosen storage. Two options are available:
storage.envelope.cache.enabledEnable the cache
storage.envelope.cache.max-size(default
1073741824(ie 1GiB)) Set the cache size, in bytes.
Metrics
When xbusd metrics are enabled, new metrics are available:
xbus_storage_calls, a summary with the following dynamic labels:name: The storage name (“cache”, “default”…)implementation: The storage implementation (“cache”, “sql”, “sql-ng”)function: The function. Possible values are:ReadEnvelope: Read a fragmentStoreEnvelope: Store a fragment