MongoDB Sacrifices Data Safety for Speed as Engineer Quits Tech

Episode 1 - Mongo DB Is Web Scale — gar1t

gar1t

Engineering teams risk catastrophic data loss when abandoning ACID transactions for memory-staged benchmark speed, even though 99.9% of workloads require nothing beyond proven relational databases like MySQL.

AI-assisted summary of Episode 1 - Mongo DB Is Web Scale — original source. Check the original for full context.

Source published:

Key ideas

  • A viral architectural debate exposes the clash between battle-tested relational databases like MySQL and hyped NoSQL options like MongoDB, which proponents claim are inherently 'web scale'. (0:00)
  • The presenter highlights that MongoDB achieves its high benchmark numbers by staging writes asynchronously in memory, risking permanent data loss during crashes. (1:00)
  • While petabyte-scale tech giants like Google require custom distributed architectures, an estimated 99.9% of companies can fulfill their operational needs with MySQL paired with Memcached. (2:30)
  • The discussion warns against sacrificing core ACID guarantees—transactions, consistency, and durability—solely to maximize raw write throughput benchmarks. (4:10)

Detailed notes

## Background Published on YouTube by creator gar1t on August 27, 2010, this animated video portrays an engineering debate between two developers. According to the show notes, the piece captures a Q&A discussion weighing the merits of NoSQL against relational databases.

## TL;DR Following a presentation endorsing MySQL for production workloads, a pragmatic systems engineer is interrogated by an enthusiastic developer dogmatically insisting that MongoDB is inherently 'web scale.' The presenter points out that MongoDB's impressive benchmarks come at the cost of durability, transactional safety, and data consistency, but his architectural warnings are ignored in favor of buzzwords like sharding and MapReduce. Confronted by the realization that superficial hype-chasing dominates the industry, the presenter experiences an existential crisis and abandons software engineering altogether in favor of manual farm labor.

## Atmosphere & style The exchange unfolds as a sharply satirical, deadpan tech parody driven by the clash between unblinking, buzzword-fueled optimism and mounting existential exhaustion. Watching the presenter slowly unravel evokes the excruciating familiarity of modern engineering debates, where sound architectural fundamentals collide with uncritical marketing hype. The tone steadily spirals from professional exasperation into pitch-black comedy as the engineer retreats into vivid, gruesome agricultural fantasies just to escape the conversation.

## Bulletin - [00:00](https://www.youtube.com/watch?v=b2F-DItXtZs&t=0s) A viral architectural debate exposes the clash between battle-tested relational databases like MySQL and hyped NoSQL options like MongoDB, which proponents claim are inherently 'web scale'. - [01:00](https://www.youtube.com/watch?v=b2F-DItXtZs&t=60s) The presenter highlights that MongoDB achieves its high benchmark numbers by staging writes asynchronously in memory, risking permanent data loss during crashes. - [02:30](https://www.youtube.com/watch?v=b2F-DItXtZs&t=150s) While petabyte-scale tech giants like Google require custom distributed architectures, an estimated 99.9% of companies can fulfill their operational needs with MySQL paired with Memcached. - [04:10](https://www.youtube.com/watch?v=b2F-DItXtZs&t=250s) The discussion warns against sacrificing core ACID guarantees—transactions, consistency, and durability—solely to maximize raw write throughput benchmarks.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=b2F-DItXtZs&t=0s) The presenter defends MySQL as a proven, mature database solution suitable for production workloads. - [00:16](https://www.youtube.com/watch?v=b2F-DItXtZs&t=16s) The audience member advocates for MongoDB, arguing it is 'web scale' because it avoids relational joins and SQL. - [00:45](https://www.youtube.com/watch?v=b2F-DItXtZs&t=45s) The MongoDB proponent asserts relational databases inherently cannot scale due to disk writes and impedance mismatch. - [01:05](https://www.youtube.com/watch?v=b2F-DItXtZs&t=65s) MongoDB's superior benchmark performance is attributed to staging data asynchronously in memory rather than immediate disk persistence. - [01:30](https://www.youtube.com/watch?v=b2F-DItXtZs&t=90s) The developer dismisses data durability concerns, arguing performance compromises are acceptable if they yield kick-ass benchmarks. - [01:41](https://www.youtube.com/watch?v=b2F-DItXtZs&t=101s) Sarcastic suggestions to pipe data to '/dev/null' for maximum speed are met with serious inquiries about whether it supports sharding. - [01:55](https://www.youtube.com/watch?v=b2F-DItXtZs&t=115s) Sharding is dogmatically championed as 'the secret ingredient in the web scale sauce' without an understanding of its mechanisms. - [02:13](https://www.youtube.com/watch?v=b2F-DItXtZs&t=133s) Exasperated by buzzword-driven development, the presenter announces his desire to resign and work on a farm. - [02:20](https://www.youtube.com/watch?v=b2F-DItXtZs&t=140s) RDBMS technologies represent decades of continuous engineering and testing, making them robust and reliable since the 1970s. - [02:30](https://www.youtube.com/watch?v=b2F-DItXtZs&t=150s) 99.9% of companies do not operate at Google or Amazon scale and are better served by MySQL combined with Memcached. - [03:40](https://www.youtube.com/watch?v=b2F-DItXtZs&t=220s) The developer blindly favors Redis over Memcached purely based on claimed speed and scalability buzzwords. - [04:10](https://www.youtube.com/watch?v=b2F-DItXtZs&t=250s) The presenter cautions that abandoning ACID properties (atomicity, consistency, isolation, durability) compromises the core purpose of a database. - [04:20](https://www.youtube.com/watch?v=b2F-DItXtZs&t=260s) The developer rattles off MongoDB features, including document models, MapReduce, memory-mapped files, and GridFS, without evaluating engineering trade-offs. - [05:30](https://www.youtube.com/watch?v=b2F-DItXtZs&t=330s) The presentation abruptly concludes as the presenter walks out rather than continuing to debate superficial architectural hype.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=b2F-DItXtZs&t=0s) The MySQL Conclusion and the "Web Scale" Objection

