免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: wlmqgzm
打印 上一主题 下一主题

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

论坛徽章:
12
2015年辞旧岁徽章
日期:2015-03-03 16:54:1515-16赛季CBA联赛之同曦
日期:2017-03-17 19:13:162016科比退役纪念章
日期:2016-11-07 08:28:12luobin
日期:2016-06-17 17:46:36wusuopu
日期:2016-06-17 17:43:4515-16赛季CBA联赛之福建
日期:2016-01-14 12:49:22程序设计版块每日发帖之星
日期:2015-12-13 06:20:00程序设计版块每日发帖之星
日期:2015-06-08 22:20:00程序设计版块每日发帖之星
日期:2015-06-08 22:20:002015年亚洲杯之科威特
日期:2015-03-24 14:21:272015年迎新春徽章
日期:2015-03-04 09:57:092016科比退役纪念章
日期:2018-04-10 16:20:18
31 [报告]
发表于 2016-05-11 08:38 |只看该作者
好,这个贴加精,好,也是对楼主一个激励,加把劲啊,

论坛徽章:
12
2015年辞旧岁徽章
日期:2015-03-03 16:54:1515-16赛季CBA联赛之同曦
日期:2017-03-17 19:13:162016科比退役纪念章
日期:2016-11-07 08:28:12luobin
日期:2016-06-17 17:46:36wusuopu
日期:2016-06-17 17:43:4515-16赛季CBA联赛之福建
日期:2016-01-14 12:49:22程序设计版块每日发帖之星
日期:2015-12-13 06:20:00程序设计版块每日发帖之星
日期:2015-06-08 22:20:00程序设计版块每日发帖之星
日期:2015-06-08 22:20:002015年亚洲杯之科威特
日期:2015-03-24 14:21:272015年迎新春徽章
日期:2015-03-04 09:57:092016科比退役纪念章
日期:2018-04-10 16:20:18
32 [报告]
发表于 2016-05-11 08:38 |只看该作者
之前在学 redis 的时候,也曾有过用 C++ 自己写个,不过水平有限,没敢动手。

论坛徽章:
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
33 [报告]
发表于 2016-05-11 08:49 |只看该作者
本帖最后由 wlmqgzm 于 2016-05-11 09:21 编辑

高性能文件读写模块,  File_Mapping基本功能已经完成, 初步简单的测试了一下性能:

zero填充新的空文件,16GB文件初始化性能大约30微秒,  
写刷新磁盘性能大约每秒350MByte,  
读磁盘性能大约每秒700MByte,   
读数据已经缓冲到内存的性能每秒1.6GByte,  
写数据不刷新并且有足够空闲内存的性能每秒1.1GByte

磁盘是RAID0+1软阵列,  由四块普通SATA 1TB硬盘组成.
新技术的磁盘IO性能确实还好. 尤其是读缓存基本上是读内存, 没有用户空间到系统空间切换带来的延迟.   

论坛徽章:
12
2015年辞旧岁徽章
日期:2015-03-03 16:54:1515-16赛季CBA联赛之同曦
日期:2017-03-17 19:13:162016科比退役纪念章
日期:2016-11-07 08:28:12luobin
日期:2016-06-17 17:46:36wusuopu
日期:2016-06-17 17:43:4515-16赛季CBA联赛之福建
日期:2016-01-14 12:49:22程序设计版块每日发帖之星
日期:2015-12-13 06:20:00程序设计版块每日发帖之星
日期:2015-06-08 22:20:00程序设计版块每日发帖之星
日期:2015-06-08 22:20:002015年亚洲杯之科威特
日期:2015-03-24 14:21:272015年迎新春徽章
日期:2015-03-04 09:57:092016科比退役纪念章
日期:2018-04-10 16:20:18
34 [报告]
发表于 2016-05-11 08:55 |只看该作者
回复 33# wlmqgzm


    代码git上了?

论坛徽章:
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
35 [报告]
发表于 2016-05-11 09:16 |只看该作者
本帖最后由 wlmqgzm 于 2016-05-11 17:57 编辑

因为发现扩展文件并填充新空间为零的时间是微秒级别, 所以, 修改设计. 数据文件大小可随时扩充, 并增加预读函数.

