MongoDB核心贡献者不是MongoDB不行,而是你不懂！.PDFVIP

MongoDB 核心贡献者：不是 MongoDB 不行，而是你不懂！ 近期MongoDB 在Hack News 上是频繁中枪。许多人更是声称恨上了MongoDB， David mytton 就在他的博客中揭露了MongoDB 许多现存问题。然而恨的人 有之偏爱的也同样很多，作为回击：Russell Smith 带来了多年工作经验 的总结。Russell Smith 曾担任Ops 和大型网站缩放顾问并且帮助过 Guardian、Experian 等多家公司，MongoDB London User Group 的联合创 始人。作为 MongoDB Master （MongoDB 官方认可的 MongoDB 核心贡献者组 织，并通过社区分享自己的专业技术），其参与工作的基础设施单服务器 每秒查询超过 3 万次，每天活跃数据更在 1TB 以上。 下面来看 Russell 对 MongoDB 一些常见及生僻的问题做出分析： 32 位 vs 64 位 现在大多数的服务器都对 32 位操作系统实现支持，更有许多新型硬件支持 着允许更多 RAM 的 64 位操作系统。 MongoDB 也同时发布了 32 位及 64 位两个版本的数据库。归结于 MongoDB 使用的内存映射文件，32位版本只支持2G数据的存储。对于标准的Replica Set，MongoDB 只拥有单一的处理策略 —— mongod。如果你想在未来储存 2G 以上的数据，请使用64 位版本的 MongoDB。如果拥有分片安装，那么 32 位版本同样可以使用。 总结：使用 64 位版本或者理解 32 位版本的限制。 文件大小限制 不同于RDBMS 把数据储存在行与列中，MongoDB 的数据是储存在文件中的。 这些文件使用二进制存储形式，其格式为类似 JSON 格式的 BSON 格式。 和其它的数据库一样，单个文件的储存大小是有限制的。在旧版本的 MongoDB 中，单个文件都限制在4M 以内。而新版本的MongoDB 单文件已经 支持到 16M 大小。这样的限制也许是令人厌烦的，但是 10gen 的意见是： 如果这项设置不停的困扰到你，那么是否你的设计模式存在着问题；或者 你可以使用 文件无大小限制的 GridFS。 这种情况通常的建议是避免存储过大的文件，不定期的更新数据库中存储 的各种对象。而像Amazon S3 或者 Rackspace Cloudfiles 这样的服务通常 可能会是更好的选择，而非必要情况下最好别让基础设施陷入过载。 总结：把每个文件保持在 16M 以下，那么一切都好。 写入失败 MongoDB 在默认的情况下允许高速的写入和更新，而付出的代价就是没有 明确的错误通知。默认情况下多数的驱动都在做异步、 “不安全”写入 —— 这就意味着驱动程序不能立即反馈错误信息，类似于MySQL 的INSERT DELAYED。如果你想知道某个事情是否成功，你必须使用 getLastError 手 动的检查错误信息。 某些情况下如果你需要在错误发生后立刻得到错误信息，即：大多数的驱 动中都很容易实现同步 “安全”查询。这将谋杀掉 MongoDB 不同于传统数 据库的优点。 如果对比 “完全安全”的同步写入你需要多一点性能，同时还想要一定程 度的安全，那么你可以使用 getLastError with‘j’让 MongoDB 只到一份 日志提交后再发出错误报告通知。那么日志将以100 毫秒一次的速度输出 到磁盘，而不是 60 秒。 总结：如果必须要写入确认，你可以使用安全写入或 getLastError。 数据结构模型的弱化不等于没有数据结构模型 RDBMS 一般都拥有一个预定义的数据结构模型：表格的行和列，每个字段 都拥有名称和数据类型。如果你想给其中一行加一列，那么你必须给整个 表格都添加一列。 MongoDB 则是移除了这个设置，对于 Collection 和文件没有强制的模型限 定。这有益于快速开发及简易修改。 当然这不意味着你就可以无视结构模型的设计，一个合适的结构模型可以 让你获得 MongoDB 的最佳性能。赶快阅读MongoDB 文档，或者观看这些结 构模型设计的相关视频吧！  Schema Design Basics  Schema Design at Scale  Schema Design Principles and Practice 总结：设计结构模型并充分利用 MongoDB 的特色。 默认情况下修改语句修改的只是单个文件 在传统的 RDBMS 中除非使用LIMIT 子句，修改语句作用的