搜索
移动应用在数据库上所需的适应与改变@lockfreeAgenda•LBS的应用特点与面临的问题•当RDBMS与NOSQL遇到LBS•街旁的解决之道：CrabDB多一维的视角实时的签到计算•签到•计算地主•计算惊喜•弹出攻略•去过的好友•计算积分•大量实时计算实时的签到计算(Cont.)实时的签到计算(Cont.)迅猛的压力高峰与众不同的广告类型快速的需求变化•LBS的快速发展•未来产品的发展•性能的需求•低成本的硬件平台Agenda•LBS的应用特点与面临的问题•当RDBMS与NOSQL遇到LBS•街旁的解决之道：CrabDBRDBMS如何处理？•一张简单的表loc_post（示例）idloc_iduser_idprivate……013011312132SELECTCount(DISTINCTuser_id)FROMloc_postWHEREloc_id=1andprivate=0;1SELECTCount(user_id)FROMloc_postWHEREloc_id=1andprivate=0;1SELECTCount(DISTINCTuser_id)FROMloc_postWHEREloc_id=1andprivate=1;1SELECTCount(user_id)FROMloc_postWHEREloc_id=1andprivate=1;2SELECTCount(DISTINCTuser_id)FROMloc_postWHEREloc_id=1andprivate=1anduser_idin(1,2,3);1•普通用户查询•朋友查询•自己查询RDBMS如何处理？(Cont.)•查询/计算类型很多SELECT…WHERE…SELECT…IN…SELECT…ORDERBY…SELECTCount(…)…GROUPBY…ORDERBY…UPDATE…INSERT…•索引过多•数据一致性要求高，不能批量/推迟计算，IO过多，缓存失效很快RDBMS如何处理？(Cont.)•的确可以做很多优化（分区、设计更合理的schema、数据库调优、etc）•应用开发工程师需要注意的优化情况太多•不利于产品的快速开发和迭代NOSQL@Foursquare(2011.06)•9Musers•~3Mcheckins/day(52checkin/sec)•20Mplaces•MongoDB,PostgreSQL(legacy,migratingoff)•allonEC2•~40machines(68GB,m2.4xlonEC2)选择MongoDB•Schema-Free•减少join•Replica-sets与容灾•GEO-Indices•高性能为什么迁移出MongoDB•数据总量大（超出内存），IO压力比较高•CPUloadavg:4（16核64G内存）为什么迁移出MongoDB(Cont.)Pagefaults频繁Median=26pagefaults/secAvg=33.86pagefaults/secMongoDB不适用分析(1)：数据膨胀•BSON是把双刃剑-SchemaFree-空间开销巨大•索引过多•数组索引MongoDB不适用分析(2):内存有限•不同版本Linux内核实现mmap(2)的writeback机制差异•缓存粒度难以有效控制（OS负责页面换入换出）•LBS中对大量长尾数据的访问造成随机读写•vmtouch告诉我们只有35.5%的数据被缓存MongoDB不适用分析(3):数据分布•数据分布不可控，按照非_id连续访问记录并不具备优势-LBS计算中存在大量选择所有属于同一个user_id的记录并计算的需求-RDBMS中可以使用ClusteredIndexAgenda•LBS的应用特点与面临的问题•当RDBMS与NOSQL遇到LBS•街旁的解决之道：CrabDBCrabDB的数据结构•简单的key-listloc_id:[{user_id:{id,private,…}},{user_id:{id,private,…}},{user_id:{id,private,…}},……]•定长存储CrabDB的查询与计算•多种查询（类似于MongoDB的调用）db.find(Expr)db.group(Expr)db.sort(Expr)db.limit(Expr)db.count()•条件表达式支持tcc动态编译表达式请求（比MongoDB中js实现表达式计算更快）更加方便快速的实现复杂的表达式group(datetime/86400):将存储的datetime类型转换为天进行聚合find(R.id*2==6)•快速的查询与计算一些用例及对比•对比•更多查询（Python调用）crab.location_post[1].find((R.privacy==0)|R.user_id.in([1,2,3,4,5])).count()crab.location_post[1].find(R.type==2,R.user_id.in([123,456,678])).sort([R.is_great,-R.num_likes,-R.post_id])CrabDBMongoDBcrab.user_post[3].find(R.type==3)db.post.find({'u':3,'type':3})CrabDB的存储分配•Slab分配策略•按照比例扩容•只保存数值，内存利用率高，便于压缩•放在内存中，减少IOCrabDB的分布式实现•分布式对象系统•Master/Slave•CrabDB可以被部署在任何机器•CrabDB只用于计算•Slab块在后台异步扩容CrabDB的分布式实现(Cont.)•扩展性扩展计算扩展存储•容灾与恢复恢复计算恢复存储CrabDB上线后的成果•系统响应更快•MongoDB压力大幅降低，线上机器资源大幅节省•写入未减少是因为数据被备份至MongoDBCrabDB上线后的成果（Cont.）Pagefaults大幅减少Median=1pagefaults/secAvg=2.33pagefaults/sec让MongoDB做最擅长的事情•足够好的性能•更快速的开发支持•SchemaFree•地理位置索引