文档章节

基准测试:Apache Ignite仍然领先于Hazelcast

李玉珏
 李玉珏
发布于 2017/05/14 23:15
字数 799
阅读 884
收藏 7

当在谷歌中搜索Apache Ignite时,发生了一个奇怪的事:Hazelcast的广告跑到了列表的顶部,建议说Hazelcast比Ignite快50%:

1

要注意的第一个疑点是当你点击链接时,显示的是Hazelcast与一年前发布的Ignite的1.5版本的比较!另外,一段时间内吹嘘自己也是可以的,但是可笑的是这持续了一年而不在页面中更新基准测试结果。 那好,这可能是Hazelcast营销团队的疏忽,既然这样了,那么就有必要帮助他们展示一下Ignite和Hazelcast最新版本的当前状态。

常规测试

对像Apache Ignite或者Hazelcast这样的分布式平台进行测试的最简单方式是,启动一个拥有若干节点的集群然后运行一个客户端进程产生负载再收集测试结果。作为基准,在AWS上准备了一个拥有四台机器/数据节点的集群,然后负载来自一个单一客户端机器(或者说应用)。Yardstick作为测试框架,所有的参数和操作方法如下所示: 2

根据给定的配置,按照在Amazon上运行Yardstick的说明,可以再现如下数据: 3

非常明显,在大多数的基本操作中Ignite 1.9.0版本都显著优于Hazelcast 3.8.1版本,部分场景中甚至领先160%。 同时,也可以发现在部分原子操作中,Hazelcast领先Ignite大约4%,老实说,知道Ignite还有性能改进空间非常好,Hazelcast没有让Ignite的性能工程师轻松起来。 然而,发现性能缺陷之后,决定在一个更高的负载下执行同样的测试集,这样会更接近生产场景-负载由8台客户端机器产生(或者说应用)而不是一台客户机,结果令人振奋!下一章中会看到。

高压测试

上面的Yardstick配置只修改了如下的部分: 4

在客户机数量从1个增加到8个之后,再现了如下的结果: 5

这是从一台客户机上获取的数据,要想获得一秒内的操作总数,只需要累加即可。从目前这个结果来看,在高负载下,在任何场景的每项测试中Ignite都领先于Hazelcast。 比如,Ignite的ANSI-99 SQL引擎领先Hazelcast的基于谓词的查询引擎200%,而在只有一个客户端的场景中,这个差距只有80%。 甚至,Ignite在先前的atomic-put-get-bs-6场景原子测试中,由落后Hazelcast4%到领先Hazelcast42%。

结论

在产品化时可能总是要决定使用哪个产品,但是一个黄金法则是不要盲目相信厂商提供的官方数据。掌握所有的信息后了解一个产品,然后在自己的场景中进行测试,只有这样,才能知道哪个产品更适合自己。

本文译自Denis Magda的博客

© 著作权归作者所有

李玉珏

李玉珏

粉丝 373
博文 76
码字总数 143787
作品 0
沈阳
架构师
私信 提问
加载中

评论(28)

Geiliever
Geiliever

引用来自“李玉珏”的评论

引用来自“Geiliever”的评论

请教下 ignite有没有Hazelcast的用groupName、groupPassword自动创建集群的功能的?我觉得配置ip,端口的方法实在不太方便

可以通过组播地址或者组播端口创建集群,创建集群后可以通过节点属性对集群进行分组,很方便的。

引用来自“Geiliever”的评论

我这边一台机器上面有很多应用,我想应用之间的集群都分开,这样就得每个应用都要去配置ip、端口。
节点属性倒是一个思路,不知道会不会集群很大,通过节点属性区分有性能的影响?
另外TcpDiscoverySpi和TcpCommunicationSpi区别是什么?一个是用来集群发现的,一个是用来集群通信的?为什么不用一个端口?

引用来自“李玉珏”的评论

像你这种情况,用组播端口进行隔离是最方便的,每个应用配置不同的TcpDiscoveryMulticastIpFinder,然后配置不同的multicastPort属性就可以了。
性能的问题,你不用担心。
内部通信和发现机制不同,发现机制和外部网络环境强相关。

引用来自“Geiliever”的评论

