RethinkDB:​​为什么我们失败了

77050ed8bf7652ab7c488e8ec32a5ede.gif

本文转自公众号:

本文来自 rethinkDB 失败后的复盘,正是因为有点年代现在拿出来看更有意思,可以对复盘作个复盘,哪些分析和对未来 (也就是今天) 的判断不对,原文地址:https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html

当我们宣布[1]RethinkDB 将关闭时,我承诺会写一份事后分析。我花了一些时间来处理这段经历,现在我可以清楚地写出来了。

在HN 讨论[2]帖中,人们提出了 RethinkDB 失败的许多原因,从莫名其妙的人性和 MongoDB 营销人员的聪明诡计,到未能建立经验丰富的上市团队,再到缺乏超过 64- 的数字类型支持。我在这里[3]将这些评论汇总成一个建议的失败原因列表。

其中一些原因对他们来说有一定的道理,但它们是症状而不是原因。

事后看来,有两件事出了问题——我们选择了一个糟糕的市场,并针对错误的指标优化产品。每个错误都可能使 RethinkDB 的估值降低一到两个数量级。因此,如果其中任何一个都正确,RethinkDB 的规模就会与 MongoDB 一样大,如果我们两个都正确,我们最终可能会达到 Red Hat[1] 的规模。

糟糕的市场

我们的想法是这样的。新公司并没有建立在甲骨文之上,因此有机会建立一家新的基础设施公司。数据库市场巨大。如果我们开发的产品能够占领该市场的一部分,我们最终将建立一家非常成功的公司。

不幸的是,你不在你认为你所在的市场——你在你的用户认为你所在的市场。我们的用户清楚地认为我们是一家开源开发工具公司,因为这才是我们真正的目标。事实证明这是非常不幸的,因为开源开发人员工具市场是可能最糟糕的市场[4]之一。成千上万的人使用 RethinkDB,通常是在商业环境中,但大多数人愿意为使用期限支付的费用低于一杯星巴克咖啡的价格(也就是说,他们根本不愿意支付任何费用)。

这不是因为产品太好了,人们不需要为支持付费,也不是因为开发人员不控制预算,也不是因为资本主义的失败。答案是基本的微观经济学。开发人员喜欢构建开发人员工具,而且通常是免费的。因此,尽管需求量很大,但供应量却大大超过了它。推动[5]了替代品的数量增加,并将价格降至零

要了解这对其他公司有何影响,请考虑 MongoDB(价值约 1.6B 美元,拥有约 700 名员工)和 Docker(价值约 1B 美元,拥有约 300 名员工)。两家公司在各自的市场中完全占据主导地位。对于处于成长阶段的私营科技公司来说,两条非常粗略的经验法则是估值是年收入的 10 倍。这意味着 MongoDB 的年收入在 1.6 亿美元左右,Docker 的年收入在 1 亿美元左右。

这看起来相当不错,直到您看到市场上的非开发工具占主导地位的 B2B 技术公司。像 SalesForce、Palantir 或 Box(面临激烈竞争)这样的公司。突然之间,MongoDB 和 Docker 开始看起来很小。这些都是巨大的成功。

如果拥有现有合作伙伴关系、分销基础设施和大客户访问权限的相对成熟的公司在成长过程中遇到困难,这对于处于萌芽阶段的初创公司意味着什么?

对我们来说,这意味着一个棘手的客户获取渠道。如果在肥沃的 B2B 市场中的初创公司必须处理 100 条潜在客户才能获得 10 次销售机会,那么对于开发工具初创公司来说,这个数字会增加 10 倍。您可以接触到大量高质量的潜在客户——很多人正在下载您的产品并与您互动,但您必须通过大量可笑的线索才能收敛到一次销售。

这具有灾难性的多米诺骨牌效应。它使团队士气低落,使吸引投资和聘请顶尖人才变得非常具有挑战性。反过来,这会限制您的资源,因此您无法在产品和分销方面进行足够的投资。早期的分销挑战几乎总是注定你最终会死亡。

错误的善良指标

好的,所以市场很糟糕,但其他开发工具公司仍在销售大量产品。为什么不重新思考数据库?

