读性能超过Memcached 65%, 单核也超过redis, 支持日志支持掉电保护，欢迎试用

wlmqgzm

今年第1个高性能数据库产品开发已经完成，

由于支持日志功能，所以，可以满足各中对可靠性要求比较高的场合， 并且在打开日志功能的情况下， 依旧具备非常高的性能，满足了性能和可靠性 。
日志部分也是亮点， 主要是日志的写合并技术比较先进，因此，超越了各类数据库很多。

产品试用下载： http://www.haisql.com/fwzc/soft/
如果产品的试用期过了30天， 请重新下载拷贝一次， 就又可以使用30天了。

我们的软件读性能: 读4.1Kbyte的数据包大小, 4核8线程3.4G主频DDR3内存, 读900万次数据, 900并发, 花费时间23.631秒, 读性能38万QPS.
我们的软件写性能: 写4.1Kbyte的数据包大小, 写100万次数据, 100并发, 花费时间3.136秒, 写性能32万TPS.

目前版本1.0.35  查询性能已经比memcache大约高出64%，
插入/更新性能比memcache高出30%，
由于Redis只支持单CPU线程, 我们的软件支持多CPU线程,因此, 我们的性能在多核CPU下比Redis快得多.

由于与Memcache指令集兼容，包括返回的内容和错误提示均一致， 所以直接作为一个MemCached的客户端上连使用就行，
可以把我们的程序也作为一个特殊版本的MemCache服务器端来看待，
使用时与使用Memcache没有区别，
Linux下测试性能， 也可以用MemCache的测试工具， 例如：memcslap等。

===========================================================================================================================
准备开发一个高性能KV数据库, 类似MongoDB这样的, 学习MongoDB leveldb innodb，只是一个练手贴,  记录一下自己的学习开发KV数据库的过程.
去年学习开发过一个基于ASIO的网络库,  觉得写日记对自己有帮助, 起到一定的督促作用,  而且能够得到很多高手的各种提点( 尤其感谢Windoze ).

今年比较懈怠, 为了督促自己学习和进步, 决定现在开始开发一个小型化的KV数据库, 测试了解高性能软件开发的特性.
第一次开发高性能KV数据库, 只是一个练手的过程,  记录下来, 当做工作日志, 以便日后总结经验.
非开源项目, 只是一个练手贴.

初步计划的思路是:
1)完全使用Memcached或者MYSQL的命令集, 这样就不用开发客户端代码了, 实现一个服务器端的软件.
2)测试和优化, 对比与MemCached/MongoDB的性能, 找到提升性能的思路.

以下部分是优化部分:
主要是实现一个高性能的磁盘IO系统
3)实现存储和落地, 增加KV数据库的适应性, 并且学习磁盘IO的处理之道.
4)实现存储层对SSD的完全优化, 做到完全去掉随机写, 只有随机读和顺序写, 实现一个高性能的存储层.
5)存储层实现高性能压缩, 初步计划输入输出数据可采用LZ4压缩
6)多线程的处理过程, 实现高性能的查询性能.
7)高性能的缓存系统, 学习高性能缓存的开发思路.

已经实现的部分:
7)高性能网络层, 已经实现低端4核8线程CPU上, 使用4工作线程, 4测试线程, PingPong测试,  87万QPS的性能.
具体实现 在这个帖子中讨论过    <<ASIO,高并发,高可靠, 统一网络架构,抗DOS,低端4核心服务器CPU 每秒87万QPS ECHO >> http://bbs.chinaunix.net/thread-4189684-1-1.html

wlmqgzm

完全重新造轮子, ,  不用现在常用的技术手段和方法, 看能否找到新的开发思路和方法.

初步计划先开始就弄存储层,  存储层代码先不采用AIO, 先测试和完善一个基于 file_mapping 技术的磁盘IO,  采用这个技术方案可以减少IO过程中一半的data Copy过程, 对SSD有吸引力, 实现了用户态内存和系统态内存共享, 减少用户态的切换次数, 有望提供更高的磁盘读写性能.

lxyscls

file map？那你应该看看mongo

王楠w_n

欢迎继续更新，加油回复 2# wlmqgzm


   

windoze

对于memcache这一类业务逻辑超级简单的应用，你得先看看LSM tree之类的数据结构，其它的部分其实真没什么好操心的，随便写写就能把千兆网跑满。

wlmqgzm

存储层的数据规划思路:  

1)主要技术思路与Mangodb接近.分为数据和索引两部分, 数据完全在存放在文件中, 由File mapping管理, 所有的读写全部由操作系统来控制, 代码除了定期flush一下, 就完全不管了. 索引全部放在内存中.

其余部分是与mangoDB不同的:
2)索引部分是真正由自己的代码控制, 主要就是一个"hash(Key)===>(Key_value data)offset"的构造, 实现Key--Value的查询.
   查询过程是: Key==>Hash(key) 统一转化为8字节的编码==>hash_map find, map内部第2次hash,==>输出8字节全局Offset==>3字节文件索引号+4字节File offset+1字节块内部索引编号
   ==>利用file mapping读取数据头, 发现是LZ4压缩, 执行LZ4读, 如果是非压缩格式, 直接读