我理解你的意思,但是应用很多,然后不同的应用归属不同的开发人员。要求他们各自配置不同的属性比较困难,万一多个应用没有配置或者重复了,那么会有问题的。像Hazelcast的用groupName、groupPassword则不会有这样的问题,很方便,直接应用名和自己设置的密码。

引用来自“李玉珏”的评论

没明白你的意思。
Hazelcast不是也得修改配置么?只不过配置方式不同而已。
Ignite可以通过编程的方式进行配置,也可以通过配置文件的方式进行配置,Hazelcast也是一样的,都是同时支持API和配置文件的,不可能一点改动没有啊?

引用来自“Geiliever”的评论

就是Hazelcast的用户名和密码的配置更方便,不同的项目不会用混淆。Ignite只能用ip、端口的方式,对于项目很多的环境里面不够友好,相互直接必须区分开端口。

引用来自“李玉珏”的评论

你就没明白。
不要用默认的那个需要配置ip和端口那个。
用这个TcpDiscoveryMulticastIpFinder,你用组播的发现机制,只要不同的应用配置不同的组播端口就行了。
不要用TcpDiscoveryVmIpFinder。
没觉得比Hazelcast的更复杂,或者工作量更大。

引用来自“Geiliever”的评论

只要不同的应用配置不同的组播端口就行了。
在我们这边一台机器上面有很多应用,属于不同的开发组,配置不同的组播端口意味着我需要联系他们一个个分配端口,这个分配工作比较难以执行,而且容易出错。
而对于Hazelcast我只需要和他们说你们配置你们的应用名和你们自己设置的密码就可以了。

引用来自“李玉珏”的评论

你的业务同时用了这两种技术?还是在做技术选型?
如果是做技术选型,如果这个问题点不符合你的需求,那么Ignite这个技术可能不适合你们。
如果你们已经使用了这个技术,还不想换掉,那么就得想办法规避这点区别。
Hazelcast和Ignite都比较重,功能类似,你不可能都用,拿公司实际业务给人家做对比测试呢?
目前在做技术选型,其实主要我希望用Ignite,感觉Ignite更open些,目前主要想有没有办法规避掉上面那个点,如果实在没有办法就暂时先用Hazelcast,后面等Ignite支持用户名和密码的方式再考虑替换。
李玉珏
李玉珏 博主

引用来自“李玉珏”的评论

引用来自“Geiliever”的评论

请教下 ignite有没有Hazelcast的用groupName、groupPassword自动创建集群的功能的?我觉得配置ip,端口的方法实在不太方便

可以通过组播地址或者组播端口创建集群,创建集群后可以通过节点属性对集群进行分组,很方便的。

引用来自“Geiliever”的评论

我这边一台机器上面有很多应用,我想应用之间的集群都分开,这样就得每个应用都要去配置ip、端口。
节点属性倒是一个思路,不知道会不会集群很大,通过节点属性区分有性能的影响?
另外TcpDiscoverySpi和TcpCommunicationSpi区别是什么?一个是用来集群发现的,一个是用来集群通信的?为什么不用一个端口?

引用来自“李玉珏”的评论

像你这种情况,用组播端口进行隔离是最方便的,每个应用配置不同的TcpDiscoveryMulticastIpFinder,然后配置不同的multicastPort属性就可以了。
性能的问题,你不用担心。
内部通信和发现机制不同,发现机制和外部网络环境强相关。

引用来自“Geiliever”的评论

我理解你的意思,但是应用很多,然后不同的应用归属不同的开发人员。要求他们各自配置不同的属性比较困难,万一多个应用没有配置或者重复了,那么会有问题的。像Hazelcast的用groupName、groupPassword则不会有这样的问题,很方便,直接应用名和自己设置的密码。

引用来自“李玉珏”的评论

没明白你的意思。
Hazelcast不是也得修改配置么?只不过配置方式不同而已。
Ignite可以通过编程的方式进行配置,也可以通过配置文件的方式进行配置,Hazelcast也是一样的,都是同时支持API和配置文件的,不可能一点改动没有啊?

引用来自“Geiliever”的评论

就是Hazelcast的用户名和密码的配置更方便,不同的项目不会用混淆。Ignite只能用ip、端口的方式,对于项目很多的环境里面不够友好,相互直接必须区分开端口。

引用来自“李玉珏”的评论

