携程持久化KV存储挑战Redis，狂省90%成本( 五 ) 一、背景过去几年

TRocks在内网上线后，在各个业务线都得到了广泛的使用，排除公有云的部分，私有云上已经有将近2K的实例， 10T+的数据量，下图（图10 ，图11）可以看到同样的数据写TRocks和Redis的性能对比。平均响应时间， 99.9%在同一个水平，并且我们还可以看到，得益于自定义的命令，同样的功能相比Redis更加简洁。

文章图片

文章图片
图10

文章图片

文章图片
图11
根据我们跟业务方压测，一台40C和2块RAID0的SATASSD在保证良好响应的前提下（99.9%2、成本数据
假设TRocks都是容器化部署，并且一台40C的宿主机上可以部署20个实例，每个实例大小为40G ，因为TRocks相比Redis有不小的压缩功能（约3-7倍的压缩率），如果将Redis的数据导过来可以平稳运行，那么TRocks相比Redis约可以节约90%的成本。
既然能省这么多成本，是否所有的Redis都可以用TRocks来代替，我们是否需要将私有云上所有的Redis都替换成为TRocks？
答案都是否定的，也不是我们推广TRocks的初衷，原因有以下两点：
1）如上文所提到的，我们希望TRocks能拥有Redis的大部分能力，而又不仅仅局限于Redis ，希望它更是一个通用的KV数据库，能提供更多样化的能力来支撑业务的诉求。
2）硬盘的带宽与内存有2个数量级的差距，而这些先天不足也无法满足某些Redis场景的需求。比如大Key（>100K）响应和Redis还是有一定的差距，此外某些数据量小并且单个实例访问QPS较高的实例，用TRocks来替换也并不合适，因为规模化运维治理，我们需要考虑整个宿主机和每个实例是否能平稳运行，一般来说单个实例>10G ， QPS六、未来规划
1、复合命令增强
我们调研发现，业务经常为了获取一条数据，需要多次查询TRocks ，类似二度人脉的取数据逻辑，多次的网络IO会导致耗时增加，而设计通用的命令来支持业务需求，减少网络IO变得非常重要，此外还有些用户询问TRocks的hash类型中的subkey是否也可以实现过期。由于hash功能目前仍然是遵照Redis的规则，所以现在是按照整个hashkey一起过期而不能实现内部数据项的过期。这个需求是有一定价值的，未来我们会通过提供一个特殊的hash结构来实现此类功能。
2、引入checkpoint
Kvrocks1.X在进行全量复制时， master会生成硬的backup ，会拷贝文件产生大量的IO ，而官方2.0版本已经用Rocksdbcheckpoint解决了这个问题，我们也已经将2.0版本merge过来测试，准备适时升级上线。
3、使用NVMESSD
【携程持久化KV存储挑战Redis，狂省90%成本】目前携程的大量TRocks还是跑在SATA接口的SSD上，而据我们的测试下来两块SATAraid0的带宽大约为800MB/S ，导致硬盘非常容易跑满，相比之下， NVMESSD的带宽基本都是几G起步，并且我们测试下来NVMESSD在小的压力下，对于SATASSD性能有3-5倍的提升，而对于大Key的情况（超过100K）和大的压力下， NVMESSD的性能提升可以高达10-100倍。因此我们已经计划将SATASSD全换成NVMESSD ，进一步提升TRocks的性能。