分享人:Digoal,阿里云数据库产品经理
正文:
本篇内容将从5个部分为读者介绍订餐系统为什么不会凉凉,分析这其中的技术手段及技术难点并提出解决方案。
Ÿ 为什么要讨论这个问题?
Ÿ 牛顿告诉我们为什么真相离我们越来越远
Ÿ 懒人改变历史 - 网上订餐凉凉史
Ÿ 牛顿给了饿了么什么启发?
Ÿ 如何利用MyBase PG解决问题
这次的话题依旧和日常生活息息相关,同样也会引申到数据库里面,在技术层面也是非常有挑战性的。在网上订餐系统中,牛顿起什么作用呢?这两者之间到底存在什么关系?这背后的技术方案又是什么样的呢?
一、为什么要讨论这个问题?
民以食为天的中国,一日三餐是我们每天都要思考的问题。今天吃什么,什么时候能吃得上,这是生活的必要元素。如果吃不好会影响了生活工作,通过网上订餐,拿到手上依然是热腾腾的,那么网上订餐有什么技术来保障呢?
二、牛顿告诉我们为什么真相离我们越来越远
牛顿因为被一颗苹果砸到头上进而想到万有引力,也是因为他的发散性思考才会想到的。我们再来看看网络订餐平台,在这个产品刚刚上线的是时候肯定会遇到很多技术的瓶颈。我们应该发挥自己的想象力,多去看看别人家的产品,了解一下这些瓶颈怎么突破怎么解决。
三、懒人改变历史 - 网上订餐凉凉史
接下来我们讲一下网上订餐的凉凉史。为什么会凉凉?首先是骑手没钱赚、骑手调度算法不够优, 导致人不够;调度算法有问题,导致骑手接的单与单之间距离过远;调度算法错误导致派送订单时间过短,保温箱容量有限;骑手薪资与配送时间限制、单数不挂钩, 无保障配送时长等问题导致凉凉。最主要的还是与调度算法的技术相关。
四、牛顿给了饿了么什么启发?
网上订餐平台可以从缩短配送时间、降低“单数/骑手”比例两个核心指标提高效能。那么怎样让骑手的多单配送目的地就近?其实这也是pgrouting – 图算法, 商旅问题;怎样避免或减少骑手有未完成的单就安排下一单?怎样避免保温箱超载?怎样避免呼叫远离卖家的骑手?
初步的解决方法就是通过频繁更新的骑手位置、查询范围、数组、其他in查询、距离排序(GIS, 距离排序) 限制返回N条、其他优先级排序返回等手段解决。
但也有几个痛点,只能用1个条件进行索引过滤、其他条件需要回表后再过滤、需要额外对空间进行排序过滤。这几个痛点也导致了整个性能并不好用。当然费用也相对比较高。
五、如何利用MyBase PG解决问题
经过独立思考之后,我们想到了另一个方案:购买集群后选择pg 引擎创建实例,创建实例后还需要创建create extension gano(阿里云空天数据库模块)、create extension btree_gist( 空间、普通类型组合通用索引模块)、create extension intarray(数组组合通用索引模块)这三个模块。结构设计为:
create table tbl_pos (id int primary key,
att1 int, att2 int, att3 int, att4 int[],
mod_time timestamp, pos geometry);
大家可以看下图,我们把问题拆成三个子查询,每个子查询的条件、空间排序不一样,最终把耗时6秒的查询降到10毫秒。
最后,我们来看一下指标怎么样。一是机器数26核;二是数据量是2000万。最终更新速度达9.6万/s、骑手调度查询达 5000/s, RT 11毫秒。通过利用MyBase达到500倍的性能提升。