虽然我们对市场动态无能为力,但产品决策完全在我们的控制范围内。我们想打造一款优雅、强大且美观的产品,因此我们针对以下指标进行了优化:

  • 正确性。 我们做出了非常严格的保证,并且 虔诚[6]地履行[7] 了它们。

  • 界面简洁。 我们承担了实现中的大部分复杂性,因此应用程序开发人员变得简单。

  • 一致性。 我们使从查询语言、客户端驱动程序、集群配置、文档到首页营销副本的所有内容尽可能保持一致。

事实证明,对大多数用户来说,正确性、界面简单性和一致性是错误的衡量标准。[8]大多数用户想要这三个权衡取舍:

  • 准时到达。 他们希望产品在需要时实际存在,而不是三年后。

  • 触手可及的速度。 人们希望 RethinkDB 能够快速处理他们实际尝试过的工作场景,而不是我们建议的“现实世界”中的场景。例如,他们会编写快速脚本来测量插入一万份文档而不读回它们需要多长时间。MongoDB 出色地掌握了这些场景,而我们则打了一场失败的教育市场之战。

  • 一个用例。 我们开始构建一个好的数据库系统,但是用户想要一个做 X 的好方法(例如从 hapi 存储 JSON 文档的好方法,存储和分析日志的好方法,创建报告的好方法等)

并不是说我们没有尝试快速发布,让 RethinkDB 快速,并围绕它构建生态系统以使有用的工作变得容易。我们做到了。但是正确、简单和一致的软件需要很长时间才能构建。这使我们落后于市场三年。

当我们觉得 RethinkDB 满足了我们的设计目标并且我们有足够的信心推荐它用于生产时,几乎每个人都在问“RethinkDB 与 MongoDB 有什么不同?” 我们努力解释为什么正确性、简单性和一致性很重要,但最终这些并不是大多数用户关心的好指标。

说实话,很痛。它伤害了很多。我们无法理解为什么人们会选择一个几乎不做它应该做的事情(存储数据)的系统,有一个大内核锁,随机抛出错误,实现单节点功能,尽管分片系统是产品的核心功能之一,但它几乎不能正常工作,基本上没有提供正确性保证,并且暴露了一个大杂烩,没有明显的一致性或视觉统一性。

每次 MongoDB 发布一个新版本并且人们祝贺他们做出改进时,我都会感到一阵怨恨。他们会宣布他们修复了 BKL,但实际上他们会将粒度级别从数据库降低到集合。他们会添加更多的操作,但不是一个适合系统其余部分的可组合界面,他们只是简单地使用一次性命令。他们会改进分片,但很明显他们不愿意或无法做出最基本的数据一致性保证。

但随着时间的推移,我学会了欣赏群众的智慧。当人们需要时, MongoDB 将普通开发人员变成了英雄,而不是事后几年。它使数据存储快速,让人们快速运送产品。随着时间的推移,MongoDB 成长了。他们一个接一个地解决了架构的问题,现在它是一个优秀的产品。它可能没有我们想要的那么漂亮,但它可以完成这项工作,而且做得很好。

当 2014 年年中我们无法竞争时,我们努力与 MongoDB 区分开来。我们找到了一种非常优雅的方式来添加 实时推送[9],希望能够让开发者构建出他们以前无法构建的一代应用程序。但这还不够。突然间,我们发现自己与 Meteor 和 Firebase 竞争,这些公司多年来一直致力于解决实时问题,甚至在我们想到之前。我们又一次落后于市场三年,我们又一次发现自己无法竞争。

云呢?

一些人建议我们应该构建一个云产品。实际上,我们确实有一个正在开发中,所以这是我想介绍的一个有趣的话题。

小型数据库公司构建云服务的一个明显问题是,它的模式与常见的启动失败模式相匹配——分裂焦点。构建、交付和运营可靠的多租户云服务非常困难。它需要不平凡的专业知识和资源,所以如果你走这条路,你会发现自己同时经营两家初创公司。但是我们面临着生存威胁并且很快就没有选择了,所以我们还是试了一下。让我们暂时假设我们可以完成它。

我们的推理是这样的。数据库云产品可能意味着以下三件事之一:托管、数据库即服务 (DBaaS) 或增值平台即服务 (PaaS)。让我们使用年收入为 20 万美元 / 员工的经验法则[10]快速回顾一下市场分析:


托管主机数据库即服务即服务
公司Compose.io,mLab动物数据库解析,Firebase,流星
雇员~30~30~30
收入< 1000 万美元< 1000 万美元< 1000 万美元

所以这些市场很小,甚至比数据库市场本身还要小。但他们中的一个会比其他人更好吗?

托管主机本质上是在 AWS 上为人们运行数据库,因此他们不必这样做。使用这些服务的替代方法是自己在 AWS 上设置数据库。这很痛苦,但实际上并没有那么难。因此,托管数据库托管服务的收费有一个非常严格的上限。考虑到 Compose.io 和 mLab 提供的 MongoDB 用户数量比 RethinkDB 多一到两个数量级,我们推断提供托管不会产生影响。

数据库即服务是托管托管的更复杂版本——DBaaS 产品完全从用户那里抽象节点管理。您只需运行查询,系统就会处理它们。您不知道引擎盖下运行了多少节点。这项业务非常具有挑战性——部分原因是 DBaaS 公司必须与巨头竞争(例如 DynamoDB 和 DocumentDB),部分原因是当有很多其他替代品和替代品时,客户非常不愿意将数据管理完全交给初创公司。

最后一个选择是建立一个增值平台即服务。我们认为这是一个很有前途的方向,因为我们在这里拥有巨大的技术优势。Firebase 和 Meteor 必须在 MongoDB 之上构建应用程序级实时逻辑,这从根本上限制了实时查询能力和大规模性能。另一方面,我们一直控制堆栈,因此我们可以提供 Firebase 和 Meteor 无法构建的显着优势。

因此,我们构建了Horizo[11]n 并开始研究 Horizon Cloud——一种供用户部署和扩展 RethinkDB/Horizon 应用程序的方式。用一个非常小的团队构建三个大型项目(RethinkDB、Horizon 和 Horizon Cloud)的挑战最终赶上了我们,我们在资金用完之前从未设法交付云产品。

根本问题

我们还可以进行更高级别的根本原因分析。为什么我们选择了一个糟糕的市场并针对错误的指标优化产品?

当我还是个小孩的时候,我想建立自己的收音机。我用胶合板做了一个盒子,在里面扔了一些金属垃圾,然后将盒子连接到电源线。我家里有关于电子产品的书籍,但我认为我不需要它们——我坚信我可以自己做。最终,我确实构建了一个可以工作的接收器,但我花了好几年才最终意识到我需要学习基本的电子学。

早期的 RethinkDB 有点像这样。我们对产品或市场没有直觉,所以我们会在没有真正了解我们在做什么的情况下完成建立公司的动作。更重要的是,我们有巨大的乐观偏见[12]。我们相信我们不受经济规律和经营企业规律的影响。

我们能做些什么来避免这些错误吗?就像我小时候可以制作一台可以工作的收音机一样。我们在不知不觉中无能,这种无能需要数年时间才能变得有意识。

一些人指出,如果我们建立了一支经验丰富的上市团队,我们会做得更好。这是 100% 正确的,但我们个人发展的时机与公司的需求不符。最初,我们不知道我们需要进入市场的专业知识,因此我们没有寻求将其纳入创始团队。等到我们建立了一个能很好地映射现实的心智模型时,我们发现自己缺乏现金,在一个充满有能力的竞争对手的困难市场中,以一个落后三年的产品,世界上最好的上市团队也救不了我们。

离别的思念

许多人对开发者工具市场有着非常强烈的感受。工程师喜欢构建开发人员工具,因此他们非常希望开发人员工具公司能够蓬勃发展。

我对完全否定市场犹豫不决——部分是因为我不想从单一的经验中概括,部分是因为我不喜欢说“它做不到”,部分是因为有很多例外。GitHub、MongoDB 和 Docker 建立了强大的公司。GitLab 和 Unity 似乎做得很好。

如果您确实打算建立一家开发工具公司,请谨慎行事。市场上充满了不错的选择。用户期望很高,价格很低。深入思考您为客户提供的价值。请记住——希望世界以某种方式成为现实并不会如此。

2009 年,我们在 YCombinator 演示日向投资者宣传 RethinkDB 的早期想法(我们还没有软件)。我们以一张幻灯片结束了演讲,其中包含三个要记住的关键点。

  • 选择一个大市场,但为特定用户构建。

  • 学会识别你缺少的才能,然后像地狱般努力让他们加入你的团队。

  • 虔诚地阅读 《经济学人》[13],它会让你更快更好。

引用链接

[1]

宣布: https://rethinkdb.com/blog/rethinkdb-shutdown/

[2]

HN 讨论: https://news.ycombinator.com/item?id=12649414

[3]

我在这里: https://gist.github.com/coffeemug/af8dcb6f653a7f9c31daedbbdaa3402c

[4]

最糟糕的市场: https://techcrunch.com/2014/02/13/please-dont-tell-me-you-want-to-be-the-next-red-hat/

[5]

推动: https://en.wikipedia.org/wiki/Porter's_five_forces_analysis

[6]

虔诚: https://aphyr.com/posts/330-jepsen-rethinkdb-2-2-3-reconfiguration

[7]

地履行: https://aphyr.com/posts/329-jepsen-rethinkdb-2-1-5

[8]

衡量标准。: http://www.artima.com/weblogs/viewpost.jsp?thread=24807

[9]

实时推送: https://rethinkdb.com/blog/1.16-release/

[10]

的经验法则: https://www.saastr.com/how-to-figure-out-your-competitors-revenues-in-about-70-seconds/

[11]

Horizo: http://horizon.io/

[12]

乐观偏见: https://doc.research-and-analytics.csfb.com/docView?document_id=1048541371&serialid=mofPYk1Y4WanTeErbeMtPx6ur0SCIcSlaZ7sKGPdQQU%3D

[13]

《经济学人》: http://www.economist.com/

a08f4e0d032fe9ac20bbf51cc193f13b.gif

40965a4fb4e3b97b004e5195b5bdaaa2.png

你可能还喜欢

点击下方图片即可阅读

864d2e0650663dfa9ad05d56685a7c0f.png

滑了个大稽,顶级开源项目的 5.4 万个 Star 一夜之间化为乌有!

cbc7cd1c87f4d6abeb8f37376b9a4830.gif

云原生是一种信仰 🤘

关注公众号

后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具,只需一条命令,连 ssh 都不需要!

6843f527edb28ba38503f22b9d2ce046.gif

26b01ae2a6d26d721b22ca457fcd41f0.gif

点击 "阅读原文" 获取更好的阅读体验!

发现朋友圈变“安静”了吗?

4b8e8291f15b5eb216dfe16bba28feeb.gif

RethinkDB 设计用来存储 JSON 文档的分布式数据库,可通过简单操作实现多机分布式存储。支持表的联合和分组查询。什么是RethinkDB?RethinkDB 是从头打造的第一个开源、可扩展的JSON数据库,用于搭建实时网页。全新的访问模型颠覆了传统的数据库结构:开发者只需告诉RethinkDB,实时连 续地将查询更新结果推送到应用就可以了,不用每次都去poll一遍。RethinkDB的实时推送结构为搭建可扩展实时应用节省了大量时间精力。除了为实时应用提供了全新的设计之外,RethinkDB 还提供了一种灵活的查询语言、直观的操作和监控API,安装学习起来也非常容易。你可以查看这篇 Advancing the realtime web 得到更多RethinkDB计划的技术细节。什么时候RethinkDB是一个好的选择?当你的应用很大程度上有赖于数据的实时反馈时,RethinkDB 就会成为一个很棒的选择。“查询-响应”式的数据库访问模型在web上的确很有用,它可以直接映射到HTTP的“请求-响应”。而现代应用则需要将数据直接实时地传送到客户端。能够最大化得益于RethinkDB实时推送架构的例子包括:协作网站和移动应用数据流分析应用多人在线游戏实时交易场所设备联机举个例子:在协作设计一个app的时候,其中一个用户改变了某个按钮的位置,服务器就必须在第一时间通知所有在完成同一项目的其他用户。网页浏览器 能够通过WebSockets和http持久连接来支持这一功能,但数据库系统要迎合实时需求仍然是一个大的工程难题。而RethinkDB作为第一个开 源、可扩展的数据库,就是特别为实时推送数据到应用而设计的。哪些人在用 RethinkDB?RethinkDB 的用户包括上百个科技创业公司、咨询工作室和世界五百强企业。这里是其中的一些:Jive Software 和 Mediafly 使用RethinkDB搭建强大的响应式网页和移动应用Pristine.io 和 Narrative Clip 使用RethinkDB搭建用于设备连接的云架构Platzi 和 Workshape.io 使用RethinkDB进行实时分析CMUNE 和 NodeCraft 使用RethinkDB构建大规模可扩展多人游戏RethinkDB 拥有超过十万开发者的活跃社区和上百个来自世界各地的代码贡献者。RethinkDB是基于现有技术的吗?高效实现实时推送架构需要重新设计绝大部分的数据库成分,包括查询执行引擎、分布式系统、超高速缓存子系统和存储引擎。因为架构影响到每一个数据库 组成部分,RethinkDB不得不从C 开始一步步写起来。RethinkDB 是由数据库专家组成的团队花了五年时间做出来的,还得到了来自世界各地上百个代码贡献者的帮助。RethinkDB和realtime sync不同在哪里?和Firebase, PubNub 或者Pusher 这类实时同步API相比,RethinkDB主要不同在以下三个方面:首先,实时同步API是云服务,而RethinkDB 是开源项目。RethinkDB也有云端,可以通过我们的合作伙伴 Compose.io 和 Amazon AWS获得。它还可以部署在你自己的架构中,没有任何限制。其次,同步实时API只局限于同步文档,而RethinkDB是一个有着更普遍应用范围的数据库系统。 在RethinkDB中你可以运行任意query,包括table joins, subqueries, geospatial queries, aggregation, 还有map-reduce。实时同步服务有更多查询功能上的限制。最后,实时同步API的设计是直接从浏览器访问。这使得基本的app能够快速地跑起来,然而一旦app扩展了,灵活性就会受到限制。 RethinkDB的设计是从应用服务器进行访问,这一点上更像是传统的数据库。可能会要多花一点设置代码,但拥有足够的灵活性去适应应用的成熟。RethinkDB和MongoDB又不同在哪里?RethinkDB所基于的架构和MongoDB非常不同。开发者只需告诉RethinkDB,实时连续地将查询更新结果推送到应用就可以了,不用 每次都去poll一遍。你同样可以在RethinkDB上用传统的“查询-响应”范式来书写应用。然后在你开始为app添加实时功能时再去订阅实时数据 流。举个例子,这是你让RethinkDB查询一个文件时的命令:r.table('users').get('coffeemug').run()然后这是你从RethinkDB订阅更新流时用到的语句,在任何时候文档发生了变化就会推送:r.table('users').get('coffeemug').changes().run()RethinkDB的实时架构可以和MongoDB的oplog相提并论,但前者提供了更高层次的抽象。RethinkDB的数据流与查询计算引擎无缝整合,并允许你订阅查询结果的变化,而不仅仅是把数据复制过来。这种架构大幅度地减少了搭建实时app所需的时间和精力。除了实时推送架构,RethinkDB 还有许多胜过 MongoDB的地方:一种高级的查询语言,能够支持table joins, subqueries 和大规模并行式分布计算。融合了查询语言的操作和监控API,大幅度降低了RethinkDB扩展的难度。简洁美观的UI 易于复制转发,拥有在线文档支持和查询语言建议。可以看看这篇 technical comparison of RethinkDB and MongoDB 里面的评论比较中立一些。想听听个人观点的,请看@coffeemug 的what makes RethinkDB different.什么时候RethinkDB是一个不好的选择?当你需要用到完整ACID支持或者更强大的架构实施,RethinkDB就不大好用了。在这种情况下你最好用一些传统的MySQL或者PostgreSQL数据库。如果你需要做深度、密集型计算分析的话,你最好用Hadoop或者类似于Verticaa的面向列的存储工具。在某些情况下RethinkDB会在一定程度上牺牲书写可用性(write availability)来保证数据一致性(data consistency)。如果高要求的书写可用性对你来讲很重要,那你也不要纠结了,像Riak这样的Dynamo式系统可能更适合你。想要更多地学习RethinkDB?阅读 ten-minute guide 开始学习RethinkDB。对于熟悉分布式系统的程序员可以直接阅读 architecture overview 。走捷径用 cookbook,你可以看到许多常用的 RethinkDB查询例子。 标签:分布式数据库
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值