Ignite vs Hazelcast

内存数据网格HazelcastIgnite是大家非常熟悉的两种分布式内存数据网格工具。

Hazelcast 是一款基于 Java的内存数据网格,它的名称和公司的名称相同。hazelcast支持分布式队列,集合,map,线程池,锁,支持事务处理,分布式的监听和事件,支持动态增加集群节点,动态备份数据,动态failover等。

关于Apache Ignite 的中文介绍可以参考李玉珏写的Apache Ignite(一):简介以及和Coherence、Gemfire、Redis等的比较等系列文章。Ignite来源于尼基塔·伊万诺夫于2007年创建的GridGain系统公司开发的GridGain软件,2015年1月,GridGain通过Apache 2.0许可进入Apache的孵化器进行孵化,很快就于8月25日毕业并且成为Apache的顶级项目,9月28日即发布了1.4.0版,2016年1月初发布了1.5.0版,迭代速度很快。

两个产品背后的公司Hazelcast和GridGain都有风投的背影。所以产品在开源免费的基础上还会提供商业版的支持。

我没有在实际产品中使用过这两款产品,仅仅关注过这一类的产品,所以并不完全了解它们的详细特性,但是最近的一些有趣的争论引起了我的兴趣,特地跟踪了多个帖子,弄清楚了争论的来龙去脉,特地整理了一下,也算作为我的性能系列的文章的一部分吧。

最近的事件是这两个产品背后的公司进行了激烈的性能之争。

起因是GridGain发布了一篇性能报告:GridGain vs. Hazelcast Benchmarks, 它比较了最新的GridGain Community Edition 1.5.0 和 最新的Hazelcast 3.6-EA2的性能,测试数据显示Ignite的性能要好于Hazelcast。相关的测试代码可以参照yardstick-ignite yardstick-hazelcast

进一步GridGain还到Hazelcast的用户讨论组中踢馆子,他们把测试结果和代码发布在Hazelcast的邮件列表中,请Hazelcast的人review和提意见。嚣张啊!
Hazelcast的CEO Luck把这个帖子从邮件列表中删除了,并说:

我们认为你在我的地盘上发布这样的性能数据是不合适的。 我们将删除这个帖子,请发布在你的地盘上。

当然,这也不是GridGain第一次踢馆子,在2015初Apache孵化器Ignite项目的导师Konstantin Boudnik就到Tachyon 的邮件列表中比较这两个项目的缓存特性差异,也被认为是营销惨遭删帖。

阅读全文

Kafka Connect简介

Kafka 0.9+增加了一个新的特性Kafka Connect,可以更方便的创建和管理数据流管道。它为Kafka和其它系统创建规模可扩展的、可信赖的流数据提供了一个简单的模型,通过connectors可以将大数据从其它系统导入到Kafka中,也可以从Kafka中导出到其它系统。Kafka Connect可以将完整的数据库注入到Kafka的Topic中,或者将服务器的系统监控指标注入到Kafka,然后像正常的Kafka流处理机制一样进行数据流处理。而导出工作则是将数据从Kafka Topic中导出到其它数据存储系统、查询系统或者离线分析系统等,比如数据库、Elastic SearchApache Ignite等。

Kafka Connect特性包括:

  • Kafka connector通用框架,提供统一的集成API
  • 同时支持分布式模式和单机模式
  • REST 接口,用来查看和管理Kafka connectors
  • 自动化的offset管理,开发人员不必担心错误处理的影响
  • 分布式、可扩展
  • 流/批处理集成

阅读全文

1百万线程的性能

瑞士的金融软件工程师和创业者Alexander Temerev在github上创建了一个项目skynet ,用来测试各语言(框架)的多线程并行计算的性能,并得到了一些有用的数据。本文翻译整理自这个项目的说明。

测试并行性能的代码逻辑很简单:创建一个actor(goroutine,或者其它语言中类似的并发库),它会创建10个子actor,然后每个子actor再创建10个子actor,一直这样创建下去,直到创建了1百万个actor,每个actor包含一个唯一的数字(0到999999)。然后最底层的actor把它们的数字返回给父actor,父actor计算总和后再把结果返回给它的父actor,一直返回直到根actor,这样根actor的包含数字就是0到999999的和,结果应该为499999500000。

所以测试代码的逻辑就是并行计算0到999999的和,测试各种语言的并行库性能。

当然标题是不准确的,只是借用了这个项目的名称,1百万的线程不太可能在一台机器上创建,Alexander Temerev比较的是一些语言的并发框架的实现,聪明的读者应该明白项目性能测试的是什么东西,
它包括了Scala Actor、Scala-Future、Go、erlang、haskell、C# Core、C# TPL、RxJava、node-bluebird、python、rust等语言/框架的测试代码。所以大家不必吐槽标题中的"线程",其实比较的是异步编程模型的性能。

阅读全文

Scala Async 库

在我以前的文章中,我介绍了Scala Future and PromiseFuture代表一个异步计算,你可以设置你的回调函数或者利用Await.result等待获取异步计算的结果,你还可以组合多个future为一个新的futurePromise让你可以控制是否完成计算还是抛出异常,它的future方法返回一个Future对象,completesuccessfailure允许你完成计算。如果想要同步操作,可以使用Await.result等待Future完成或者超时,对于没有实现Awaitable的代码块,可以使用blocking方法实现同步执行。

阅读全文

Scala 魔法函数

Scala有一些语法糖,让一些特定名称的函数拥有一些特殊的能力。这些语法糖并没有专门的文档介绍,只是散落在不同的文章和教程中。本文整理里这些魔法函数,并通过例子演示它们的功能。

阅读全文

为豆瓣电影实现Item-based协同过滤的推荐系统

前面的两篇文章分别使用Spark mllib ALS实现了Model-based协同过滤推荐系统和使用Mahout实现了User-based的协同过滤推荐系统。
我们再来回顾一下item-base CF算法的特点:

  • 物品数明显小于用户数的场合,否则物品相似度矩阵计算代价很大
  • 适合长尾物品丰富,用户个性化需求强的领域
  • 对新用户友好,对新物品不友好,因为物品相似度矩阵不需要很强的实时性
  • 利用用户历史行为做推荐解释,比较令用户信服

所以item-base挺适合做电影的推荐。当用户浏览某个电影的时候,我们可以推荐给他类似的电影,或者根据用户以前的观影记录,推荐他感兴趣的电影。
本文还是以mahout 非分布式计算的方式实现。因为电影的记录比较少(166条),计算量不是很大。

阅读全文

为豆瓣电影实现User-based协同过滤的推荐系统

协同过滤(Collaborative Filtering),简单来说是利用某兴趣相投、拥有共同经验之群体的喜好来推荐使用者感兴趣的信息,个人透过合作的机制给予信息相当程度的反馈(如评分)并记录下来以达到过滤的目的进而帮助别人筛选信息,反馈不一定局限于特别感兴趣的,特别不感兴趣信息的纪录也相当重要,比如浏览信息,收藏,分享,点击等。

阅读全文

使用Spark MLlib给豆瓣用户推荐电影

推荐算法就是利用用户的一些行为,通过一些数学算法,推测出用户可能喜欢的东西。
随着电子商务规模的不断扩大,商品数量和种类不断增长,用户对于检索和推荐提出了更高的要求。由于不同用户在兴趣爱好、关注领域、个人经历等方面的不同,以满足不同用户的不同推荐需求为目的、不同人可以获得不同推荐为重要特征的个性化推荐系统应运而生。

阅读全文