吃瓜看RethinkDB公司倒闭？——回思技术人的产品开发与开源
Author：zhoulujun Date：
7个牛人花了7年中的前5年多终于把一个牛逼但是暂时没有卵用的功能做稳定了，然后最后一年在赶那些不牛逼很无聊但是实用必须的功能——rethink花了很大气力塞到存储层，写个todolist确实很惊艳，却也没有解决realtime pivoting，transactional consistent等诸多real time streaming的实际问题。剩下的跟其他db比较不过你有我也有的就更没什么明显优势了。即使 feed诱人，不过毕竟用户还是会更关心db的功能，毕竟是要一个 db 而不是 mq。
rethinkdb和mongo db技术上的对比，我认为从设计上rethinkdb是优越于mongodb很多的：
如果时光倒流，如果从一开始先甘于做一个更好的mongodb，有了一定的市场以后再做牛逼的功能，可能结局不是这样。
只能说：向工程妥协的时候，我们就胜利。向教条主义坚持的时候，我们就失败！
链接：https://www.zhihu.com/question/51345388/answer/125704664
几年前，部门要收购一个小小的、不知名的但对公司有用的文档数据库小公司，在领导感召下，对比mongodb和rethinkdb这两个，好知己知彼。因此接触对比了这两个产品做了一下内部评估。我后来得到结论：mongodb如mysql，rethinkdb如postgresql。今天回头看，公司结局也证明了这点。
利益不相关，但开篇明确，两者都用过但都没有在生产环境用过，只内部评估的用过。必须对比谈这两家，因为其中关系很显然：mongodb赢得了竞争。
rethinkdb代码规整，团队懂行，文档齐备，交流顺畅。他们会很直接的告诉你：我们还不支持blah blah blah，然后很多人说这是必须的功能! 他们去赶工，做出某某功能，如此往复很多年，到了今天。回头看，mvcc，join，sharding, read/write strong consistency, reconfiguration, live backup都有，UI admin工具也方便。但还是走到了今天。
这几年同样加功能做开发，感觉rethinkdb一直在追，不比mongo差，但活在人家阴影下，很苦很累。当年看的时候，不支持secondary index，有mvcc但没有live backup。后来还得知primary死掉以后要人工干预，这个被人诟病的问题到一年前才解决。看最近的报道，老本行分布方面，动态membership变更解决的更晚，这几个月的事情，但总的来讲重大问题很少听到。
说mongodb如mysql再合适不过，那么多当年最初的简化设计甚至设计错误，一个个变成了性能优势，那个叫mysql的故事重演一遍而已。mongodb和rethinkdb的性能差异网上能看到的太多了，但3年前测mongodb，他的可靠性是玩具级，太容易脑裂大规模丢数据。其它各种丢数据方法一大堆，当年用mongo的公司真的是为行业吃了螃蟹。别的匪夷所思的事情还有比如你要三台额外的机器做config server去玩sharding，replica复制系统bug可以整个把你的数据删掉。还有那个著名的fire and forget写操作，居然也是功能非bug，匪夷所思。
同样问题一堆，但人家有大嘴CTO，死的说成活的，否认几乎所有质疑，态度及其恶劣，基本态度就是“你遇到了问题，只要在我们的issue tracker里没有记录，这个问题就不存在”。最有意思的，丢数据都是“环境因素”（原话environmental issue）。但network partition 处理有错丢了写数据，那么多业界报告，怪network发生了partition？甩锅能力一项，rethinkdb惨败给mongodb。
结果呢？大嘴好，甩锅重要，脸皮厚关键啊，mongodb更容易聚合到资源 - github上，比如mongodb用60%的star汇聚了两倍的contributor。整个社群生态比较好，早年没有mvcc，但有第三方的，到后来我们评估的时候，各种衍生工具项目一大堆了，成规模了。
这就是互联网，这就是产业，mysql和postgresql的故事会一遍遍重演，RethinkDB和mongodb就是我们今天看到的这一编。回到本题，rethinkdb最终公司关门了。那么多年，mongodb当然也改变，当然也懂行，不要去考虑究竟是技术还是运作，或者说情怀加大嘴，不要去看任何一个点，rethinkdb的今天肯定是mongodb整体阴影下的一个结果。
题外话，mongodb如mysql，rethinkdb如postgresql，那我们最后买进的那个不知名小公司像啥？sqlite，别笑哈，便宜啊。但我们1年多大改了一番，用它成功存储了人类所有某一类型的文件（大嘴很重要哈），10种应用以上支持了公司几十亿美元一年的生意，学到无数实际的干货。 :)
我们查看 rethinkDB失败后的复盘：https://zhuanlan.zhihu.com/p/500572982
RethinkDB：为什么我们失败了
当我们宣布RethinkDB
将关闭时，我承诺会写一份事后分析。我花了一些时间来处理这段经历，现在我可以清楚地写出来了。
在HN 讨论帖中，人们提出了 RethinkDB 失败的许多原因，从莫名其妙的人性和 MongoDB 营销人员的聪明诡计，到未能建立经验丰富的上市团队，再到缺乏超过 64- 的数字类型支持。我在这里将这些评论汇总成一个建议的失败原因列表。
其中一些原因对他们来说有一定的道理，但它们是症状而不是原因。
事后看来，有两件事出了问题——我们选择了一个糟糕的市场，并针对错误的指标优化产品。每个错误都可能使 RethinkDB 的估值降低一到两个数量级。因此，如果其中任何一个都正确，RethinkDB 的规模就会与 MongoDB 一样大，如果我们两个都正确，我们最终可能会达到 Red Hat[1] 的规模。
糟糕的市场
我们的想法是这样的。新公司并没有建立在甲骨文之上，因此有机会建立一家新的基础设施公司。数据库市场巨大。如果我们开发的产品能够占领该市场的一部分，我们最终将建立一家非常成功的公司。
不幸的是，你不在你认为你所在的市场
你在你的用户认为你所在的市场。我们的用户清楚地认为我们是一家开源开发工具公司，因为这才是我们真正的目标。事实证明这是非常不幸的，因为开源开发人员工具市场是可能最糟糕的市场之一。成千上万的人使用 RethinkDB，通常是在商业环境中，但大多数人愿意为使用期限支付的费用低于一杯星巴克咖啡的价格（也就是说，他们根本不愿意支付任何费用）。
这不是因为产品太好了，人们不需要为支持付费，也不是因为开发人员不控制预算，也不是因为资本主义的失败。答案是基本的微观经济学。开发人员喜欢构建开发人员工具，而且通常是免费的。因此，尽管需求量很大，但供应量却大大超过了它。这推动了替代品的数量增加，并将价格降至零。
要了解这对其他公司有何影响，请考虑 MongoDB（价值约 1.6B 美元，拥有约 700 名员工）和 Docker（价值约 1B 美元，拥有约 300 名员工）。两家公司在各自的市场中完全占据主导地位。对于处于成长阶段的私营科技公司来说，两条非常粗略的经验法则是估值是年收入的 10 倍。这意味着MongoDB的年收入在1.6亿美元左右，Docker的年收入在1亿美元左右。
这看起来相当不错，直到您看到市场上的非开发工具占主导地位的 B2B 技术公司。像 SalesForce、Palantir 或 Box（面临激烈竞争）这样的公司。突然之间，MongoDB 和 Docker 开始看起来很小。这些都是巨大的成功。
如果拥有现有合作伙伴关系、分销基础设施和大客户访问权限的相对成熟的公司在成长过程中遇到困难，这对于处于萌芽阶段的初创公司意味着什么？
对我们来说，这意味着一个棘手的客户获取渠道。如果在肥沃的 B2B 市场中的初创公司必须处理 100 条潜在客户才能获得 10 次销售机会，那么对于开发工具初创公司来说，这个数字会增加 10 倍。您可以接触到大量高质量的潜在客户——很多人正在下载您的产品并与您互动，但您必须通过大量可笑的线索才能收敛到一次销售。
这具有灾难性的多米诺骨牌效应。它使团队士气低落，使吸引投资和聘请顶尖人才变得非常具有挑战性。反过来，这会限制您的资源，因此您无法在产品和分销方面进行足够的投资。早期的分销挑战几乎总是注定你最终会死亡。
错误的善良指标
好的，所以市场很糟糕，但其他开发工具公司仍在销售大量产品。为什么不重新思考数据库？
虽然我们对市场动态无能为力，但产品决策完全在我们的控制范围内。我们想打造一款优雅、强大且美观的产品，因此我们针对以下指标进行了优化：
正确性。我们做出了非常严格的保证，并且 虔诚地履行了它们。
界面简洁。我们承担了实现中的大部分复杂性，因此应用程序开发人员变得简单。
一致性。我们使从查询语言、客户端驱动程序、集群配置、文档到首页营销副本的所有内容尽可能保持一致。
事实证明，对大多数用户来说，正确性、界面简单性和一致性是错误的衡量标准。大多数用户想要这三个权衡取舍：
准时到达。他们希望产品在需要时实际存在，而不是三年后。
触手可及的速度。人们希望 RethinkDB 能够快速处理他们实际尝试过的工作场景，而不是我们建议的“现实世界”中的场景。例如，他们会编写快速脚本来测量插入一万份文档而不读回它们需要多长时间。MongoDB 出色地掌握了这些场景，而我们则打了一场失败的教育市场之战。
一个用例。我们开始构建一个好的数据库系统，但是用户想要一个做 X的好方法（例如从 hapi 存储 JSON 文档的好方法，存储和分析日志的好方法，创建报告的好方法等）
并不是说我们没有尝试快速发布，让 RethinkDB 快速，并围绕它构建生态系统以使有用的工作变得容易。我们做到了。但是正确、简单和一致的软件需要很长时间才能构建。这使我们落后于市场三年。
当我们觉得 RethinkDB 满足了我们的设计目标并且我们有足够的信心推荐它用于生产时，几乎每个人都在问“RethinkDB 与 MongoDB 有什么不同？” 我们努力解释为什么正确性、简单性和一致性很重要，但最终这些并不是大多数用户关心的好指标。
说实话，很痛。它伤害了很多。我们无法理解为什么人们会选择一个几乎不做它应该做的事情（存储数据）的系统，有一个大内核锁，随机抛出错误，实现单节点功能，尽管分片系统是产品的核心功能之一，但它几乎不能正常工作，基本上没有提供正确性保证，并且暴露了一个大杂烩，没有明显的一致性或视觉统一性。
每次 MongoDB 发布一个新版本并且人们祝贺他们做出改进时，我都会感到一阵怨恨。他们会宣布他们修复了 BKL，但实际上他们会将粒度级别从数据库降低到集合。他们会添加更多的操作，但不是一个适合系统其余部分的可组合界面，他们只是简单地使用一次性命令。他们会改进分片，但很明显他们不愿意或无法做出最基本的数据一致性保证。
但随着时间的推移，我学会了欣赏群众的智慧。当人们需要时， MongoDB 将普通开发人员变成了英雄，而不是事后几年。它使数据存储快速，让人们快速运送产品。随着时间的推移，MongoDB 成长了。他们一个接一个地解决了架构的问题，现在它是一个优秀的产品。它可能没有我们想要的那么漂亮，但它可以完成这项工作，而且做得很好。
当 2014 年年中我们无法竞争时，我们努力与 MongoDB 区分开来。我们找到了一种非常优雅的方式来添加 实时推送，希望能够让开发者构建出他们以前无法构建的一代应用程序。但这还不够。突然间，我们发现自己与 Meteor 和 Firebase 竞争，这些公司多年来一直致力于解决实时问题，甚至在我们想到之前。我们又一次落后于市场三年，我们又一次发现自己无法竞争。
云呢？
一些人建议我们应该构建一个云产品。实际上，我们确实有一个正在开发中，所以这是我想介绍的一个有趣的话题。
小型数据库公司构建云服务的一个明显问题是，它的模式与常见的启动失败模式相匹配——分裂焦点。构建、交付和运营可靠的多租户云服务非常困难。它需要不平凡的专业知识和资源，所以如果你走这条路，你会发现自己同时经营两家初创公司。但是我们面临着生存威胁并且很快就没有选择了，所以我们还是试了一下。让我们暂时假设我们可以完成它。
我们的推理是这样的。数据库云产品可能意味着以下三件事之一：托管、数据库即服务 (DBaaS) 或增值平台即服务 (PaaS)。让我们使用年收入为 20 万美元/员工的经验法则快速回顾一下市场分析：
托管主机本质上是在 AWS 上为人们运行数据库，因此他们不必这样做。使用这些服务的替代方法是自己在 AWS 上设置数据库。这很痛苦，但实际上并没有那么难。因此，托管数据库托管服务的收费有一个非常严格的上限。考虑到 Compose.io 和 mLab 提供的 MongoDB 用户数量比 RethinkDB 多一到两个数量级，我们推断提供托管不会产生影响。
数据库即服务是托管托管的更复杂版本——DBaaS 产品完全从用户那里抽象节点管理。您只需运行查询，系统就会处理它们。您不知道引擎盖下运行了多少节点。这项业务非常具有挑战性——部分原因是 DBaaS 公司必须与巨头竞争（例如 DynamoDB 和 DocumentDB），部分原因是当有很多其他替代品和替代品时，客户非常不愿意将数据管理完全交给初创公司。
最后一个选择是建立一个增值平台即服务。我们认为这是一个很有前途的方向，因为我们在这里拥有巨大的技术优势。Firebase 和 Meteor 必须在 MongoDB 之上构建应用程序级实时逻辑，这从根本上限制了实时查询能力和大规模性能。另一方面，我们一直控制堆栈，因此我们可以提供 Firebase 和 Meteor 无法构建的显着优势。
因此，我们构建了Horizon 并开始研究 Horizon Cloud——一种供用户部署和扩展 RethinkDB/Horizon 应用程序的方式。用一个非常小的团队构建三个大型项目（RethinkDB、Horizon 和 Horizon Cloud）的挑战最终赶上了我们，我们在资金用完之前从未设法交付云产品。
根本问题
我们还可以进行更高级别的根本原因分析。为什么我们选择了一个糟糕的市场并针对错误的指标优化产品？
当我还是个小孩的时候，我想建立自己的收音机。我用胶合板做了一个盒子，在里面扔了一些金属垃圾，然后将盒子连接到电源线。我家里有关于电子产品的书籍，但我认为我不需要它们——我坚信我可以自己做。最终，我确实构建了一个可以工作的接收器，但我花了好几年才最终意识到我需要学习基本的电子学。
早期的 RethinkDB 有点像这样。我们对产品或市场没有直觉，所以我们会在没有真正了解我们在做什么的情况下完成建立公司的动作。更重要的是，我们有巨大的乐观偏见。我们相信我们不受经济规律和经营企业规律的影响。
我们能做些什么来避免这些错误吗？就像我小时候可以制作一台可以工作的收音机一样。我们在不知不觉中无能，这种无能需要数年时间才能变得有意识。
一些人指出，如果我们建立了一支经验丰富的上市团队，我们会做得更好。这是 100% 正确的，但我们个人发展的时机与公司的需求不符。最初，我们不知道我们需要进入市场的专业知识，因此我们没有寻求将其纳入创始团队。等到我们建立了一个能很好地映射现实的心智模型时，我们发现自己缺乏现金，在一个充满有能力的竞争对手的困难市场中，以一个落后三年的产品，世界上最好的上市团队也救不了我们。
离别的思念
许多人对开发者工具市场有着非常强烈的感受。工程师喜欢构建开发人员工具，因此他们非常希望开发人员工具公司能够蓬勃发展。
我对完全否定市场犹豫不决——部分是因为我不想从单一的经验中概括，部分是因为我不喜欢说“它做不到”，部分是因为有很多例外。GitHub、MongoDB 和 Docker 建立了强大的公司。GitLab 和 Unity 似乎做得很好。
如果您确实打算建立一家开发工具公司，请谨慎行事。市场上充满了不错的选择。用户期望很高，价格很低。深入思考您为客户提供的价值。请记住——希望世界以某种方式成为现实并不会如此。
2009 年，我们在 YCombinator 演示日向投资者宣传 RethinkDB 的早期想法（我们还没有软件）。我们以一张幻灯片结束了演讲，其中包含三个要记住的关键点。
选择一个大市场，但为特定用户构建。
学会识别你缺少的才能，然后像地狱般努力让他们加入你的团队。
虔诚地阅读《经济学人》 。它会让你更快更好。 sealos 以kubernetes为内核的云操作系统发行版，让云原生简单普及
laf 写代码像写博客一样简单，什么docker kubernetes统统不关心，我只关心写业务！
转载本站文章《吃瓜看RethinkDB公司倒闭？——回思技术人的产品开发与开源》,
请注明出处：https://www.zhoulujun.cn/html/DB/NotOnlySQL/8983.html