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

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”的测试：

从上面两个图，咱们能够看到：

• 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：

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对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版本，能够到如下地址下载：

• google code svn：http://fourinone.googlecode.com/svn/trunk/

• 国内oschina code：https://git.oschina.net/fourinone/fourinone/blob/master/fourinone-4.05.06.zip

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