你就没明白。
不要用默认的那个需要配置ip和端口那个。
用这个TcpDiscoveryMulticastIpFinder,你用组播的发现机制,只要不同的应用配置不同的组播端口就行了。
不要用TcpDiscoveryVmIpFinder。
没觉得比Hazelcast的更复杂,或者工作量更大。

引用来自“Geiliever”的评论

只要不同的应用配置不同的组播端口就行了。
在我们这边一台机器上面有很多应用,属于不同的开发组,配置不同的组播端口意味着我需要联系他们一个个分配端口,这个分配工作比较难以执行,而且容易出错。
而对于Hazelcast我只需要和他们说你们配置你们的应用名和你们自己设置的密码就可以了。
你的业务同时用了这两种技术?还是在做技术选型?
如果是做技术选型,如果这个问题点不符合你的需求,那么Ignite这个技术可能不适合你们。
如果你们已经使用了这个技术,还不想换掉,那么就得想办法规避这点区别。
Hazelcast和Ignite都比较重,功能类似,你不可能都用,拿公司实际业务给人家做对比测试呢?
Geiliever
Geiliever

引用来自“李玉珏”的评论

引用来自“Geiliever”的评论

请教下 ignite有没有Hazelcast的用groupName、groupPassword自动创建集群的功能的?我觉得配置ip,端口的方法实在不太方便

可以通过组播地址或者组播端口创建集群,创建集群后可以通过节点属性对集群进行分组,很方便的。

引用来自“Geiliever”的评论

我这边一台机器上面有很多应用,我想应用之间的集群都分开,这样就得每个应用都要去配置ip、端口。
节点属性倒是一个思路,不知道会不会集群很大,通过节点属性区分有性能的影响?
另外TcpDiscoverySpi和TcpCommunicationSpi区别是什么?一个是用来集群发现的,一个是用来集群通信的?为什么不用一个端口?

引用来自“李玉珏”的评论

像你这种情况,用组播端口进行隔离是最方便的,每个应用配置不同的TcpDiscoveryMulticastIpFinder,然后配置不同的multicastPort属性就可以了。
性能的问题,你不用担心。
内部通信和发现机制不同,发现机制和外部网络环境强相关。

引用来自“Geiliever”的评论

我理解你的意思,但是应用很多,然后不同的应用归属不同的开发人员。要求他们各自配置不同的属性比较困难,万一多个应用没有配置或者重复了,那么会有问题的。像Hazelcast的用groupName、groupPassword则不会有这样的问题,很方便,直接应用名和自己设置的密码。

引用来自“李玉珏”的评论

没明白你的意思。
Hazelcast不是也得修改配置么?只不过配置方式不同而已。
Ignite可以通过编程的方式进行配置,也可以通过配置文件的方式进行配置,Hazelcast也是一样的,都是同时支持API和配置文件的,不可能一点改动没有啊?

引用来自“Geiliever”的评论

就是Hazelcast的用户名和密码的配置更方便,不同的项目不会用混淆。Ignite只能用ip、端口的方式,对于项目很多的环境里面不够友好,相互直接必须区分开端口。

引用来自“李玉珏”的评论

你就没明白。
不要用默认的那个需要配置ip和端口那个。
用这个TcpDiscoveryMulticastIpFinder,你用组播的发现机制,只要不同的应用配置不同的组播端口就行了。
不要用TcpDiscoveryVmIpFinder。
没觉得比Hazelcast的更复杂,或者工作量更大。
只要不同的应用配置不同的组播端口就行了。
在我们这边一台机器上面有很多应用,属于不同的开发组,配置不同的组播端口意味着我需要联系他们一个个分配端口,这个分配工作比较难以执行,而且容易出错。
而对于Hazelcast我只需要和他们说你们配置你们的应用名和你们自己设置的密码就可以了。
李玉珏
李玉珏 博主

引用来自“李玉珏”的评论

引用来自“Geiliever”的评论

请教下 ignite有没有Hazelcast的用groupName、groupPassword自动创建集群的功能的?我觉得配置ip,端口的方法实在不太方便

可以通过组播地址或者组播端口创建集群,创建集群后可以通过节点属性对集群进行分组,很方便的。

引用来自“Geiliever”的评论

