MongoDB是不是理想的数据库选项？
极客时间编辑部
讲述：丁婵大小：7.15M时长：05:12
过去几年来，一直不断出现用户不该将 MongoDB 作为数据库选项的声音与文章。然而，在重重阻力之下，MongoDB 仍然发展成了一款更为成熟的产品。那么，MongoDB 是不是理想的数据库选项呢？
此前，Simple Thread 的博客作者贾斯汀·埃瑟利奇（Justin Etheredge）列举了 MongoDB 独特的优势和缺点，试图回答上述问题，并分享了在确定技术方案时要思考的两个问题，以下为重点内容。
首先，需要明确的是，MongoDB 以及文档数据库等能够帮助人们搞定很多传统关系数据库无法应对的难题，比如：
严格的模式：在传统数据库当中，如果你掌握的是动态数据，就必须创建一堆随机的“杂项”数据列以将数据作为数据块进行推送，或者使用 EAV 设置等，而这些都有着严重的缺陷。
难于扩展：在传统数据库中，如果你的数据规模太过庞大就无法被直接存放在单一服务器当中，相比之下，MongoDB 的内置功能允许你跨越多台计算机实现数据扩展。
架构修改难题：在使用关系数据库时，变更数据库结构无疑是一大难题。MongoDB 会简化这一过程，使得结构调整更加轻松顺手，你可以持续更新架构并快速完成迁移。
写入性能： MongoDB 的性能相当不错，特别是在配合正确的配置方式之后。MongoDB 开箱即用的写入配置虽然成为不少人抨击它的理由，但也确实带来了一些令人印象深刻的性能数字。
MongoDB 能够带来的潜在优势无疑是巨大的，面对特定问题类型的用户确实可以从中获益良多。但它也存在不少问题，MongoDB 公司并不是没有考虑到这些问题，他们只是做出了自己的权衡。
事务机制的局限性。事务可以说是众多关系数据库的核心特征。事务机制意味着用户能够以原子方式执行多项操作，并始终确保数据内容保持一致。尽管 MongoDB 4.0 已经引入了事务机制，但其中仍然存在不少局限性。
关系完整性（外键）丢失。如果你的数据之间存在关系，那么这种关系就是一种客观现实。几乎所有数据中都包含某种关系，如果数据库没有强制体现这些关系，就得由应用程序负责构建。具体来讲，由数据库强制执行这些关系将帮助应用程序减轻大量负担，从而降低软件工程师们的日常工作量。
缺乏执行数据结构的能力。强模式有时候代表着一种短板，但只要加以合理运用，其同时也可能成为确保数据拥有良好结构的有力机制。相比之下，MongoDB 这类文档数据库能够在模式层面带来令人难以置信的灵活性，但这种灵活性同时会将责任转嫁到维护者身上，强制要求其保持数据清洁。如果没有给予应有的关注，那你最终不得不在应用程序中添加大量代码，从而消化那些在结构上与预期不符的数据。 注意：MongoDB 支持模式验证，这项功能非常有用，但仍然无法带来可与关系数据库相媲美的保障。首先，添加或修改架构验证不会影响集合中的任何现有数据，因此你需要自行确保数据更新以匹配新的架构。换言之，到底是否满足需求还是得由你自己决定。
另外，很多开发者常常将 MongoDB 视为应用程序的主数据存储区，而这样的决定通常意味着极为昂贵的维护成本。
那么，到底该如何确定哪些技术方案对自己的用例具备实际意义？目前已经出现不少尝试性项目，希望就技术评估工作构建一套系统性框架。事实上并不需要这么复杂，你只需思考两个主要问题，就足以合理评估众多的技术方案，不过前提是找到能够负责任地回答这些问题的人。第一个问题是你打算解决什么问题？第二个问题是你放弃了什么？对于那些新兴技术，你需要谨慎地回答以下两个问题：
这款工具是否能为你解决实际问题？
你是否真正理解该工具在开发中所做出的权衡？
现在让我们回到主题：MongoDB 到底是不是理想的数据库选项？是的，它当然是，但与大多数软件工程问题一样，这得分具体情况。
以上就是埃瑟利奇的观点，希望能给你带来参考价值。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
第一装甲集群司令克莱斯特MongoDB+Kafka，业务快速查询，屡试不爽。1
收起评论