编程与软件工程sarahmei.com
为什么你不该使用 MongoDB
Why You Should Never Use MongoDB
2013 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者以社交网络项目 Diaspora 的失败为例，说明 MongoDB 这类文档数据库并不适合需要复杂关联查询和事务的场景：反范式化的数据内嵌导致数据大量重复、更新难以同步。文章提醒开发者不要因技术潮流而选型，关系型数据库在多数情况下仍是更稳妥的默认选择。
为什么经久不衰：它把 NoSQL 热潮中的选型教训讲成了一个具体案例，多年后仍是讨论数据库选型与'反炒作'思维的必读经典。
HN 评论精选
关系型数据库是对未知查询需求的对冲，创业公司没有理由放弃这个默认选择。
关系型数据库长期是新应用默认的数据存储是有充分理由的：它本质上是对查询方式的一种对冲。完全范式化的数据库是一种空间高效的数据模型表示，配合适当的索引，几乎可以从任何角度高效查询。当然对冲意味着对任何特定访问模式都不是最优的，某些 NoSQL 存储可能更快。但走这条路之前，你最好非常确定自己今天乃至永远会如何使用数据，还得有真正严苛的扩展性需求，否则就是过早优化。创业公司这两条都不满足，所以除非真的清楚自己在做什么，否则应该远离 Mongo。因为不懂 SQL、被无模式存储的'灵活性'吸引而选 Mongo，绝对是错误的理由。
dasil003查看英文原文
There is a good reason that relational databases have long been the default data store for new apps: they are fundamentally a hedge on how you query your data. A fully-normalized database is a space-efficient representation of some data model which can be queried reasonably efficiently from any angle with a bit of careful indexing. Of course relational databases being a hedge, are not optimal for anything. For any particular data access pattern there's probably an easy way to make it faster using x or y nosql data store. However as the article points out, before you decide to go that route you better be pretty certain that you know exactly how you are going to use your data today and for all time. You also should probably have some pretty serious known scalability requirements otherwise it could be premature optimization. Neither of these things are true for a startup, so I'd say startups should definitely stay away from Mongo unless they really know what they are doing. Being ignorant of SQL and attracted by the "flexibility" of schema-less data stores powered by javascript is definitely the wrong reason to look at Mongo.
问题不在 MongoDB 本身，而在于不加评估、跟风选型。
这篇文章的标题或许应该改成'为什么不该基于炒作、不加评估就选技术'。MongoDB 有（可能至今仍有）一些缺陷，也不是完美的数据库系统，但确实存在适合它的合理使用场景。要建一个需要沿关系图做丰富查询的社交网站，这绝对不是其中之一。
ThePhysicist查看英文原文
The post should probably be titled "Why you should not pick a technology based on hype and without evaluating it first". While MongoDB has (and probably still has) some flaws and is not the perfect DB system, there are valid use cases where it can be a good choice. Building a social networking site that requires rich queries along a relationship graph is most definitely not one of them.
Diaspora 的失败是盲目跟风炒作、从不评估需求的典型案例。
与其说是 MongoDB 的故事，不如说是炒作的故事：仅仅因为某个享受十五分钟名气的人发了条推文，就盲目接受某项技术。Diaspora 团队要建的是一个需要支持复杂查询和事务性更新的分布式数据库，只是他们自己没意识到，却因为炒作选了 MongoDB，失败是必然的。'当时信息有限、选择不算不合理'这种说法站不住脚——他们没有讨论需求，没有意识到数据模型与 MongoDB 的明显冲突，更没讨论事务需求。
geophile查看英文原文
More than a story about MongoDB, this is a story about hype. The unquestioning, unthinking acceptance of some technology just because someone enjoying his 15 minutes of fame has tweeted about it. The designers of Diaspora set out to build a distributed database that needed to support complex queries and transactional updates. Only they didn't realize it. And they chose MongoDB because of hype. And of course it failed. TFA says: "In 2010, when the Diaspora team was making this decision, Etsy’s articles about using document stores were quite influential, although they’ve since publicly moved away from MongoDB for data storage. Likewise, at the time, Facebook’s Cassandra was also stirring up a lot of conversation about leaving relational databases. Diaspora chose MongoDB for their social data in this zeitgeist. It was not an unreasonable choice at the time, given the information they had." Yes, it was an unreasonable choice. This is basically saying that the cool kids are using document stores, so we should too. There is no discussion of requirements, no recognition of the obvious conflict between Diaspora's data model and MongoDB's, and no discussion at all of the need for transactions, let alone distributed transactions! TFA says: "In this post I’ve talked about how we used MongoDB vs. how it was designed to be used. I’ve talked about it as though all that information were obvious, and the Diaspora team just failed to research adequately before choosing. But this stuff wasn’t obvious at all." Of course it was obvious. If you have a highly recursive data structure, and you decide to basically store the result of a seven-way join in a single document, then there is duplication. You should know, just from your earliest programming days, that duplicating data in data structures leads to grief. How are updates going to be handled? And if you decide against duplication, you have to do the joins, and clearly MongoDB doesn't solve that problem. So even before worrying about transactions it is obvious that you have a problem. Finally, they migrate to MySQL and (then also? in addition?) Postgres. Although I don't quite see how this fits their database per pod architecture. I'm guessing that each pod talks to -- what -- one centralized database? Maybe they will eventually figure out what's wrong with that. Oy.
讨厌 join 的人只是没学好 SQL，join 正是关系型数据库的核心价值。
'七表 join，呃'——什么？这正是关系型数据库存在的意义，七表根本不算什么，索引得当的话会非常快。这就像 C 程序员说'解引用指针，呃'一样。这种态度源于没花时间学习 SQL、索引和 join 的原理，自己写出的烂查询慢了就怪数据库。join 是好的，它是关系型数据库的全部意义所在，就像指针一样强大，但要用对。它唯一的缺点是无法跨多台数据库服务器扩展，但以如今单机的能力，大多数产品根本碰不到这个限制。
gmjoe查看英文原文
> Seven-table joins. Ugh. What? That's what relationship databases are for. And seven is nothing. Properly indexed, that's probably super-super-fast. This is the equivalent of a C programmer saying "dereferencing a pointer, ugh". Or a PHP programmer saying "associative arrays, ugh". I think this attitude comes from a similar place as JavaScript-hate. A lot of people have to write JavaScript, but aren't good at JavaScript, so they don't take time to learn the language, and then when it doesn't do what they expect or fit their preconceived notions, they blame it for being a crappy language, when it's really just their own lack of investment. Likewise, I'm amazed at people who hate relational databases or joins, because they never bothered to learn SQL and how indexes work and how joins work, discover that their badly-written query is slow and CPU-hogging, and then blame relational databases, when it's really just their own lack of experience. Joins are good, people. They're the whole point of relational databases. But they're like pointers -- very powerful, but you need to use them properly. (Their only negative is that they don't scale beyond a single database server, but given database server capabilities these days, you'll be very lucky to ever run into this limitation, for most products.)
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选