后使用快捷导航没有帐号？
查看: 1836|回复: 22
MongoDB中关系的设计思考
论坛徽章:1
课程中给出了在MongoDB中一对一关系，一对多关系，多对多关系的设计考虑，同学们思考下还有其他的设计思路吗？如果有的话，其他的设计思路是怎么样的？
1、本周互动作业请在当前主题帖内进行发布，其他版块发起回复贴无效。
2、回复内容需符合主题帖讨论方向，灌水或者复制他人回帖，管理员及老师可以删除此贴，并判处作业不合格。
3、发起回帖需符合：1个回帖，字数不少50个字符的帖子。
金牌会员, 积分 2571, 距离下一级还需 429 积分
论坛徽章:16
MongoDB的设计和RDBMS设计还是有很大的区别的，MongoDB在集合的设计上可以使用嵌套集合，这个非常灵活和自然。
MongoDB集合和RDBMS表还有一个非常大的区别是，MongoDB集合是无模式的里面的文档可以是各式各样的。
中级会员, 积分 288, 距离下一级还需 212 积分
论坛徽章:14
MONGODB数据库和传统关系型数据库在设计集合（表结构）时，都会碰到一对一关系、一对多关系、多对多关系的情况。关系型数据库可以根据数据库三大范式的原则来设计表和表结构，建立冗余较小、结构合理的数据库。MONGODB可以模仿三大范式的原则，也可以根据具体业务需求情况采用嵌套的方式来，建立集合和文档。
中级会员, 积分 222, 距离下一级还需 278 积分
论坛徽章:6
Mongodb 地理位置索引
& &&&MongoDB支持二维空间索引，这是设计时考虑到基于位置的查询。例如“找到离目标位置最近的N条记录”。可以有效地作为附加条件过滤。
& &&&如果需要使用这种索引，应确定对象中存储的字段是子对象或数组，前两个元素为X，Y坐标(或者Y，X坐标，保持一致即可。it might be advisible to use order-preserving dictionaries/hashes in your client code, to ensure consistency)
论坛徽章:43
本帖最后由 dizzy21c 于
13:34 编辑
mongodb的一对多,实际应用中,又可以区分为几种情况:
每种情况有不同的优缺点需要考虑.
系列文章讨论了不同情况下的设计适应情况.
金牌会员, 积分 1292, 距离下一级还需 1708 积分
论坛徽章:7
1. mongodb 嵌套更自然，但是更新不方便、单条16MB的限制
2. RDBMS遵循范式、查询条件更灵活、扩展性高
3. 在mongodb我觉得可以学习rdbms反范式功能，比如sns中 我关注谁 或 谁关注了我这种功能，可以创建两个集合，比如分别以 关注对象用户uid 或者 被关注对象用户uid作为key 优化功能，提供查询效率，以空间来换取时间
金牌会员, 积分 1534, 距离下一级还需 1466 积分
论坛徽章:7
在MongoDB中，表示关系有两种办法：
一种是嵌套(embedded)，既是将一个文档包裹一个子文档；&&
而另一种是引用链接(reference link)，使用MongoDB的DBRef对象建立文档和文档之间的关系。
除此之外，MongoDB的关系比起传统的SQL表关系更丰富一些，可以有 1对1 ， 1对N ， N对1 和 N对N 几种关系
高级会员, 积分 532, 距离下一级还需 468 积分
论坛徽章:46
推荐本书：[MongoDB.Applied.Design.Patterns(2013.3)].Rick.Copeland
书里面关于网站访问记录统计这部分，有一个表设计的实例，感觉很有启发
能够体现出MongoDB和RDBMS的设计思想的区别。
& & _id: &/site-1/apache_pb.gif&,
& & metadata: {
& && &&&date: ISODate(&T00:00:00Z&),
& && &&&site: &site-1&,
& && &&&page: &/apache_pb.gif& },
& && &&&daily: 5468426,
& && &&&hourly: {
& && && && &&0&: 227850,
& && && && &&1&: 210231,
& && && && &...
& && && && &&23&: 20457 },
& && &&&minute: {
& && && && &&0&: 3612,
& && && && &&1&: 3241,
& && && && &...
& && && && &&1439&: 2819 }
注册会员, 积分 159, 距离下一级还需 41 积分
论坛徽章:4
一对多的设计：
课程中给出的MongoDB嵌套：
{uid:XX, msg:{[{msgid:1,msg_content:你好},{msgid:2, msg_content:在吗}]}}
其实还可以这样设计：
» {msg,msg_content}
»&&1, 你好
»&&2,在吗
» {userid,username,msgids:{[1,2]}}
注册会员, 积分 159, 距离下一级还需 41 积分
论坛徽章:4
本帖最后由 ikon999 于
14:20 编辑
怎么回事，回帖出问题了
& && && && && && && && && && &&&
& && && && && && && && &
& && && && && &新时代应用程序设计及MongoDB的十个深入理解
发表于 08:38|
来源个人博客|
作者Rotem Hermon& Asya Kamsky
摘要：区别于从小做起，Serendip从服务发布起就需要处理大量数据，因此他们不得不放弃传统的软件设计方式，转向Scala、Akka、Play、MongoDB、Elasticsearch等新时代技术堆栈。
正如前文所说，Serendip为了减少MongoDB中的复杂性而避免使用分片及一些功能，接下来我们为大家带来的是MongoDB资深解决方案架构师所分享的10个MongoDB深入理解：
1.&MongoDB同样需要运维。首先，MongoDB是个数据库，因此与其他数据库一样，它需要容量规划、性能调优、监视及维护。请不要因为MongoDB易于安装、开始及比传统关系型数据库更友好就认为MongoDB不需要关心及投入精力，同样不要因为小数据集运行飞快就认为MongoDB不需要优秀的模式、索引策略以及支撑应用程序所需的资源。然而一旦你做了充分的准备并且吃透了那些最佳实践，那么管理一个大型MongoDB集群将只是麻烦而不是伤透脑筋！
2.&成功的MongoDB使用者会监控一切并随时准备好它的增长。并做是使用任何数据库系统必备的基础，MongoDB也不能免俗。你必须了解当下集群可以支撑的负载量，也必须清楚在负载峰值时的硬件需求。如果你不清楚负载的增长情况，你必将因为资源耗尽而烦恼。为了监视你的MongoDB部署，你可以使用来可视化你的操作。
3.&扩展过程中的困难可能并不符合你的预期。在了解数百用户的部署后，发现性能瓶颈通常会因为以下几个问题产生（影响程度从大到小）：
应用程序访问模式设计得不够优化
很差或缺少索引，有时候也会存在太多无效索引
不足以支撑负载的缓慢磁盘或者IOPS
内存容量不足以支撑负载
模式设计不适合应用程序需求是影响性能的首罪，其次就是索引——很差、缺少或者是太多；然而即使这两个方面都没有问题，性能还可能受到磁盘IO的吞吐量限制，特别是写入吞吐量。内存不足会导致许多page&faulting并且给磁盘IO带来压力，随着应用规模的增加，系统所需的内存越来越多。
4.&许多MongoDB用户得益于单一的副本集。过早分片容易产生不成熟的优化，不是每个MongoDB部署都需要分片。分片只适合特定的情况，而不是应对“数据库缓慢”的灵丹妙药。如果你有1个错误的模式或者是不恰当的索引，分片不能解决任何问题。只有某个资源在单机或者单副本集情况下产生瓶颈时，并且继续扩展这个资源不符合投资回报比，分片才是最佳优化方案。系统可能会需求更多的IO吞吐量、RAM，亦或是更多的存储或并发性，这些情况下，分片往往比较好的选择。
5.&即使不是将整个数据库放入RAM中，你也可以获得优异的性能。在MongoDB世界里存在一个普遍的误区——将整个数据库放入RAM才可以获得较高的性能。然而取决于负载的类型，这可能是世界上最大的笑话。下面是一个显示和度量，体现了负载不同数据库所需的RAM。如你所见，随着数据库体积的增加，放入RAM中的部分受限于有效的实体存储器。如果RAM的大小不适合性能的需求，你将会看到page&faulting，同时随着错误数量的增加，系统的性能不升反降。
6.&数据持久化到磁盘。如果磁盘使用率已经达到100%，那么将无法执行更快地写入。你可以在MMS&Background&flush&average图表中查看脏页面从数据文件写入磁盘耗费的时间，从这个趋势来看，随着写入增多，这个过程将花费更多的时间。在这种情况下，你可以通过让磁盘更快、使用更多的分片以及优化应用程序来解决问题。需要注意的是，每个写入都会持久化到磁盘两次——及数据文件，将这两个操作划分到不同的物理磁盘上可以切实地降低IO带宽争用。
7.&副本不等于备份。所有人都清楚备份的重要性，但是备份为何如此重要？一般情况下该归结于可以从影响到所有副本节点数据的灾难事件中恢复，的原因非常简单，备份可以阻止数据被一些人为因素破坏——比如，某个人突然的删掉所有生产数据，或者是部署了错误版本的应用程序代码，这都可能让你的部分或者全部数据陷入危险之中。类似的情况下，你必须拥有一个备份来防止灾难的发生。因此，请进行适当的备份，即使你已经使用了、或者是。请不要让你首次备份发生在数据已经被受到威胁之时！
8.&副本集的健康程度不只看Replication&lag。Replication&lag体现了副本落后于主节点的程度，它只是副本集健康状态的指标之一。与之同等重要的还有，它会基于当下的写入负载计算出
完全恢复所需的时间。换句话说，它表示了一个预计时间——节点发生故障并有能力从中恢复，而无需去执行完全的数据同步。随着时间的推移，系统的写入负载可能会出现波动，replication&oplog&window同样会随之改变。在峰值负载下，replication&oplog&window将会缩短，这点在容量规划中是非常重要的。下面是一个MMS的对比视图，显示了跨副本集的replication&oplog&window：
9.&MongoDB不会知道数据需要什么级别的安全。任何数据库的管理都需要建立在“按需访问”之上，原则上，因此你。对MongoDB本身的安全限制也是非常重要的，你需要关闭所需访问之外所有的权限。
10.&请勿擅自修改MongoDB的高级选项。虽然MongoDB具备这个功能，但是除非万不得已请勿使用。在问题产生时，对比修改底层参数，更应该做的是定期分析查询及其他力所能及的事。
相关链接：
&& （编译/仲浩 审校/毛梦琪）
”为主题的
将于5月20-23日在北京国家会议中心隆重举办。产业观察、技术培训、主题论坛、行业研讨，内容丰富，干货十足。票价优惠，马上
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章2559人阅读
MongoDB（7）
摸索了几天，大体也初步算入了mongodb的门，仔细一想，mongodb和传统关系型数据库差别很大了。
传统关系型数据库中，一个数据库有一个或者多个表（Table），表中的数据是称之为记录，一行一行的，每行数据分不同的字段。
举一个容易理解的例子。一个人有姓名，性别，年龄，以及很多张银行卡；
如果使用关系型数据库，我们可能会是使用两张或者更多表来做记录，一张用户表来存用户的基本信息，另一张表通过用户id，和银行卡id,通过多条记录来存此人的多张银行卡对应关系；
那如果是在mongodb中，那就对应一个文件了
举个例子就是这样的数据了
Name:’小明’,Sex:’男’,Age:’25’,
BankCards:[ ‘’,’’,’5555555’]&&
所以到目前的mongodb中，它是没有关系这个概念的；
此图反应了mongdb和传统的关系型数据库（mysql,oracle）之间的对比;
应该说是，mongodb存的是一个完整的对象了，这个对象数据是已文档的形式存储的。至于它有什么优点，网上一大片说它优点，这里抓网络内容贴上：
架构：MongoDB是文档型数据库，其中一个集合保存不同的不同的文件。字段的数量，内容和该文件的大小可以是不同于从一个文件复制到另一个。
一个单一的对象是结构清晰
没有复杂的连接
深查询能力。 MongoDB支持动态查询使用基于文档的查询语言，如SQL几乎一样强大的文件
易于规模化：MongoDB是易于扩展
不需要数据库对象的应用程序对象转换/映射
使用内部存储器存储（窗口）工作组，从而实现更快的数据存取
不过缺点有很多，首先：不支持事物，而不会支持这种什么inner join ,left join等这样的关系连接，（因为不是关系型数据库嘛）。还有个我觉得是缺点，占用空间！
&下周再继续；
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：117584次
积分：2300
积分：2300
排名：第11578名
原创：113篇
转载：25篇
评论：21条
(4)(3)(13)(13)(1)(4)(2)(1)(12)(5)(6)(1)(3)(3)(11)(10)(14)(25)(8)MongoDB 之类的 NoSQL 与关系型数据库相比，各有什么优缺点及适用场景？
MongoDB之类的NoSQL数据库能完全取代关系型数据库吗？
按投票排序
NoSQL产品各有特色，下面就我熟悉的MongoDB来谈什么时候用NoSQL，算是部分地回答这个问题，欢迎批评。我看到的最好的讨论来自StackOverflow:When to use MongoDB or other document oriented database systems?其中引用了 NoSQL: If Only It Was That Easy 这一篇文章和一组问答很好地回答了什么时候用NoSQL的问题。下面引用加评论。I think Mongo might be the closest thing to a RDBMS replacement that I’ve seen so far. It won’t work for all data sets and access patterns, but it’s built for your typical CRUD stuff. Storing what is essentially a huge hash, and being able to select on any of those keys, is what most people use a relational database for. If your DB is 3NF and you don’t do any joins (you’re just selecting a bunch of tables and putting all the objects together, AKA what most people do in a web app), MongoDB would probably kick ass for you.上文说如果数据集比较简单，没有Join，MongoDB会非常棒。没错。但这不意味着如果数据复杂就不行。相反，这时需要重新设计数据schema (模式、架构、结构)，把相关的内容放到一个document里，这是与关系型数据库追求的三范式最不一样的地方。比如一篇文章的评论不算太多，最多几百个，就可以把评论放到数组(array)里，作为文章这一document的一部分。是的，数组(array)是支持的，查询数组元素也非常自然。这样的好处是在读取文章这一document时，一个页面上所有需要的数据都有了，读硬盘（内存）的次数少了，自然就快，相比之下，关系型数据库Join就麻烦很多了。这个例子里数据的access pattern决定了数据schema。相关文档（MongoDB的官方文档真是个好地方，尤其是他们最近在扩充文档团队）：MongoDB的设计哲学，牺牲什么专注什么：MongoDB的schema设计：MongoDB与SQL查询的对比：最后这个对比说明了，MongoDB希望在大多数应用中做为关系型数据库的替代品，提供这些优点：Document-oriented，用文档来组织数据，不需要严格的结构。High performance，高性能High availability，高可用，比如复制 (Replica set)Easy scalability，易扩展，比如ShardingRich query language，富查询这些特点都是以关系型数据库当假想敌来说的，你没有的我有，你有的我也可以有。实际上，10gen, MongoDB背后的公司，把Oracle作为真正的竞争对手，他们要从关系型数据库的碗里抢饭吃。MongoDB这样的NoSQL会火的根本原因，是许多用户不必需关系型数据库的特性，有时候还带来了限制。我从以上特性中选几个谈谈。Document-oriented.《MongoDB in Action》中举了扩展或自定义属性的例子。比如电子商务网站的产品除了预设的价格，id等，因具体产品不同有许多自定义属性，产品这个表应该怎么设计？就算一类产品大致相似，也有独特的属性，比如LCD和LED显示器的产品特性就不一样。这个问题有一些解决方案，比如 Entity-attribute-value Model
但是这些方案都很复杂，这时，schemaless的优点就显现出来了。Easy scalability. 当数据规模大到一个机器装不下了，或者一台机器数据读写负载太高，需要使用cluster的时候，关系型数据库的partitioning, sharding要复杂的手工处理。MongoDB可以自动按照用户给定的sharding key把数据分片，并且动态地平衡各个机器的数据量。Rich query language. 这是关系型数据库擅长的地方，也是用户所希望的，而有的key-value数据库只把value当作一个binary blob，比如Voldemort，只能通过key查询。简言之，不通用。MongoDB内部也是按key-value存的，但是支持各种查询，并且可以建各种索引，提供了易用与高性能。技术上，MongoDB用到的都是在学术上很成熟的，但是针对用户需要，它把不同的技术组合起来，建立了易用的产品，构成了关系型数据库强有力的挑战。当然，MongoDB不是什么功能都有，往往这也是其他NoSQL产品做不好的。最明显的就是事务现在没有被直接支持，其他知友也提到了。在MongoDB不适合干什么上，我还得多做做功课，再来补充。开头说到的文章中还提到了几个NoSQL产品的对比：What am I going to build my next app on? Probably Postgres. Will I use NoSQL? Maybe. I might also use Hadoop and Hive. I might keep everything in flat files. Maybe I’ll start hacking on Maglev. I’ll use whatever is best for the job. If I need reporting, I won’t be using any NoSQL. If I need caching, I’ll probably use Tokyo Tyrant. If I need ACIDity, I won’t use NoSQL. If I need a ton of counters, I’ll use Redis. If I need transactions, I’ll use Postgres. If I have a ton of a single type of documents, I’ll probably use Mongo. If I need to write 1 billion objects a day, I’d probably use Voldemort. If I need full text search, I’d probably use Solr. If I need full text search of volatile data, I’d probably use Sphinx.唯一的遗憾是这一文章写得太早（2009），此后MongoDB加入了不少很棒的新功能。比如文章提出的扩展性问题，2010年引入的Sharding提供了自动的扩展功能，，这一功能之后又不断被完善，可以算是一个对关系型数据库的杀手级feature了。这些应广大用户要求加入的feature使得MongoDB倍受欢迎。一个例子就是MongoDB成为在线招聘网站上继HTML5之后第二大增长最快的关键词。 这个说明许多startup的应用中可以用MongoDB代替关系型数据库。这是市场对这个问题的回答。其实开头文章中我最喜欢的一句话是NoSQL is a great tool, but it’s certainly not going to be your competitive edge, it’s not going to make your app hot, and most of all, your users won’t give a shit about any of this.做为一个工程师，最重要的是务实地去build something. 这也是为什么我想修改问题描述，把“完全取代”放到副标题，我们比较不同产品的特点，不预测未来，不空谈谁好谁坏。
不能！以下文章摘自：
理解ACID与BASE的区别（ACID是关系型数据库强一致性的四个要求，而BASE是NoSQL数据库通常对可用性及一致性的弱要求原则，它们的意思分别是，ACID：atomicity, consistency, isolation,BASE：Basically Available, Soft-state, Eventually Consistent。同时有意思的是ACID在英语里意为酸，BASE意思为碱）理解持久化与非持久化的区别。这么说是因为有的NoSQL系统是纯内存存储的。你必须意识到传统有关系型数据库与NoSQL系统在数据结构上的本质区别。传统关系型数据库通常是基于行的表格型存储，而NoSQL系统包括了列式存储（Cassandra）、key/value存储（Memcached）、文档型存储（CouchDB）以及图结构存储（Neo4j）与传统关系数据库有统一的SQL语言操作接口不同，NoSQL系统通常有自己特有的API接口。在架构上，你必须搞清楚，NoSQL系统是被设计用于成百上千台机器的集群中的，而非共享型数据库系统的架构。在NoSQL系统中，可能你得习惯一下不知道你的数据具体存在何处的情况。在NoSQL系统中，你最好习惯它的弱一致性。”eventually consistent”(最终一致性)正是BASE原则中的重要一项。比如在Twitter，你在Followers列表中经常会感受到数据的延迟。在NoSQL系统中，你要理解，很多时候数据并不总是可用的。你得理解，有的方案是拥有分区容忍性的，有的方案不一定有。
经常会有客户问我MongoDB的特点和使用场景，以及如何平滑迁移到云端，我正好总结了下，就mongodb而言谈谈我的看法。MongoDB的特点和适用场景实用性MongoDB是一个面向文档的数据库，它并不是关系型数据库，直接存取BSON，这意味着MongoDB更加灵活，因为可以在文档中直接插入数组之类的复杂数据类型，并且文档的key和value不是固定的数据类型和大小，所以开发者在使用MongoDB时无须预定义关系型数据库中的”表”等数据库对象，设计数据库将变得非常方便，可以大大地提升开发进度。可用性和负载均衡MongoDB在高可用和读负载均衡上的实现非常简洁和友好，MongoDB自带了副本集的概念，通过设计适合自己业务的副本集和驱动程序，可以非常有效和方便地实现高可用，读负载均衡。而在其他数据库产品中想实现以上功能，往往需要额外安装复杂的中间件，大大提升了系统复杂度，故障排查难度和运维成本。扩展性在扩展性方面，假设应用数据增长非常迅猛的话，通过不断地添加磁盘容量和内存容量往往是不现实的，而手工的分库分表又会带来非常繁重的工作量和技术复杂度。在扩展性上，MongoDB有非常有效的，现成的解决方案。通过自带的Mongos集群，只需要在适当的时候继续添加Mongo分片，就可以实现程序段自动水平扩展和路由，一方面缓解单个节点的读写压力，另外一方面可有效地均衡磁盘容量的使用情况。整个mongos集群对应用层完全透明，并可完美地做到各个Mongos集群组件的高可用性。数据压缩自从MongoDB 3.0推出以后，MongoDB引入了一个高性能的存储引擎WiredTiger，并且它在数据压缩性能上得到了极大的提升，跟之前的MMAP引擎相比，压缩比至少可增加5倍以上，可以极大地改善磁盘空间使用率。其他特性相比其他关系型数据库，MongoDB引入了”固定集合”的概念。所谓固定集合，就是指整个集合的大小是预先定义并固定的，内部就是一个循环队列，假如集合满了，MongoDB后台会自动去清理旧数据，并且由于每次都是写入固定空间，可大大地提升写入速度。这个特性就非常适用于日志型应用，不用再去纠结日志疯狂增长的清理措施和写入效率问题。另外需要更加精细的淘汰策略设置，还可以使用TTL索引(time-to-live
index)，即具有生命周期的索引，它允许为每条记录设置一个过期时间，当某条记录达到它的设置条件时可被自动删除。在某些LBS的应用中，使用MongoDB也有非常巨大的优势。MongoDB支持多种类型的地理空间索引，支持多种不同类型的地理空间查询，比如intersection，within和nearness等。MongoDB不适用的应用场景在某些场景下，MongoDB作为一个非关系型数据库有其局限性。MongoDB不支持事务操作，所以需要用到事务的应用建议不用MongoDB，另外MongoDB目前不支持join操作，需要复杂查询的应用也不建议使用MongoDB。MongoDB云数据库的优势通常使用MongodB一般有个方案，一是在主机上自己搭建，另外一个就是使用云计算厂商提供的MongoDB云数据库产品。相对自建MongoDB而言，以公有云UCloud的云MongoDB举例，使用MongoDB云数据库主要有以下优势1 部署流程UCloud是最早提供云MongoDB产品的云计算厂商，相对其他云计算厂商而言，配置也是最为灵活的。UCloud云MongoDB提供了2.4,2.6,3.0和3.2四个最为常用的版本，除了可自定义磁盘容量和内存上限外，客户可根据自身业务需求创建单实例MongoDB，任意节点数量的副本集，任意节点数量的configsvr和mongos，以及选择创建普通磁盘和SSD磁盘的MongoDB。2 弹性扩容和统一管理弹性扩容是云计算的一个非常巨大的优势，在MongoDB云数据库中，可以非常方便地实现内存在线升降级和磁盘升降级，已经资源的申请和释放，从而最高效地实现了容量规划。另外在自建DB中如果实例达到一定的规模，集中化的管理往往会成为一个较大的运维成本，MongoDB在云数据库中可以根据项目和业务种类进行分组，比如相同的业务使用统一的配置文件，从而有效地减少了运维成本。3 备份管理在自建的MongoDB中，备份的管理往往也较为混乱，另外还需要额外的磁盘空间去存取备份文件。在MongoDB云数据库中，基本上各个云服务商都提供有成熟的备份策略，同样以UCloud举例，它可保存7次自动备份，3次手工备份，并根据自己的业务低峰期设置每天的定时备份时间段，还可以设置是否从secondary节点进行备份4 监控和告警自建MongoDB中，数据库本身的监控项一般通过脚本获取mongostat的结果实现，CPU，内存，磁盘使用率等监控项还需要额外再写脚本，并配置好相应的告警策略。使用MongoDB云数据库，可提供非常丰富的监控项和告警策略，及时地发现和处理性能瓶颈。5 故障处理使用MongoDB云数据库，当DB所在的物理机出现硬件故障或者DB本身出现性能问题，云计算厂商往往具备非常丰富的故障处理经验，可保障在最短的时间内恢复服务。另外，虽然云数据库虽然禁止客户登陆DB所在的物理机，不过一般云计算厂商比如UCloud可以提供错误日志下载等功能，方便客户去定位故障原因。迁移到云数据库一般MongoDB的迁移上云的策略都是通过副本集的高可用性来实现，不过需要首先保证网络的连通性（这一点一般云计算厂商都会负责或协助打通）。通过将云DB作为自建DB的Secondary节点，当两边的数据达到完成一致，确认数据正常后，手工做一次高可用的切换，使得服务整理从自建DB切换到云DB。当切换完成后，云DB可成功选举成为新的Primary节点，这时即可在新的Primary节点上rs.remove移除自建DB节点，从而实现了MongoDB上云的平滑迁移。下面已自建的MongoDB是三个节点组成的副本集为例，现在想迁移到云上，方案图如下当数据完全一致后，人为地将旧主库关闭，并将Mongodb云数据库中的一个Secondary节点提升为新的Primary节点确认业务正常，数据没有问题后，在MongoDB云数据库的Primary节点中挨个删除自建DB的数据节点即可。另外，部分云计算厂商，比如UCloud已经推出完整的MongoDB数据库上云工具，用户可自行调用API即可实现MongoDB迁移到云数据库。
身边正巧有个实例，公司90后小程序，下载了最近热传的 2000w，导入 couchdb，写了几个map reduce 分析适合下手的样本。这才不到4天，已经成功约炮两女！当然咯，sql是肯定能做到同样的事情的，不过你在等着建索引，分析语句的时候，人家已经在啪啪啪，啪啪啪，啪啪啪啪啪科学技术就是爱情的生产力么
用PostgreSQL 就好了，鱼和熊掌兼得。
自己不是搞存储的，不过前段时间和某位在google megastore的paper上有名字的基友面基了几天，基本上就是不停的黑MongoDB, 比如：“MongoDB那帮人根本不懂DB”“MongoDB还说什么NoSQL，不如叫NoDB”还有很多，具体记不清了总之我听从基友教诲，好好学postgre...
pymongo 的 find() 挺慢的.
NoSQL!=NO SQL
一般情况下，像redis,memcache,mongoDB等更多的作缓存服务，但是数据落地最好还是用关系型数据库
肯定不能。IE6到现在都很多人用，为何，习惯尔。RMDB成熟，无数人习惯了，无数软件作为后台，无数石器时代的软件公司依偎生存。
已有帐号？
无法登录？
社交帐号登录