前面的文章讲到ignite支持扫描查询和sql查询,其sql查询是ignite产品的一个亮点,那么哪一种的查询更适合我们的产品使用呢,往下看:
先分别贴一下扫描查询和sql查询两种查询方式的代码,供参考:
扫描方式:
IgniteCache<Long, Person> cache = ignite.cache("mycache");
// Find only persons earning more than 1,000.
IgniteBiPredicate<Long, Person> filter = new IgniteBiPredicate<>() {@Override public boolean apply(Long key, Perons p) {return p.getSalary() > 1000;}
};
try (QueryCursor cursor = cache.query(new ScanQuery(filter)) {for (Person p : cursor)System.out.println(p.toString());
} sql方式:
IgniteCache<String, Task> cache = cache();SqlQuery sql = new SqlQuery(Task.class,"taskStatus = ? ");List<CacheEntryImpl> list = cache.query(sql.setArgs(status)).getAll();
开始实验:
说明
1.Cache<String,Task>
2.Task是一个复杂pojo,其中设立索引 taskId和taskTemplateId
3.单节点启动,cache容量为50000
案例:
- 查询分四步进行,
a) 根据模板扫描查询任务(截图中日志未说明按模板查询)
b) 根据模板sql查询任务
c) 扫描查询所有任务
d) Sql查询所有任务
结果:
可以看到查询结果为:
B优于 a;
D优于 c;
初步说明用sql查询的方式要优于扫描查询
但是继续运行会发现查询时间越来越短,为了防止ignite自动加载到缓存引起的时间不准确,如图:
将查询的顺序调换,方案顺序为(d,c,b,a)重新测试:
结果:
重新测试依然发现查询次数越多花的时间越少,得出结论,先执行的查询要花更多的时间,后执行的查询会利用一些本地缓存,但是对比两次的测试结果不妨碍得出结论:
无论是全部扫描还是根据某个属性查询,sql查询的速度都要优于扫描查询的速度
测试二:
在以上环境基础上,验证索引的建立对于查询的意义,保留以上测试的日志留作去掉索引时测试结果的对比
结果:
这个结果比较上一张截图发现,其他查询都没什么变化,但是利用模板索引的查询显然比上面快了不少???这个跟设想完全不同,建立索引反而降低了速度,去掉索引更快.
为了验证是不是哪里出了错误或者看到的结果不够端正,继续查看查询平稳之后的查询速度:
有索引:
无索引:
观察得出:有索引的查询在稳定后根据模板索引的查询稳定在了0.3秒附近,而没有索引的查询只能稳定在0.4秒附近,得出建立索引确实会让sql的查询变得更快,另外索引的建立会导致扫描方式的查询变得更慢.至于最开始的查询截图得出的相悖结论只是一时情况,与实际生产情况不符,只遵循稳定后的速度.
初步验证就到这里,还有问题后续验证:
- 由于ignite机制的存在会导致同一个cache越查越快,但是如果中途加入新的数据,sql查询能否维持0.3秒左右的查询速度,还是会恢复到最开始的0.7秒?
- 为什么最开始的时候没有索引的情况下反而速度更快?
- 多节点下,查询是否会变得更快还是更慢?
多节点下的查询效率
初步验证:
在上面实验结果的情况下,直接双开节点,获取结果信息
对比结果发现:
双节点的情况下,扫描查询的速度会变得更慢,但是sql的查询没有因为网络交互速度变慢,反而速度更快,查询基本低于0.3秒,
初步得出ignite使用结论:
多节点下使用sql查询并建立索引是最好的查询.