为什么订餐不会凉凉和牛顿发现万有引力有关

分享人: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倍的性能提升。

   

 

上一篇:PG+MySQL第1课


下一篇:在数据库中跑全文检索、模糊查询SQL会不会被开除