pika 与 redis 对比测试

0 测试环境

测试机器配置

• mem: 128G
• disk: 800G ssd
• cpu: 32 core
• net: 10Gbps

版本

• redis: 3.2.11
• pika: 2.2.6

1 pika worker 线程数测试

pika 和 redis 不一样，底层采用了 rocksdb 作为存储引擎，线程数对 pika 的性能影响较大

• 5 thread，100 client
• ops: GET SET
• value payload: 128 bytes

image

说明：其中线程数为 0 的是 redis 的测试数据。

结论：pika 的 qps 基本是符合预期的，get 和 set 性能与线程数成正相关关系，当线程数到达 8 时，再增加线程数，对 get 性能提升几乎没有太多影响，同时对 set 性能的增益也衰减较大；与 redis 相比，qps再线程数足够的情况下可以做到比 redis 还要好，特别是 get 性能，可以达到 redis 的 2 倍以上。

2 pika redis get set 不同 payload 延时及 qps 对比

环境：

• 5 thread，100 client
• ops: GET SET
• pika workers：8 thread
• 1000000 次

image

结论： pika get 性能受 payload 影响较小，99.9% 的请求都能再 1ms 内返回，且 qps 不受影响，set 性能受 palyload 影响较大，再 512 bytes 之前都能保持和redis 相当的性能，99.9% 的请求能再 2-3 ms内返回，和 redis 性能相当；超过 512 bytes 后，性能下降较大，10k 的数据需要 300ms 左右才能完成 set 操作；而 redis 在 10 k 内都能维持较好的性能，100k 以后 set 性能才会有较大的衰减。

3 不同操作与 redis 对比测试

• 5 thread，100 client
• pika workers：8 thread
• payload: 128 bytes

image

结论：大部分strings 相关的操作可以和redis 持平甚至更优，list 相关操作性能较 redis差，hash 相关操作稍弱于 redis

4 持续写入测试

持续写入测试用于测试写入数据量大小对写入的性能衰减影响，测试过程中将 compact 操作调整至 凌晨 2-4 点。

• golang 协程数量: 50
• client 数量: 50
• ops: SET
• pika workers：8 thread
• payload: 128 bytes
• 持续写入数量: 7 * 10^9 次

结论：写入非常稳定，基本都能稳定再 每秒 10w-15w 条之间，写入数据量达到 700GB 以上，未发生写入性能衰减情况；需要注意的是，compact 对性能影响较大，compact 期间写入速度衰减到 2k-1w /s，每次持续大概 20-40s, 2-4 点过程中共发生 4 次 compact；

5 结论

5.1 优点

• 节约成本，占用内存较小，写入数据达到 700 GB 后，占用内存在 7GB 左右
• 采用 snappy 压缩数据，数据压缩比较大，写入数据达到 700GB 后，占用磁盘约为 110 GB 左右
• 重新启动后恢复数据的过程很快，没有redis 将数据加载到内存的过程
• 多线程，不会像redis 一样由于某个耗时操作导致后面操作阻塞的现象
• 自带持久化
• 官方支持 docker 部署

5.2 缺点

• 严重依赖磁盘 io 性能，注意不同实例写入同一块盘时的影响
• lsm tree 普遍存在的 io 放大问题
• 不支持 multi exec 的事务操作
• list 相关操作性能比 redis 差
• compact 时较大的影响写入性能
• 极限性能下对 cpu 的压力较大

5.3 结论

• 并不能完全替代 redis，与 redis 可以形成互补关系。
• 对延时及延时稳定性要求高，或者用作 队列等场景，还需使用redis
• 对于大部分数据量较大，没有复杂的 链表等集合操作的场景，可使用 pika

5.4 其他注意事项

• 关闭 slotmigrate (用于 codis slot 迁移)，对性能有部分提升
• compact 对写入性能影响较大，需要根据业务情况调整写入策略
• 读取性能依赖系统 cache 和 buffer
• 同步采用 binlog，官方提供 redis 向 pika 迁移工具
• 必须使用 ssd，hdd 性能太差