yexiang
TA的个人档案
yexiang个人页面-阿里云开发者社区
个人介绍
数据库，NoSQL
擅长的技术
- 高分内容
- 最新动态
- 文章
- 问答
-
发表了文章 2017-01-07
通过MongoDB安全事件来谈谈为什么要用云服务
每到年底，比铁路部门还忙碌就是各路小偷，恰巧最近一篇关于NoSQL暴露公网的文章开拓了他们的思路。就在文章发布后这一周里，陆陆续续接到关于自建MongoDB被“黑客”攻击，数据被删，并且索要Q币的案例。今天我自卖自夸下，为了数据库安全，快点上云MongoDB。但正式自夸之前，我们先来复盘看看。 被黑者特征 本次事件的作案手法实在是称不上高级，所以我暂且称他们为“坏人”，但这事不能完全埋怨“坏人”，被攻击的这些自建MongoDB，全部都满足两个特征： 1. 暴露公网地址，甚至有些实例端口号都是默认的27017； 2. 没有配置鉴权约束，谁来都可以访问； 怎么攻击的 这就是把自己家的大门敞开，任由“坏人”搜割，“坏人”会做几件事： 1. 访问shadon网站，本来这个网站是做互联网数据分析的，原理是扫描全球IP和端口，通过分析协议来收集各种设备或者服务的统计数据。不幸被人利用，这些“坏人”甚至连端口扫描都不用，shadon都为你准备好了； 2. 用mongoshell等管理工具尝试登入，因为很多人的MongoDB都没有配置鉴权，所以连破解密码都的步骤都可以省了； 3. 单独破坏数据库意义不大，一般都是把数据dump到本地留存一份，或者直接修改集合名称或者地址，存在一个相对隐蔽的地方；也有“坏人”纯恶意破坏； 4. 勒索受害人，索要Q币或者比特币，交钱放“人”（归还数据，如果有的话）； 该埋怨谁 看吧，实在不是很高明的手段，也真的不能完全埋怨“坏人”不讲情理。这事情责任三方各打一板，怎么是三方？ 1. “坏人”责任50%，勒索良民； 2. 自己责任40%，谁叫你公网地址，谁叫你不配鉴权的？大门敞开，家里被盗，上哪都喊不了冤； 3. MongoDB责任10%，说起来有点冤，但默认配置就应该强制要求鉴权访问，并且这事情也是需要官方不断去教育用户（虽然官方英文文档明确有写明要配置鉴权来保障安全），但不能指望人人都有安全意识；另外，MongoDB 3.0开始修改了鉴权协议，不支持2.x的Driver，很多用户也因此懒得去升级客户端，索性不要鉴权； 亡羊补牢 事实已经发生了，埋怨没有用，怎么解决： 1. 不论你有没有中招，有没有在公网，都要检查鉴权配置，避免更多的损失； 2. 关闭公网的访问入口，把门关上； 3. 如果你是阿里云用户，尝试恢复ECS存储镜像，有多少算多少；但是有一定的风险是镜像恢复了，但数据文件可能是不完整的，用MongoDB的repair命令尝试修复，祈祷吧； 4. 碰碰运气，看看数据表是不是只是被rename了，因为数据dump是有时间成本和存储成本的，有监控数据的可以对比下看看容量有没有变化； 5. [**心有余孽的话就快点用阿里云MongoDB**；](https://www.aliyun.com/product/mongodb) 还是来用阿里云MongoDB吧 阿里云的云版MongoDB从设计之初就重点考虑了安全问题，所以整个服务提供上我们具备： 1. 基于MongoDB 3.2兼容版本的解决方案，并且强制要求鉴权，并且默认不提供公网入口。还在用2.X版本的同学们尽快升级吧，各种原因可以参考另一篇文章，[《告别 MongoDB 2.x 拥抱 3.x 版本的5大理由》](https://yq.aliyun.com/articles/67120?spm=5176.100240.searchblog.22.YA5jTQ)； 2. 阿里云提供云MongoDB的VPC能力，即使在阿里云内网，也可以网络隔离； 3. 阿里云MongoDB提供白名单功能，只接受你自己的ECS访问； 4. 重点的来了哦，这可是自建没有能力，增量数据备份与恢复，哪怕被人删了，或者自己不小心drop了，可以恢复到任意时间的数据状态； 5. 重点的又来了，这可是官方企业版的能力，完整的审计日志，被谁删的，怎么删的，数据哪里去了，一清二楚； 6. 阿里云安全专家众多，“攻击者”也是看风险和收益比的； 另外，值得一提的是，因为PHP这种高级语言，对数据库的操作都是短连接，所以鉴权开启后会带来大量的性能损失（主要影响并发能力），阿里云MongoDB也在这方面做了优化处理，针对短连接场景，阿里云有10倍性能优化。同时，也提供上云在线迁移服务DTS，详情请访问官网了解。 最后再来个硬广，我们不趁火打劫，还大幅度降价，比自建成本更低的三节点集群服务，ApsaraDB产品线6折促销中，请猛烈点击我。
-
发表了文章 2016-12-13
MongoDB数据建模小案例：物联网时序数据库建模
注：本案例来自MongoDB官方教程PPT，也是一个非常典型的CASE，故此翻译，并结合当前MongoDB版本做了一些内容上的更新。 本案例非常适合与IoT场景的数据采集，结合MongoDB的Sharding能力，文档数据结构等优点，可以非常好的解决物联网使用场景。 需求 案例背景是来自真实的业务，美国州际公路的流量统计。数据库需要提供的能力： 存储事件数据 提供分析查询能力 理想的平衡点： 内存使用 写入性能 读取分析性能 可以部署在常见的硬件平台上 几种建模方式 每个事件用一个独立的文档存储 { segId: "I80_mile23", speed: 63, ts: ISODate("2013-10-16T22:07:38.000-0500") } 非常“传统”的设计思路，每个事件都会写入一条同样的信息。多少的信息，就有多少条数据，数据量增长非常快。 数据采集操作全部是Insert语句； 每分钟的信息用一个独立的文档存储（存储平均值） { segId: "I80_mile23", speed_num: 18, speed_sum: 1134, ts: ISODate("2013-10-16T22:07:00.000-0500") } 对每分钟的平均速度计算非常友好（speed_sum/speed_num）； 数据采集操作基本是Update语句； 数据精度降为一分钟； 每分钟的信息用一个独立的文档存储（秒级记录） { segId: "I80_mile23", speed: {0:63, 1:58, ... , 58:66, 59:64}, ts: ISODate("2013-10-16T22:07:00.000-0500") } 每秒的数据都存储在一个文档中； 数据采集操作基本是Update语句； 每小时的信息用一个独立的文档存储（秒级记录） { segId: "I80_mile23", speed: {0:63, 1:58, ... , 3598:54, 3599:55}, ts: ISODate("2013-10-16T22:00:00.000-0500") } 相比上面的方案更进一步，从分钟到小时： 每小时的数据都存储在一个文档中； 数据采集操作基本是Update语句； 更新最后一个时间点（第3599秒），需要3599次迭代（虽然是在同一个文档中） 进一步优化下： { segId: "I80_mile23", speed: { 0: {0:47, ..., 59:45}, ..., 59: {0:65, ... , 59:56} } ts: ISODate("2013-10-16T22:00:00.000-0500") } 用了嵌套的手法把秒级别的数据存储在小时数据里； 数据采集操作基本是Update语句； 更新最后一个时间点（第3599秒），需要59+59次迭代； 嵌套结构正是MongoDB的魅力所在，稍动脑筋把一维拆成二维，大幅度减少了迭代次数； 每个事件用一个独立的文档存储VS每分钟的信息用一个独立的文档存储 从写入上看：后者每次修改的数据量要小很多，并且在WiredTiger引擎下，同一个文档的修改一定时间窗口下是可以在内存中合并的；从读取上看：查询一个小时的数据，前者需要返回3600个文档，而后者只需要返回60个文档，效率上的差异显而易见；从索引上看：同样，因为稳定数量的大幅度减少，索引尺寸也是同比例降低的，并且segId，ts这样的冗余数据也会减少冗余。容量的降低意味着内存命中率的上升，也就是性能的提高； 每小时的信息用一个独立的文档存储VS每分钟的信息用一个独立的文档存储 从写入上看：因为WiredTiger是每分钟进行一次刷盘，所以每小时一个文档的方案，在这一个小时内要被反复的load到PageCache中，再刷盘；所以，综合来看后者相对更合理；从读取上看：前者的数据信息量较大，正常的业务请求未必需要这么多的数据，有很大一部分是浪费的；从索引上看：前者的索引更小，内存利用率更高； 总结 那么到底选择哪个方案更合理呢？从理论分析上可以看出，不管是小时存储，还是分钟存储，都是利用了MongoDB的信息聚合的能力。 每小时的信息用一个独立的文档存储：设计上较极端，优势劣势都很明显； 每分钟的信息用一个独立的文档存储：设计上较平衡，不会与业务期望偏差较大； 落实到现实的业务上，哪种是最优的？最好的解决方案就是根据自己的业务情况进行性能测试，以上的分析只是“理论”基础，给出“实践”的方向，但千万不可以此论断。 VS InfluxDB 说到时序存储需求，大家一定还会想到非常厉害的InfluxDB，InfluxDB针对时序数据做了很多特定的优化，但MongoDB采用聚合设计模式同样也可以大幅度较少数据尺寸。根据最新的测试报告，读取性能基本相当，压缩能力上InfluxDB领先MongoDB。但MongoDB的优势在于可以存储更丰富的信息，比如地理坐标，文本描述等等其他属性，业务场景上支持更广泛。另外，MongoDB的Sharding水平扩展能力，Aggragation功能，Spark Connector等等特性，对IoT来说，生态优势明显。
-
发表了文章 2016-12-09
MongoDB数据建模小案例：朋友圈评论内容管理
需求 社交类的APP需求，一般都会引入“朋友圈”功能，这个产品特性有一个非常重要的功能就是评论体系。先整理下需求： 这个APP希望点赞和评论信息都要包含头像信息： 点赞列表，点赞用户的昵称，头像； 评论列表，评论用户的昵称，头像； 数据查询则相对简单： 根据分享ID，批量的查询出10条分享里的所有评论内容； 建模 不好的 跟据上面的内容，先来一个非常非常"朴素"的设计： { "_id": 41, "username": "小白", "uid": "100000", "headurl": "http://xxx.yyy.cnd.com/123456ABCDE", "praise_list": [ "100010", "100011", "100012" ], "praise_ref_obj": { "100010": { "username": "小一", "headurl": "http://xxx.yyy.cnd.com/8087041AAA", "uid": "100010" }, "100011": { "username": "mayun", "headurl": "http://xxx.yyy.cnd.com/8087041AAB", "uid": "100011" }, "100012": { "username": "penglei", "headurl": "http://xxx.yyy.cnd.com/809999041AAA", "uid": "100012" } }, "comment_list": [ "100013", "100014" ], "comment_ref_obj": { "100013": { "username": "小二", "headurl": "http://xxx.yyy.cnd.com/80232041AAA", "uid": "100013", "msg": "good" }, "100014": { "username": "小三", "headurl": "http://xxx.yyy.cnd.com/11117041AAB", "uid": "100014", "msg": "bad" } } } 可以看到，comment_ref_obj与praise_ref_obj两个字段，有非常重的关系型数据库痕迹，猜测，这个系统之前应该是放在了普通的关系型数据库上，或者设计者被关系型数据库的影响较深。而在MongoDB这种文档型数据库里，实际上是没有必要这样去设计，这种建模只造成了多于的数据冗余。 另外一个问题是，url占用了非常多的信息空间，这点在压测的时候会有体现，带宽会过早的成为瓶颈。同样username信息也是如此，此类信息相对来说是全局稳定的，基本不会做变化。并且这类信息跟随评论一起在整个APP中流转，也无法结局”用户名修改“的需求。 根据这几个问题，重新做了优化的设计建议。 推荐的设计 { "_id": 41, "uid": "100000", "praise_uid_list": [ "100010", "100011", "100012" ], "comment_msg_list": [ { "100013": "good" }, { "100014": "bad" } ] } 对比可以看到，整个结构要小了几个数量级，并且可以发现url，usrname信息都全部不见了。那这样的需求应该如何去实现呢？ 从业务抽象上来说，url，username这类信息实际上是非常稳定的，不会发生特别大的频繁变化。并且这两类信息实际上都应该是跟uid绑定的，每个uid含有指定的url，username。是最简单的key，value模型。所以，这类信息非常适合做一层缓存加速读取查询。 进一步的，每个人的好友基本上是有限的，头像，用户名等信息，甚至可以在APP层面进行缓存，也不会消耗移动端过多容量。但是反过来看，每次都到后段去读取，不但浪费了移动端的流量带宽，也加剧了电量消耗。 总结 MongoDB的文档模型固然强大，但绝对不是等同于关系型数据库的粗暴聚合，而是要考虑需求和业务，合理的设计。有些人在设计时，也会被文档模型误导，三七二十一一股脑的把信息塞到一个文档中。反而最后会带来各种使用问题。
-
发表了文章 2016-12-06
MongoDB数据建模小案例：多列数据结构
需求 最近收到一个业务需求，需求是基于电影票售卖的不同渠道价格存储。某一个场次的电影，不同的销售渠道对应不同的价格。整理需求为： 数据字段： 场次信息； 播放影片信息； 渠道信息，与其对应的价格； 渠道数量最多几十个； 业务查询有两种： 根据电影场次，查询某一个渠道的价格； 根据渠道信息，查询对应的所有场次信息； 建模 不好的 我们先来看其中一种典型的不好建模设计： { "scheduleId": "0001", "movie": "你的名字", "price": { "gewala": 30, "maoyan": 50, "taopiao": 20 } } 数据表达上基本没有字段冗余，非常紧凑。再来看业务查询能力： 根据电影场次，查询某一个渠道的价格； 建立createIndex({scheduleId:1, movie:1})索引，虽然对price来说没有创建索引优化，但通过前面两个维度，已经可以定位到唯一的文档，查询效率上来说尚可； 根据渠道信息，查询对应的所有场次信息； 为了优化这种查询，需要对每个渠道分别建立索引，例如： createIndex({"price.gewala":1}) createIndex({"price.maoyan":1}) createIndex({"price.taopiao":1}) 但渠道会经常变化，并且为了支持此类查询，肯能需要创建几十个索引，对维护来说简直就是噩梦； 此设计行不通，否决。 一般般的设计 { "scheduleId": "0001", "movie": "你的名字", "channel": "gewala", "price": 30 } { "scheduleId": "0001", "movie": "你的名字", "channel": "maoyan", "price": 50 } { "scheduleId": "0001", "movie": "你的名字", "channel": "taopiao", "price": 20 } 与上面的方案相比，把整个存储对象结构进行了平铺展开，变成了一种表结构，传统的关系数据库多数采用这种类型的方案。信息表达上，把一个对象按照渠道维度拆成多个，其他的字段进行了冗余存储。如果业务需求再复杂点，造成的信息冗余膨胀非常巨大。膨胀后带来的副作用会有磁盘空间占用上升，内存命中率降低等缺点。对查询的处理呢： 根据电影场次，查询某一个渠道的价格； 建立createIndex({scheduleId:1, movie:1, channel:1})索引； 根据渠道信息，查询对应的所有场次信息； 建立createIndex({channel:1})索引； 更进一步的优化呢？ 合理的设计 { "scheduleId": "0001", "movie": "你的名字", "provider": [ { "channel": "gewala", "price": 30 }, { "channel": "maoyan", "price": 50 }, { "channel": "taopiao", "price": 20 } ] } 注意看，这里使用了在MongoDB建模中非常容易忽略的结构--”数组“。查询方面的处理，是可以建立Multikey Index索引，详细信息可以参考官方文档。]说明 根据电影场次，查询某一个渠道的价格； 建立createIndex({scheduleId:1, movie:1, "provider.channel":1})索引； 根据渠道信息，查询对应的所有场次信息； 建立createIndex({"provider.channel":1})索引； 再通过explain来验证上面两个索引是否起到作用： db.movie.find({"scheduleId":"0001","movie":"你的名字", "provider.channel":"taopiao"}).explain() ...... "winningPlan": { "stage": "FETCH", "inputStage": { "stage": "IXSCAN", "keyPattern": { "scheduleId": 1, "movie": 1, "provider.channel": 1 }, "indexName": "scheduleId_1_movie_1_provider.channel_1", "isMultiKey": true, ...... db.movie.find({"provider.channel":"taopiao"}).explain() ...... "winningPlan": { "stage": "FETCH", "inputStage": { "stage": "IXSCAN", "keyPattern": { "provider.channel": 1 }, "indexName": "provider.channel_1", "isMultiKey": true, ...... 总结 这个案例并不复杂，需求也很清晰，但确实非常典型的MongoDB建模设计，开发人员在进行建模设计时经常也会受传统数据库的思路影响，沿用之前的思维惯性，而忽略了“文档”的价值。
-
发表了文章 2016-06-06
云数据库MongoDB为什么需要限制连接数？
连接是要消耗资源的，而且消耗的并不少。 内存：MongoDB为例，每个线程都要分配1MB的栈内存出来。1000个连接，1G内存就这么没了，甭管是否是活跃连接 文件句柄：每个连接都要打开一个文件句柄，当然从成本上讲，这个消耗相对内存是小了很多。但换个角度，文件句柄也被其他模块消耗着，比如WT存储引擎，就需要消耗大量的文件句柄 是否真的需要这么多的链接，一般的业务场景下请求压力在1000QPS左右，按照每个请求50ms计算，最多也就需要1000/(1000/50)==50个链接即可满足需求，并且是整个系统50个链接即可。 很多人平时没有怎么注意过链接数概念，上云后发现居然有这样的限制，心里很不舒服，可能非常不理解。这里说下常见的两种情况： 短链接：一般都是PHP环境，因为PHP的框架决定了PHP短链接的特性，并且链接数的需求一般是在1000-3000左右，具体多少还要根据业务部署的PHP数量来计算。并且MongoDB开源版本在短链接Auth处理上并不优雅，会消耗非常多的CPU资源，3000链接即可跑满24Core的CPU。PHP大拿Facebook也有同样的问题，所以他们用go语言自行开发了一套Proxy代理，来解决对MongoDB的短链接请求问题，但这毕竟带来部署成本和兼容性问题。阿里云的解决方案是从MongoDB源码优化下手，可以参考文章 长链接：比较健康合理的使用方式，但是也要正确的配置客户端，相关的参数为&maxPoolSize=xx 在ConnectionURI上追加上去即可，否则默认每个客户端就是高处100来个，平白的浪费资源 链接数的上限需要综合考虑性能，稳定性，业务需求。多方面去考虑，缺一不可。超低的内存，配置超高的链接数，得到的只能是OOM。 更多的关于连接数和如何正确配置的文章请参考MongoDB云数据库常见问题诊断
滑动查看更多
暂无更多信息
-
发表了文章
2017-01-07
通过MongoDB安全事件来谈谈为什么要用云服务
-
发表了文章
2016-12-13
MongoDB数据建模小案例：物联网时序数据库建模
-
发表了文章
2016-12-09
MongoDB数据建模小案例：朋友圈评论内容管理
-
发表了文章
2016-12-06
MongoDB数据建模小案例：多列数据结构
-
发表了文章
2016-06-06
云数据库MongoDB为什么需要限制连接数？
-
发表了文章
2016-05-26
MongoDB源码解析：Full Text Search Index
-
发表了文章
2016-05-09
阿里云MongoDB与EMR的HelloWorld
-
发表了文章
2016-01-25
MongoDB使用教程系列文章--Driver原理(初始化)
-
发表了文章
2016-01-25
MongoDB使用教程系列文章--开篇
-
发表了文章
2015-12-10
MongoDB Kill Hang问题排查记录
-
发表了文章
2015-12-10
基于空间数据库MongoDB实现全国电影票预定系统
-
发表了文章
2015-12-10
MongoDB Replication NetworkInterface
-
发表了文章
2015-12-10
MongoDB的索引代码实现--BtreeBasedAccessMethod
-
发表了文章
2015-12-10
MongoDB的网络协议
-
发表了文章
2015-12-10
MongoDB权限验证流程
滑动查看更多
-
回答了问题
2019-07-17
微博、论坛 用mongodb怎么设计数据库
微博，论坛类的内容管理业务，是非常适合MongoDB的文档结构，因为其JSON结构支持嵌套，数组等数据结构。
这类案例非常多，建议先通过互联网搜索技术方案。
赞0 踩0 评论0 -
回答了问题
2019-07-17
mongodb,主键_id的作用
_id相当于一个唯一标识，背后也是一个uniq key索引。从通用性的角度上看，MongoDB用其独特的算法生成了一个唯一标识，可以认为是绝不冲突的。并且MongoDB内部同步时，也严重依赖这个_id索引。
当然，如果你的业务比较独特，希望自定义_id，MongoDB完全支持的。但建议也是自增形式，对性能有好处。
赞0 踩0 评论0 -
回答了问题
2019-07-17
mongodb有异地双活的方案吗？
这么巧，阿里云有MongoDB异地多活的解决方案。
赞0 踩0 评论0 -
回答了问题
2019-07-17
用了mongodb，还需要用redis吗？
MongoDB自身的NoSQL特性，决定了其存储读取的性能都非常高。另外，非常非常重要的原因是，MongoDB具有灵活的扩展性，完善的Sharding机制。另外，5W并发的成功案例非常多。
赞1 踩0 评论0 -
回答了问题
2019-07-17
mongodb 查询内嵌文档
建议检查下自己的语法，内嵌查询肯定是可以的
赞0 踩0 评论0 -
回答了问题
2019-07-17
mongodb入数据时会出现OOM killer问题
注意配置cacheSizeGB，建议低于系统内存的50%。更深入的调整还有些Eviction参数，但调整起来比较麻烦。建议先尝试设置cacheSizeGB
赞1 踩0 评论0 -
回答了问题
2019-07-17
MongoDB 3.2如何使用InMemory引擎？
MongoDB 3.2中将InMemory是企业版功能，同时提供了另外一个存储引擎命名为ephemeralForTest。
但实际上MonogoDB 3.0.6的InMemory就是MongoDB 3.2的ephemeralForTest。参考配置：
storage: engine: "ephemeralForTest"赞3 踩0 评论0
滑动查看更多