17

我使用数据网格作为我的主要“数据库”。我注意到 Hazelcast 和 Ignite 查询性能之间存在巨大差异。我通过适当的自定义序列化和索引优化了我的数据网格使用，但 IMO 的差异仍然很明显。

由于没有人在这里问过，我将回答我自己的问题以供将来参考。这不是一个抽象的（学习）练习，而是一个真实的基准测试，它模拟了我在大型 SaaS 系统中的数据网格使用情况——主要用于显示排序和过滤的分页列表。我主要想知道与原始的无框架 Hazelcast 和 Ignite 使用相比，我的通用 JDBC-ish 数据网格访问层增加了多少开销。但由于我是在比较苹果和苹果，所以这里是基准。

4

2 回答 2

16

我在 GitHub 上查看了提供的代码并有很多评论：

索引和连接

  1. 可能最重要的一点是 Apache Ignite 索引比 Hazelcast 复杂得多。与 Hazelcast 不同，Ignite 支持 ANSI 99 SQL，因此您可以随意编写查询。
  2. 最重要的是，与 Hazelcast 不同，Ignite 支持跨不同缓存或数据类型的组索引和 SQL JOIN。假设您有 Person 和 Organization 表，并且您需要选择为同一组织工作的所有人员。这在 Hazelcast 的 1 步中是不可能做到的（如果我错了，请纠正我），但在 Ignite 中，这是一个简单的 SQL JOIN 查询。

鉴于上述情况，创建 Ignite 索引将需要更长的时间，尤其是在您有 7 个索引的测试中。

TestEntity 类中的修复

在您的代码中，您存储在缓存中的实体TestEntity会在每次调用 getter 时重新计算 idSort 、createdAtSort和modifiedAtSort的值。当实体存储在索引树中时，Ignite 会多次调用这些 getter。对 TestEntity 类的简单修复提供了 4 倍的性能提升：https ://gist.github.com/dsetrakyan/6bfe089d53f888448503

堆测量不准确

您测量堆的方式不正确。您至少应该在进行堆测量之前调用System.gc()，即使这样也不准确。例如，在下面的结果中，我使用您的方法得到了负堆大小。

暖身

每个基准测试都需要热身。例如，当我按照上面的建议应用TestEntity修复并执行缓存填充和查询 2 次时，我会得到更好的结果。

MySQL比较

我认为将单节点数据网格测试与 MySQL 进行比较是不公平的，无论是对于 Ignite 还是对于 Hazelcast。数据库有自己的缓存，每当使用如此小的内存大小时，您通常会测试数据库内存缓存与数据网格内存缓存。

每当对分区缓存进行分布式测试时，通常都会获得性能优势。这样，数据网格将在每个集群节点上并行执行查询，结果应该会更快地返回。

结果

这是我为 Apache Ignite 得到的结果。在我进行上述修复后，它们看起来好多了。

请注意，我们第二次执行缓存填充和缓存查询时，我们会得到更好的结果，因为 HotSpot JVM 已预热。

值得一提的是，Ignite 不缓存查询结果。每次运行查询时，都是从头开始执行的。

[00:45:15] Ignite node started OK (id=0960e091, grid=Benchmark)
[00:45:15] Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, heap=8.0GB]
Starting - used heap: 225847216 bytes
Inserting 100000 records: ....................................................................................................
Inserted all records - used heap: 1001824120 bytes
Cache: 100000 entries, heap size: 775976904 bytes, inserts took 14819 ms
------------------------------------
Starting - used heap: 1139467848 bytes
Inserting 100000 records: ....................................................................................................
Inserted all records - used heap: 978473664 bytes
Cache: 100000 entries, heap size: **-160994184** bytes, inserts took 11082 ms
------------------------------------
Query 1 count: 100, time: 110 ms, heap size: 1037116472 bytes
Query 2 count: 100, time: 285 ms, heap size: 1037116472 bytes
Query 3 count: 100, time: 19 ms, heap size: 1037116472 bytes
Query 4 count: 100, time: 123 ms, heap size: 1037116472 bytes
------------------------------------
Query 1 count: 100, time: 10 ms, heap size: 1037116472 bytes
Query 2 count: 100, time: 116 ms, heap size: 1056692952 bytes
Query 3 count: 100, time: 6 ms, heap size: 1056692952 bytes
Query 4 count: 100, time: 119 ms, heap size: 1056692952 bytes
------------------------------------
[00:45:52] Ignite node stopped OK [uptime=00:00:36:515]

