floyd存储方案

[wangshao1]

pika存储结构

整体架构

新的存储架构中，pika实例存储引擎包括内存缓存redis和硬盘持久存储RocksDB。每个pika实例由一个redis和多个RocksDB实例构成。

pika当前是将不同的数据类型放在不同的RocksDB实例中，线上使用过程中发现，同一个业务服务使用的数据类型一般集中在一两个数据类型中，无法发挥多RocksDB实例的优势。因此，pika新版本中计划不再按照数据类型区分RocksDB实例，而是通过column-family区分。单个pika节点的RocksDB实例个数根据物理机硬件配置决定，每个RocksDB实例使用独立的compaction线程池和flush线程池，初次之外每个RocksDB实例使用一个后台线程，该后台线程用来发起manual compaction以及对RocksDB中存储的数据进行定期的统计和巡检。

每个节点在启动时获取到当前节点持有的分片（目前不支持，需要进行代码开发），将分片排序并等分为RocksDB实例个数，保证每个分片持有的RocksDB实例个数近似相同。

数据格式

为了兼容redis协议，即为同一个数据类型的数据设置统一的过期时间值，复合数据类型中的meta信息还是需要保留，否则ttl/expire接口操作性能耗时增加。不同的数据类型混合使用RocksDB实例，通过column family中进行区分。为了方便后期remote Compaction，参考todis的数据存储格式，对userkey进行编码后存储，保证datakey和metakey参与排序的前缀相同。除此之外，数据存储格式与之前的blackwidow基本相同，只是key，value增加一些字段。

对于key来讲，前缀增加8字节的reserve保留字段，后缀增加16字节的保留字段。

对于value来讲，在value最后统一增加：16字节的保留字段，8字节的数据的写入时间cdate，8字节的数据过期时间。

string结构

key格式
| reserve1 | key | reserve2 | 
|      8B      |       |      16B     |

value格式
| value | reserve | cdate | timestamp | 
|           |     16B   |     8B  |        8B       |

hash结构

meta数据格式

key格式
| reserve1 |  key | reserve2 | 
|        8B    |        |      16B     |

value格式
| hash_size | version |  reserve  | cdate | timestamp | 
|        4B      |     8B     |      16B    |     8B  |        8B       |

data数据格式

key格式
| reserve1 | key | version | field | reserve2 |
|       8B    |        |       8B   |         |      16B     |

value格式
| hash value | reserved | cdate |
|                    |       16B   |   8B  | 

List结构

meta数据格式

key格式
| reserve1 | key | reserve2 |
|       8B     |        |     16B     |

value格式
| list_size | version | left index | right index | reserve |  cdate | timestamp | 
|     4B    |       8B    |       8B      |         8B       |   16B     |    8B    |        8B        |

data数据格式

key格式
| reserve1 | key  | version | index | reserve2 | 
|       8B    |         |       8B   |   8B   |      16B     |

value格式
| value | reserve | cdate |
|           |     16B   |    8B  | 

set结构

meta数据格式

key格式
| reserve1 |  key | Reserved2 |
|        8B    |         |    16B    |

value格式
| set_size | version | reserve | cdate | timestamp | 
|     4B      |     8B     |    16B     |   8B   |        8B        |

data数据格式

key格式
| reserve1 |  key | Version | member |  reserve2 |
|      8B     |         |    8B      |                 |       16B    |  

value格式
| reserve | cdate |
|     16B   |    8B   | 

zset结构

meta数据格式

key格式
| reserve1 |  key | reserve2 |
|       8B    |         |     16B      |  

value格式
| zset_size | version | reserved | cdate | timestamp | 
|       4B      |      8B    |      16B     |   8B   |        8B        |

member to score数据格式

key格式
| reserve1 |  key | version | Field | reserve2 |
|      8B      |        |       8B   |          |      16B    |   

value格式
| score value | reserve | cdate |
|         8B        |    16B    |   8B  | 

score to member数据格式

key格式
| reserve1 |  key | version | score | member |  reserve2 |
|       8B    |         |      8B    |  8B     |                |       16B    |

value格式
| reserve | cdate |
|     16B   |     8B  | 

RocksDB使用优化

blobdb使用优化

RocksDB支持了key-value分离的实现，即通过将大value存储到blob文件中，在sst文件中存储大value在blob文件的索引信息，从而减少写写放大，有效提升大value场景下的写入性能。pika依赖自定义的compactionFilter实现过期数据的处理，ttl存储在value中，因此在compaction过程中不可避免导致额外的blob文件IO。一种方法是修改sst文件中存储的blobindex，在blobindex的相同offset位置存储value的ttl值，这样compaction过程中对过期数据的清理的逻辑，就不需要查询blob文件，减少额外的磁盘IO。对于非string类型的数据，通过实现FilterByBlobKey的方式，省掉额外的BLOB文件IO开销。

dealslowkey

参考新浪微博的经验，当pika上层代码发现一个慢查询key时，发起一次manual compaction，compaction的范围即对应的key前缀对应的数据范围。性能待验证。

compact老的sst文件

参考新浪微博的经验，定期对最老的sst文件进行compaction可明显提升集群性能。看官方文档，貌似类似的功能RocksDB已经支持，链接如下：https://github.com/facebook/rocksdb/wiki/Leveled-Compaction#ttl。计划使用RocksDB官方的实现。

新技术探索

主要是包括了RocksDB的异步IO，协程，remote compaction等新技术的测试和落地。

[AlexStocks]

related discussion #2052