背景

各位大佬好，目前小弟手上有百万级的 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. 求大佬推荐一下适合的产品（或技术方案）。

要求：

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

备用方案：

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

再加前置缓存...

laminux29

2020-02-05 05:15:39 +08:00

1.海量数据，又要关键操作性能高，这种情况下，读与写本来就是个矛盾，要不读快写满，要不写快读满，你要两者都高，这怎么可能。

2.你对开源（免费）产品，既要求性能高，又要求功能多，还要求运维成本低，这怎么可能。

3.在一堆海量数据里，确定一条数据的唯一性，这本来就是世界难题，原因是在硬件与运维有限的前提下，这操作完全是在挑战计算机设备的性能极端，这事在理论上根本没办法搞定，就连谷歌最后都只能选择砸钱堆服务器堆运维，才有了较好的性能。你又没服务器，又没人给你运维数据性能，这事怎么可能解决得了？

建议：
1.你应该选择你最关注的因素，比如读速度快，然后牺牲一下写数据，按这个模式，来做业务逻辑。

2.现在任何一款主流的分布式数据库，都做不到帮你把冷热数据均摊好，保证每台物理设备的性能平均。因为这个操作要涉及到经常的大规模的数据迁移，这个过程本身就会大幅度降低系统性能。因此，还不如你自己设计一个冷热数据记录器，再根据业务繁忙度，在闲时就像停服一样，重新分布冷热数据。这操作其实就是运维工作，你不去做这个工作，没办法把冷热数据高质量地均摊在不同物理设备上。

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

背景

value 格式：

对比

为什么不选 Redis?

要求：

备用方案：