CoolHash数据库引擎压测对比报告

jopen 10年前

Coolhash 当前性能指标:读写吞吐量超过百万,千万级别查询1秒完成,连续48小时打满CPU强压力运行稳定。redis官方公布读写性能在10万 tps,leveldb官方公布写性能在40万tps,读在6万tps,redis和leveldb都是倾向k/v高速读写,但不具备高效检索功能,没有 join关联设计。coolhash可以拿去pk世界上任何的数据库引擎产品。

下面以redis为例进行了详细测试和技术分析,leveldb 的性能可详见其官方资料,在写性能上优于redis,但是读性能和多数据结构支持上不如redis,leveldb读代价高是因为需要在内存以及各级数据 文件逐项查找并要优先考虑数据最新状态,另外redis还提供server和集群功能,leveldb不提供,redis是内存方式+内存快照持久化,而 leveldb是Memtable+硬盘持久化,leveldb持久化不受内存限制,也做到了接近缓存的性能,未来k/v数据库的趋势最好能直接当作缓存 使用,并能支持高效检索功能。

按照redis的常用方式,我们在一台服务器上进行redis“单server”和“多server”的测试:

CoolHash数据库引擎压测对比报告

CoolHash数据库引擎压测对比报告
从上面两个图,我们可以看到:

  • redis是一个单进程单线程的实现,单server的读写TPS大概在8—12万(跟redis官网公布的数据一致),为了充分利用能够资源,redis官方建议一台机器部署多个redis server。

  • 上面第二个图的TPS超过了8-12万的限制,这实际上是在一台服务器上部署了多个redis server,并将该服务器总的吞吐量算到一个redis server上得到的。但是写的时候是客户端各自写不同的redis server,多个redis server之间的数据是彼此独立的,在不同的内存空间中,如果分开计算每个redis server的写入总量除以时间,TPS还是在8-12万左右。

我们再到24核/256g/SATA硬盘的pc server上测试一下redis的benchmark,200个客户端共写入2000万数据,发现性能变化不大,还是在10万左右的TPS,又测试了20个客户端写入2000万数据,12万TPS:

CoolHash数据库引擎压测对比报告


Redis很优秀,但是也有一些局限:

  • redis不是一个并行数据库,由单进程单线程实现,已经做到了单进程极限,性能很难再突破。如果要重新改写redis,代价很大,而且 只有redis作者有能力做,其他外围的捐献者动不了。redis官方采取一种曲线救国方式,不改变单进程模式,采取外围做集群,部署多个server来 提高CPU利用率,redis3.0的集群方案使用一种hash slot算法(不是一致哈希),用多个redis server做数据分片存储,按照crc16/16384取模方式,让客户端根据hash slot的配置寻址,扩容按照slot单位做数据迁移达到负载均衡。由于在同台服务器也存在多server实例集群,会牵扯出很多server的 master-slave复制和数据迁移一致性等复杂性,也容易引起后端的IO争用,特别是在AOF模式时。

  • redis是一种内存快照方式,也就意味着它的持久化大小受内存限制,不是真正的数据库持久化存储,内存是昂贵的,为了扩大内存存储,往 往需要更多的服务器搭建缓存集群,redis作者曾想增加一种diskstore的全持久化+cache方式,采用SHA1算法来建立存储结构,来改进内 存快照方式的种种不足,但是涉及到对redis底层持久化方式的重构,这个计划从11年提出,截至到目前3.0版本,仍然还没有提供。

  • redis的存储方式不是按照数据库存储索引结构设计,无法做到高性能的按范围、按key/value的模糊检索,更多只能在内存中进行全局数据的遍历过滤,没有高效的查询功能,redis更适合做缓存读写,不适合当作数据库存储使用。

国内的redis使用团队更多也是在运维工具、监控管理、主备、故障恢复等等方面改进,不具备对上面redis的3点内核局限的重构能力。