File_mapping 第一个初始化文件大小默认修改为1MByte,  所以, 计划初始化为1MB,  然后根据数据的增量随时扩充, 每次扩充一倍, 最大扩充到4G, 然后更换文件名.
这样的模式, 更节约硬盘空间, 第2个文件及以后的文件是直接到4G, 这样对于小的Table就不浪费空间.

对比固定XG, 对于小Table, 节约空间是明显的.

确定File_mapping 采用如下文件编码方式:
文件路径:/db_name/table_name/

前缀: 从00000001开始,依次增加的文件名.

后缀:
.dbw   表示正在读写模式(write)的文件, 一般是最后一个文件序列号.
.dbf    表示已经写完毕(finish)的文件, 这部分文件都是采用标准格式, 一般是写完毕, 但是还没有LZ4压缩合并的文件.
.dbz    表示已经LZ4或者其他格式压缩过的文件.
.~dbz   表示正在执行压缩过程的文件.
.dbi 表示索引文件(非主索引), 索引文件目前还没有做代码, 索引文件的内部格式比较难确定, 又想简单化, 又要append only, 初步想还是采用类似LevelDB的办法  索引文件名=索引名称+序列号+ dbi, 还是要不断合并.

论坛徽章:
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
36 [报告]
发表于 2016-05-11 09:18 |只看该作者
本帖最后由 wlmqgzm 于 2016-05-11 09:18 编辑

回复 34# VIP_fuck

这个不是开源的项目, 也不是公司的开发项目, 是个人的自学作业, 做着玩的练手项目, 暂时不开源.


   

论坛徽章:
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
37 [报告]
发表于 2016-05-11 09:35 |只看该作者
回复 4# 王楠w_n

感谢版主加精华, 这个开发项目会持续更新的, 直到做完为止.

论坛徽章:
146
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
38 [报告]
发表于 2016-05-11 09:37 |只看该作者
加油 回复 37# wlmqgzm


   

论坛徽章:
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
39 [报告]
发表于 2016-05-11 12:18 |只看该作者
本帖最后由 wlmqgzm 于 2016-05-11 16:37 编辑

存储层的整体数据规划思路已经全部完成:

整体流程在脑海中完整的过了一遍.

块数据的整体设计思路已经完成, 正在书写当中, 基本上确定, 存储层的数据格式完整支持MVCC和数据库SQL标准的全部四个隔离级别: 即read uncommited, read commit, repeatable read,serializable.
比最早的想法又进了一步, 最早没有打算实现这些, 随着数据规划, 发现 在数据层的定义中 只需要修改少量关键字节, 就可以实现与innodb格式完全一致的功能.

因此, 初步计划出2个版本;
2个版本在硬盘存储格式上完全一致, 只是软件功能上做了扩展.
第一个版本1.00  按照KV数据库的标准做, 实质是实现read uncommited的SQL隔离级别版本. 先做这个版本.
第二个版本2.00 按照SQL数据库的标准做, 再陆续增加read commit, repeatable read,serializable这三个SQL隔离级别版本,
其中repeatable read 在目前的数据规划中, 与innodb类似, 实现了幻读保护, 即 repeatable read=serializable,
准确的说, 将实现两个SQL隔离级别. 在性能上, repeatable read将与read commit很接近,  主要的差别在于缓存中有效数据的多少,
我的规划实现中 repeatable read 将利用空间保护(offset隔离), 实现幻读保护, 没有像innodb一样使用间隙锁, 因此性能将更好一些.


今天心情比较高兴,自己也很意外,基本上按照KV数据库的标准,实现了SQL数据库的全部功能点的设计,而且全部是高性能设计,做完的话,会有比较好的性能
主要的技术难题的突破在MVCC的设计,找到了一条覆盖各类情况的模型.

设计压缩块/标准块的结构:
// 1) 块的位置号, 就是块的唯一标志,  位置号就是offset,  4字节整数,  位置号==实际存储的offset, 即该位置上读到的4字节数据==该位置的offset
// 2) 块的压缩格式及压缩率: 1字节,  0=不压缩, 1-9=lz4压缩, 21-29=gzip压缩,  31-39=bzip2, 先只做lz4, 其他备用