我这边一台机器上面有很多应用,我想应用之间的集群都分开,这样就得每个应用都要去配置ip、端口。
节点属性倒是一个思路,不知道会不会集群很大,通过节点属性区分有性能的影响?
另外TcpDiscoverySpi和TcpCommunicationSpi区别是什么?一个是用来集群发现的,一个是用来集群通信的?为什么不用一个端口?

引用来自“李玉珏”的评论

像你这种情况,用组播端口进行隔离是最方便的,每个应用配置不同的TcpDiscoveryMulticastIpFinder,然后配置不同的multicastPort属性就可以了。
性能的问题,你不用担心。
内部通信和发现机制不同,发现机制和外部网络环境强相关。

引用来自“Geiliever”的评论

我理解你的意思,但是应用很多,然后不同的应用归属不同的开发人员。要求他们各自配置不同的属性比较困难,万一多个应用没有配置或者重复了,那么会有问题的。像Hazelcast的用groupName、groupPassword则不会有这样的问题,很方便,直接应用名和自己设置的密码。

引用来自“李玉珏”的评论

没明白你的意思。
Hazelcast不是也得修改配置么?只不过配置方式不同而已。
Ignite可以通过编程的方式进行配置,也可以通过配置文件的方式进行配置,Hazelcast也是一样的,都是同时支持API和配置文件的,不可能一点改动没有啊?

引用来自“Geiliever”的评论

就是Hazelcast的用户名和密码的配置更方便,不同的项目不会用混淆。Ignite只能用ip、端口的方式,对于项目很多的环境里面不够友好,相互直接必须区分开端口。
你就没明白。
不要用默认的那个需要配置ip和端口那个。
用这个TcpDiscoveryMulticastIpFinder,你用组播的发现机制,只要不同的应用配置不同的组播端口就行了。
不要用TcpDiscoveryVmIpFinder。
没觉得比Hazelcast的更复杂,或者工作量更大。
Geiliever
Geiliever

引用来自“李玉珏”的评论

引用来自“Geiliever”的评论

请教下 ignite有没有Hazelcast的用groupName、groupPassword自动创建集群的功能的?我觉得配置ip,端口的方法实在不太方便

可以通过组播地址或者组播端口创建集群,创建集群后可以通过节点属性对集群进行分组,很方便的。

引用来自“Geiliever”的评论

我这边一台机器上面有很多应用,我想应用之间的集群都分开,这样就得每个应用都要去配置ip、端口。
节点属性倒是一个思路,不知道会不会集群很大,通过节点属性区分有性能的影响?
另外TcpDiscoverySpi和TcpCommunicationSpi区别是什么?一个是用来集群发现的,一个是用来集群通信的?为什么不用一个端口?

引用来自“李玉珏”的评论

像你这种情况,用组播端口进行隔离是最方便的,每个应用配置不同的TcpDiscoveryMulticastIpFinder,然后配置不同的multicastPort属性就可以了。
性能的问题,你不用担心。
内部通信和发现机制不同,发现机制和外部网络环境强相关。

引用来自“Geiliever”的评论

我理解你的意思,但是应用很多,然后不同的应用归属不同的开发人员。要求他们各自配置不同的属性比较困难,万一多个应用没有配置或者重复了,那么会有问题的。像Hazelcast的用groupName、groupPassword则不会有这样的问题,很方便,直接应用名和自己设置的密码。

引用来自“李玉珏”的评论

没明白你的意思。
Hazelcast不是也得修改配置么?只不过配置方式不同而已。
Ignite可以通过编程的方式进行配置,也可以通过配置文件的方式进行配置,Hazelcast也是一样的,都是同时支持API和配置文件的,不可能一点改动没有啊?
就是Hazelcast的用户名和密码的配置更方便,不同的项目不会用混淆。Ignite只能用ip、端口的方式,对于项目很多的环境里面不够友好,相互直接必须区分开端口。
李玉珏
李玉珏 博主

引用来自“李玉珏”的评论

引用来自“Geiliever”的评论

请教下 ignite有没有Hazelcast的用groupName、groupPassword自动创建集群的功能的?我觉得配置ip,端口的方法实在不太方便

可以通过组播地址或者组播端口创建集群,创建集群后可以通过节点属性对集群进行分组,很方便的。

引用来自“Geiliever”的评论

