本期
嘉宾
高亮 高德服务平台部 技术专家
嘉宾简介：高亮 高德服务平台部 技术专家。
早期负责高德开放平台业务部后台的架构搭建与开发，涉及RestAPI业务以及云图业务。2015年，调入高德服务平台部，主要负责高德地图用户数据存储类业务服务架构设计与开发（如收藏夹、设置项乃到后来的搜索历史记录，骑行轨迹等等）
议题：高德单元化改造的实践与思考
简介: 2016年，随着高德业务量的不断攀升，高德对用户存储数据的安全性、用户访问数据效率提出了更高的要求，正因如此本人带领团队和阿里云Mongo团队一起开始了高德单元化改造的探索与尝试。
2017年初，阿里巴巴集团提出要将断网演练常态化新要求，从月态常规的断网演练到未来无征兆的突然网络中断，目的只有一个，就是让我们系统架构能够经受得住的实战的考验。
Q
A
颖敏
高亮
Q: 高德早是从什么时候开始使用MongoDB的？高德是否还使用了什么其他的数据库？
整个公司里面不是很清楚，因为在我之前可能已经有一些部门已经在做mongo的使用和探索了。只说说我的团队的情况吧，早接触应该在13年，不过那个时候并未完全开始大规模应用，只是做了一些小规模的探索和尝试，真正开始使用mongo还是在14、15年的时候。其它数据库产品也在用，比如RDS（Mysql）、KVStore（Redis）之类的产品也是用得比较多的。
Q：与传统的关系型数据库相比，MongoDB有哪些优势使得您的团队终选择了它？
先说说背景，14年底的时候我们当初启动了一个叫云图的项目，这个项目的初衷就是进一步开放高德的位置服务能力，让那些有自有位置数据用户，能把自己的数据玩起来。用户可以通过云图产品展现存储、检索、标点从而制作一张自己的位置地图，再结合自己的应用把地图真正的玩起来，给自己的APP做位置赋能。
说到用户数据，能抽象的就是数据异构化。我们不知道用户数据是什么含义，所以我们只要求用户上传的几个基本字段（比如，名称、地址或者坐标）,其它字段完全由用户自定义。所以由于异构化的特点，我们就需要选择一款NoSql产品来实现会更加方便一些。
所以说到选择mongo，有如下几个方面的考虑：
，肯定是Nosql的特性。
第二，看重的就是社区资料文档全，当时项目从调研、立项启动只有一个月的时间。遇到坑这件事情，是我们预料之中的事情，所以社区和文档就显得尤为重要。
第三，我们也做了一些数据规模的验证，mongo整体性能各方面基本我们还是比较满意的。
第四，mongo本身对空间索引的支持也还算不错的。
Q: MongoDB在地理数据相关领域有何应用场景？其是否对地理数据的存储和获取进行了优化？
其实这个问题和上面的问题我放到一起来讲了，关于位置领域的应用场景其实蛮多的，云图你可以理解为是Mongo+高德位置能力的封装。说到应用场景，我就不开脑洞了，因为我能看到的了解到的就很多了。比如说，有些人用他来发布位置任务（类似众包的场景），有些人可以用它来分享车辆位置（物流行业也很多），有些人用它来做连锁门店信息管理等等。因为现在移动时代位置服务已经无处不在了，所以更多脑洞还是到时候和大家去分享交流吧。
Q： 高德在原有功能的基础上对MongoDB进行了什么改进？您是否衡量过MongoDB对您业务的影响？
改进不敢当，还是说到应用吧，这个问题我到时候会和大家在论坛上去分享高德单元化的改造经验，这也是我在本次论坛上要和大家分享、探讨的主题。到时候给我们提供mongo支持的阿里云的同事应该也会在，大家现场聊吧。
说到对我们业务的影响，刚才其实在聊上面几个问题的时候都已经谈到了，其实mongo对我们的业务支撑还是蛮大的也蛮多的。有结合位置服务应用，当然也有和位置无关的业务，比如我们本次单元化改造中涉及到的云同步业务。
Q：对于那些正在考虑在他们下一个项目上使用MongoDB的用户，您有什么建议？
这个建议也确实不太好给，因为每个业务场景遇到问题未必相同。
比如：我们在做云图业务的时候，为方便管理，开始为每个用户每张表分配了一个独立的collection,所以很快collection就破万，性能直线下降。到后来我们对数据规模在一定范围的用户表做了整合。当然这个问题，除非大家和我们一样做云服务，否则应该多数开发者不会遇到。我们就当给mongo做了一次极限测试了。
再比如：WiredTiger的cache被打满的问题，如果业务量突增，一旦cache达到95%%的利用率，目前看，如果不通过DBA重启好像无法解决。所以业务或者网关层需要做好限流和熔断，确保DB能够在一个安全水位，当然业务监控和DB监控都需要完善起来。不能完全把所有事情和压力都扔到DB层去处理。
后一个建议就是，大家平时多关注社区多分享经验吧，毕竟别人遇到的坑，你看到了、听到的就可以不用再踩一次了。
