Here you will find technical articles, best practices, and community updates from the HugeGraph ecosystem:
HugeGraph (OLTP): Core graph database features, performance optimization, storage engines, and more
HugeGraph-AI: Application cases combining AI with graph computing
HugeGraph Computing (OLAP): Large-scale graph computing and analytical practices
Explore more content to enhance your graph database experience!
HugeGraph (OLTP)
ToplingDB
ToplingDB Quick Start
ToplingDB is a configurable and observable extension of RocksDB. It supports dynamic tuning via YAML files and enables real-time monitoring through a built-in Web Server.
Update hugegraph.properties
backend=rocksdb
serializer=binary
rocksdb.data_path=.
rocksdb.wal_path=.
# Path to YAML configuration file
# For security reasons, HG only allows YAML files to be located under the `conf/graphs` directory
rocksdb.option_path=./conf/graphs/rocksdb_plus.yaml
# Enable Web Server
rocksdb.open_http=true
Initialize the database (required on the first startup, or a new configuration was manually added under ‘conf/graphs/’)
cd *hugegraph-${version}bin/init-store.sh
Start server
bin/start-hugegraph.sh
Starting HugeGraphServer...
Connecting to HugeGraphServer (http://127.0.0.1:8080/graphs)....OK
Verify ToplingDB Is Working Properly
Prerequisite: Ensure Core Parameters Are Correctly Configured
Check that hugegraph.properties includes:
# Configuration file path
rocksdb.option_path=./conf/graphs/rocksdb_plus.yaml
# Enable Web Server
rocksdb.open_http=true
Method 1: Access the Web Monitoring Interface
Visualize the Web monitoring page. Example screenshot:
Verify via terminal:
# Access http://localhost:2011 (port depends on listening_ports in YAML config)curl http://localhost:2011 | grep topling
The following output indicates the page is working:
<p><ahref="https://topling.cn">Topling Inc.</a>This is <strong>Engine Inspector</strong>, for metrics, see <ahref='javascript:grafana()'>Grafana</a>!</p>
Method 2: Check ToplingDB Initialization Info in Logs
RocksDB provides a rich set of configuration parameters, but most of them typically require hardcoded setup.
ToplingDB introduces a SidePlugin + YAML mechanism, making configuration more modular and composable.
This document focuses on the extended parameters of ToplingDB, helping readers understand their purpose and usage.
0. rocksdb_plus.yaml used in HugeGraph
The following includes only the configuration parameters used in HugeGraph. For the full configuration supported by ToplingDB, refer to the SidePlugin Wiki:
http:# Web Server related configuration# normally parent path of db pathdocument_root:/dev/shm/rocksdb_resource# Static resource directory, extracted by `preload_topling.sh` in HugeGraphlistening_ports:'127.0.0.1:2011'# Web Server listening port for management/monitoringsetenv:# Environment variable settingsStrSimpleEnvNameNotOverwrite:StringValueIntSimpleEnvNameNotOverwrite:16384OverwriteThisEnv:#comment: overwrite is default to falseoverwrite:truevalue:force overwrite this env by overwrite trueCache:# Cache configurationlru_cache:# Define an LRU cache instanceclass:LRUCacheparams:capacity: 8G # Cache capacity:8GBnum_shard_bits:-1# Number of shards, -1 means autostrict_capacity_limit:falsehigh_pri_pool_ratio:0.5use_adaptive_mutex:falsemetadata_charge_policy:kFullChargeCacheMetadata# Metadata also counts toward cache capacityStatistics:# Sampling configurationstat:class:defaultparams:discard_tickers:# Discarded tickers to reduce overhead- rocksdb.block.cache- rocksdb.block.cachecompressed- rocksdb.block- rocksdb.memtable.payload.bytes.at.flush- rocksdb.memtable.garbage.bytes.at.flush- rocksdb.txn- rocksdb.blobdb- rocksdb.row.cache- rocksdb.number.block- rocksdb.bloom.filter- rocksdb.persistent- rocksdb.sim.block.cachediscard_histograms:# Discarded histogram metrics# comment: ....- rocksdb.blobdb- rocksdb.bytes.compressed- rocksdb.bytes.decompressed- rocksdb.num.index.and.filter.blocks.read.per.level- rocksdb.num.data.blocks.read.per.level- rocksdb.compression.times.nanos- rocksdb.decompression.times.nanos- rocksdb.read.block.get.micros- rocksdb.write.raw.block.micros# comment end of array#stats_level: kAllstats_level:kDisableAll # Disable all statisticsMemTableRepFactory:# MemTable implementation in memorycspp:# ToplingDB-specific high-concurrency memory structureclass:csppparams:mem_cap:16G# Preallocate sufficient virtual memory space; may reserve address space without actual allocationuse_vm:falsetoken_use_idle:truechunk_size:16K# Internal allocation granularityconvert_to_sst: kFileMmap # Convert MemTable directly to SST, skipping flush; options:{kDontConvert, kDumpMem, kFileMmap}sync_sst_file:false# Whether to fsync after SST conversion when using kFileMmapskiplist:# Default skiplist structure in RocksDBclass:SkipListparams:lookahead:0TableFactory:cspp_memtab_sst:class:CSPPMemTabTable# TableFactory paired with csppparams:# empty paramsbb:class:BlockBasedTable# Default block-based table in RocksDBparams:checksum:kCRC32cblock_size:4Kblock_restart_interval:16index_block_restart_interval:1metadata_block_size:4Kenable_index_compression:trueblock_cache:"${lru_cache}"# Use the LRU cache defined aboveblock_cache_compressed:persistent_cache:filter_policy:dispatch:class:DispatcherTableparams:default:bb# Default to BlockBasedTablereaders:BlockBasedTable:bbCSPPMemTabTable:cspp_memtab_sstlevel_writers:[bb, bb, bb, bb, bb, bb ]# Custom write strategy per levelCFOptions:default:max_write_buffer_number:6memtable_factory:"${cspp}"# Reference cspp defined abovewrite_buffer_size:128M# set target_file_size_base as small as 512K is to make many SST files,# thus key prefix cache can present efficiencytarget_file_size_base:64Mtarget_file_size_multiplier:1table_factory:dispatch# Reference dispatch defined abovemax_bytes_for_level_base:512Mmax_bytes_for_level_multiplier:10level_compaction_dynamic_level_bytes:falselevel0_slowdown_writes_trigger:20level0_stop_writes_trigger:36level0_file_num_compaction_trigger:2merge_operator:uint64add# support mergelevel_compaction_dynamic_file_size:trueoptimize_filters_for_hits:trueallow_merge_memtables:truemin_write_buffer_number_to_merge:2compression_per_level:- kNoCompression- kNoCompression- kSnappyCompression- kSnappyCompression- kSnappyCompression- kSnappyCompression- kSnappyCompressionDBOptions:dbo:create_if_missing:truecreate_missing_column_families:false# this is important, must be false to hugegraphmax_background_compactions:-1max_subcompactions:4max_level1_subcompactions:0inplace_update_support:falseWAL_size_limit_MB:0statistics:"${stat}"# Use the statistics config defined abovemax_manifest_file_size:100Mmax_background_jobs:8compaction_readahead_size:0memtable_as_log_index: true # Combined with convert_to_sst:kFileMmap to enable [omit L0 Flush](https://github.com/topling/toplingdb/wiki/Omit-L0-Flush)
Key points:
listening_ports: '127.0.0.1:2011' sets the Web Server listening port to 2011 and restricts access to localhost.
memtable_as_log_index: true combined with convert_to_sst: kFileMmap enables omit L0 Flush.
memtable_factory: "${cspp}" specifies the memory structure as CSPP Memtable.
table_factory: dispatch sets the TableFactory to the custom DispatcherTable defined in YAML.
1. Plugin-based configuration and reference mechanism
YAML modularization: The configuration file is organized as objects; each object can be defined independently and referenced elsewhere.
Reference syntax: Objects can be reused across sections via ${lru_cache}, ${cspp}, etc.
DispatcherTable: Allows selecting different TableFactories at different levels or scenarios. RocksDB natively supports only a single TableFactory.
ToplingDB YAML Reference and Reuse Diagram:
This mechanism makes configuration more flexible and easier to compose in complex scenarios.
2. New MemTable implementation: CSPP
ToplingDB provides a MemTable type that RocksDB does not natively have, configured with the following parameters:
mem_cap
mem_cap is the size of the virtual address space reserved for CSPP. This may be just reserved address space without actual physical allocation.
The actual memory usage of mem_cap is approximately equal to write_buffer_size.
Background of mem_cap Design
The underlying algorithm of CSPP adopts a pre-allocation strategy to support high-concurrency writes.
Once the pre-allocated memory is filled, no further writes can proceed.
However, RocksDB itself lacks a mechanism that allows a memtable to actively report
“the pre-allocated memory is full, a new memtable is required”.
Due to the complexity of its call chain, it is impractical to refactor RocksDB to add this capability.
Therefore, CSPP adapts to RocksDB’s behavior through parameter design.
Core Idea of mem_cap
ToplingDB sets mem_cap to be much larger than write_buffer_size,
so that RocksDB will not prematurely trigger an “out of memory” error when writing to a memtable.
During CSPP initialization (New), the system rechecks the setting.
If mem_cap is found to be too small, it will be automatically adjusted to 2 * write_buffer_size to ensure stability during the write process.
The default value is 2G, and the effective maximum is 16G.
Small deployments (<16GB RAM): set to 20–30% of system memory
Medium deployments (16–64GB RAM): set to 8–16G
Large deployments (>64GB RAM): set to 16G
use_vm
When allocating memory via malloc/posix_memalign, the address space may already be physically allocated (heap space with mapped pages), while CSPP only needs reserved virtual address space. When use_vm is true, allocation is forced to use mmap, ensuring reserved address space without occupying physical pages. The default is true. If physical memory is sufficient, it is recommended to disable this option—establishing mappings from mmap’s virtual memory to physical pages can trigger many minor page faults and may affect performance.
convert_to_sst
convert_to_sst supports three enum values:
kDontConvert: Disables the feature (default). Uses the traditional Flush process, offering the best compatibility for stability-focused scenarios.
kDumpMem: During conversion, dumps the entire MemTable memory to an SST file, reducing CPU consumption but not memory usage.
kFileMmap: mmaps MemTable content into a file—the key feature—reduces both CPU and memory usage. You can also set DBOptions.memtable_as_log_index = true to essentially eliminate MemTable Flush.
These parameters offer more tunable options for the write path, allowing users to choose as needed.