忘记密码   免费注册 查看新帖 | 论坛精华区

ChinaUnix.net

  平台 论坛 博客 认证专区 大话IT 视频 徽章 文库 沙龙 自测 下载 频道自动化运维 虚拟化 储存备份 C/C++ PHP MySQL 嵌入式 Linux系统
最近访问板块 发新帖
查看: 18737 | 回复: 144

[C++] 读性能超过Memcached 65%, 单核也超过redis, 支持日志支持掉电保护,欢迎试用 [复制链接]

论坛徽章:
9
程序设计版块每日发帖之星
日期:2015-10-18 06:20:00程序设计版块每日发帖之星
日期:2015-11-01 06:20:00程序设计版块每日发帖之星
日期:2015-11-02 06:20:00每日论坛发贴之星
日期:2015-11-02 06:20:00程序设计版块每日发帖之星
日期:2015-11-03 06:20:00程序设计版块每日发帖之星
日期:2015-11-04 06:20:00程序设计版块每日发帖之星
日期:2015-11-06 06:20:00数据库技术版块每周发帖之星
日期:2015-12-02 15:02:47数据库技术版块每日发帖之星
日期:2015-12-08 06:20:00
发表于 2016-05-08 15:14 |显示全部楼层
本帖最后由 wlmqgzm 于 2017-04-23 19:51 编辑

今年第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
打赏鼓励一下!

论坛徽章:
9
程序设计版块每日发帖之星
日期:2015-10-18 06:20:00程序设计版块每日发帖之星
日期:2015-11-01 06:20:00程序设计版块每日发帖之星
日期:2015-11-02 06:20:00每日论坛发贴之星
日期:2015-11-02 06:20:00程序设计版块每日发帖之星
日期:2015-11-03 06:20:00程序设计版块每日发帖之星
日期:2015-11-04 06:20:00程序设计版块每日发帖之星
日期:2015-11-06 06:20:00数据库技术版块每周发帖之星
日期:2015-12-02 15:02:47数据库技术版块每日发帖之星
日期:2015-12-08 06:20:00
发表于 2016-05-08 15:25 |显示全部楼层
本帖最后由 wlmqgzm 于 2016-05-08 15:26 编辑

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

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

论坛徽章:
12
水瓶座
日期:2014-06-10 09:51:0215-16赛季CBA联赛之吉林
日期:2016-08-20 10:43:1215-16赛季CBA联赛之广夏
日期:2016-06-23 09:53:58程序设计版块每日发帖之星
日期:2016-02-11 06:20:00程序设计版块每日发帖之星
日期:2016-02-09 06:20:0015-16赛季CBA联赛之上海
日期:2015-12-25 16:40:3515-16赛季CBA联赛之广夏
日期:2015-12-22 09:39:36程序设计版块每日发帖之星
日期:2015-08-24 06:20:002015亚冠之德黑兰石油
日期:2015-08-07 09:57:302015年辞旧岁徽章
日期:2015-03-03 16:54:15摩羯座
日期:2014-07-21 10:11:2815-16赛季CBA联赛之八一
日期:2017-04-12 14:26:28
发表于 2016-05-08 22:14 |显示全部楼层
file map?那你应该看看mongo

论坛徽章:
135
2015年亚洲杯之日本
日期:2015-04-28 13:32:012015年亚洲杯之朝鲜
日期:2015-05-06 10:16:442015年亚洲杯之日本
日期:2015-05-06 10:21:342015年亚洲杯纪念徽章
日期:2015-05-13 17:16:442015亚冠之北京国安
日期:2015-05-13 17:18:292015亚冠之鹿岛鹿角
日期:2015-05-13 17:19:062015亚冠之德黑兰石油
日期:2015-05-27 16:47:402015亚冠之塔什干棉农
日期:2015-05-28 15:24:122015亚冠之卡尔希纳萨夫
日期:2015-06-01 13:52:392015亚冠之柏斯波利斯
日期:2015-06-04 17:37:292015亚冠之阿尔纳斯尔
日期:2015-06-16 11:31:202015亚冠之塔什干火车头
日期:2015-06-23 10:12:33
发表于 2016-05-09 09:03 |显示全部楼层
欢迎继续更新,加油回复 2# wlmqgzm


   

论坛徽章:
38
巨蟹座
日期:2013-10-25 10:53:02程序设计版块每日发帖之星
日期:2016-01-26 06:20:00程序设计版块每日发帖之星
日期:2016-01-27 06:20:00每日论坛发贴之星
日期:2016-01-27 06:20:0015-16赛季CBA联赛之佛山
日期:2016-02-04 21:11:3615-16赛季CBA联赛之佛山
日期:2016-02-05 00:55:2015-16赛季CBA联赛之福建
日期:2016-03-18 12:13:4015-16赛季CBA联赛之辽宁
日期:2016-03-24 21:38:2715-16赛季CBA联赛之福建
日期:2016-04-12 15:21:2915-16赛季CBA联赛之山东
日期:2016-04-17 12:00:282016科比退役纪念章
日期:2016-04-23 00:51:2315-16赛季CBA联赛之新疆
日期:2016-04-25 10:55:45
发表于 2016-05-09 09:43 |显示全部楼层
对于memcache这一类业务逻辑超级简单的应用,你得先看看LSM tree之类的数据结构,其它的部分其实真没什么好操心的,随便写写就能把千兆网跑满。