The presentation concludes with the speaker affirming that MySQL has proven to be an excellent, battle-tested database choice for their website architecture. Immediately opening the floor for audience questions, an enthusiastic web developer challenges the decision by asking why MongoDB was not chosen instead. The questioner asserts that MongoDB is fundamentally a "web scale" database that achieves superior performance precisely because it eliminates SQL and relational joins. The presenter calmly responds that the engineering team evaluated several NoSQL databases, but determined that the available options remained far too immature for mission-critical production workloads, whereas MySQL is a globally proven relational database offering the exact feature set and stability they require.

The audience member immediately rejects this rationale, arguing that relational databases are fundamentally incapable of scaling because they rely on disk writes and relational joins. When the presenter attempts to explain that scalability is a nuanced engineering problem and points out that numerous high-profile websites successfully run on relational backends, the questioner pivots to buzzwords, asserting that relational databases suffer from "impedance mismatch" and claiming that MySQL is inherently "slow as a dog." In response to the blanket claim that MongoDB runs circles around relational systems, the presenter concedes that MongoDB posts impressive benchmark figures, but explains the architectural catch behind those numbers: MongoDB stages data asynchronously rather than guaranteeing immediate persistent writes to disk. If a server failure or crash occurs during that staging window, data is lost permanently. When asked if sacrificing basic data safety sounds like sound system architecture, the MongoDB advocate dismisses the concern entirely, insisting that whatever compromises are necessary to produce kick-ass benchmarks constitute great design.

- **MongoDB proponent's stance**: Relational databases cannot scale due to joins and disk writes; MongoDB is "web scale" right out of the box. - **Presenter's critique**: The benchmarks are inflated because writes are merely staged in memory; if an error or crash occurs before the write is flushed, data is wiped out. - As the audience member bluntly puts it: “If that's what they need to do to get those kickass benchmarks then it's a great design.”

---

