百万级 Hash，十亿个元素，分布式存储和索引选什么适合？

[dusu]

背景

各位大佬好，目前小弟手上有百万级的 Hash，约十亿个元素，格式如下：

00000001
  |-key=a, val=2 字符:[1-20]-crc32 字符:整数 1:整数 2
  |-key=b, val=2 字符:[1-20]-crc32 字符:整数 1:整数 2
  ...
  |-key=z, val=2 字符:[1-20]-crc32 字符:整数 1:整数 2
  

00000002
  |-key=aa, val=2 字符:[1-20]-crc32 字符:整数 1:整数 2
  |-key=bb, val=2 字符:[1-20]-crc32 字符:整数 1:整数 2
  ...
  |-key=zz, val=2 字符:[1-20]-crc32 字符:整数 1:整数 2
  
...

value 格式：

一个元素代表一个文件：

2 字符：代表所在的机器

[1-20]-crc32：代表目标所在文件

整数 1：代表目标在文件的起始位置

整数 2：代表文件长度

---例子---

ab:9-cbdg3323:1200:500

每个 Hash 的 key 大概在 100-5000 个。

目前场景读大于写（读约 500/s，写约 200/s ），方案用的是 ssdb，

ssdb 单线程 compact 的时候对服务影响太大，经常 loadavg 过载

加上另外，leveldb 层面似乎更适合读大于写的场景（还有部署机器也不一定是 SSD 硬盘）。

对比

对比过市面上类似产品：Pika\Ledis\redix(主要对比了不同存储引擎)，似乎效果相差不大。

为什么不选 Redis?

成本问题，目前 ssdb 已经快 100G 了，

再加上要求分布式的话，如果能把这 十亿个元素 x5 倍 存在可观的 Redis 中，也可以考虑。

SO. 求大佬推荐一下适合的产品（或技术方案）。

要求：

1. 支持「分布式」，扩容无忧
2. 可支持高效在 hash 中「批量」检查元素 key 是否存在
3. 高效的读大于写的场景，读 QPS 能达到目前的 5x
4. 最好有现成的 redis/http 协议可开箱用
5. 全家桶性质的产品慎推，不想引入太多运维成本

备用方案：

按 id 水平拆表存 mysql，将元素里的数据拆开来存储、索引.

再加前置缓存...

[luozic]

是在云里面还是物理机器？ 物理机器可以去看看 dpdk 这种方案，不过想要低成本的条件的话，最好根据具体的需求特征定制一下 proxy 层，存储层基本现在开源的 rocksdb 系的基本可以直接用。 通用的肯定不是特定场景下的成本最低方案。

[justfly]

直接尝试 redis cluster 吧。

我算了一下你的 value，大概 30 个字节，10 亿级别占用大概不到 30G 内存空间，留 5 倍的扩展空间和 value 外额外空间，redis 集群使用 10 个以内的节点够用了。

[ppyybb]

@dusu 原来是集群那你扩大分片不就行了，怎么会有 100g 呢？你说的集群是主从？

[wangyzj]

redis 啊
又不是不够用
再就得看业务场景和其它功能了

[aliipay]

val 搞什么 string，直接用 byte 定义
机器名：2Byte 最高支持 65536 台，如果不超过 128 个节点可以设为 1B，高 1 位保留扩展性
文件：crcr32 只要 4Byte
文件起始： 不知道具体范围，假设 4GB 内， 就是 4Byte. 如果存在小数值偏多，可以考虑 utf8 编码
文件长度：同上
所以总长度在 14B 左右，目测能少掉一半量

[wzw]

@dusu #14 根据你的了解, ssdb 和 pika 有啥区别呀, 最直观的