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