92 lines
3.8 KiB
Plaintext
92 lines
3.8 KiB
Plaintext
emqx_ds_schema {
|
|
|
|
messages.label: "MQTT message storage"
|
|
messages.desc:
|
|
"""~
|
|
Configuration related to the durable storage of MQTT messages.~"""
|
|
|
|
builtin.label: "Builtin backend"
|
|
builtin.desc:
|
|
"""~
|
|
Builtin session storage backend utilizing embedded RocksDB key-value store.~"""
|
|
|
|
builtin_backend.label: "Backend type"
|
|
builtin_backend.desc:
|
|
"""~
|
|
Built-in backend.~"""
|
|
|
|
builtin_data_dir.label: "Database location"
|
|
builtin_data_dir.desc:
|
|
"""~
|
|
File system directory where the database is located.
|
|
|
|
By default, it is equal to `node.data_dir`.~"""
|
|
|
|
builtin_n_shards.label: "Number of shards"
|
|
builtin_n_shards.desc:
|
|
"""~
|
|
The built-in durable storage partitions data into shards.
|
|
This configuration parameter defines the number of shards.
|
|
Please note that it takes effect only during the initialization of the durable storage database.
|
|
Changing this configuration parameter after the database has been already created won't take any effect.~"""
|
|
|
|
builtin_local_write_buffer.label: "Local write buffer"
|
|
builtin_local_write_buffer.desc:
|
|
"""~
|
|
Configuration related to the buffering of messages sent from the local node to the shard leader.
|
|
|
|
EMQX accumulates PUBLISH messages from the local clients in a write buffer before committing them to the durable storage.
|
|
This helps to hide network latency between EMQX nodes and improves write throughput.~"""
|
|
|
|
builtin_local_write_buffer_max_items.label: "Max items"
|
|
builtin_local_write_buffer_max_items.desc:
|
|
"""~
|
|
This configuration parameter defines maximum number of messages stored in the local write buffer.~"""
|
|
|
|
builtin_local_write_buffer_flush_interval.label: "Flush interval"
|
|
builtin_local_write_buffer_flush_interval.desc:
|
|
"""~
|
|
Maximum linger time for the buffered messages.
|
|
Local write buffer will be flushed _at least_ as often as `flush_interval`.
|
|
|
|
Larger values of `flush_interval` may lead to higher throughput and better overall performance, but may increase end-to-end latency.~"""
|
|
|
|
builtin_layout.label: "Storage layout"
|
|
builtin_layout.desc:
|
|
"""~
|
|
Storage layout is a method of arranging messages from various topics and clients on disc.
|
|
|
|
Depending on the type of workload and the topic structure, different types of strategies for storing the data can be employed to maximize efficiency of reading messages from the durable storage.~"""
|
|
|
|
layout_builtin_wildcard_optimized.label: "Wildcard-optimized storage layout"
|
|
layout_builtin_wildcard_optimized.desc:
|
|
"""~
|
|
_Wildcard-optimized_ layout is designed to maximize the throughput of wildcard subscriptions covering large numbers of topics.
|
|
|
|
For example, it can handle scenarios where a very large number of clients publish data to the topics containing their client ID, such as: `sensor/%device-version%/%clientid%/temperature`, `sensor/%device-version%/%clientid%/pressure`, etc.
|
|
This layout will automatically group such topics into a single stream, so a client subscribing to a topic filter containing wildcards (such as `sensor/+/+/temperature`) will be able to consume messages published by all devices as a single batch.
|
|
|
|
This layout is efficient for non-wildcard subscriptions as well.~"""
|
|
|
|
layout_builtin_wildcard_optimized_type.label: "Layout type"
|
|
layout_builtin_wildcard_optimized_type.desc:
|
|
"""~
|
|
Wildcard-optimized layout type.~"""
|
|
|
|
wildcard_optimized_epoch_bits.label: "Epoch bits"
|
|
wildcard_optimized_epoch_bits.desc:
|
|
"""~
|
|
Wildcard-optimized layout partitions messages recorded at different times into "epochs".
|
|
Reading messages from a single epoch can be done very efficiently, so larger epochs improve the throughput of subscribers, but may increase end-to-end latency.
|
|
|
|
Time span covered by each epoch grows exponentially with the value of `epoch_bits`:
|
|
|
|
- `epoch_bits = 1`: epoch time = 1 millisecond
|
|
- `epoch_bits = 2`: 2 milliseconds
|
|
...
|
|
- `epoch_bits = 10`: 1024 milliseconds
|
|
- `epoch_bits = 13`: ~8 seconds
|
|
...~"""
|
|
|
|
}
|