开源数据计算引擎,实现媲美ElasticSearch的高性能并发查询

面对高并发帐户查询场景,传统的SQL数据库和数据仓库性能不佳。文章介绍了如何通过开源数据计算引擎SPL实现数据有序存储和高效索引,以达到媲美甚至超过ElasticSearch的查询性能。SPL支持行式存储,允许根据需求选择行存或列存,同时提供简便的JOIN运算和快速追加数据功能,适合高并发查询且对JOIN有需求的场景。
摘要由CSDN通过智能技术生成

高并发帐户查询的应用场景有很多,例如:手机银行查流水、电商系统查购物订单、手游帐户查充值记录等等。这些场景一般会涉及众多帐户,数据总量非常大,需要外存。每个帐户的数据量通常不大(几条到几千条),而且就是简单查询,几乎没有什么运算。不过,众多的帐户自然也会有大量、高频率的查询,并发访问量会很大,要达到秒级甚至更高的响应速度也是一个不小的挑战。

在SQL数据库或数据仓库中,用索引查找单个帐户数据的速度很快,几乎感觉不到耗时,但并发很多时就会有明显延迟了。这是因为,基于无序集合理解的关系数据库不能保证数据在存储时的次序,也就无法保证同一帐户数据在物理上连续存放,查找一个帐户数据时,可能要到硬盘的很多位置读取才能全部取出。而硬盘有最小读取单位,在读取不连续数据时,会取出很多无关内容,查询就会变慢。虽然每个帐户数据量很少,单个帐户查询的时候只是慢一点,但是高并发访问的每个查询都慢一点,总体性能就会很差了。

因为关系数据库的表现不如人意,所以搜索引擎Elastic Search经常会被用来应对这种场景,即把数据导出到ES里,利用搜索技术实现高性能并发查询。使用ES后,通常确实可以达到期望的性能要求,但遗憾的是ES对JOIN支持非常差,如果查询过程中还涉及关联计算,就会造成巨大的麻烦。比如帐户交易明细表,要和用户表、商品表、网点表等等关联,使用ES时通常只能将这些数据全都整合到交易表中形成大宽表。准备这个大宽表的过程费时费力,还会丧失很多灵活性;而且ES的数据导入非常慢,会进一步加剧这个问题。使用大宽表后无法在关联数据发生变动时简单追加写入,只能重新准备新的宽表再重新导入,耗时很长,这期间只能暂停查询服务。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值