我们接下来在同机环境(24核/256g/SATA硬盘)测试coolhash, 实际上coolhash也可以像上面redis那样在一台服务器上部署多个server实例,但是我们这里启动一个coolhash就够了。 coolhash是一个并行数据库引擎和数据库server,可以通过调整“coolhash数据工人数量、客户端并发数量、每客户端读写数量”三个指标 项达到一台服务器的最佳吞吐量性能。

coolhash通过一组数据工人并行的完成任务,我们先测试一个coolhash启动多少个数据工 人最合适,下面在一台服务器上运行coolhash并分别启动1-96个工人,再用另外一台服务器模拟了200个客户端并发,每个客户端写入10万数据, 累计2000万数据,数据格式key=n(0
测试1:x个数据工人,200个客户端并发,每个客户端写入10万数据

数据工人 1个工人 8个工人 24个工人 32个工人 96个工人
耗时 400秒 40秒 20秒 23秒 25秒
cpu最高峰 10% 20% 75% 85% 90%
TPS 5万/秒 50万/秒 100万/秒 87万/秒 80万/秒

分析:可以清晰的看到并行数据库的优势明显,如果只有一个数据工人,也就是单进程模式,它的TPS是很难超出 10万的,如果是8个数据工人并行作业,性能一下子就能从400秒减少到40秒,提升10倍,但也不是数据工人越多性能越好,我们看到24-32个工人是 个顶峰,如果再增加工人数虽然能提升cpu使用率,但是调度开销大,后端硬盘io等跟不上,导致性能反而有所下降。
根据上面的结论,我们配置coolhash启动24个数据工人最合适,接下来再进一步调整“客户端并发数”和“每个客户端写入数量”,来达到一台服务器的最佳性能。

测试2:24个数据工人,x个客户端并发,每个客户端写入10万数据

客户端数 1并发 10并发 20并发 50并发 100并发 200并发
写入总量 10万 100万 200万 500万 1000万 2000万
耗时 1秒 3秒 5秒 10秒 18秒 20秒
TPS 10万/秒 33万/秒 40万/秒 50万/秒 55万/秒 100万/秒

分析:如果每个客户端写相同数量的数据,随着并发数的提高,总体的吞吐量会高于单客户端呈线性增长趋势,但是受 服务器cpu、内存、io等性能限制,不会一直增长,会倾向于一个平衡值。每台服务器并不是能承受无限大的并发数量,如果超出了承受限制,客户端会长时间 等待,容易产生socket连接超时。合理的控制并发数量能提升服务器的吞吐性能,下面我们增大每个客户端的写入数量,减少总的并发数,并观察效果。

测试3:24个数据工人,20个客户端并发,每个客户端写入x万数据

每客户端写 10万/每 50万/每 100万/每 200万/每 300万/每
写入总量 200万 1000万 2000万 4000万 6000万
耗时 4秒 6秒 10秒 15秒 22秒
写TPS 50万/秒 167万/秒 200万/秒 267万/秒 272万/秒

分析:可以看到同样写入2000万数据,采用20并发*100万比200并发*10万的性能提升了一倍,能达到 200万以上TPS。这是因为客户端建立连接后,一次提交100万条数据的写入请求,相比每条数据连接server,能很大节省网络开销和硬盘IO开销。 由此我们也能得到,并不是并发连接越多越好,而是控制一定数量的连接池性能会更好。

接下来我们再以使用相同参数,测试一下读的性能。
测试4:24个数据工人,20个客户端并发,每个客户端读出x万数据

每客户端读 10万/每 50万/每 100万/每 200万/每 300万/每
读出总量 200万 1000万 2000万 4000万 6000万
耗时 4秒 6秒 11秒 20秒 30秒
读TPS 50万/秒 167万/秒 182万/秒 200万/秒 200万/秒

分析:coolhash是一个读写平衡的数据库引擎,可以看到读和写的性能相差不大,都能达到200万的TPS。

coolhash 提供了高效的查询检索功能,可以支持key和value的同时模糊查询,下面按照600万—3亿不同的数据总量进行模糊查询,数据格式为key=n(0& lt;n<3亿),value=n(0 CoolHashResult hr = chc.find("*", ValueFilter.contains(“8888888”))
测试5:24个数据工人,x个客户端模糊查询x万数据
单个客户端模糊查询:

数据总量 600万 2000万 6000万 1亿 3亿
耗时 0.9秒 1秒 1.7秒 2秒 6秒

多个客户端高并发模糊查询:

客户端数 1并发 10并发 20并发 50并发 100并发 200并发
600万 0.9秒 2秒 4秒 9秒 14秒 18秒
2000万 1秒 4秒 9秒 21秒 37秒 45秒

分析:对于千万级别的数据,客户端一次任意模糊查询的耗时都是在1秒完成,如果超过1亿需要2秒,3亿需要6秒 (在没有额外构建索引情况下)。如果是100个客户端并发模糊查询,按照上面表格里100并发查询2000万数据,平均耗时37秒,每次查询耗时 37/100=0.37秒,每秒查询次数100/37=2.7次,每秒查询数据范围大小100*2000万/37秒=5400万。这里测试key是“*” 代表所有,如果key根据业务特点进行了分层设计,以“user.*.name”这样形式模糊查询,范围会缩小,速度会更快。

测试6:压力测试,200高并发下每客户端读取10万数据连续48小时不间断,服务端cpu、内存、带宽资源高压力运行稳定无异常。

下面归纳一下coolhash和redis的基本区别:


redis coolhash
实现语言 c java
大小 2.3万行代码 小于1万行(含fourinone)
运行环境 Linux Linux/windows
数据库类型 k/v缓存数据库 k/v持久化数据库
实现模式 单进程模式,所有操作单线程完成 多进程模式,并行数据库,所有操作并行完成
持久化模式 内存快照,aof日志 硬盘持久化+cache
存储大小 受内存大小限制 无限制,取决硬盘大小
数据类型支持 String,Hash,List,Set,Sorted set等,List是一个双向链表实现,可用于实现消息队列。 基本数据类型:“String、short、int、long、double、float、Date”,高级数据类型:大部分的java集合都能支持(List、Map、Set等),以及任意可序列化的自定义java类型,底层数据类型:二进制型
存储结构 redisDb内存结构,Key和key之间无联系,无上下层结构 按照数据库索引存储结构设计,CoolHash算法实现,支持key的树型层次结构
查询检索 没有针对范围检索设计 Key索引+并行计算高效查询,查询性能在秒级
关联设计 没有针对join设计 Key指针设计,并可连续指,支持建立1对1、1对n、n对n的复杂关联关系
读写性能 单server吞吐量10万tps(内存) 单server可达到百万以上tps(硬盘)
事务处理 支持,但没有事务隔离级别 支持ACID,实现TRANSACTION_SERIALIZABLE隔离级别
Server支持 支持 支持
命令行支持 支持 不支持
主备支持 直接支持,通过redis.conf配置主备 不直接支持,提供fttp分布式备份api开发包支持
集群支持 3.0版直接支持,通过hash slot算法 不直接支持,提供分布式缓存集群和fttp等开发包支持

总结:

  • 首先不能简单的以实现语言来衡量性能,认为c实现的就一定比java高效,数据库引擎的效率提升更多取决于底层算法改进和设计突破,c在底层和操作系统交互上有优势,但是取决于开发者,一个蹩脚的c工程师写出的代码只会低效和漏洞百出。

  • redis的优势在于快速的缓存读写、丰富的数据类型支持,以及完善的主备复制和集群实现,劣势在于单进程模式、内存限制、查询检索等方面。

  • coolhash是一个并行数据库引擎,在很多地方采用了大胆创新的设计,并获得了很好的性能体验,改进后的哈希算法能实现更快的读写吞 吐量,key层次结构和key指针等设计能实现更高效的查询检索和join关联。由于只做数据库引擎,暂不提供主备和集群功能,但是fourinone提 供了大部分分布式技术简单实现的开发API,开发者可以利用这些自己去实现。

  • 随着数据库实现技术的发展,kv缓存和kv持久化存储的性能越来越接近,边界会越来越模糊,也会越来越涵盖关系数据库的功能。存储硬件技术也在发展,未来在内存+ssd混合存储上还会有更好的性能突破。


以上测试程序和运行包都来源于fourinone4.0版本,可以到以下地址下载:

CoolHash数据库demo目录内容:

  • RunServer.java:启动服务端

  • RunClient.java:启动客户端

  • CoolHashTestRun.java:启动多个并发客户端

 
CoolHash作者声明:欢迎各位朋友理性验证和讨论,不欢迎不理会各种喷子言论。
这 里有很多人是redis和leveldb的使用者和封装者,其中一部分人会看coolhash不爽,甚至失去理性变成喷子,对coolhash大加攻击和 诋毁,希望coolhash只是玩具,希望coolhash没有场景...但是喷子们要清楚自己的位置,redis和leveldb不是你的作品,你只是 站在洋人前面狐假虎威而已,核心层面的东西你甚至不具备发言权。长期以来国内工程师都是以学习和使用国外开源软件为生存技能,能理解这些人也只是混口饭 吃。
很多人软件思想意识落后,“软件傻瓜化”超出了他的理解范 围,看到demo简单,便误认为框架源码也肤浅,看到demo里没有synchronized,便以为框架没有同步,有人甚至怀疑源码是假的。demo简 单是为了保护用户的自信心和驾驭感,用户只需要看到一个美丽的躯壳,血肉模糊的东西留给框架戴着口罩拿着手术刀去做,这实际上对设计者提出了更大的难度, 所以源码要实现那么多功能,还要做到体验傻瓜化,一定是非常精密的逻辑组成,源码不可能像demo那样通俗易懂。
一些人一来就对 fourinone源码指手画脚,评头论足,大部分批评只停留在“编程规范、格式、变量名、包名、调了哪些工具类”这些层面,这些人需要多花时间提升自己 的技术积累、设计能力、算法能力,才能真正理解源码的各种行为,作者到过国内各种IT企业,非常清楚国内工程师的技术能力能到什么程度,国内的开源软件大 部分是基于国外开源软件封装后的二次开源,真正意义上的原创很少,大部分中国IT企业处在产业链末端,没有核心技术,依靠外包劳动力,工程师的技术寿命很 短,平均只有3-5年,然后周围环境会暗示他转向管理或者业务,只有这样才能得到领导认可,技术积累太短暂,技术人员没有悟性,也缺乏兴趣,过于依赖国 外,是不可能在核心软件层面有真正的原创。

一些人对coolhash很质疑,认为很少人很少代码实现不了高性能,实际上早在几年 前,fourinone就在一片质疑声中被要求压测,结果出乎意料在计算性能上优于hadoop,现在coolhash只是重演了创新能力而已。建议各种 质疑者跟风者先放下政治偏见、利益冲突、情感排斥,耐心的动手去试试。对于技术上缺乏分辨力的人,建议你认准三点,一看上手是否容易;二看功能是否强大; 三看性能是否高效,只要满足这三点就没有人可以忽悠得了你,然后你再结合源码去反思是如何做到的。

曾国藩说过“窃喜洋人之智巧中国亦能为之,彼不能傲我以其所不知矣!”

文 人不相轻,技术归技术,本文对redis和leveldb的作者充满尊敬和虚心学习,Salvatore Sanfilippo(antirez) 说过代码像一首诗,Jeffrey Dean更是google map/reduce的作者,他们都表现出很高的职业素养和天赋,是这些人推动着世界软件技术的发展,也成为中国架构师内心难以跨越的丰碑。是存在差距, 但是可以站着学习,而不是跪着膜拜,一味跟从只会丧失判断力和创新力,香港的年轻人曾经不相信大陆的taobao会比eBay强大,QQ会比MSN强大, 直到MSN垮了仍然不相信是真的,没有信心,没有努力,梦想只会变成做梦。

来自:http://my.oschina.net/fourinone/blog/289122