3)只有索引部分常驻内存, 因此,这部分数据决定了内存的消耗量, 目前的设计是16个字节索引一条记录, 8字节的hash(Key), 8字节的全局Offset. 对于1亿条记录, 总体消耗1.6G内存.
   32G内存, 理论上总体可实现20亿条记录的索引全部缓存在内存中, 实际按照80%可用内存消耗计算, 对于32G的单机, 大约是16亿条记录每台服务器.

8字节全局Offset==>3字节文件索引号+4字节File offset+1字节块内部索引编号
3字节索引号 表示最大使用1600万个文件.
4字节File offset  表示每个文件最大4G字节, 其实默认就是4G字节, 也是推荐的参数. 这个可以把4字节的每个比特都用尽, 不浪费.
1字节块内部索引编号  表示每个数据块最大存储254个记录, 其中记录号0保留作为单块单记录的标识, 记录号255保留做未来扩充使用, 能够使用的只有1-254, 一共能够最大存储254个记录.
为了提高性能, 初步确定, 每个数据块内部的记录Offset使用2个字节来表示, 因此,数据块最大长度为64KByte,  这个块的大小是可调整的, 建议的范围是０K--64KB, 这个块大小与Mysql 4K-32K很接近.
最终推荐大小将根据产品的实际测试情况,推荐或者固定为一个最优值.

与过去的其他任何数据库的设计的重要的区别:
1)这次设计的数据块要完全优化SSD, 绝对避免随机写, 任何数据块都是只写一次, 不会有第2次重写, 因此, 为了节约存储空间, 所有的块都是按照实际使用量连续排列的, 内部没有任何浪费,没有任何预留空间, 并且块开头不是4K对齐的.
由于块与块是紧密相连的, 为了故障处理和崩溃恢复, 在块与块之间, 引入了同步隔离码的概念.

2)数据是压缩与非压缩混合的, 任何一个数据块在第一次写入时都是非压缩的, 就是说任何最近的数据都是非压缩格式. 这样提供了最高的读写性能.
对于稍微旧一些的数据(还是有效数据), 或者在夜间时段，或者满足一定的条件，　将在后台低优先级进程启用最高压缩率的处理,  数据将第2次写入, 但是写入到新的区域,
使用LZ4压缩, LZ4压缩方式是HC模式, 即默认高压缩模式, 该模式非常消耗CPU资源, 大约压缩性能与gzip相当, LZ4解压是高性能的, 大约500M字节每秒.
这种设计实现了高性能并发与高压缩比同时兼顾,  并且实现了查询下的高性能解压缩, 从设计理念上是非常先进的.

数据块内部的进一步编码优化: 这个部分尚在仔细考虑设计中, 因为已经决定使用LZ4压缩存储, 对块内部的压缩, 或者没有必要进行额外的压缩处理.  (正在考虑是否采用)
长整数编码的压缩设计: 使用压缩编码来编码8字节长整数, 压缩后编码长度范围是1字节到9字节, 平均长度是4字节.  4字节整数的压缩后平均长度是2字节
这部分整数压缩代码虽然已经测试完毕, 但是可能最终会废弃不使用.  整数压缩的原理是: 4-8字节的整数, 可能多数时候只有少数字节是非零的,这样就可以用非零字节数+非零字节来表示, 尤其是全零的整数, 只需要1个字节就可表示.

先提交这部分设计, 后续再写.

wlmqgzm

回复 5# windoze

我的设计与LSM Tree有类似的地方，但是可能更接近MangoDB的存储层的设计思路，基本上融合了LSM Tree与MangoDB的优点，还额外提供了压缩处理．

我觉得自己的最大优势是全新设计的存储层，可以采用目前所有nosql中的精华，现有的Mysql数据库存储层太老了，对SSD的优化基本没有，　　

至于用户接口层是采用Memcached, 还是Mysql, 还在犹豫中．．．．．．．．．．，决定先做核心关键技术，最后再做用户接口层．　
其实，如果时间足够的话，想做一个MYSQL接口，而不是利用MemCached的接口，那个接口太简陋了，但是实现起来快，只是过渡产品，　但是　有利于我的性能测试和快速迭代．

或者先做一个单Table的Mysql, 实现单表的SELECT, UPDATE，DELETE, INSERT, CREATE TABLE.　DROP TABLE, ALTER TABLE, TRUNC TABLE.
由于存储层的全新设计，ALTER TABLE将不会更新数据,　只是更新几条头数据．
这个是我的理想．

MYSQL接口还是好用一些，最起码功能丰富一些，　这个还在犹豫．．．．．．．．，等存储层主要代码做完，再决定用户接口层，使用什么接口吧．

   

windoze

对于memcache来说压缩几乎总是划算的，本来就没什么地方特别耗CPU，IO才是最贵的。

fender0107401

windoze 发表于 2016-05-09 11:59
对于memcache来说压缩几乎总是划算的，本来就没什么地方特别耗CPU，IO才是最贵的。

IO永远是个要命的话题啊。。。

最近弄一个东西，需要打开几十万个小文件。。。

结果程序慢的死去活来的。。。

windoze

回复 9# fender0107401

你可以考虑把这些小文件合并成一个大文件，建一个偏移量索引，然后用mmap。