极客时间已完结课程限时免费阅读

062 | 文档数据库的缔造者MongoDB（上）

062 | 文档数据库的缔造者MongoDB（上）-极客时间

062 | 文档数据库的缔造者MongoDB（上）

2018-02-23 徐飞 来自北京
《技术与商业案例解读》
课程介绍

讲述：秭明

时长16:49大小7.70M

大数据和云计算的风被谷歌吹起来的时候，被谷歌收购的网络广告公司 DoubleClick 的原 CEO 和 CTO 们觉得自己应该蹭上时代的列车，再次创业，然后 10gen 公司就这样在纽约诞生了。它的创始人分别是 DoubleClick 的创始人兼 CTO 德怀特 · 梅里曼（Dwight Merriman）、CEO 凯文 · 瑞安（Kevin Ryan），以及工程师埃利特 · 霍洛威兹（Eliot Horowitz）。
公司成立之初，创始人的想法和 MongoDB 这个产品毫无关系：他们想做一个云计算的服务，并用开源的东西来搭建。然而很遗憾，这几位二次创业的人在开源社区找了一圈，也没有看到一个让人满意的东西。于是，怀着构建伟大云计算服务的梦想，他们决定先把这个事情停一停，先搭一个自己满意的数据库出来。这个数据库就是后来赫赫有名的 MongoDB。
MongoDB 的名字需要解释一下。国内很多人觉得是“芒果数据库”，其实不是的。在英文里，“芒果”是 Mango，而 Mongo 是 humongous 的中间部分，在英文里是“巨大无比”的意思。所以 MongoDB 可以翻译成“巨大无比的数据库”，更优雅的叫法是“海量数据库”。
这几位创始人的梦想就是创建一个和过去关系数据库完全不一样的数据库，使之具有这样一些特点：海量数据库、数据库的模型极其灵活、适合程序员使用。
大概怀着伟大理想的人都会做出伟大的产品。MongoDB 注定是独特的，在历史上会留下浓重一笔的产品。
当 MongoDB 开发出来的时候，创始人们给它的定义是：这是一个面向集合的、模式自由的文档型数据库。听到这里，你可能觉得有点晕了，那就先普及一下数据库的基本常识吧。
在过去的 30 多年里，整个工业界的数据库被所谓的关系数据库所主导。一个不太严谨的说法是：关系数据库的基本存储单元是表。而一张表则是有行有列的数据集合，而列的定义有严格的类型。所以关系数据库是一个严格定义的数据模型，每张表里的每条记录都是一个样的。
查询关系数据库的标准语言叫作 SQL。SQL 这个东西自从 IBM 发明出来以后，已经有 30 多年的历史了，人们爱它的有，恨它的也有。但是通常来说，程序员不太喜欢这个东西，因为它的基本理念和程序员编程的想法不一致。后来所谓的 NoSQL 风，指的就是那些不用 SQL 作为查询语言的数据存储系统，而文档数据库 MongoDB 正是 NoSQL 的代表。
和关系数据库相反，MongoDB 的数据模型很不一样。简单来说，MongoDB 面向的是集合而不是表，所有的数据存储都以集合为单位，而每个集合里面包含的东西则称为文档，一个集合可以包含无数个文档。每个文档，我们可以大致认为是个 JSON 数据模型。文档自带元数据。也就是说，MongoDB 里面每个集合的每个文档并不要求数据严格一致，而是可能千差万别。
MongoDB 还有一个特色，它的查询使用的不是 SQL，而是程序语言和 API。这样一来，MongoDB 对程序员就是一个非常友善的选择。当然，对于原本非常熟悉 SQL 的 DBA 和数据分析人员，这就显得不太友好了。
MongoDB 这个数据模型其实是非常脑洞大开的。在数据库领域的几十年发展里，很多人都试过各种各样挑战关系数据库的模型，但是鲜有成功的。即使成功了，也往往让人感觉雷声大雨点小，并不会对关系数据库的根本造成实质性的影响。然而 MongoDB 这个东西一出现，对有经验的数据库从业人员和使用者来说，第一个感觉就是这个东西是来搞事情的。
在开发 MongoDB 的过程中，随着开发的深入，10gen 的人越来越觉得原来那个云计算平台是个虚无缥缈的东西。而这个他们一手缔造的文档数据库，可能是一个惊天动地的大杀器！虽然这些人其实不是数据库领域科班出身的，但他们对于数据库领域某些弊端的深刻理解，的确是一般人望尘莫及的。
于是他们决定彻底忘记那个云计算平台，集中精力开发这个被命名为“巨大无比的数据库”的产品。在漫长的开发过后，2009 年 2 月 10gen 正式开源了 MongoDB 的第一个版本。这对于 10gen 来说是一个非常重要的里程碑。
然而我们必须要说，这个产品尽管看起来很新颖很有意思，但并不是一个很成熟的产品。它有无数多的东西没实现，有无数多的坑等着人们去踩。但是这些都已经不重要了，踩着 NoSQL 的东风，MongoDB 开始飞起来了。
10gen 是一家特别注重宣传的公司，它在早期就对如何花钱做宣传非常有一套。他们的做法是在全球各地资助成立很多的用户组，并组织每年一次的 MongoDB 大会。MongoDB 还开起了 Mongo 大学。他们知道自己产品的用户都是开发人员，因此只要开发人员说好，尤其是各个地区那些在圈内有名的技术大牛说好，那么不管这个产品实际上好不好，完善不完善，炒起来的感觉起码很好。
先把大家都绑上 Mongo 的船，再慢慢地修理这艘船也是一种做法。俗话说“吃人的嘴短，拿人的手软”，那些在 10gen 支持下成长起来的用户组，那些 10gen 给报销机票和旅馆来做宣讲的大牛们，互利互惠地就借着 NoSQL 的东风把 MongoDB 给“吹”起来了。
10gen 的 CTO 在某次采访中就说，他觉得与其花费那么多钱去做各种各样的广告，不如把钱花在资助用户组，资助 MongoDB 的会议上。让大家感觉到 MongoDB 产品好，公司对社区的支持力度大，是 10gen 花广告费的最佳途径。
踏上 MongoDB“贼船”的公司很多，比如说卖车的 Edmunds、美国版的“五八同城”Craigslist，以及老牌网络企业——思科。但是这些都比不上当年非常优秀的社交初创公司独角兽 FourSquare 使用 MongoDB 的影响来的大。当然这家公司现在是过气了，但在社交网络最为火爆的时候，FourSquare 可是非常著名的。
在 MongoDB 刚出来的时候，FourSquare 整个地“搬家”去用 MongoDB，这曾是一件非常大的事情。这件事情当然被 10gen 公司大书特书地进行宣传。而 MongoDB 在独角兽里面被广泛使用这一事实，让 MongDB 是新时代的数据库、MongoDB 适合开发 APP，以及 MongoDB 适合创业公司使用等等的观点，都瞬间被“吹”了起来。
到 2012 年的时候，作为 10gen 公司创始人之一的梅里曼，其与人联合运营的科技博客 Business Insider 把 MongoDB 作为仅次于 HTML 的新时代最重要的技能宣传给大家。一时间仿佛只要 MongoDB 掌握好了，就能够有一碗饭吃。而很多在线教育网站也专门开起课来，给那些急于从其他职业转战 IT 的人普及 MongoDB 的用法。
我们必须说，这种宣传非常成功。大概是因为 MongoDB 的创业者在这之前已经成功创业一次，要知道 DoubleClick 在网络广告领域非常成功，而且被成功卖给了谷歌，所以这些人搞创业公司的套路，一点都不像那些毫无经验的初创公司创始人。他们非常懂得如何做才能够最大限度地吸引眼球，最大程度地把自己的产品铺出去。至于盈利与否，在初创阶段，并不是他们最需要关心的问题。无论从何种角度去看，这个做法都很成功。
除了在商业宣传上很成功，10gen 发布 MongoDB 以后，在产品的开发和维护上也采取了和其他公司很不一样的策略。这个策略对于 MongoDB 的流行同样功不可没。
简单一点来说，10gen 公司决定集中精力做最重要的几件事情：
吸引客户上 MongoDB 的船；
让 MongoDB 更好用；
对常用的编程语言，提供各种各样的库和接口的支持；
整个技术支持团队非常地友善，而且尽职尽责。
10gen 公司重点去做的这些事情，有很多值得我们深思的地方。如果要简单概括的话，就是 10gen 公司希望所有使用 MongoDB 的用户都觉得这个产品非常非常地好用。如果万一真的出了问题，也有很好的技术支持来及时地解决问题。
这种用户体验，绝对是开源社区中其他产品所不能达到的高度。举个简单的例子，要想自己去部署 Hadoop 的一个计算集群，那绝对是一件老难老难的事情了。如果这个东西容易部署，也就不会诞生一批以卖“更好用的 Hadoop”为生的公司了。再举个例子，Hive 的部署也同样不好用。
如果我们从企业级应用上来看，Oracle 就是一个非常典型的难用的产品。一个企业如果想要把 Oracle 用好了，请有经验的 DBA 是基本条件，很多时候都需要咨询公司来帮助设计解决方案。这种项目的落地绝非简简单单就能行的。而 SQL Server 作为一个后起之秀，在数据库市场获得成功的一个重要原因，并非性能有多好，而是“很好用”。当然，SQL Server 只是和 Oracle 比起来好用得多。
但是 MongoDB 就不一样了，10gen 公司的目标就是让 MongoDB 非常非常地好用。而且从这一点上说，他们做得非常成功。整个社区里无数的用户组在提供支持，10gen 自己的客服绝对是用户至上，有问必答，而且非常礼貌及时。整个 10gen 的开发重点，也是让用户更好上手。
所有的因素加起来，MongoDB 对于创业公司来说就变得很有意思了：这个产品很好上手，支持也很多，而且还免费。创业公司拿着这个轮子，可以迅速实现自己的业务逻辑，而不需要再去学习怎么搭东西。我想正是这个原因，突然之间就着 NoSQL 的春风，MongoDB 就开始流行起来了。
然而，接下来事情的发展，多少有些脱离美好的一面。MongoDB 从产品的角度来说，其实就是个半成品。MongoDB 实在有太多的东西没有做了，尤其是那些基本的东西，包括数据是不是会丢、结果是不是错的、并发做得好不好、支不支持事务处理，以及当规模上来的时候，能不能够通过加机器来解决问题。
这些看起来本应是一个数据库产品非常重要的、基本的东西，MongoDB 做得却很差。一般来说，当一个人开始用 MongoDB 的时候，并不会遇到这样的问题，当然主要还是规模不够大，不至于触发瓶颈和问题。当 APP 或者网站的规模上去之后，同时工作的人多了，问题就会越来越常见，越来越令人无法忍受。
而 10gen 的 CEO 在宣传时，又往往以极其夸大的方式，告诉大家 MongoDB 就是未来，MongoDB 就是一切。这样的结果就是：很多人用 MongoDB 去取代关系数据库。然而渐渐地，这些人发现这种取代并没有带来真正的好处，除了一开始开发省了点力气外，后面要维护的成本越来越高。
而 10gen 这种侧重于提高用户初始体验，外加一切都是 MongoDB 的宣传方式，终于导致了负面作用。有经验的程序员开始跳出来，在各种论坛里公开宣称千万别上 MongoDB 的“贼船”，因为虽然开船的时候容易，接下来要付出的代价也很大，一旦规模上来，各种丢数据的问题就都出来了。
10gen 的 CTO 经常亲自上阵去和这些程序员们 PK。他接受采访的时候说，MongoDB 是个新产品嘛，新产品总是会有这样那样的问题，请给我们一些时间。他在论坛上和这些程序员交流，通常来说跳不出这样一些套路，就是：
这个问题我们在下一版里会修好的；
这个问题我从来没有遇到过，估计是假的吧；
这个问题你给我们开 BUG 啊；
这个问题我不相信是真的，肯定是你们程序写错了。
不管你信不信，这种回复，加上 10gen 的公关能力，确实在很多时候给 MongoDB 赢得了修复问题的时间。但是这样的一种方式也让用户的接受度在降低。2009 到 2012 的三年里，MongoDB 被接受的比例一直处于飞升状态，而 2012 年开始这个曲线就越来越平。大家到底要不要用 MongoDB，已经不再是“无脑”上的问题，而是要反复斟酌之后再做决定的事情。
尽管 10gen 的 CEO 一直高调宣布 MongoDB 无所不能，大家赶紧上，实际上后面的几年里，很多人反而是渐渐地离开了 MongoDB。大家意识到，MongoDB 作为一个一开始上手很快的东西，可能只适合一个 V1 产品。产品上一点规模之后，背后的数据存储系统还是要换的。
当然，任何公司都有盈利的压力。MongoDB 作为一个开源、免费的产品，10gen 公司不可能免费赚吆喝，它烧在社区建设上的钱也不是小数目。10gen 推出盈利产品的第一步，是推出了对 MongoDB 的商业付费技术支持。
商业付费支持是很多公司常用的方式。比如说 Hadoop 平台公司的 Hortonworks，其收入就基本上依赖于其提供的商业付费技术支持。MongoDB 从这里开始赚第一笔钱，并且其技术支持以“态度好”而著称。
仅仅靠商业技术支持并不能为公司带来足够的收入，10gen 的另外一个创收途径是推出商业版的 MongoDB。和开源的 MongoDB 比起来，商业版的自然要带更多的功能。这些功能最主要的是一个加密的存储引擎——数据以企业级密码强度加密后再存储，以及额外的安全相关的功能，比如说 LDAP 和 Kerberos 的支持，等等。这方面倒是体现了企业级应用市场和开源小创业公司之间的差异：企业级应用市场对加密和安全相关的内容要重视得多，没有这些功能大企业是不会使用这些产品的。
在很长时间里，MongoDB 的企业版都是 10gen 公司最主要的收入来源。此外，10gen 也提供云上的托管服务，给那些不愿意自己管理数据库的人提供服务。MongoDB 的业务模式和赚钱模式都还是很清晰的，但是一个巨大的问题在突显：MongoDB 作为一个数据库，始终都不是一个成熟的产品，并因此给很多采用 MongoDB 的企业带来了一些出乎意料的东西。
2013 年的时候，10gen 公司觉得自己的名字已经不太符合现在的品牌效应了，于是正式更名为 MongoDB 公司，将产品名和公司名匹配起来。
尽管 MongoDB 的发展经历了很多曲折，它的产品在功能上、性能上有很多问题，乃至受到了某些程序员的公开抵制；尽管 MongoDB 的接受度自 2012 年以来开始大幅度降低，它在企业市场上却依然保持着一个非常可观的占有率。
今天，我详细讲了 10gen 在 MongoDB 的开发、推广、发展和营收上的策略。MongoDB 侧重于易用性和对社区的支持，对其他方面则有些忽视了。那么，倘若你在运营一家做工具类产品的初创公司，在技术发展上又会采取什么样的策略呢？
分享给需要的人，Ta购买本课程，你将得20元
生成海报并分享