我这边一台机器上面有很多应用,我想应用之间的集群都分开,这样就得每个应用都要去配置ip、端口。
节点属性倒是一个思路,不知道会不会集群很大,通过节点属性区分有性能的影响?
另外TcpDiscoverySpi和TcpCommunicationSpi区别是什么?一个是用来集群发现的,一个是用来集群通信的?为什么不用一个端口?

引用来自“李玉珏”的评论

像你这种情况,用组播端口进行隔离是最方便的,每个应用配置不同的TcpDiscoveryMulticastIpFinder,然后配置不同的multicastPort属性就可以了。
性能的问题,你不用担心。
内部通信和发现机制不同,发现机制和外部网络环境强相关。

引用来自“Geiliever”的评论

我理解你的意思,但是应用很多,然后不同的应用归属不同的开发人员。要求他们各自配置不同的属性比较困难,万一多个应用没有配置或者重复了,那么会有问题的。像Hazelcast的用groupName、groupPassword则不会有这样的问题,很方便,直接应用名和自己设置的密码。
没明白你的意思。
Hazelcast不是也得修改配置么?只不过配置方式不同而已。
Ignite可以通过编程的方式进行配置,也可以通过配置文件的方式进行配置,Hazelcast也是一样的,都是同时支持API和配置文件的,不可能一点改动没有啊?
Geiliever
Geiliever

引用来自“李玉珏”的评论

引用来自“Geiliever”的评论

请教下 ignite有没有Hazelcast的用groupName、groupPassword自动创建集群的功能的?我觉得配置ip,端口的方法实在不太方便

可以通过组播地址或者组播端口创建集群,创建集群后可以通过节点属性对集群进行分组,很方便的。

引用来自“Geiliever”的评论

我这边一台机器上面有很多应用,我想应用之间的集群都分开,这样就得每个应用都要去配置ip、端口。
节点属性倒是一个思路,不知道会不会集群很大,通过节点属性区分有性能的影响?
另外TcpDiscoverySpi和TcpCommunicationSpi区别是什么?一个是用来集群发现的,一个是用来集群通信的?为什么不用一个端口?

引用来自“李玉珏”的评论

像你这种情况,用组播端口进行隔离是最方便的,每个应用配置不同的TcpDiscoveryMulticastIpFinder,然后配置不同的multicastPort属性就可以了。
性能的问题,你不用担心。
内部通信和发现机制不同,发现机制和外部网络环境强相关。
我理解你的意思,但是应用很多,然后不同的应用归属不同的开发人员。要求他们各自配置不同的属性比较困难,万一多个应用没有配置或者重复了,那么会有问题的。像Hazelcast的用groupName、groupPassword则不会有这样的问题,很方便,直接应用名和自己设置的密码。
李玉珏
李玉珏 博主

引用来自“李玉珏”的评论

引用来自“Geiliever”的评论

请教下 ignite有没有Hazelcast的用groupName、groupPassword自动创建集群的功能的?我觉得配置ip,端口的方法实在不太方便

可以通过组播地址或者组播端口创建集群,创建集群后可以通过节点属性对集群进行分组,很方便的。

引用来自“Geiliever”的评论

我这边一台机器上面有很多应用,我想应用之间的集群都分开,这样就得每个应用都要去配置ip、端口。
节点属性倒是一个思路,不知道会不会集群很大,通过节点属性区分有性能的影响?
另外TcpDiscoverySpi和TcpCommunicationSpi区别是什么?一个是用来集群发现的,一个是用来集群通信的?为什么不用一个端口?
像你这种情况,用组播端口进行隔离是最方便的,每个应用配置不同的TcpDiscoveryMulticastIpFinder,然后配置不同的multicastPort属性就可以了。
性能的问题,你不用担心。
内部通信和发现机制不同,发现机制和外部网络环境强相关。
Geiliever
Geiliever

引用来自“李玉珏”的评论

引用来自“Geiliever”的评论

请教下 ignite有没有Hazelcast的用groupName、groupPassword自动创建集群的功能的?我觉得配置ip,端口的方法实在不太方便

