SSDB 配置文件详解
SSDB 的配置非常简单, 附带的 ssdb.conf 你不用修改便可以使用. 如果你要高度定制, 还是需要修改一些配置的. 下面做介绍.
SSDB 的配置文件是一种层级 key-value 的静态配置文件, 通过一个 TAB 缩进来表示层级关系. 以 '#' 号开始的行是注释. 标准的配置文件如下:
# ssdb-server config
# relative to path of this file, must exist
work_dir = ./var
pidfile = ./var/ssdb.pid
server:
ip: 127.0.0.1
port: 8888
replication:
slaveof:
# sync|mirror, default is sync
#type: sync
#ip: 127.0.0.1
#port: 8889
logger:
level: info
output: log.txt
rotate:
size: 1000000000
leveldb:
# in MB
cache_size: 500
# in KB
block_size: 32
# in MB
write_buffer_size: 64
# in MB
compaction_speed: 100
# yes|no
compression: yeswork_dir: ssdb-server 的工作目录, 启动后, 会在这个目录下生成 data 和 meta 两个目录, 用来保存 LevelDB 的数据库文件. 这个目录是相对于 ssdb.conf 的相对路径, 也可以指定绝对路径.
server: ip 和 port 指定了服务器要监听的 IP 和端口号. 如果 ip 是 0.0.0.0, 则表示绑定所有的 IP. 基于安全考虑, 可以将 ip 设置为 127.0.0.1, 这样, 只有本机可以访问了. 如果要做更严格的更多的网络安全限制, 就需要依赖操作系统的 iptables.
replication: 用于指定主从同步复制. slaveof.ip, slaveof.port 表示, 本台 SSDB 服务器将从这个目标机上同步数据(也即这个配置文件对应的服务器是 slave). 你可以参考 ssdb_slave.conf 的配制.
logger: 配置日志记录. level 是日志的级别, 可以是 trace|debug|info|error. output 是日志文件的名字, SSDB 支持日志轮转, 在日志文件达到一定大小后, 将 log.txt 改名, 然后创建一个新的 log.txt.
leveldb: 配置 LevelDB 的参数. 你一般想要修改的是 cache_size 参数, 用于指定缓存大小. 适当的缓存可以提高读性能, 但是过大的缓存会影响写性能.
另外注意cache_size、和write_buffer_size的配置的阈值以及占用内存的计算：
一个 ssdb-server 实例占用的内存瞬时(有可能, 而且即使达到, 也只是持续短时间)最高达到(MB):
cache_size + write_buffer_size * 66 + 32这是对于压缩选项没有开启的情况, 如果 compression: yes, 计算公式是:
cache_size + 10 * write_buffer_size * 66 + 32你可以调整配置参数, 限制 ssdb-server 的内存占用.
LevelDB：
Log文件
当应用写入一条Key:Value记录的时候，LevelDb会先往log文件里写入，成功后将记录插进Memtable中，这样基本就算完成了写入操作，Log文件在系统中的作用主要是用于系统崩溃恢复而不丢失数据，假如没有Log文件，因为写入的记录刚开始是保存在内存中的，此时如果系统崩溃，内存中的数据还没有来得及Dump到磁盘，所以会丢失数据（Redis就存在这个问题）。
因为一次写入操作只涉及一次磁盘顺序写和一次内存写入，所以这是为何说LevelDb写入速度极快的主要原因。
LevelDB首先将每条写入数据序列化为一个Record，单个Log文件中包含多个Record。同时，Log文件又划分为固定大小的Block单位，并保证Block的开始位置一定是一个新的Record。这种安排使得发生数据错误时，最多只需丢弃一个Block大小的内容。显而易见地，不同的Record可能共存于一个Block，同时，一个Record也可能横跨几个Block。
Log文件划分为固定长度的Block，由连续的32K为单位的物理Block构成的，每次读取的单位是以一个Block作为基本单位；每个Block中包含多个Record；Record的前56个位为Record头，包括32位checksum用做校验，16位存储Record实际内容数据的长度，8位的Type可以是Full、First、Middle或Last中的一种，表示该Record是否完整的在当前的Block中，如果Type不是Full，则通过Type指明其前后的Block中是否有当前Record的前驱后继。
levelDb中的Cache
读取操作如果没有在内存的memtable中找到记录，要多次进行磁盘访问操作。假设最优情况，即第一次就在level 0中最新的文件中找到了这个key，那么也需要读取2次磁盘，一次是将SSTable的文件中的index部分读入内存，这样根据这个index可以确定key是在哪个block中存储；第二次是读入这个block的内容，然后在内存中查找key对应的value。
levelDb中引入了两个不同的Cache： Table Cache 和 Block Cache。其中Block Cache是配置可选的，即在配置文件中指定是否打开这个功能。
compression压缩操作
为了加快读取速度，levelDb采取了compaction的方式来对已有的记录进行整理压缩，通过这种方式，来删除掉一些不再有效的KV数据，减小数据规模，减少文件数量等。
数据压缩是LevelDB中重要的部分，即上文提到的归并。冷数据会随着Compaction不断的下移，同时过期的数据也会在合并过程中被删除。
LevelDB的压缩操作由单独的后台线程负责。这里的Compaction包括两个部分，Memtable向Level 0 SST文件的Compaction，以及SST文件向下层的Compaction。
levelDb的compaction机制和过程与Bigtable所讲述的是基本一致的，Bigtable中讲到三种类型的compaction: minor ，major和full。所谓minor Compaction，就是把memtable中的数据导出到SSTable文件中；major compaction就是合并不同层级的SSTable文件，而full compaction就是将所有SSTable进行合并。
LevelDb包含其中两种，minor和major。
转载：http://www.ideawu.net/blog/archives/733.html
转载：https://www.cnblogs.com/chenny7/p/4569837.html
levelDB原理：https://blog.csdn.net/qq_26499321/article/details/78063856#commentBox