论坛徽章:
9
程序设计版块每日发帖之星
日期:2015-10-18 06:20:00程序设计版块每日发帖之星
日期:2015-11-01 06:20:00程序设计版块每日发帖之星
日期:2015-11-02 06:20:00每日论坛发贴之星
日期:2015-11-02 06:20:00程序设计版块每日发帖之星
日期:2015-11-03 06:20:00程序设计版块每日发帖之星
日期:2015-11-04 06:20:00程序设计版块每日发帖之星
日期:2015-11-06 06:20:00数据库技术版块每周发帖之星
日期:2015-12-02 15:02:47数据库技术版块每日发帖之星
日期:2015-12-08 06:20:00
发表于 2016-05-09 10:18 |显示全部楼层
本帖最后由 wlmqgzm 于 2016-05-09 14:35 编辑

存储层的数据规划思路:  

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,  这个块的大小是可调整的, 建议的范围是0K--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个字节就可表示.

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

论坛徽章:
9
程序设计版块每日发帖之星
日期:2015-10-18 06:20:00程序设计版块每日发帖之星
日期:2015-11-01 06:20:00程序设计版块每日发帖之星
日期:2015-11-02 06:20:00每日论坛发贴之星
日期:2015-11-02 06:20:00程序设计版块每日发帖之星
日期:2015-11-03 06:20:00程序设计版块每日发帖之星
日期:2015-11-04 06:20:00程序设计版块每日发帖之星
日期:2015-11-06 06:20:00数据库技术版块每周发帖之星
日期:2015-12-02 15:02:47数据库技术版块每日发帖之星
日期:2015-12-08 06:20:00
发表于 2016-05-09 10:57 |显示全部楼层
本帖最后由 wlmqgzm 于 2016-05-09 11:16 编辑

回复 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接口还是好用一些,最起码功能丰富一些, 这个还在犹豫........,等存储层主要代码做完,再决定用户接口层,使用什么接口吧.

   

论坛徽章:
38
巨蟹座
日期:2013-10-25 10:53:02程序设计版块每日发帖之星
日期:2016-01-26 06:20:00程序设计版块每日发帖之星
日期:2016-01-27 06:20:00每日论坛发贴之星
日期:2016-01-27 06:20:0015-16赛季CBA联赛之佛山
日期:2016-02-04 21:11:3615-16赛季CBA联赛之佛山
日期:2016-02-05 00:55:2015-16赛季CBA联赛之福建
日期:2016-03-18 12:13:4015-16赛季CBA联赛之辽宁
日期:2016-03-24 21:38:2715-16赛季CBA联赛之福建
日期:2016-04-12 15:21:2915-16赛季CBA联赛之山东
日期:2016-04-17 12:00:282016科比退役纪念章
日期:2016-04-23 00:51:2315-16赛季CBA联赛之新疆
日期:2016-04-25 10:55:45
发表于 2016-05-09 11:59 |显示全部楼层
对于memcache来说压缩几乎总是划算的,本来就没什么地方特别耗CPU,IO才是最贵的。

论坛徽章:
88
水瓶座
日期:2014-04-01 08:53:31天蝎座
日期:2014-04-01 08:53:53天秤座
日期:2014-04-01 08:54:02射手座
日期:2014-04-01 08:54:15子鼠
日期:2014-04-01 08:55:35辰龙
日期:2014-04-01 08:56:36未羊
日期:2014-04-01 08:56:27戌狗
日期:2014-04-01 08:56:13亥猪
日期:2014-04-01 08:56:02亥猪
日期:2014-04-08 08:38:58每日论坛发贴之星
日期:2015-08-28 06:20:00每周论坛发贴之星
日期:2016-01-10 22:22:00
发表于 2016-05-09 12:54 |显示全部楼层
本帖最后由 fender0107401 于 2016-05-09 12:54 编辑
windoze 发表于 2016-05-09 11:59
对于memcache来说压缩几乎总是划算的,本来就没什么地方特别耗CPU,IO才是最贵的。


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

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

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

论坛徽章:
38
巨蟹座
日期:2013-10-25 10:53:02程序设计版块每日发帖之星
日期:2016-01-26 06:20:00程序设计版块每日发帖之星
日期:2016-01-27 06:20:00每日论坛发贴之星
日期:2016-01-27 06:20:0015-16赛季CBA联赛之佛山
日期:2016-02-04 21:11:3615-16赛季CBA联赛之佛山
日期:2016-02-05 00:55:2015-16赛季CBA联赛之福建
日期:2016-03-18 12:13:4015-16赛季CBA联赛之辽宁
日期:2016-03-24 21:38:2715-16赛季CBA联赛之福建
日期:2016-04-12 15:21:2915-16赛季CBA联赛之山东
日期:2016-04-17 12:00:282016科比退役纪念章
日期:2016-04-23 00:51:2315-16赛季CBA联赛之新疆
日期:2016-04-25 10:55:45
发表于 2016-05-09 13:12 |显示全部楼层
回复 9# fender0107401

你可以考虑把这些小文件合并成一个大文件,建一个偏移量索引,然后用mmap。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

  

北京皓辰网域网络信息技术有限公司. 版权所有 京ICP证:060528号 北京市公安局海淀分局网监中心备案编号:1101082001
广播电视节目制作经营许可证(京) 字第1234号 中国互联网协会会员  联系我们:
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP