idea's blog

在最近的 SSDB 1.6.1 版本中, 更新到了最新的 leveldb-1.14.0 版本. 这是一次常规升级, 大家可以根据情况决定升级.

SSDB 预编译的 Windows 可执行安装包

另外, SSDB 提供了预编译的 Windows 下的可执行安装包, Windows 用户可以下载后直接运行 ssdb-server.exe. Windows 下的 SSDB 依赖 cygwin, 所以附带了几个 dll 文件. 使用方式:

1. 从 https://github.com/ideawu/ssdb-bin 下载可执行文件 ssdb-server.exe 和相关 dll.
2. 从 https://github.com/ideawu/ssdb 下载 ssdb.conf 配置文件.
3. 解压, 然后从开始菜单中运行 cmd.exe.
4. 在 cmd.exe 启动后, cd ssdb-server.exe 所在的目录.
5. 执行 ssdb-server.exe ssdb.conf

SSDB 是一个 C++ 开发的 NoSQL 存储服务器, 支持 zset, map 数据结构, 可替代 Redis, 特别适合存储集合数据. SSDB 被开发和开源出来后, 已经在生产环境经受了3个季度的考验, 一直稳定运行.

在一个支撑数千万用户的列表数据(例如用户的订单历史, 用户的好友列表, 用户的消息列表等)的实例上, SSDB 每天处理上亿个读写请求, 仍然能保持 CPU 占用在3%左右, 内存占用为 1G. 这种数据规模是我们原来使用的 Redis 所无法满足的, 因为 Redis 无法保存如此大量的数据, 物理内存的容量限制了 Redis 的能力. 根据我们的经验, Redis在10G数据规模时比较适用, 数据规模再扩大时, Redis 就非常吃力, 而且几乎无法扩展. 这时, 必须改用 SSDB.

Continue reading »

SSDB 提供了 flushdb 命令, 用于清除整个数据库的数据. 这是在命令行客户端实现的, 所以只在 ssdb-cli 里才能用. 因为这是一个非常危险的命令, 所以输入后, 还要用户再输入"yes"确认.

flushdb 还支持单独清理 kv, hash, zset 三种数据, 分别对应的用法是 flushdb kv, flushdb hash, flushdb zset.

还等什么? 赶快升级吧! 不需要重新编译, 也不需要重启服务器.

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: yes

work_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 参数, 用于指定缓存大小. 适当的缓存可以提高读性能, 但是过大的缓存会影响写性能.

SSDB 在 1.5.7 版本中增加了 key_range 查询, 用于获取 SSDB 服务器当前数据的范围. 下一个版本会增加 set_key_range 功能, 用于指定 SSDB 应该服务的数据的区间范围. 这个 key_range 是 SSDB 未来集群之路的开始.

在很多基于客户端的存储集群方案中(如 hash), 数据存储在哪台服务器需要客户端来决定, 也就是由用户(开发者)来决定. 这一类的方案都是伪集群和伪分布式, 因为数据的定位要求客户端主动进行, 而且数据没有无缝的迁移机制, 就不能称为一个系统.

为了实现存储集群, 数据必须分片(Sharding). SSDB 不会使用 hash 分布, 因为 hash 分布的粒度控制不精确. SSDB 将使用的是区间分布式(堆查找表), 从而实现最小一个 key 粒度的数据分片. 分片的粒度越小, 实现数据的无缝迁移就越好, 因为数据迁移过程的不稳定状态非常短暂.

集群中的每一个节点必须知道自己的 range, 这样就可以明确拒绝超越自己服务范围的请求. 比如 key=a 不在这台服务器上, 那么当这台服务器收到 key=a 的操作时, 它就可以明确拒绝, 以便让客户端主动去更新自己的查找表. 所有的客户端都是不可靠的, 服务器必须做自己的一套验证!

虽然拥有主从同步结构, 甚至是多主多从的同步结构, SSDB仍然是一个单机存储数据库系统, 所以SSDB天生适合存储1TB以内的数据. 如果数据可以静态分布, SSDB当然可以存储无限的数据量. 当然, 这样的SSDB并不是一个集群, 也不是一个严格意义上的分布式存储系统, 统一入口是集群的最基本特征.

"一致性哈希"常常被认为是分布式存储系统的一个重要概念, 事实上, 它只是一个可选的九牛一毛而已. 分布式存储要解决的重要问题不是数据如何分布, 而是如何保证数据迁移对用户不可见.

当一个区间(r1, r2)内的数据在从S1存储点向S2存储点迁移的过程, 处于这个区间的数据的读写会涉及到定位的问题. 读问题其实很好解决, 把迁移分为复制和删除两个步骤, 那么就可以保证在复制过程中还是从S1读取. 写问题也是类似, 但要复制得多, S1必须保证复制过程中的所有写操作都被同步(sync)到S2.

在区间内数据被删除后, S1再接收到读或者写请求时, 应该返回一个out-of-range(oor)错误, 并redirect到S2, 这时客户端可以更新寻址表然后重试.

另外, 迁移完成后, 应该由S1进行报告, S2无权进行报告, 而只能被动地接受通知区间的变化. 也就是说, 虽然S2知道自己已经接收了区间内的数据, 但S1仍然可以在这时取消迁移.