我将使用更正的代码创建另一个 GitHub 存储库，并在我更清醒时将其发布在这里（咖啡不再有帮助）。

于 2015-08-11T08:36:45.267 回答
8

这是基准源代码：https ://github.com/a-rog/px100data/tree/master/examples/HazelcastVsIgnite

它是我前面提到的 JDBC-ish NoSQL 框架的一部分：Px100 Data

构建和运行它：

cd <project-dir>
mvn clean package
cd target
java -cp "grid-benchmark.jar:lib/*" -Xms512m -Xmx3000m -Xss4m com.px100systems.platform.benchmark.HazelcastTest 100000
java -cp "grid-benchmark.jar:lib/*" -Xms512m -Xmx3000m -Xss4m com.px100systems.platform.benchmark.IgniteTest 100000

如您所见，我将内存限制设置得很高以避免垃圾收集。您也可以运行我自己的框架测试（请参阅 Px100DataTest.java）并与上述两个进行比较，但让我们专注于纯粹的性能。除了 Hazelcast 3.5.1 和 Ignite 1.3.3 之外，这两个测试都没有使用 Spring 或其他任何东西——目前是最新的。

基准以事务方式插入指定数量的 appr。1K 大小的记录（其中 100000 条 - 您可以增加它，但要注意内存）以 1000 条为批次（事务）。然后它执行两个按升序和降序排序的查询：总共四个。所有查询字段和 ORDER BY 都已编入索引。

我不会发布整个课程（从 GitHub 下载）。Hazelcast 查询如下所示：

PagingPredicate predicate = new PagingPredicate(
        new Predicates.AndPredicate(new Predicates.LikePredicate("textField", "%Jane%"),
            new Predicates.GreaterLessPredicate("id", first.getId(), false, false)),
        (o1, o2) -> ((TestEntity)o1.getValue()).getId().compareTo(((TestEntity)o2.getValue()).getId()),
        100);

匹配的 Ignite 查询：

SqlQuery<Object, TestEntity> query = new SqlQuery<>(TestEntity.class,
        "FROM TestEntity WHERE textField LIKE '%Jane%' AND id > '" + first.getId() + "' ORDER BY id LIMIT 100");
    query.setPageSize(100);

以下是在我的 2012 年 8 核 MBP 上执行的结果，内存为 8G：

榛树

Starting - used heap: 49791048 bytes
Inserting 100000 records: ....................................................................................................
Inserted all records - used heap: 580885264 bytes
Map: 100000 entries, used heap: 531094216 bytes, inserts took 5458 ms
Query 1 count: 100, time: 344 ms, heap size: 298844824 bytes
Query 2 count: 100, time: 115 ms, heap size: 454902648 bytes
Query 3 count: 100, time: 165 ms, heap size: 657153784 bytes
Query 4 count: 100, time: 106 ms, heap size: 811155544 bytes

点燃

Starting - used heap: 100261632 bytes
Inserting 100000 records: ....................................................................................................
Inserted all records - used heap: 1241999968 bytes
Cache: 100000 entries, heap size: 1141738336 bytes, inserts took 14387 ms
Query 1 count: 100, time: 222 ms, heap size: 917907456 bytes
Query 2 count: 100, time: 128 ms, heap size: 926325264 bytes
Query 3 count: 100, time: 7 ms, heap size: 926325264 bytes
Query 4 count: 100, time: 103 ms, heap size: 934743064 bytes

一个明显的区别是插入性能 - 在现实生活中很明显。但是很少有人插入 1000 条记录。通常它是一次插入或更新（保存输入的用户数据等），所以它不会打扰我。但是查询性能确实如此。大多数以数据为中心的业务软件都需要大量阅读。

注意内存消耗。Ignite 比 Hazelcast 更需要 RAM。这可以解释更好的查询性能。好吧，如果我决定使用内存网格，我应该担心内存吗？

您可以清楚地知道数据网格何时命中索引以及何时没有命中索引，它们如何缓存已编译的查询（7ms 的查询）等。我不想推测，也让您使用它，就像 Hazelcast 和Ignite 开发人员提供了一些见解。

就一般性能而言，它是可比的，如果不是低于 MySQL 的话。IMO 内存技术应该做得更好。我相信两家公司都会做笔记。

上面的结果非常接近。但是，当在 Px100 Data 和更高级别的 Px100（严重依赖索引“排序字段”进行分页）中使用时，Ignite 会领先并更适合我的框架。我主要关心查询性能。

于 2015-08-11T04:08:50.027 回答