// 3) 块内部记录数:1字节. 每个数据块可存放1-240条记录,  标准块是一条记录一个块, 压缩块是1-240个记录一个块

这里保留了241-255的编号, 这些编号主要是为了未来(第2个版本)预留,
这些编号对应的内存结构, 在硬盘空间中没有使用,
在内存空间中使用, 将以特殊的方式, 提供高性能虚拟锁
每个编号将在主键上以特殊方式(类似于MVCC)提供4M个锁空间, 一共可以提供60M个锁空间,即每个table可提供最大6000万个锁空间
将用于 存储层的行锁--更新锁内部使用, 这部分代码还没有做, 但是计划在第2个版本中使用, 使用行锁以后, 将提供完整MVCC和READ COMMIT等数据库标准功能
第2个版本将实现完整的MVCC, 读取是没有任何锁, 可提供高的性能. MVCC在第一个版本中做好预留, 但是不占数据内存空间, 以便提供最好的性能
行锁是写锁,即更新锁, 正在考虑  不过都是第2个版本的事情, 这个版本只是做好预留, 按最简单的方式实现

这个字节的关键设计在于它定位于内存中8字节长整数offset的最高位,对于1-240的值将直接掩码转换为8bit全零的offset+1-240两个参数,对于241-255这个部分+3字节将转化为一个最大60M的整数,这个整数用atomic表示,依次循环使用这个参数,最大可表示60M个正在更新中的数据,实现最大6000万个虚拟锁,对于超过用户自身offset中的数据, 用户级别的MVCC是不可见的, 因此,任何在此位置上的更新,将不会被任何用户读取.
说了半天,其实就是一句话, 在没有增加新字节的情况下,实现了与MVCC以及事务处理的全兼容功能.所以,就是高效的实现.
一种激进的思路:所有的更新是MVCC的,这样每个线程都可以提交请求更新数据,但是最终的Commit是单写线程的,这样可以实现最大化的并发,考虑中.......

// 3) 块的大小, 1-5字节整数, 压缩编码整数, 表示未压缩的长度
// 4) 块的大小, 1-5字节整数, 压缩编码整数  表示压缩后实际的长度,如果不压缩,同上一个值
// 5) 块的内容 0K--3.999G
// 6) 块的校验码:   8字节,  块内容crc64校验
// 7) 块的同步码  8字节
// 块的管理用掉 4+1+1+3+3+8+8=28字节 ,   对于4K字节的压缩块,  大约不到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
40 [报告]
发表于 2016-05-12 14:56 |只看该作者
本帖最后由 wlmqgzm 于 2016-05-12 16:25 编辑

今天在考虑这样一个问题, 主要是多层对象的负责任务, 应该如何分配??

传统的模式: 底层对象比较傻瓜, 基本属于木头人, 上层让干啥就干啥, 基本复杂一点的事情什么都不干, 高层代码负责全部复杂流程, 高层代码, 才算是有智慧的, 对下层代码派工.

这次代码, 准备换一种编程模式, 做成 每个对象自身都是: 智慧的对象, 每个对象对自己的操作负责到底, 底层可以通知高层干活, 高层也可向底层派工,
底层才能更了解需要干什么, 传统模式的情况下, 高层代码操心的事情太多, 需要判断太多本不是自己该负责的内容, 代码效率低, 会增加执行一些本不需要反复执行(例如:检查状态和空间等)的代码.

对象之间的交互一种思路是A对象提供某个观察者的function接口, B对象传递 std::bind(...) 提供执行的动作, 这样每个对象都可以向任意对象申请某个参数的观察者模式, 被观察者派工, 实现了灵活性和自由性.
代码还没有做, 准备试试, 觉得这种新模式有可能降低开发难度, 当然采用全新技术, 也会有很多额外的风险, 要试验一下 .....

具体到这次开发过程, 考虑 File_mapping 作为底层对象, 将向上层Block对象, 提供: 文件空间切换(达到最大长度,更换文件), (压缩完毕,切换到压缩空间),(空间自动扩展,重新Mapping)....各种通知, 这样底层自主在恰当的时候做各种事情, 然后通知上层,丢弃即将无效的对象(指针对象), 重新获取......
总之, 在考虑 底层对象智慧化, 这样新的编程思路, 会实验一下, ......

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP