《黑历史：Mongo》：现由PostgreSQL驱动

Original 冯若航非法加冯

2024-09-04

前言

明天我会发一篇抨击 MongoDB 的文章，作为对其近期恶劣营销碰瓷 PostgreSQL 的回应。在那之前，我想先分享一篇在 2015 年时的精彩文章作为预热。

这篇文章最经典的一点在于，它是由 MongoDB 的合作伙伴发出的血泪控诉，MongoDB 对尝试在生态中做分析的伙伴不屑一顾，而是跑去拿了一个 PostgreSQL 作为自己的分析引擎忽悠用户，从而让合作伙伴彻底灰心丧气的故事。

本文原文链接：https://www.linkedin.com/pulse/mongodb-32-now-powered-postgresql-john-de-goes （双向被墙状态，你需要开无痕模式挂代理方能访问）

作者：John De Goes —— 挑战 Ziverge 的现状
发布日期: 2015年12月8日

本文所述观点仅为个人看法，不代表我雇主^[1]的立场或观点。

在将各种线索综合起来后，我感到极度震惊。若我的猜测属实，MongoDB^[2]可能正要犯下我认为是数据库公司历史上最大的错误。

我是一个开源分析工具^[3]的开发者，该工具支持连接至如 MongoDB 这类的 NoSQL 数据库，我每天都在努力推动这些新一代数据库供应商更加走向成功。

事实上，我不久前在 MongoDB Days Silicon Valley^[4] 上向一室之内的众人^[5]进行了演讲^[6]，阐述了采纳这种新型数据库的诸多益处。

因此当我意识到这一潜在的破坏性秘密时，我立即敲响了警钟。在 2015 年 11 月 12 日，我发送了一封邮件至 MongoDB 的首席产品经理 Asya Kamsky。

尽管措辞谦和，但我表达得十分明确：MongoDB 正在犯下一个巨大的错误，并应当在还有机会纠正前，重新考虑自身决策。

然而我没有再接收到 Asya 或其他任何人的回应。我曾成功劝说 MongoDB 改变策略^[7]，避免将错误的功能^[8]商业化的经历，这一次未能重演。

以下我如何从新闻稿、YouTube 视频以及散布在 Github 上的源代码中找到线索，以及我最终未能说服 MongoDB 改变方向的经过。

故事起始于 2015 年 6 月 1 日，在纽约市举行的年度 MongoWorld 大会上。

MongoWorld 2015

SlamData^[9] 是我新创办的分析初创公司，它赞助了 2015 年的 MongoWorld，因此我得到了一个难得的 VIP 派对门票，得以参加大会前夜的活动。

活动在 NASDAQ MarketWatch 举行，地点优雅，俯瞰时代广场。我穿着工装裤和初创公司的 T 恤，明显感觉自己穿得不合时宜。高级小吃和酒水随意畅饮，MongoDB 的管理团队也全员出动。

我与 MongoDB 的新任 CEO Dev ("Dave") Ittycheria 握了手，并对他未来的工作表示了几句鼓励。

今年早些时候，富达投资公司Fidelity Investments^[10] 将 MongoDB 的估值削减至 2013 年的一半（16 亿美元），将这个初创公司从“独角兽”降级为“驴子”。Dev 的任务就是证明 Fidelity 以及其他质疑者是错误的。

Dev 从 Max Schireson 手中接过了公司（Max 在 2014 年著名辞职^[11]），在任期间，Dev 组建了一个新的管理团队，对 MongoDB 整个公司产生了深远影响。

虽然我只与 Dev 交谈了几分钟，但他给我的感觉是聪明、友善的，而且非常渴望了解我公司正在做的事情。他递给我一张名片，并表示如果我有需要可以随时联系他。

接下来是 MongoDB 的 CTO 兼联合创始人 Eliot Horowitz。我与他握手，自我介绍，并用 30 秒钟介绍了我的初创公司。

当时，我觉得我的介绍一定很糟糕，因为 Eliot 对我说的每一句话似乎都不感兴趣。事实证明，Eliot 讨厌 SQL，把分析工具视为一种麻烦，所以不难理解我为什么让他感到无聊！

不过，Eliot 确实听到了“分析”这个词，并透露说第二天的大会上，MongoDB 将发布 3.2 版本的一些有趣的新消息。

我请求他透露更多细节，但不行，这些内容严格保密。我只能等到第二天，与全世界一同揭晓答案。

我将这个消息告诉了我的联合创始人 Jeff Carr，我们短暂地感到了一丝恐慌。对于我们这个由四个人组成、完全自筹资金的初创公司来说，最大的担忧是 MongoDB 会宣布推出自己的分析工具，这可能会影响我们融资的机会。

令人宽慰的是，第二天我们发现 MongoDB 的重大宣布并不是分析工具，而是一个名为 MongoDB BI Connector的解决方案，这是即将发布的 3.2 版本中的一个重要功能。

MongoDB 3.2 BI Connector

Eliot 得以宣布 BI 连接器的推出。尽管当天的公告众多，但他对这一连接器似乎不甚感兴趣，因此仅略加提及。

然而，详细信息很快通过一份官方新闻稿^[12]发布，其概括如下：

MongoDB 今日宣布推出一款全新的 BI 和数据可视化连接器，该连接器将 MongoDB 数据库与业界标准的商业智能（BI）及数据可视化工具相连。该连接器设计以兼容市场上所有符合 SQL 标准的数据分析工具，如 Tableau、SAP Business Objects、Qlik 以及 IBM Cognos Business Intelligence 等。目前该连接器处于预览阶段，预计将在 2015 年第四季度全面发布。

根据该新闻稿，BI 连接器将使全球任何 BI 软件都能与 MongoDB 数据库进行交互。

这则消息迅速在 Twitter 上[传播开来](https://twitter.com/search?f=tweets&vertical=default&q=mongodb bi connector&src=typd)，并引发了媒体广泛报道。TechCrunch^[13] 等多家媒体均转载了这一消息，每次报道都为人们提供了新的细节，甚至《财富》杂志还宣称该 BI 连接器实际上已在 MongoWorld 发布^[14]！

考虑到公告的性质，媒体的这种热烈反响似乎是合理的。

当世界碰撞

MongoDB 与许多其他 NoSQL 数据库一样，不存储关系型数据。它存储的是复杂的数据结构，这些结构是传统的关系型 BI 软件无法理解的。MongoDB 的战略副总裁 Kelly Stirman 对此进行了精辟的解释：

“这些被称为现代应用的软件之所以如此命名，是因为它们采用了不适用于传统数据库行列格式的复杂数据结构。”

一个能让全球任何 BI 软件在这些复杂数据结构上进行强力分析而且不损失分析精度的连接器，无疑是重大新闻。

MongoDB 是否真的做到了不可能的事？他们是否开发出了一种既能满足所有 NoSQL 分析需求^[15]，又能在扁平化、统一的数据上暴露关系语义，使传统 BI 软件能够处理的连接器？

几个月前，我曾与 MongoDB 的产品副总裁 Ron Avnur 交谈。Ron 表示，所有 MongoDB 的客户都在寻求分析功能，但公司尚未决定是自主开发还是寻找合作伙伴。

这意味着 MongoDB 可能在短短几个月内，从一无所有迅速转变为拥有神奇解决方案。

掀开内幕

发布会结束后，我和 Jeff 回到了我们赞助商的展位。Jeff 问了我一个显而易见的问题：“他们怎么能在短短几个月内，从无到有做出一个能兼容所有 BI 工具的 BI 连接器？！”

我仔细思考了这个问题。

BI 连接器需要解决的诸多问题中，有一个是如何在 MongoDB 上高效执行类似 SQL 的分析任务。凭借我在分析领域的深厚^[16]背景^[17]，我知道要在像 MongoDB 这样现代数据库上高效地执行通用分析是非常具有挑战性的。

这些数据库支持非常丰富的数据结构，并且它们的接口是为所谓的操作型用例设计的（而不是分析型用例）。能够利用操作型接口在丰富的数据结构上运行任意分析的技术，需要多年的开发。不是你能在两个月内搞定的事情。

于是我直觉性地回答了 Jeff：“他们没有开发新的 BI 连接器。这不可能。这里面肯定有其他问题！”

具体是什么问题，我并不清楚。但在握手和发名片的间隙，我做了一些调查。

Tableau 展示了他们的软件与 MongoDB BI 连接器配合使用的演示，这引起了我的好奇心。Tableau 在关系型数据库上的可视化分析领域设立了标准，而他们前瞻性的大数据团队一直在认真思考 NoSQL。

借助与 MongoDB 的关系，Tableau 发布了一份与 MongoWorld 发布会同步的新闻稿^[18]，我在他们的网站上找到了这篇新闻稿。

我仔细阅读了这篇新闻稿，想要了解一些新的细节。在深处，我发现了一个微弱的线索：

MongoDB 将很快宣布连接器的测试版，计划在今年晚些时候 MongoDB 3.2 版本发布时提供正式版。在 MongoDB 的测试期间，Tableau 将通过我们的 PostgreSQL 驱动程序在 Windows 和 Mac 上支持 MongoDB 连接器。

这些话给了我第一个线索：通过我们的 PostgreSQL 驱动程序。这至少意味着 MongoDB 的 BI 连接器将使用与 PostgreSQL 数据库相同的“语言”（wire protocol）。

这让我感到有些可疑：MongoDB 是否真的在重新实现整个 PostgreSQL 的通信协议，包括对数百个 PostgreSQL 函数的支持？

虽然可能，但这看起来极其不可能。

我转向 Github，寻找 MongoDB 可能借鉴的开源项目。由于会议的 WiFi 不稳定，我不得不通过手机热点，查找了几十个同时提到 PostgreSQL 和 MongoDB 的仓库。

最终，我找到了我要找的东西：mongoose_fdw^[19]，一个由 Asya Kamsky（当时我不认识她，但她的简介提到她为 MongoDB 工作）分叉的开源仓库。

这个仓库包含一个所谓的 Foreign Data Wrapper (FDW) for PostgreSQL 数据库。FDW 接口允许开发者插入其他数据源，以便 PostgreSQL 可以提取数据并在这些数据上执行 SQL（为使 BI 工具正常工作，NoSQL 数据必须被展平、填充空值，并做其他简化处理）。

“我想我知道是怎么回事了。” 我对 Jeff 说。“看起来，他们可能在原型中将数据展平，然后使用另一个数据库来执行由 BI 软件生成的 SQL 语句。”

“什么数据库？” 他马上问道。

“PostgreSQL。”

Jeff 哑口无言。他一句话也没说。但我能完全明白他在想什么，因为我也在想同样的事。

糟了。这对 MongoDB 来说是个坏消息。真的很糟糕。

PostgreSQL：MongoDB 终结者

PostgreSQL 是一个流行的开源关系型数据库。它的受欢迎程度如此之高，以至于目前在排名^[20]上几乎与 MongoDB 并驾齐驱。

这个数据库对 MongoDB 构成了激烈竞争，主要原因是它已经获得了 MongoDB 的一些功能，包括存储、验证、操作和索引 JSON 文档^[21]的能力。第三方软件甚至赋予了它^[22]横向扩展的能力（或者我该说，巨量扩展的能力）。

每隔一个月左右，就会有人写文章推荐使用 PostgreSQL 而不是 MongoDB。这些文章往往会迅速传播，飙升到 HackerNews 网站的热榜。以下是其中一些文章的链接：

•告别 MongoDB。迎接 PostgreSQL^[23]•Postgres 性能优于 MongoDB，并引领开发者新现实^[24]•MongoDB 已死。PostgreSQL 万岁 :)^[25]•你永远不应该使用 MongoDB 的理由^[26]•SQL vs NoSQL 决斗。Postgres vs Mongo^[27]•为什么我放弃了 MongoDB^[28]•为什么你永远永远永远不该使用 MongoDB^[29]•Postgres NoSQL 比 MongoDB 更好吗？^[30]•再见 MongoDB。你好 PostgreSQL^[31]

商业化 PostgreSQL 的最大公司是 EnterpriseDB^[32]（虽然还有很多其他公司，一些历史更悠久或同样活跃），它在官网上维护了一个大量的内容库^[33]，主张 PostgreSQL 是比 MongoDB 更好的 NoSQL 数据库。

无论你对这个观点有何看法，有一点是明确的：MongoDB 和 PostgreSQL 在开发者的认知中正进行着一场激烈而血腥的争夺战。

从原型到生产

任何有经验的工程师都会告诉你，原型不能直接用于生产环境。

即便 MongoDB 确实在使用 PostgreSQL 作为原型的 BI 连接器，也许某些聪明的 MongoDB 工程师正被关在某个房间里，努力开发一个独立的生产版本。

实际上，从 Tableau 的新闻稿措辞来看，依赖 PostgreSQL 驱动的情况可能只是暂时的：

在 MongoDB 的测试阶段，Tableau 将通过我们的 PostgreSQL 驱动程序，在 Windows 和 Mac 上支持 MongoDB 连接器。

我猜测，或许 MongoDB 3.2 版本发布时会带来真正的产品：一个能够暴露 MongoDB 所支持的丰富数据结构（而不是展平、填充空值和丢弃数据）、完全在数据库内执行所有查询，并且无需依赖竞争数据库的 BI 连接器。

七月，在 MongoWorld 结束一个多月后，我在一次商务旅行中顺道拜访了 MongoDB 在帕洛阿尔托的办公室。我所了解到的情况让我倍感鼓舞。

拜访 MongoDB

以帕洛阿尔托的标准来看，MongoDB 的办公室相当大。

之前几次去硅谷时，我看到过这家公司的招牌，但这是我第一次有机会进去看看。

就在前一周，我通过邮件与 Asya Kamsky 和 Ron Anvur 聊过天。我们讨论了我公司在 MongoDB 内部直接执行高级分析的开源工作^[34]。

由于我们恰巧同时在帕洛阿尔托，Asya 邀请我过去，一边吃着外卖披萨喝着办公室的汽水，一边聊聊。

刚聊了几分钟，我就能感觉到 Asya 非常聪明、技术过硬且注重细节——这些正是你希望在像 MongoDB 这样高度技术化产品的产品经理身上看到的特质。

我向 Asya 解释了我们公司正在做的事情，并帮助她在她的电脑上运行我们的开源软件，让她可以亲自试试。我们聊着聊着，自然而然地谈到了 MongoDB 的 BI 连接器市场，上面有很多产品（如 Simba、DataDirect、CData 等等）。

我们似乎都持有相同的观点：BI 软件需要具备理解更复杂数据的能力。另一种选择是简化数据以适应老旧 BI 软件的限制，但这意味着会丢失大量信息，从而失去解决 NoSQL 分析中关键问题^[35]的能力。

Asya 认为，MongoDB 的 BI 连接器应该能够暴露原生的 MongoDB 数据结构，比如数组，而不需要进行任何展平或转换。这种特性，我称之为同构数据模型，是通用 NoSQL 分析系统的关键需求之一，我在多篇文章^[36]中对此进行了深入讨论。

让我感到非常鼓舞的是，Asya 独立得出了相同的结论，这让我相信 MongoDB 已经充分理解了这个问题。我当时认为，MongoDB 的分析未来一片光明。

然而，不幸的是，我错得离谱。

MongoDB：为巨大的创意错误而生

在得知 MongoDB 走在正确的道路上之后，我对 BI 连接器放松了警惕，在接下来的几个月里没怎么关注它，虽然期间我和 Asya 以及 Ron 交换了几封电子邮件。

然而，到了九月份，我发现 MongoDB 的产品团队陷入了沉默。经过几周没有回复的电子邮件，我变得不安，开始自己四处查找线索。

我发现 Asya 分叉了一个名为 Multicorn^[37] 的项目，这个项目允许 Python 开发者为 PostgreSQL 编写 Foreign Data Wrappers（外部数据封装器）。

糟糕，我心想，MongoDB 又要故技重施了。

进一步挖掘后，我发现了所谓的“圣杯”：一个名为 yam_fdw^[38] （Yet Another MongoDB Foreign Data Wrapper）的新项目，这是一个基于 Multicorn 用 Python 编写的全新 FDW。

根据提交日志（用于追踪代码库的更改），该项目是在我与 Asya Kamsky 于七月份会面之后才开发的。换句话说，这已经是原型之后的开发工作了！

最后一根稻草让我确信 MongoDB 计划将 PostgreSQL 数据库作为其“BI 连接器”发布，是当有人转发给我一个 YouTube 视频^[39]，视频中 Asya 演示了该连接器。

视频中的措辞非常谨慎，省去了任何可能带来麻烦的信息，但视频最后总结道：

BI 连接器接收连接，并且可以使用与 Postgres 数据库相同的网络协议，因此如果你的报表工具可以通过 ODBC 连接，我们将提供一个 ODBC 驱动程序，您可以使用该驱动程序从您的工具连接到 BI 连接器。

此时，我毫无疑问地确认：即将随 MongoDB 3.2 一起发布的 BI 连接器实际上是伪装成 PostgreSQL 数据库的产物！

很可能，将 MongoDB 数据吸入 PostgreSQL 的实际逻辑是我之前发现的基于 Python 的 Multicorn 封装器的强化版。

到这个时候，MongoDB 的任何人都没有回复我的邮件，这对任何理智的人来说，应该已经足够让他们放弃了。

然而，我决定再尝试一次，机会是在 12 月 2 日的 MongoDB Days 会议上，那时距离 3.2 发布只有一周时间。

Eliot Horowitz 将发表主题演讲，Asya Kamsky 将会发言，Ron Avnur 可能也会出席。甚至 Dev 自己也可能会来。

那将是我说服 MongoDB 放弃 BI 连接器把戏的最佳机会。

MongoDB Days 2015，硅谷

感谢 MongoDB 出色的市场团队，再加上我在西雅图 MongoDB 巡回演讲中类似演讲的成功经验，我在 MongoDB Days 会议上获得了 45 分钟的演讲时间。

我在会议上的官方任务是做一场关于 MongoDB 驱动的分析的演讲，并让用户了解我们公司开发的开源软件。

但我的个人议程却截然不同：在 3.2 版本即将发布前，说服 MongoDB 放弃 BI 连接器。如果这个宏大的目标（很可能是妄想）无法实现，我至少想确认自己对该连接器的怀疑。

在会议当天，我特意向 MongoDB 的老朋友和新面孔打招呼。尽管我可能不同意某些产品决策，但公司里还是有很多出色的人，他们只是努力在做好自己的工作。

几天前我刚刚生病，但大量的咖啡让我（大部分时间）保持清醒。随着时间的推移，我在圣何塞会议中心长长的走廊里反复练习了几次演讲。

下午时分，我已经准备就绪，并在满员的会场上做了我的演讲^[40]。让我兴奋的是，有这么多人对MongoDB 上的视觉分析^[41]这一深奥的主题感兴趣（显然这个领域正在发展壮大）。

在与一些与会者握手并交换名片后，我开始寻找 MongoDB 的管理团队。

我首先遇到了 Eliot Horowitz，就在他即将开始主题演讲前几分钟。我们聊了聊孩子和美食，我还告诉他我公司的一些近况。

主题演讲在下午 5:10 准时开始。Eliot 先谈到了一些 3.0 版本的功能，因为显然很多公司仍停留在旧版本上。随后，他快速介绍了 MongoDB 3.2 的各种新功能。

我当时在想，Eliot 会说些什么关于 BI 连接器的内容呢？他会提到它吗？

结果发现，BI 连接器是主题演讲的一个重要内容，不仅有专门的介绍环节，甚至还进行了一场精彩的演示。

BI Connector

Eliot 大声宣布：“MongoDB 没有原生的分析工具”，由此引出了 BI 连接器。

我觉得这有点儿好笑，因为我曾为 MongoDB 写过一篇题为 Native Analytics for MongoDB with SlamData^[42] 的客座文章。（编辑注：MongoDB 已经撤下了这篇博客，但截至山地时间15:30，它仍然在搜索索引中仍在搜索索引中^[43]）。SlamData 也是 MongoDB 的合作伙伴，并赞助了 MongoDB Days 大会。

在介绍 BI 连接器的用途时，Eliot 似乎有些磕磕绊绊（从...可操作的洞察中获取操作？麻烦的分析！）。当他把演示交给 Asya Kamsky 时，似乎松了一口气，后者为活动准备了一个不错的演示。

在演示过程中，我发现 Asya 表现得比平时紧张。她斟词酌句，省略了关于连接器是什么的所有细节，只提到了它如何工作的无罪部分（比如它依赖 DRDL 来定义 MongoDB 的 schema）。大部分演示内容并没有集中在 BI 连接器上，而是更多地展示了 Tableau（当然，Tableau 的演示效果确实很好！）。

我所有的反馈都没能减缓 BI 连接器的进展。

全力以赴

主题演讲结束后，大批与会者前往隔壁房间参加鸡尾酒会。与会者大多在与其他与会者交谈，而 MongoDB 的员工则倾向于聚在一起。

我看到 Ron Avnur 与服务器工程副总裁 Dan Pasette 聊天，距离他们几英尺远的地方，正为与会者提供 Lagunitas IPA 的啤酒。

现在是行动的时候了。3.2 版本即将发布，几天之内就会面世。MongoDB 的人都不再回复邮件。Eliot 刚刚告诉全世界 MongoDB 没有原生的分析工具，并将 BI 连接器定位为 NoSQL 分析的革命性工具。

没有什么可失去的了，我走到 Ron 面前，加入了他们的对话，然后开始了一段大约两分钟的激烈独白，猛烈抨击 BI 连接器。

我告诉他，我对 MongoDB 的期望不仅仅是把 PostgreSQL 数据库伪装成 MongoDB 分析的神奇解决方案。我告诉他，MongoDB 应该表现出诚信和领导力，推出一个支持 MongoDB 丰富数据结构的解决方案，将所有计算都推送到数据库中，并且不依赖于竞争对手的数据库。

Ron 被震住了。他开始用模糊的语言为 BI 连接器的“下推”（pushdown）辩护，我意识到这是确认我怀疑的机会。

“Postgres 外部数据封装器几乎不支持下推”，我不动声色地说道。“这在你用于 BI 连接器的 Multicorn 封装器中更是如此，这个封装器基于较旧的 Postgres 版本，甚至不支持 Postgres FDW 的完整下推功能。”

Ron 承认失败。“这是事实”，他说。

我逼他为这个决定辩护。但他无言以对。我告诉他，在 MongoDB 发布“BI 连接器”之前，立即拉下停止绳。Ron 对这个可能性不以为然，我告诉他，这件事会彻底让他难堪。“你可能是对的，”他说，“但我现在有更大的事情要担心，”可能指的是即将发布的 3.2 版本。

我们三个人一起喝了杯啤酒。我指着 Dan 说，“这家伙的团队开发了一个真正能够进行分析的数据库。你们为什么不在 BI 连接器中使用它？”但这没有用，Ron 不为所动。

我们分道扬镳，同意彼此保留不同意见。

我从房间另一头看到了 Dev Ittycheria，走过去和他聊了几句。我称赞了市场部的工作，然后开始批评产品。我告诉 Dev，“在我看来，产品团队正在犯一些错误。”他想了解更多，所以我告诉了他我的看法，我已经重复了很多次，以至于我都能倒背如流了。他让我发邮件跟进，当然我发了，但再也没收到回复。

与 Dev 交谈后，我终于意识到我无法改变 MongoDB 3.2 的发布进程。它将与 BI 连接器一起发布，而我对此无能为力。

我很失望，但同时也感觉到一阵巨大的解脱。我已经和我能接触到的每个人都谈过了。我已经全力以赴。我已经竭尽全力。

当我离开鸡尾酒会，回到酒店时，不禁猜测公司为什么会做出我如此强烈反对的决定。

MongoDB：孤家寡人，孤岛一座

经过深思熟虑，我现在认为 MongoDB 做出糟糕产品决策的原因在于无法专注于核心数据库。而这种无法专注的原因，则在于其未能培育出一个 NoSQL 生态系统。

关系型数据库之所以能占据主导地位，部分原因在于围绕这些数据库发展的庞大生态系统。

这个生态系统催生了备份、复制、分析、报告、安全、治理以及许多其他类别的应用程序。它们相互依赖，并促进彼此的成功，形成了网络效应和高转换成本，这些都对当今的 NoSQL 厂商构成了挑战。

与之形成鲜明对比的是，MongoDB 周围几乎没有生态系统，而且不仅我一个人注意到了这一点注意到这一点^[44]。

为什么 MongoDB 没有生态系统？

我带有讽刺意味的回答是，如果你是一个为 MongoDB 提供原生分析的合作伙伴，MongoDB 的 CTO 会站在舞台上说，没有工具可以为 MongoDB 提供原生分析。

然而，更客观地说，我认为上述现象只是一个表象。真正的问题是 MongoDB 的合作伙伴计划完全失效了。

MongoDB 的合作伙伴团队直接向首席营收官（Carlos Delatorre）汇报工作，这意味着合作伙伴团队的主要任务是从合作伙伴那里获取收入。这种设置本质上会让合作伙伴活动偏向那些没有兴趣推动 NoSQL 生态系统发展的大型公司（事实上，其中许多公司还在生产与 MongoDB 竞争的关系型解决方案）。

这与 SlamData、Datos IO 等小型、以 NoSQL 为中心的公司形成鲜明对比。这些公司之所以能够成功，正是因为 NoSQL 的成功，它们提供了关系型数据库世界中标准的功能，而 NoSQL 数据库需要这些功能才能在企业级环境中蓬勃发展。

作为合作伙伴已经超过一年，我可以告诉你，几乎没有人知道 SlamData 的存在，尽管 SlamData 是企业选择 MongoDB 而不是其他 NoSQL 数据库（例如 MarkLogic）的一个强大动因，也是那些考虑从关系型技术（例如 Oracle）转向 MongoDB 的公司转型的推动者。

尽管合作伙伴们在努力，但 MongoDB 似乎对由 NoSQL 为中心的合作伙伴所带来的联合收入和销售机会完全不感兴趣。没有转售协议、没有收入分享、没有销售简介、没有联合营销，只有一个 Logo。

这意味着在组织上，MongoDB 忽视了那些可能对他们最有帮助的 NoSQL 为中心的合作伙伴。同时，他们的最大客户和潜在客户不断要求提供在关系型世界中常见的基础设施，比如备份、复制、监控、分析、数据可视化、报告、数据治理、查询分析等。

这些来自大公司源源不断的需求，结合未能培养出生态系统的无力，形成了一种有毒的组合。它导致 MongoDB 产品团队试图通过构建所有可能的产品来创造自己的生态系统！

备份？有。复制？有。监控？有。BI 连接性？有。数据发现？有。可视化分析？有。

但一个有限资源的 NoSQL 数据库供应商不可能围绕自己建立一个生态系统，去与围绕关系型技术的庞大生态系统竞争（代价太高了！）。因此，这导致了像 MongoDB Compass 这样的分散注意力的项目，以及像 BI 连接器这样的“伪”技术。

替代方案是什么？在我看来，非常简单。

首先，MongoDB 应该培育一个充满活力的、由风险投资支持的 NoSQL 为中心的合作伙伴生态系统（而不是拥有雄厚资金的关系型合作伙伴！）。这些合作伙伴应该在各自的领域内具有深厚的专业知识，并且它们都应该在 MongoDB 成功的情况下成功。

MongoDB 的销售代表和客户经理应该掌握由合作伙伴提供的信息，这些信息可以帮助他们克服异议并减少客户流失，而 MongoDB 应该将其构建为一个健康的收入来源。

其次，在通过 NoSQL 为中心的合作伙伴满足了客户对相关基础设施的需求之后，MongoDB 应该将产品和销售重点放在核心数据库上，这才是数据库供应商应当赚钱的方式！

MongoDB 应该开发对企业有重要价值的功能（例如 ACID 事务、NVRAM 存储引擎、列式存储引擎、跨数据中心复制等），并仔细划定社区版和企业版之间的界限。所有这一切都应该以一种方式进行，使开发者在不同版本中拥有相同的能力。

目标应该是让 MongoDB 从数据库中获得足够的收入，以至于产品团队不会再受到诱惑去发明一个劣质的生态系统。

你可以自己判断，但我认为哪个是更有可能成功的战略已经非常明显了。

再见了，MongoDB！

显然，我无法支持这样的产品决策——推出一个竞争性的关系型数据库，作为在像 MongoDB 这样后关系型数据库上进行分析的最终解决方案。

在我看来，这个决定对社区不利，对客户不利，对新兴的 NoSQL 分析领域也不利。

此外，如果这种做法没有 完全透明，它对诚信也是有害的，而诚信是 所有公司 的基石（尤其是开源公司）。

所以，通过这篇文章，我正式放弃。

不再给 MongoDB 发狂热的邮件。不再在 MongoDB 的鸡尾酒会上缠着管理层。不再与一个连邮件都不回的公司私下分享我的意见。

这条路我走过了，做过了，但没有效果。

显然，我现在要揭发这个事实。当你读到这篇文章时，全世界都将知道 MongoDB 3.2 BI 连接器实际上就是 PostgreSQL 数据库，附带一些拼接数据的工具，把一些数据丢弃，然后把剩下的部分吸入 PostgreSQL。

这对那些正在评估 MongoDB 的公司意味着什么？

这取决于你们自己，但就我个人而言，如果你在寻找一个 NoSQL 数据库，同时需要传统的 BI 连接性，并且也在考虑 PostgreSQL，那么你可能应该直接选择 PostgreSQL。

毕竟，MongoDB 对 MongoDB 上的分析问题的 自己答案 就是将数据从 MongoDB 中导出，扁平化，然后倒入 PostgreSQL。如果你的数据最终会变成在 PostgreSQL 中的扁平化关系数据，那为什么不直接从那里开始呢？一石二鸟！

至少你可以指望 PostgreSQL 社区在 NoSQL 领域的创新，他们已经这么做很多年了。社区绝不会将 MongoDB 数据库打包成一个假的“PostgreSQL NoSQL”产品，然后称其为 NoSQL 数据库技术的革命。

而遗憾的是，这恰恰就是 MongoDB 反其道而行之的做法。

这张“Shame”的照片由 Grey World^[45] 拍摄，版权归 Grey World 所有，并根据 CC By 2.0^[46] 许可发布。

References

[1] 雇主: http://slamdata.com/
[2] MongoDB: http://mongodb.com/
[3] 开源分析工具: http://github.com/slamdata/slamdata
[4] MongoDB Days Silicon Valley: https://www.mongodb.com/events/mongodb-days-siliconvalley
[5] 一室之内的众人: https://twitter.com/slamdata/status/672166743255592960
[6] 演讲: http://www.slideshare.net/jdegoes/slamdata-how-mongodb-is-powering-a-revolution-in-visual-analytics
[7] 改变策略: https://www.mongodb.com/blog/post/revisiting-usdlookup
[8] 错误的功能: http://slamdata.com/blog/2015/10/21/mongodb-missing-join.html
[9] SlamData: http://slamdata.com/
[10] Fidelity Investments: http://fortune.com/2015/11/12/fidelity-marks-down-tech-unicorns/
[11] 著名辞职: http://maxschireson.com/2014/08/05/1137/
[12] 官方新闻稿: https://www.mongodb.com/press/opens-modern-application-data-to-new-generation-visual-analysis-and-traditional-bi-tools
[13] TechCrunch: http://techcrunch.com/2015/06/02/new-mongodb-connector-creates-direct-connection-to-data-visualization-tools/
[14] 发布: http://fortune.com/2015/06/03/couchbase-mongodb-embrace-sql/
[15] NoSQL 分析需求: http://slamdata.com/whitepapers/characteristics-of-nosql-analytics-systems/
[16] 深厚: http://github.com/quasar-analytics/
[17] 背景: http://github.com/precog
[18] 新闻稿: http://www.tableau.com/about/blog/2015/6/tableau-mongodb-visual-analytics-json-speed-thought-39557
[19] mongoose_fdw: https://github.com/asya999/mongoose_fdw/commits/master
[20] 排名: http://db-engines.com/en/ranking
[21] JSON 文档: https://en.wikipedia.org/wiki/JSON
[22] 赋予了它: https://www.citusdata.com/
[23] 告别 MongoDB。迎接 PostgreSQL: http://developer.olery.com/blog/goodbye-mongodb-hello-postgresql/
[24] Postgres 性能优于 MongoDB，并引领开发者新现实: http://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality
[25] MongoDB 已死。PostgreSQL 万岁 :): https://github.com/errbit/errbit/issues/614
[26] 你永远不应该使用 MongoDB 的理由: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
[27] SQL vs NoSQL 决斗。Postgres vs Mongo: https://www.airpair.com/postgresql/posts/sql-vs-nosql-ko-postgres-vs-mongo
[28] 为什么我放弃了 MongoDB: http://svs.io/post/31724990463/why-i-migrated-away-from-mongodb
[29] 为什么你永远永远永远不该使用 MongoDB: http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/
[30] Postgres NoSQL 比 MongoDB 更好吗？: http://www.aptuz.com/blog/is-postgres-nosql-database-better-than-mongodb/
[31] 再见 MongoDB。你好 PostgreSQL: https://www.userlike.com/en/blog/2015/10/09/bye-by-mysql-and-mongodb-guten-tag-postgresql
[32] EnterpriseDB: http://enterprisedb.com/
[33] 大量的内容库: http://www.enterprisedb.com/nosql-for-enterprise
[34] 开源工作: http://quasar-analytics.org/
[35] 关键问题: http://slamdata.com/whitepapers/characteristics-of-nosql-analytics-systems/
[36] 多篇文章: http://www.infoworld.com/article/2983953/nosql/how-to-choose-a-nosql-analytics-system.html
[37] Multicorn: https://github.com/asya999/Multicorn
[38] yam_fdw: https://github.com/asya999/yam_fdw
[39] YouTube 视频: https://www.youtube.com/watch?v=0kwopDp0bmg
[40] 我的演讲: http://www.slideshare.net/jdegoes/slamdata-how-mongodb-is-powering-a-revolution-in-visual-analytics
[41] MongoDB 上的视觉分析: http://www.slideshare.net/jdegoes/slamdata-how-mongodb-is-powering-a-revolution-in-visual-analytics
[42] Native Analytics for MongoDB with SlamData: https://www.mongodb.com/blog/post/native-sql-analytics-mongodb-slamdata
[43] 仍在搜索索引中: https://www.mongodb.com/blog?utf8=✓&search=slamdata#
[44] 注意到这一点: http://slamdata.com/blog/2014/12/09/where-is-the-nosql-ecosystem.html
[45] Grey World: https://www.flickr.com/photos/greyworld/
[46] CC By 2.0: https://creativecommons.org/licenses/by/2.0/