MongodbDB

优势

MongoDB 以及文档数据库这一类解决方案，能够帮助人们搞定很多传统关系数据库无法应对的难题：

• 严格的模式：在传统数据库当中，如果我们掌握的是动态数据，则必须创建一堆随机的“杂项”数据列以将数据作为数据块进行推送；或者使用 EAV 设置等等……而这一切，都有着严重的缺陷。

• 难于扩展：在传统数据库当中，如果我们的数据规模太过庞大则将无法被直接存放在单一服务器当中；相比之下，MongoDB 的内置功能允许大家跨越多台计算机实现数据扩展。

• 架构修改难题：可迁移！在使用关系数据库时，变更数据库结构无疑是一项巨大的挑战（特别是在您的数据量不断增大这一背景之下）。MongoDB 承诺显著简化这一过程，使得结构调整变得更为轻松顺手，用户能够持续更新架构并快速完成迁移。

• 写入性能：MongoDB 的性能相当不错，特别是在配合正确的配置方式之后。MongoDB 开箱即用的写入配置虽然成为不少人抨击它的理由，但也确实带来了一些令人印象深刻的性能数字。

缺陷

但它却同样做了很多妥协，出现了不少的问题：

• 事务丢失：事务可以说是众多关系数据库（注意，不是全部，但确实是大多数）的核心特征。事务机制意味着用户能够以原子方式执行多项操作，并始终确保数据内容保持一致。MongoDB 4.0 已经于去年引入了事务机制，但其中仍然存在不少局限性。正如不少报道已经指出，用户需要首先评估其能否满足自己的需求。

• 关系完整性（外键）丢失：如果你的数据之间存在关系，那么这种关系就是一种客观现实。几乎所有数据中都包含某种关系，如果数据库没有强制体现这些关系，就得由应用程序负责构建。具体来讲，由数据库强制执行这些关系将帮助应用程序减轻大量负担，从而降低软件工程师们的日常工作量。

• 缺乏执行数据结构的能力：强模式有时候代表着一种短板，但其同时也可能成为确保数据拥有良好结构的有力机制。只要加以合理运用，其就能够提供一种强大的机制，用以确保您的数据在结构上与您的期望完全契合。相比之下，MongoDB 这类文档数据库能够在模式层面带来令人难以置信的灵活性，但这种灵活性同时会将责任转嫁到维护者身上，强制要求其保持数据清洁。MongoDB 支持模式验证，这项功能非常有用，但却仍无法带来可与关系数据库相媲美的保障。

• 缺少自定义查询语言 / 工具生态系统：SQL 在刚刚出现时绝对掀起了一场革命，而且时至今日仍然代表着一种客观标准。SQL 是一种非常强大的语言，但同时也给用户带来了使用挑战。我们必须使用由 JSON 片段组成的自定义查询语言查询数据库；即使对于经验丰富的 SQL 专业人士而言，这也绝对不是一项轻松的工作。另外，SQL 数据库拥有一整套互操作工具，从 IDE 到报告工具皆在其中。而一旦将数据迁移至不支持 SQL 数据库，即意味着其中大多数工具将无法继续使用。更可怕的是，即使想找到新的办法将数据放入能够继续使用这些工具的其它 SQL 数据库，其难度也远远超过大多数人的想象。

• 维护成本高昂：很多开发者常常将 MongoDB 视为应用程序的主数据存储区，导致维护成本过高。