[01:41](https://www.youtube.com/watch?v=b2F-DItXtZs&t=101s) `/dev/null`, Sharding, and Resigning for Farm Life

Confronted with the developer's complete disregard for data durability, the presenter sarcastically suggests that anyone willing to discard reliability purely for benchmark numbers should simply pipe all incoming data to `/dev/null`, since an empty null device will be lightning-fast. Completely missing the sarcasm, the developer eagerly asks whether `/dev/null` is web scale and if it supports sharding. Stunned by the response, the presenter questions whether the developer even understands what a shard is. The developer blindly defends the buzzword, calling shards "the secret ingredient in the web scale sauce" and claiming that "they just work."

Upon learning that his sparring partner is employed as an actual web programmer, the presenter experiences an existential breakdown. Pushed beyond his limit, he announces his immediate resignation from software engineering, declaring that working on a farm shoveling pig manure and administering medical suppositories to sick livestock would be infinitely preferable to sharing an industry with superficial hype-chasers. He excoriates developers who read a single article on High Scalability, assume they have the architectural competence of a Google infrastructure engineer, and endlessly parrot slogans without understanding core distributed systems principles. While acknowledging that companies operating at Google or Amazon scale—indexing petabytes across globally distributed clusters—genuinely need custom distributed architectures, he stresses that 99.9% of companies can easily satisfy all their operational requirements using mature relational tools like MySQL paired with an in-memory caching layer such as Memcached.

```mermaid flowchart TD accTitle: Architectural Decision Logic accDescr: Flowchart illustrating the decision between mature relational technology and specialized distributed infrastructure based on company scale.

subgraph Evaluation["Workload Evaluation"] A["Company Data Requirements"] --> B{"Petabytes of globally<br/>distributed data?"} end

subgraph Architecture["Infrastructure Choices"] B -->|"Yes (Google / Amazon scale)"| C["Custom Distributed / NoSQL Stores"] B -->|"No (99.9% of companies)"| D["Proven Relational Stack<br/>(MySQL + Memcached)"] end

subgraph AntiPattern["The 'Web Scale' Trap"] E["Hype-driven Developer"] -->|"Ignores durability"| F["Pipelines data blindly"] F --> G["Data Loss & Broken Projects"] end ```

- Relational database management systems have been continuously engineered, tested, and refined since the 1970s, representing some of the most mature engineering in computer science. - The presenter notes that most software projects do not operate at petabyte scale and do not need to reinvent distributed storage from scratch. - The presenter cuts through the hype with an ultimatum on realistic infrastructure needs: “If you need to build a globally distributed search engine that manages petabytes of data fine build your own database but if you're like 99.9% of companies you can probably get by very well with something like MySQL and maybe Memcached.”

---

[03:40](https://www.youtube.com/watch?v=b2F-DItXtZs&t=220s) Buzzword Bingo vs. Farm Horrors

The debate devolves into total absurdity as the developer ignores every architectural caution and interrupts with another dogmatic comparison, proclaiming that Redis kicks Memcached's ass because it is faster and more scalable. At this point, the presenter mentally disengages entirely, finding solace in increasingly brutal and grotesque farm fantasies—imagining castrating a thrashing, three-thousand-pound bull or scraping encrusted chicken droppings just to escape having to listen to a NoSQL zealot rattle off the spec sheet of a schema-free database.

Unperturbed by the presenter’s obvious distress, the programmer continues reciting talking points from promotional literature, highlighting MongoDB's document model, MapReduce queries, memory-mapped file architecture, and contention-free atomic modifiers. The presenter furiously retorts that abandoning ACID guarantees—transactions, consistency, and durability—simply to boast about high write throughput means gutting the foundational purpose of a database. He retreats further into his rural fantasy, imagining himself succumbing to hemorrhagic *E. coli* in a cattle barn, welcoming death as a peaceful escape from a tech landscape where financial institutions might be duped by NoSQL evangelists into abandoning sound transactional systems for unproven distributed tools. The developer caps off the exchange by mechanically praising MongoDB's ability to store arbitrary file sizes via GridFS without complicating the application stack. Refusing to entertain another word, the presenter abruptly terminates the presentation and walks out to begin his new agricultural life.

- **Developer's rapid-fire buzzwords**: Redis over Memcached, document models over relational tables, MapReduce instead of joins, memory-mapped files delivering a 10x write throughput boost, atomic modifiers for zero-contention writes, and native large-file handling. - **Presenter's underlying critique**: High throughput achieved by ignoring transactional safety and durability is meaningless when mission-critical integrity is required. - The presenter mocks the trend of abandoning fundamental data integrity for raw speed: “What the fuck, let's abandon transactions, consistency, durability and pin our mission critical data to a table and give it a night it will never forget—I mean who cares what we store for as long as we do it quickly?”

## Notable quotes > [01:41](https://www.youtube.com/watch?v=b2F-DItXtZs&t=101s) If you need to build a globally distributed search engine that manages petabytes of data fine build your own database but if you're like 99.9% of companies you can probably get by very well with something like MySQL and maybe Memcached. — Presenter

## Mentioned Amazon, /dev/null, Google, GridFS, High Scalability, MapReduce, Memcached, MongoDB, MySQL, NoSQL, Redis, SQL

## Video description Q&A discussion discussing the merits of No SQL and relational databases.

[Source](https://www.youtube.com/watch?v=b2F-DItXtZs)

中文简报

MongoDB为速度牺牲数据安全，工程师心灰意冷退出科技界 工程团队若为了内存暂存的基准测试速度而放弃ACID事务，将面临灾难性的数据丢失风险，尽管99.9%的工作负载只需MySQL等成熟的关系型数据库即可满足。 在一场推荐将MySQL用于生产环境工作负载的演讲之后，一位务实务实的系统工程师遭到了一位狂热开发者的质问，后者教条地坚称MongoDB本质上就是“网络级规模”（web scale）。演讲者指出，MongoDB令人瞩目的基准测试表现是以牺牲持久性、事务安全性和数据一致性为代价的，但他关于架构层面的警告却被分片（sharding）和MapReduce等流行术语所掩盖。面对行业内充斥着浮躁跟风炒作的现实，演讲者陷入了存在主义危机，最终彻底放弃软件工程转而从事农场体力劳动。 一场广泛传播的架构辩论揭示了经过实战检验的关系型数据库（如MySQL）与备受追捧的NoSQL选项（如MongoDB）之间的冲突，支持者声称后者本质上就具备“网络级规模”。 (0:00) 演讲者强调，MongoDB之所以能取得较高的基准测试数据，是因为它在内存中异步暂存写入，这在系统崩溃时存在永久丢失数据的风险。 (1:00) 虽然像谷歌这样拥有PB级规模的科技巨头需要定制的分布式架构，但据估计99.9%的公司仅靠MySQL搭配Memcached就能满足其业务需求。 (2:30) 讨论警告称，切勿仅仅为了最大化原始写入吞吐量基准测试，就牺牲核心的ACID保障——事务、一致性和持久性。 (4:10)

Reading summary

A satirical debate between a pragmatic software presenter and an enthusiastic web developer highlights the conflict between battle-tested relational databases and hype-driven NoSQL adoption. While the developer advocates for MongoDB as an inherently fast, 'web scale' solution, the presenter argues that trading data durability and ACID guarantees for synthetic benchmark speeds undermines sound system architecture. Benchmarks Versus Write Durability (0:00) The dispute begins when an audience member challenges the presenter's choice of MySQL, asserting that relational databases cannot scale because they depend on relational joins and disk writes, whereas MongoDB achieves superior performance by removing them. The presenter concedes that MongoDB posts impressive benchmark numbers, but points out the underlying mechanism: data is staged asynchronously in memory rather than immediately committed to disk, meaning any crash or server error during the staging window results in permanent data loss. When confronted with this reliability compromise, the developer defends the practice, maintaining that any engineering concession that yields superior benchmark metrics constitutes great design. Enterprise Scale Versus Everyday Architectural Needs (1:41) When the presenter sarcastically suggests piping data directly to /dev/null for maximum speed, the developer eagerly inquires whether /dev/null supports sharding, describing shards as an automatic secret ingredient for scalability. The presenter criticizes developers who skim technical articles and mimic the infrastructure patterns of technology giants without understanding core distributed systems principles. While acknowledging that organizations operating at the scale of Google or Amazon with petabytes of globally distributed data genuinely require custom distributed architectures, the presenter notes that 99.9% of companies can comfortably satisfy their operational requirements using mature relational tools such as MySQL paired with an in-memory caching tier like Memcached. Buzzword Adoption Versus Transactional Integrity (3:40) The discussion descends into an uncritical catalog of promotional specifications, with the developer arguing that Redis surpasses Memcached and praising MongoDB's document model, MapReduce queries, memory-mapped files, atomic modifiers, and GridFS file storage. In response, the presenter asserts that gutting foundational ACID guarantees—transactions, consistency, and durability—merely to boast about write throughput invalidates the primary purpose of a database. Distressed by an industry climate where mission-critical systems and financial backends might abandon proven transactional safety for unvetted distributed tools, the presenter abandons the discussion entirely to seek refuge in grueling farm labor. The exchange underscores an enduring debate in software architecture: whether adopting cutting-edge distributed databases based on raw write metrics justifies sacrificing the mature transactional integrity and reliability provided by decades-old relational technologies.

精炼阅读摘要

本场辩论围绕关系型数据库与新兴NoSQL数据库的技术选型分歧展开。演讲者指出，盲目追求所谓“网络级规模”（Web Scale）和跑分数据而牺牲ACID特性与持久性是危险的工程误区，强调绝大多数企业依靠成熟的关系型技术栈即可满足实际需求。 基准测试虚高与数据持久性牺牲 (0:00) 提问者主张关系型数据库因依赖磁盘写入和表连接（Join）而存在扩展瓶颈，并断言MySQL速度迟缓，而MongoDB则通过舍弃SQL与关联查询实现了优越的高性能。演讲者对此提出反驳，指出MongoDB惊人的写入基准测试本质上源于内存异步暂存机制，并未提供即时持久化到磁盘的安全保障；一旦发生系统崩溃或硬件故障，暂存窗口内的数据将永久丢失。面对提问者“为了亮眼基准可以牺牲可靠性”的论调，演讲者严肃指出，抛弃事务、一致性与持久性（ACID）去换取表面的高吞吐量，实质上背离了数据库保障数据完整性的核心职责。 真实业务规模与网络级规模迷思 (1:41) 提问者将“分片”（Sharding）奉为解决扩展问题的万能法则，甚至未加辨别地追问空设备`/dev/null`是否支持分片与Web Scale。演讲者以此揭示了行业内普遍存在的盲目跟风现象，批评部分开发者仅凭几篇浅显的技术文章便自认具备顶级分布式系统设计能力。演讲者指出，尽管像Google或Amazon这样需要在全球范围内处理PB级数据的巨型企业确实需要定制化的分布式NoSQL架构，但99.9%的普通企业根本无需重蹈覆辙；自20世纪70年代起便历经持续检验的关系型数据库（如MySQL）配合内存缓存（如Memcached），足以稳定承载绝大多数商业场景。 术语堆砌驱动架构与工程倦怠 (3:40) 提问者在辩论中持续机械化地罗列宣传手册中的流行术语，涵盖Redis对Memcached的替代、文档模型、MapReduce、内存映射文件的高写入吞吐、无争用原子修改器以及GridFS大文件存储等特性。演讲者对此表现出极大的工程倦怠与心理崩溃，对金融等关键行业可能受此类狂热营销误导而弃用稳健事务系统的现状深感忧虑。演讲者认为，与缺乏分布式系统底层常识、一味追逐概念的开发者共事所带来的挫败感，已远超从事繁重粗陋的农场劳作，最终以愤然离场的方式终止了技术交流。 该讨论凸显了技术炒作与工程严谨性之间的尖锐冲突。核心问题在于，面对被营销概念与性能跑分裹挟的行业环境，工程团队如何在追求吞吐性能与恪守数据持久性底线之间建立理性的技术评估边界。

Detailed notes — zh

## Background 该视频由频道 gar1t 于 2010 年 8 月 27 日发布在 YouTube 平台。视频简介将其描述为一场探讨 NoSQL 与关系型数据库各自优劣的问答讨论。 ## TL;DR 在一次技术分享问答中，演讲者主张久经考验的 MySQL 仍是绝大多数业务的最佳选型，却遭到一名盲信 NoSQL 的 Web 程序员的连环质问。提问者满嘴“Web Scale”、分片和跑分等时髦黑话，甚至在得知 MongoDB 靠延迟落盘刷分、有丢数据风险时依然盲目推崇，甚至把演讲者讽刺的 /dev/null 当真询问是否支持分片。演讲者痛斥业内读了几篇大厂论文就盲目重造轮子、抛弃事务与持久性的浮躁风气，最终在绝望与愤怒中当场宣布辞职，宁愿去农场干最脏最累的苦力活也不愿再与这样的行业狂热分子为伍。 ## Atmosphere & style 整个视频充满了极致的荒诞讽刺与黑色幽默。一边是毫无工程敬畏心、机械复读营销黑话的 NoSQL 狂热信徒，另一边则是试图进行理性工程对话却节节崩溃、最终彻底破防的资深工程师。随着提问者愈发离谱的回答，演讲者的情绪从耐心解释急转直下至愤怒咆哮，并在脑海中疯狂脑补各种可怕的农场脏活，观感极其戏剧化且令人捧腹，生动刻画了技术人员面对浮躁炒作时的深深幻灭感。 ## Bulletin - [00:00](https://www.youtube.com/watch?v=b2F-DItXtZs&t=0s) 技术分享现场围绕 MySQL 与 MongoDB 爆发激烈论战，反映出开发群体中追求成熟可靠与盲目追逐 NoSQL 及 Web Scale 概念的尖锐冲突。 - [01:14](https://www.youtube.com/watch?v=b2F-DItXtZs&t=74s) 演讲者揭露早期 MongoDB 亮眼基准跑分的本质是牺牲数据落盘持久性、仅做异步暂存，若落盘失败将导致数据永久丢失。 - [02:35](https://www.youtube.com/watch?v=b2F-DItXtZs&t=155s) 演讲者痛斥 99.9% 的企业根本不需要重造分布式系统轮子，MySQL 搭配 Memcached 已足以应对绝大多数业务场景。 - [03:43](https://www.youtube.com/watch?v=b2F-DItXtZs&t=223s) 面对满口堆砌分片、MapReduce 等术语却缺乏工程敬畏的开发者，演讲者愤而辞职并宣称宁可去农场干脏活也不愿留在 IT 行业。 ## Key takeaways - [00:00](https://www.youtube.com/watch?v=b2F-DItXtZs&t=0s) 演讲者在完成选型评估后认定 MySQL 成熟稳定且久经考验，依然是生产环境的优选底座。 - [00:00](https://www.youtube.com/watch?v=b2F-DItXtZs&t=0s) 提问者盲目鼓吹 MongoDB 的 Web Scale 属性，武断认为关系型数据库由于依赖 SQL、JOIN 与磁盘写入而无法扩展。 - [00:35](https://www.youtube.com/watch?v=b2F-DItXtZs&t=35s) 演讲者强调架构可扩展性极其复杂，业界大量超大规模高并发网站仍在核心系统中使用 MySQL。 - [01:14](https://www.youtube.com/watch?v=b2F-DItXtZs&t=74s) 早期 MongoDB 的极高写入性能很大程度上依赖异步暂存机制，一旦异步落盘失败便会导致严重的数据丢失。 - [01:25](https://www.youtube.com/watch?v=b2F-DItXtZs&t=85s) 提问者对数据持久性妥协完全无所谓，甚至认为只要能换取亮眼跑分就是优秀设计。 - [01:34](https://www.youtube.com/watch?v=b2F-DItXtZs&t=94s) 演讲者反讽若不顾数据可靠性不如直接写入 /dev/null，提问者却荒谬追问 /dev/null 是否支持分片（Sharding）。 - [02:35](https://www.youtube.com/watch?v=b2F-DItXtZs&t=155s) 行业浮躁之风盛行，部分开发者仅阅读几篇高并发博文便自以为掌握大型分布式系统精髓，热衷盲目跟风背诵黑话。 - [03:00](https://www.youtube.com/watch?v=b2F-DItXtZs&t=180s) 关系型数据库历经数十年检验具备高度成熟性，普通企业盲目模仿 Google 和 Amazon 的分布式白皮书是在无谓重造轮子。 - [03:25](https://www.youtube.com/watch?v=b2F-DItXtZs&t=205s) 绝大多数公司凭借经典的 MySQL 搭配 Memcached 即可稳定支撑业务，无需盲目追逐新潮工具。 - [03:43](https://www.youtube.com/watch?v=b2F-DItXtZs&t=223s) 提问者像背诵手册般机械罗列 MongoDB 特性，涵盖文档模型、MapReduce、内存映射文件加速及原子修改器等。 - [04:20](https://www.youtube.com/watch?v=b2F-DItXtZs&t=260s) 演讲者对行业抛弃事务、一致性与持久性（ACID）的激进风气感到极度幻灭与担忧。 - [04:45](https://www.youtube.com/watch?v=b2F-DItXtZs&t=285s) 演讲者悲观预言若狂热分子将不成熟的存储技术推入金融等关键领域，早晚会酿成严重灾难。 - [05:15](https://www.youtube.com/watch?v=b2F-DItXtZs&t=315s) 在彻底绝望中，演讲者宣布当场辞去软件工程师职位并拂袖离场，立誓转行去农场务农。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=b2F-DItXtZs&t=0s) 技术分享问答：MySQL 与 MongoDB 的 Web Scale 之争 技术分享者刚刚结束关于网站数据库选型的演讲，并在结语中指出，团队经过评估认定 MySQL 是一款非常出色的网站数据库。然而在提问环节，一名听众立即发难，质疑团队为何不选用 MongoDB。该提问者言之凿凿地宣称：“MongoDB is a web scale database and doesn't use SQL or joins so it's high performance.” 面对这一质问，演讲者耐心地解释道，团队确实认真评估了数款 NoSQL 数据库，但一致认为这些新兴方案对于关键的生产环境而言依然过于不成熟；相比之下，MySQL 在整个互联网行业久经考验，不仅成熟稳定，而且完全满足现有的业务需求。 听众对这一解释完全不买账，反驳称 MySQL 根本无法扩展，并声称“人人都知道关系型数据库无法扩展，因为它们使用 JOIN 操作而且还要写入磁盘”。演讲者试图将其拉回理性的工程讨论，指出可扩展性是一个非常复杂的技术课题，绝不能做如此武断、一刀切的概括，甚至提醒对方业界仍有许多知名的超大型高并发网站依然将关系型数据库（尤其是 MySQL）作为核心底座。然而该听众继续抛出术语，指责关系型数据库存在所谓的“阻抗失配”（甚至一度口误），坚称“MySQL 慢得像条狗”，而 MongoDB 能够轻松将 MySQL 甩在身后，因为 MongoDB 代表了所谓的“Web Scale”（网络级规模扩展）。 ```mermaid flowchart TD accTitle: MySQL与MongoDB的技术选型争议 accDescr: 展示提问者鼓吹MongoDB的术语与演讲者坚持MySQL成熟稳定之间的冲突对比 subgraph Relational["演讲者立场：MySQL"] R1["久经考验 (Battle-tested)"] R2["支持 ACID、事务与持久性"] R3["适合 99.9% 企业的生产环境"] end subgraph NoSQL["提问者立场：MongoDB"] N1["Web Scale (网络级扩展)"] N2["无 SQL、无 JOIN、支持分片"] N3["基准跑分极高 (High Benchmarks)"] end Relational <-->|"激烈争论：成熟可靠 vs 跑分炒作"| NoSQL ``` ### [01:14](https://www.youtube.com/watch?v=b2F-DItXtZs&t=74s) 基准跑分的陷阱与 /dev/null 的讽刺 演讲者随后揭开了 MongoDB 那些亮眼跑分背后的底牌：MongoDB 的基准测试数据确实让人印象深刻，但它们是通过一些“耐人寻味”的手段换来的——当应用程序向 MongoDB 发起写操作时，数据并没有真正持久化落盘，而仅仅是暂存（stage）下来以便稍后异步写入。如果后续写入磁盘时发生故障，数据就会直接丢失。面对演讲者的质疑，这位热衷 NoSQL 的程序员竟全盘接受这种妥协，大言不惭地表示：“If that's what they need to do to get those kickass benchmarks, then it's a great design.” 听到这种置数据持久性于不顾的荒谬言论，演讲者愤怒而讽刺地建议：如果为了刷基准跑分可以连可用性和数据可靠性都不要，那干脆把数据全部重定向输送到 `/dev/null`，那样的写入速度才是天下第一。令人啼笑皆非的是，提问者完全听不出其中的反讽，甚至一本正经地反问：“Does /dev/null support sharding?” 并坚称分片（Sharding）就是 Web Scale 秘方中的关键调料。当演讲者彻底崩溃并质问对方到底靠什么谋生时，提问者得意地回答自己是一名“Web 程序员”。 - 演讲者揭露 MongoDB 的写入机制实质是将数据暂存，后续异步落盘若失败会导致数据彻底丢失（“you're fucked”）。 - 提问者对 `/dev/null` 的嘲讽毫无察觉，盲目认为只要支持 Web Scale 和 Sharding 就可以采用。 - 演讲者尖锐反问：“If you are happy writing to a database that doesn't give you any idea that your data is actually written just because you want high performance numbers, why not write to devnull?” ### [02:35](https://www.youtube.com/watch?v=b2F-DItXtZs&t=155s) 软件工程师的幻灭与“逃离 IT 去农场”的咆哮 面对这位张口闭口行业黑话、缺乏基本工程敬畏心的 Web 程序员，演讲者彻底心态崩溃，当场宣布辞去软件工程师职位，发誓宁可去农场干最脏、最累的苦力活，也不愿和这样的行业败类为伍。他愤怒地痛斥，现在很多所谓的开发者仅仅在 HighScalability.com 上看了几篇博文，就自以为成了 Google 的首席架构师，整天像鹦鹉学舌一样重复着“Web Scale”和“分片”等时髦辞藻，实际上根本不知道自己在胡扯什么。 演讲者进一步抨击了盲目重造轮子的浮躁风气：关系型数据库自 20 世纪 70 年代诞生以来，是计算机领域最成熟的技术之一；仅仅因为 Google 和 Amazon 发布了几篇分布式系统的白皮书，整个行业就盲目跟风，试图颠覆一切。他强调，除非你真的需要构建一个管理 PB 级数据的全球分布式搜索引擎，否则完全不需要自己重造数据库轮子，并指出：“If you're like 99.9% of companies, you can probably get by very well with something like MySQL and maybe Memcached.” - 演讲者怒斥盲目跟风者像对待充气娃娃一样对待新技术软件，早晚会把严肃的项目彻底搞砸。 - 面对演讲者关于架构选型的严正劝告，提问者仍不以为然地插话宣称 Redis 能够暴打 Memcached，进一步展示了盲目追逐新潮工具的典型心态。 ### [03:43](https://www.youtube.com/watch?v=b2F-DItXtZs&t=223s) 对黑话信徒的彻底绝望与发布会离场 在随后的时间里，提问者彻底沦为单向输出宣传口号的机器，接连背诵 NoSQL 的宣传手册：宣称 MongoDB 是无需 JOIN 的文档数据库、原生支持 MapReduce、利用内存映射文件（mmap）能将写入吞吐量提升十倍、具备用于无竞态性能的原子修改器（Atomic Modifiers），并且能无缝存储任意大小的文件。 与之形成绝妙荒诞对比的是，演讲者完全放弃了与对方进行理性技术辩论，他在脑海中不断构想自己在农场里的各种重口味极端劳动：从给狂躁的公牛做绝育手术、清理鸡粪蓄水池，到在满是牛屁臭气的牛棚中感染出血性大肠杆菌窒息而死。演讲者直言，即便在农场里受尽折磨甚至流血致死，也远比忍受 NoSQL 狂热信徒背诵无模式（Schema-free）数据库的功能列表要轻松得多。他极为悲观地预言，这帮狂热分子早晚会忽悠金融机构抛弃成熟的数据存储底座，从而引发全球经济危机。在满腔愤怒与荒诞感中，演讲者留下了最后一句辞职宣言：“Thank you for your questions, this presentation is over, and I'm fucking off to the farm to start my new career.” 拂袖而去。 - 提问者连续背诵的 MongoDB 宣传特性包括：文档模型、MapReduce、内存映射文件提速 10 倍、原子修改器（Atomic modifiers）以及任意大小文件存储。 - 演讲者对放弃基础可靠性的行为发出最强烈的讽刺：“Let's abandon transactions, consistency, durability, and pin our mission-critical data to a table and give it a night it will never forget.” ## Notable quotes > [02:35](https://www.youtube.com/watch?v=b2F-DItXtZs&t=155s) If you're like 99.9% of companies, you can probably get by very well with something like MySQL and maybe Memcached. — 演讲者 > [01:14](https://www.youtube.com/watch?v=b2F-DItXtZs&t=74s) If you are happy writing to a database that doesn't give you any idea that your data is actually written just because you want high performance numbers, why not write to devnull? — 演讲者 ## Mentioned gar1t, MySQL, MongoDB, NoSQL, /dev/null, HighScalability.com, Google, Amazon, Memcached, Redis, MapReduce ## Video description Q&A discussion discussing the merits of No SQL and relational databases. [Source](https://www.youtube.com/watch?v=b2F-DItXtZs)

Source quotes

[2:35] 演讲者: If you're like 99.9% of companies, you can probably get by very well with something like MySQL and maybe Memcached. [1:14] 演讲者: If you are happy writing to a database that doesn't give you any idea that your data is actually written just because you want high performance numbers, why not write to devnull?

Source quotes

[1:41] Presenter: If you need to build a globally distributed search engine that manages petabytes of data fine build your own database but if you're like 99.9% of companies you can probably get by very well with something like MySQL and maybe Memcached.

Original transcript

[0:00] and in conclusion we have found my SQL [0:02] to be an excellent database for our [0:04] website any questions yes I have a [0:08] question why didn't you use mongodb [0:11] mongodb is a web scale database and [0:14] doesn't use SQL or joints so it's high [0:17] performance that's an excellent question [0:20] we evaluated several nosql databases and [0:23] concluded that the options are still too [0:25] immature for our production needs my SQL [0:28] is a proven database that is across the [0:30] web and it has the features we need but [0:33] it doesn't scale everybody knows that [0:36] relational databases don't scale because [0:38] they use joints and rate to dis [0:40] scalability is a complicated topic and [0:43] it's hard to make a general statement [0:45] like that relational databases weren't [0:47] built for web scale mongodb handles web [0:51] scale you turn it on and it scales right [0:54] up it may surprise you that there are a [0:56] handful of high-profile websites still [0:58] using relational data es and in [1:00] particular my squel relational databases [1:03] have impedance mismatch I think you mean [1:06] impedance my SQL is slow as a dog [1:09] mongodb will run circles around my [1:11] sequel because mongodb is web scale [1:14] mongod DB does have some impressive [1:16] benchmarks but they do some interesting [1:19] things to get those numbers for example [1:22] when you write to mongod DB you don't [1:25] actually write anything you stage your [1:27] data to be written at a later time if [1:29] there's a problem writing your data [1:31] you're [ __ ] does it sound like a good [1:34] design to you if that's what they need [1:37] to do to get those kickass benchmarks [1:39] then it's a great [1:41] design if you were stupid enough to [1:44] totally ignore your ability just to get [1:46] benchmarks I suggest you pipe your data [1:48] to devnull it will be very fast if [1:52] devnull is fast in web scale I will use [1:54] it is it web scale you are kidding me [1:57] right I was making a joke I I mean if [2:00] you're happy writing to a database that [2:02] doesn't give you any idea that your data [2:05] is actually written just because you [2:07] want high performance numbers why not [2:09] write to devnull it's fast as hell does [2:13] devnull support sharding holy [ __ ] for [2:16] my own mental health I'm going to assume [2:18] you're just messing with me and aren't [2:19] actually [ __ ] do you even know what [2:22] A Shard is shards are the secret [2:24] ingredient in the web scale sauce they [2:27] just work please tell me you don't act [2:29] your make a living in a Technology field [2:32] I'm a web [2:35] programmer as of this moment I [2:37] officially resigned from my job as [2:39] software engineer and will take up work [2:41] on the farm shoveling pig [ __ ] and [2:43] administering anal suppositories to sick [2:45] horses because that will be a thousand [2:47] times more tolerable than being in the [2:49] same industry as [ __ ] like you you [2:52] read the latest post on highscalability [2:54] tocom and think you're a [ __ ] Google [2:57] architect and pared slogans like webc [3:00] and charting but you have no idea what [3:02] the [ __ ] you are talking about you're [3:04] going to blow some project to hell [3:06] because you get a woody playing with [3:07] software like it's a sex doll relational [3:10] databases have been around since the [3:12] fucking' 70s and are some of the most [3:14] mature technology you can find yet [3:17] somehow everything needs to be [3:18] reinvented because Google and Amazon [3:20] post some white papers if you need to [3:23] build a globally distributed search [3:25] engine that manages petabytes of data [3:28] fine build your own data base but if [3:31] you're like [3:32] 99.9% of companies you can probably get [3:35] by very well with something like my SQL [3:37] and maybe me cash redis will kick me [3:40] catch's ass it's so fast and scalable [3:43] right now I'm thinking of how much fun [3:45] it will be to cast right my first bull [3:47] down on the farm I cannot wait to cut [3:50] off the testicles of a 3,000 Raging Bull [3:53] as it tries to kick my head in mongodb [3:56] is a document database that doesn't need [3:58] joins it uses map reduce now I'm [4:01] cleaning a sist of chicken [ __ ] but I [4:03] don't care because I don't have to [4:05] listen to the no SQL Fanboy reciting the [4:08] feature list of their favorite schema [4:10] free database by riding to memory map [4:13] files mongodb can improve its right [4:16] through put by a factor of 10 what the [4:18] [ __ ] let's abandon transactions [4:21] consistency durability and pin our [4:23] mission critical data to a table and [4:25] give it a night it will never forget I [4:27] mean who cares what we store for as long [4:30] as we do it quickly oh sorry that's [4:34] right I'm on the farm now suffocating [4:36] from the stench of a thousand cow farts [4:39] but it smells like roses to me because I [4:42] am nowhere near this moronic [4:44] conversation mongod DB uses Atomic [4:46] modifiers for contention free [4:48] performance now I've contracted moric [4:51] aoli from cleaning cow stalls and I'm [4:53] bleeding out my [ __ ] I'll be dead [4:56] soon but that is a welcome relief I will [4:58] never have to wait witness the collapse [5:00] of the world economy because no SQL [5:03] radicals talked financial institutions [5:05] into abandoning perfectly good data [5:07] stores because they didn't support [5:09] distributed [ __ ] map reduce mongodb [5:12] stores files of any size without [5:14] complicating your [5:17] stack thank you for your questions this [5:20] presentation is over and I'm [ __ ] off [5:22] to the farm to start my new career