赞 6

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
061 | Gabe Newell：Valve帝国制度的利弊
下一篇
063 | 文档数据库的缔造者MongoDB（下）
unpreview
 写留言

精选留言(14)

  • songyy
    2017-10-19
    想了一下 觉得先吸引人上船，把社区做起来，开源 吸引社区补全产品不足，也是个不算太差的解决方案。 另一种方式，我觉得可以像rails的起家：从一个成功的产品剥离出来，有现实的成功案例，同时文档写好，对新入的开发者足够友好，再考虑靠着它收咨询费的问题
    14
  • 蚂蚁内推+v
    2018-11-15
    我们公司今年也废弃 MongoDB ，继续用 MySQL 了
    8
  • 翼吹雪
    2018-05-28
    我觉得在一块成熟的市场（数据库发展几十年），切中快速爆发的移动互联网开发市场，提供更好用的解决方案，和Oracle错开竞争战场，最终获得巨大的口碑，可以说是一个完美的开局，也是初创公司非常值得借鉴的。 可惜在后来，没有将优势保持住，在企业版中将数据库一些基本的技术补上。这本来也是很考验创业者的一个地方，即在什么时候进行转型，既能迎合市场，又能进行盈利，而且自己团队还有能力达到，这个点很难把控。
    展开
    4
  • Panda
    2018-12-23
    听科技公司的发展故事 很有意思 哈哈哈
    4
  • caohuan
    2018-11-21
    再次聆听 飞哥的 MongoDB发展历程，发现 1.它 的存储 是面向 集合，集合中包含大量的文档，不像 关系型数据库 面向表格的形式 2.它的 查询 非基于SQL，而是基于 编程语言和API，都是 它比关系型数据库 让开发人员 能感觉到更友好的使用。 它的 运营 1）赞助MongoDB大会、活动、和MongoDB大学 2）提供良好的技术支持 3）与使用者沟通 4）与大牛合作，把更多数据库使用者 绑到MongoDB产品上。 回答 老师的问题，运营一家工具类的初创公司，应该 寻找 标杆企业 和 行业领头人，为自己背书，就像 文中所说，与大牛互利互惠 ，拉去更多的开发者，找 行业的标杆企业 合作，服务好它，再让企业帮做宣传，最后 从业者多，公司使用者多，二者相互促进，形成循环，做不强都难。
    展开
    3
  • 奥北北北北北北
    2019-04-29
    现在都是这样啊，房子还没修都已经卖完了
    2
  • Coding小先
    2019-11-20
    工具类的，首先要面向目标客户友好，简单易用。
  • 亚东
    2019-11-04
    要么不做，要做就要领先世界，并且高可用。
    1
  • 极客雷
    2019-11-02
    MongoDB创始人和Oracle创始人有很多共通之处
  • self-discipline
    2019-09-28
    作为产品来说核心功能应该过硬,规模到达一定量级后就暴露各种问题的话,没有哪个互联网公司敢用的.公司的宣传,服务支持尽职尽责,对社群的支持和赞助,都做的很到位.但是打铁还需自身硬的,没有好的打铁技术,其他的服务再到位,也有种本末倒置的感觉
  • 剑八
    2019-09-20
    核心价值是什么 用户是谁 竞品 壁垒 规划
  • 程
    2019-03-20
    作为一个工具类，不可能满足所有人的需求，但是应该正视自身的产品，给产品明确的定位，明晰产品的优缺点，不应一味吹嘘，忽悠所有人上船。尤其是提供企业级服务，不成熟就意味着隐患，爆发时的损失很难估量
  • 朴荷抹茶仔
    2019-03-05
    现在多数还是用sql来做关系表，工具类的新公司，刚开始想的是需要知道客户需求和竞争对手的长处和弊端，而这方面客户都能很好反馈。前期对市场的调查是必要的，先提供其他产品下载和评论获得咨询，后续发展推送自家产品
    1
  • caohuan
    2018-11-14
    本篇所得，推广一应用产品 包括工具类产品，1.先拉取大量客户 2.根据反馈，优化并让产品更好用 3.方便用户使用 4.技术支持 很友善，客服做到尽心尽责。 读完 飞哥的专栏，看出 MongoDB具有自己的特色，产品上 支持app 和海量数据的非sql文档型数据库，支持程序语言和API查询，开始使用时对技术人员很友善，在营销上 通过 1.资助用户 2.支持 MongoDB的各种会议，尽管 MongoDB还有很多需求未被实现，还有bug和坑需要修复和填补，不过 依然看好MongoDB。
    展开
    1