可以通过组播地址或者组播端口创建集群,创建集群后可以通过节点属性对集群进行分组,很方便的。
我这边一台机器上面有很多应用,我想应用之间的集群都分开,这样就得每个应用都要去配置ip、端口。
节点属性倒是一个思路,不知道会不会集群很大,通过节点属性区分有性能的影响?
另外TcpDiscoverySpi和TcpCommunicationSpi区别是什么?一个是用来集群发现的,一个是用来集群通信的?为什么不用一个端口?
李玉珏
李玉珏 博主

引用来自“Geiliever”的评论

请教下 ignite有没有Hazelcast的用groupName、groupPassword自动创建集群的功能的?我觉得配置ip,端口的方法实在不太方便

可以通过组播地址或者组播端口创建集群,创建集群后可以通过节点属性对集群进行分组,很方便的。
GridGain 确认 Apache Ignite 性能是 Hazelcast 的 2 倍

针对由 Hazelcast 的CEO,Greg Luck先生撰写的一篇有煽动性的博客,指责 Apache Ignite 社区"伪造"测试结果,该博客引发了一些混乱,我觉得我有必要澄清一下。 老实说,对于从Hazelcast看到这...

oschina
2016/02/24
4.3K
4
Apache Ignite 1.9.0 发布,内存数据组织平台

Apache Ignite 内存数组组织框架是一个高性能、集成和分布式的内存计算和事务平台,用于大规模的数据集处理。Ignite 为应用和不同的数据源之间提供一个高性能、分布式内存中数据组织管理的框...

王练
2017/03/07
1K
2
Apache Ignite上的TensorFlow

任何深度学习都是从数据开始的,这是关键点。没有数据,就无法训练模型,也无法评估模型质量,更无法做出预测,因此,数据源非常重要。在做研究、构建新的神经网络架构、以及做实验时,会习惯...

李玉珏
03/20
1K
0
Apache Ignite 2.5.0 版本发布,千级节点伸缩性

Apache Ignite 2.5: 千级节点伸缩性 Apache Ignite的用户通常知道的两个关键点是-扩展性和性能。在很多分布式系统的整个生命周期中,通常会不停地改进性能,而对扩展性相关的改进次数,会比较...

李玉珏
2018/06/01
1K
10
在Ignite中使用线性回归算法

在本系列前面的文章中,简单介绍了一下Ignite的机器学习网格,下面会趁热打铁,结合一些示例,深入介绍Ignite支持的一些机器学习算法。 如果要找合适的数据集,会发现可用的有很多,但是对于...

李玉珏
2018/11/22
239
0

没有更多内容

加载失败,请刷新页面

加载更多

关于ThinkPHP5.1+的Log无法记录SQL调试记录的小经历

项目开发阶段,除了基本编码外,性能也需要实时关注与优化。之前我的大部分项目都是使用ThinkPHP5.0以及ThinkPHP3.2,对于框架提供的日志记录和日志配置都差不多,然后使用ThinkPHP5.1的时候...

北桥苏
15分钟前
0
0
TiDB Binlog 源码阅读系列文章(四)Pump server 介绍

作者: satoru 在 上篇文章 中,我们介绍了 TiDB 如何通过 Pump client 将 binlog 发往 Pump,本文将继续介绍 Pump server 的实现,对应的源码主要集中在 TiDB Binlog 仓库的 pump/server.go...

TiDB
18分钟前
0
0
OSChina 周五乱弹 ——不知道假装开心,装的像么

Osc乱弹歌单(2019)请戳(这里) 【今日歌曲】 @巴拉迪维 :天黑了 你很忧愁, 你说世界上, 找不到四块五的妞, 行走在凌晨两点的马路上, 你疲倦地拿着半盒黄鹤楼。#今日歌曲推荐# 《四块...

小小编辑
今天
2.4K
18
Windows下学习C语言有哪些集成开发软件?

前言 初学者学习C语言遇到的最大困难想必就是搭建环境了,相当多的初学者就是被搭建环境导致放弃了学习编程,就我自己的经验而言,初学编程不应该受限于环境,使用成熟好用的环境就可以了,之...

Allen5G
昨天
2
0
Hello,Servlet!

Servlet来源 上文说过了servlet是什么,我们从servlet是什么中也可以了解到servlet的来源:servlet是Java的一个类,并且能够运行在web容器上,所以servlet是按照web容器的规范和Java的规范写...

蒙尘
昨天
1
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部