-
Notifications
You must be signed in to change notification settings - Fork 10
creation.conf settings
# ----------------#
# Global settings #
# --------------- #
root_path=/home/feiben/DBTest/
database_name = RTSeventhDB
port = 30860
linux_X86_native_enabled = yes
multi_process_support_enabled = yes
# --------------------#
# End Global settings #
# ------------------- #
# ----------------#
# runtime tunable #
# --------------- #
# -------------------- memory ---------------------#
# -lunarDB uses parameters as left offset: #
# -1 << $number . #
# -e.g. if bit_buff_length = 25, #
# -the real memeory consumes 1 << 25 = 32M bites, #
# -db restart is required if one needs changes take#
# -effective immediatly #
# ------------------------------------------------ #
bit_buff_length = 15
cache_blocks_in_memory = 8
cache_keys_in_memory = 8
cache_records_in_memory = 12
# ---------------- concurrency --------------------#
# -db restart is required if user needs changes #
# -take effective immediatly #
# ------------------------------------------------ #
internal_cache_concurrent_level = 17
ultimate_socket_concurrent_connections = 1000
# --------------------#
# End runtime tunable #
# ------------------- #
# ---------------- real time mode ------------------------- #
# rt_mode and search_engine_mode can be on or off. #
# --------------------------------------------------------- #
search_engine_mode = off
rt_mode = on
# The memory page size of your system. For most cases, it is 4K = 1<<12 bytes
rt_mem_page_size = 12
# maximum page table entries. Default is 4K = 1<< 12.
# Each entry manages 1024 pages, with page size of 4096 bytes.
# LunarMax internal has 16 tables,
# hence by default, the maximum 256GB = 16 * 4096 * 1024 * 4096 memory can be used.
#
# If rt_virtual_mem_enabled is turned off, LunarMax acquires memory directly from OS,
# and will never use extra swap space to extend the physical memory. The OS takes the responsibility
# to swap in-and-out hot and cold pages. In this mode, LunarMax has no controll of
# how many memory will be used, and will race memory resource with other services
# running on the same server.
#
# If rt_virtual_mem_enabled is on, LunarMax takes the controll of memory consumption.
# For example, set rt_max_memory = 28, then at most 256MB = 1 << 28 physical memory will be used.
# Theoretically on a 64-bit machine, virtual memory has no limitation.
# We strongly suggest locating the swap space (by rt_vm_swap) on a SSD device for quick page exchange.
rt_virtual_mem_enabled = on
rt_max_memory = 28
rt_max_virtual_pte = 12
rt_vm_swap = /home/feiben/DBTest/Swap
# for float data: 0 for integer, 1 for 0.1, 2 for 0.01, 3 for 0.001, and so on.
rt_precision = 3
# threads for real time computation.
# Concerning performance, rt_threads+ internal_cache_concurrent_level
# will never exceeds the threads that OS can provide.
# One property with one thread gives the best performance.
rt_threads = 4
# ------------------------------#
# unchangable after creating #
# ----------------------------- #
# -------------------- storage --------------------#
# -lunarDB uses these parameters as left offset: #
# -1 << $number . #
# -e.g. if mani_file_bit_len = 18, #
# -the memeory consumption then is 1 << 18 = 256K, #
# -db rebuild is required if one need changes of #
# -any storage specifications take effective #
# -immediatly #
# ------------------------------------------------ #
mani_file_bit_len = 18
records_table_file_bit_len = 28
# -------------------- file system level ----------#
# Maximum block level controlls the size of blocks #
# of Lunar virtual file system. #
# -level 0: block size = 64 bit, #
# -level 1: block size = 512 bit, #
# -level 2: block size = 4K bit, #
# -level 3: block size = 32K bit, #
# Maximum level 2 serves well for most of the #
# applications with lunardb as their infrastructure#
# ------------------------------------------------ #
block_ultimate_level = 2
# --------------------------------- #
# End unchangable after creating #
# --------------------------------- #
1 Home
1.1 summary
1.2 System Preparation
1.3 When LunarBase is your best choice
1.4 Benchmark
1.5 Power consumption
2 Data Model And Process
2.1 Why internal big cache
2.2 Memory Management: LunarMMU
2.3 Garbage Collection
2.4 Transaction Log
2.5 JOIN via materialized view
3 Real Time Computation: LunarMax
3.1 In-Memory File System: Memory Estimation
3.2 Configuration
3.3 Use SSD as a cheaper memory
3.4 Data Safety
3.5 HE Server VS. Cluster
3.6 High Availability
4 Create a database
4.1 Three modes
4.2 creation.conf settings
4.3 Table space
4.4 Multiple Instance
4.5 Database Status
4.6 Remove and Restore a table
5 Insertion
5.1 Insert as normal record
5.2 Insert to search engine
6 Query
6.1 Point Query
6.2 Result Handler: register your own event handler
6.3 Interpreter Pattern: complex query conditions
6.4 Range Query
6.5 Full-text Search
6.6 Algebraic Logical Query
8 Deletion
9 Materialized view
9.1 Eventual consistency
9.2 Update
9.3 MVCC in LunarBase
9.4 Easy JOIN via denormalization
9.5 CRUD in view
10 Distributed integration with
10.1 Kafka
10.2 Storm
10.3 Spark
11 Storage: Lunar Virtual File System
13 Roadmap of LunarBase future
15 FAQ