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

wlmqgzm

回复 20# lijianweiabcde

由于存储层是新的设计，全动态字段的存储模式，新增或者删除任意字段，不需要重新rebuild table,  
实质是一个NOSQL的存储层， 无法与现有版本的MYSQL对接，还是要自己造轮子．

初步的设计思路是
存储层的字段设计是下推到底的，字段名对应的ｉｄ直接在数据块的每行中存在，因此，字段的数量是随时可变的，字段的顺序也是可变的，提供了灵活性，适应一切变化．
属于一个统一的存储层架构．
对于Memcached来说，就是有２个字段，字段K(ey)和字段V(alue), 也是下推到底的，有一些浪费．
就是因为数据中存在太多的冗余，　所以，一定要有压缩跟上，这样来解决　灵活性和数据长度的兼顾，


   

wlmqgzm

已经完成 File_mapping层的read/write初步编码设计，简单进行了数据读写，还未进行详细测试．后面还要增加动态扩展大小的功能，　目前暂时固定大小．

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

// 3) 块内部记录数：１字节．　每个数据块可存放１－２40条记录，  标准块是一条记录一个块，　压缩块是１－240个记录一个块

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

// 3) 块的大小, 1-5字节整数, 压缩编码整数，　表示未压缩的长度
// 4) 块的大小, 1-5字节整数, 压缩编码整数  表示压缩后实际的长度,如果不压缩，同上一个值
// 5) 块的内容 ０K--3.999G
// 6) 块的校验码:   8字节,  块内容crc64校验
// 7) 块的同步码  8字节
// 块的管理用掉 ４+1+１＋３+３+8+8=28字节 ,   对于4K字节的压缩块,  大约不到1%的开销,

bule_gay_是条狗

回复 22# wlmqgzm


    楼主对 memcached 是不是也非常熟？

wlmqgzm

回复 23# bule_gay_是条狗

不熟，但是简单看过代码


   

bule_gay_是条狗

回复 24# wlmqgzm


    错了，我是想说 mangoDB的，不然怎么会想起模仿他呢。

VIP_fuck

坐等楼主的源码开源，这代码风格还不错。不少码农都胡乱命名，根本不知道什么意思。

folklore

lzv5, 8741

wlmqgzm

回复 25# bule_gay_是条狗

简单看过mongoDB的介绍，代码看了几段，没有仔细看，代码风格不是喜欢的那种，
主要是设计存储层的思路接近，但是，还是有很多地方不同，尤其是mongoDB浪费空间的地方很多，还有不少随机写的设计，
C++风格方面，例如：　它里面是自己包封的mmap, 我是采用Boost库已经做好的封装．应该说，写mongoDB代码的人对C++Boost库的熟悉程度还不够,所以自己造轮子．

自己的设计上，还有很多接近Google LevelDb的思想设计，　主要体现消灭随机写，数据的自动回收合并和压缩部分．　　
思路上接近，但是做法上差别比较大，结构上不一样，最终实现的功能是一样的，都是高速写入优化的，都是只有顺序写，都会自动合并文件．

觉得自己重新开始设计存储层的话，可能会比MongoDB更节约空间，彻底消灭随机写，更C++, 更优美一些．
对现有的各类存储层都不够满意，所以，想综合各类存储层的主要优点，综合起来，实现更优化的一个存储层．

这次开发的存储层基本框架和思路都比较先进，虽然经过仔细考虑，要综合各类存储层的优点，实现起来比一般的设计难度要大一些，开发的时间估计会比较长，初步估计要２个月的时间，弄完存储层的代码．
然后，再看情况，嫁接一个用户层接口．



   

lijianweiabcde

回复 21# wlmqgzm
我们对接的存储层是一个kv的存储系统，搞了一个中间适配层做转换


   

cokeboL

lzv5871b,up up!