Skip to content
lkairies edited this page Jun 12, 2014 · 1 revision

Configuration options

Hints on how the options are named in a properties-file are given below the explanations of the fields.

public BabuDBConfig(String baseDir, String dbLogDir, int numThreads,
            long maxLogfileSize, int checkInterval, SyncMode syncMode, int pseudoSyncWait,
            int maxQ, boolean compression)

baseDir

The directory in which all database index files are stored. Each database uses a subdirectory with the database name.

Name in the properties-file: babudb.baseDir
Default value: n.a. - field is required

checkInterval

The number of seconds between two checks of the disk log size for automatic checkpointing. Set this value to 0 to disable automatic checkpointing.

Name in the properties-file: babudb.checkInterval
Default value: 0

compression

Flag that determines whether the indices shall be compressed or not. Details on how this compression works can be found [http://code.google.com/p/babudb/wiki/DiskIndexCompression here].

Name in the properties-file: babudb.compression
Default value: false

dbLogDir

The database disk logs are stored in this directory. It can be the same as baseDir. For better performance, the disk logs should use a different hard disk than the index files. For maximum performance the disk logs can be stored on a SSD.

Name in the properties-file: babudb.logDir
Default value: n.a. - field is required

maxLogfileSize

If automatic checkpointing is enabled, a checkpoint is created when the disk logfile exceedes maxLogfileSize bytes. The value should be reasonable large to keep the checkpointing-rate low. However, it should not be too large as a large disk log increases the recovery time after a crash.

Name in the properties-file: babudb.maxLogfileSize
Default value: 1

pseudoSyncWait

The BabuDB disk logger can batch multiple operations into a single write+fsync to increase the throughput. This does only work if there are operations executed in parallel by the worker threads. In turn, if you work on a single database it becomes less efficient.

To circumvent this problem, BabuDB offers a pseudo-sync mode which is similar to the PostgreSQL write-ahead log (WAL). If pseduoSyncWait is set to a value larger then 0, this pseudo-sync mode is enabled.

In this mode, insert operations are acknowledged as soon as they have been executed on the in-memory database index. The disk logger will execute a batch write of up to 500 operations followed by a single sync (see syncMode) every pseudoSyncWait ms. This mode is considerably faster than synchronous writes but you can lose data in case of a crash. In contrast to ASYNC mode the data loss is limited to the operations executed in the last pseudoSyncWait ms.

Name in the properties-file: babudb.pseudoSyncWait
Default value: 0

syncMode

The sync mode influences how operations are commited to the disk log before the operation is acknowledged to the caller.

  • ASYNC mode the writes to the disk log are buffered in memory by the operating system. This is the fastest mode but will lead to data loss in case of a crash, kernel panic or power failure.
  • SYNC_WRITE_METADATA opens the file with O_SYNC, the system will not buffer any writes. The operation will be acknowledged when data has been safely written to disk. This mode is slow but offers maximum data safety. However, BabuDB cannot influence the disk drive caches, this depends on the OS and hard disk model.
  • SYNC_WRITE similar to SYNC_WRITE_METADATA but opens file with O_DSYNC which means that only the data is commit to disk. This can lead to some data loss depending on the implementation of the underlying file system. Linux does not implement this mode.
  • FDATASYNC is similar to SYNC_WRITE but opens the file in asynchronous mode and calls fdatasync() after writing the data to disk.
  • FSYNC is similar to SYNC_WRITE_METADATA but opens the file in asynchronous mode and calls fsync() after writing the data to disk.

For best throughput use ASYNC, for maximum data safety use FSYNC.

Name in the properties-file: babudb.sync
Default value: n.a. - field is required

maxQ

If set to a value larger than 0, this is the maximum number of requests which can be in a worker's queue. This value should be used if you have pseudo-synchronous mode enabled to ensure that your queues don't grow until you get an out of memory exception. Can be set to 0 if pseudo-sync mode is disabled.

Name in the properties-file: babudb.worker.maxQueueLength
Default value: 0

numThreads

The number of worker threads to be used for database operations. As BabuDB does not use locking, each database is handled by only one worker thread. If there are more databases than worker threads, the databases are distributed onto the available threads. The number of threads should be set to a value smaller than the number of available cores to reduce overhead through context switches. You can also set the number of worker threads to 0. This will considerably reduce latency, but may also decrease throughput on a multicore system with more than one database.

Name in the properties-file: babudb.worker.numThreads
Default value: 1

debugLevel

0 = emergency
1 = alert
2 = critical
3 = error
4 = warning
5 = notice
6 = info
7 = debug

Name in the properties-file: babudb.debug.level
Default value: 4

maxNumRecordsPerBlock

Sets the maximum number of key-value pairs per internal database block. The less blocks are stored per index, the faster the lookups and the higher the memory footprint will be.

Name in the properties-file: babudb.maxNumRecordsPerBlock
Default value: 64

disableMMap

Disables memory mapping of index files. Memory mapping makes it possible to efficiently read content from files. However, there may be limits on the total amount of memory that may be mapped by a single process, especially on 32 bit JVMs. To avoid 'map failed' errors, memory mapping can be explicitly disabled with this option.

Name in the properties-file: babudb.disableMmap
Default value: false

mmapLimit

Sets an upper bound for the total amount of memory that may be mapped by BabuDB. If databases size exceed this limit in MB, memory mapping will be internally switched off. This parameter has no effect if memory mapping is switched off.

Name in the properties-file: babudb.mmapLimit
Default value: 200

##Replication related options##

BabuDB uses a master-slave related replication model. All BabuDB instances participating on the replication can be declared to master or slave. A slave does obey only one master at a time.

public ReplicationConfig(String baseDir, String logDir, int numThreads, 
            long maxLogFileSize, int checkInterval, SyncMode mode, 
            int pseudoSyncWait, int maxQ, Set<InetSocketAddress> participants, 
            int localTimeRenew, SSLOptions sslOptions, int syncN, 
            String backupDir, boolean compression)

"baseDir", "logDir", "numThreads", "mayLogFileSize", "checkInterval", "mode", "pseudoSyncWait", "maxQ" and "compression" are used in the same way as described above.

backupDir

DB backup directory - needed for the initial loading of the BabuDB from the master BabuDB.

Name in the properties-file: babudb.repl.backupDir
Default value: n.a. - field is required

localTimeRenew

Intervall in milliseconds for synchronizing the message-transmitting-facilities (ONCRPCServer and ONCRPCClient) with the local clock. This value must not be less than the worst expected timedrift of the synchronized system clock.

Name in the properties-file: babudb.localTimeRenew
Default value: 3000

participants

The addresses of the hosts running an instance of BabuDB and participating at the replication. The local address is also required in this list. BabuDB will find out on its own, which of the given addresses is the local one.

Field babudb.repl.participant.i defines the domain-name or IP-address.
Field babudb.repl.participant.i.port defines the port.

Name in the properties-file:
babudb.repl.participant.0
babudb.repl.participant.0.port
babudb.repl.participant.1
babudb.repl.participant.1.port
...
babudb.repl.participant.n
babudb.repl.participant.n.port
-for n participants.
Default value: n.a. - fields are required

syncN

The number of slaves that at least have to be synchronous to the master BabuDB application. To use asynchronous replication, this value has to be set to 0. Otherwise it has to be less or equal to the number of participants.

Name in the properties-file: babudb.repl.sync.n
Default value: 0

sslOptions

Options to use a secure connection with SSL authenticaion and optionally encryption.

Name in the properties-file: babudb.ssl.enabled
Default value: n.a. - field is required.

If babudb.ssl.enabled is set true, following fields are required:

  • Flag that determines if authentication should be used without encrypting the connection:

    • babudb.ssl.authenticationWithoutEncryption
  • Server credentials for SSL handshakes:

    • babudb.ssl.service_creds
    • babudb.ssl.service_creds.pw
    • babudb.ssl.service_creds.container
  • Trusted certificates for SSL handshakes:

    • babudb.ssl.trusted_certs
    • babudb.ssl.trusted_certs.pw
    • babudb.ssl.trusted_certs.container

##Additional fields not configurable within the constructors, but through the properties file##

config file

Name for the database configuration file.

Name in the properties-file: babudb.cfgFile
Default value: config.db

debug category

Not supported at the moment!

Name in the properties-file: babudb.debug.category
Default value: all

chunk size

At the initial load mechanism the database files will be split into chunks. The size of this chunks in bytes can be defined here.

Name in the properties-file: babudb.repl.chunkSize
Default value: 5242880