🤼 🈳 👼🏼 该数据库着火了... 🔲 🈳 🧓🏽

让我告诉您一个技术故事。

许多年前，我正在开发一个内置了协作功能的应用程序。这是一个方便的实验堆栈，它充分利用了早期React和CouchDB的全部潜力。它通过JSON OT实时同步数据。它已在公司内部使用，但在其他领域具有广泛的适用性和潜力。

在尝试将该技术出售给潜在客户时，我们遇到了意外的障碍。在演示视频中，我们的技术看上去很棒并且运行良好，没问题。视频完全显示了它的工作原理，并且没有模仿任何内容。我们提出并编写了使用该程序的实际方案。

实际上，这成为问题。我们的演示完全按照其他所有人模拟其应用程序的方式工作。更具体地说，即使是大型媒体文件，信息也立即从A传输到B。登录后，每个用户都看到新条目。使用该应用程序，即使Internet连接在村庄中的某个地方中断，不同的用户也可以在完全相同的项目上进行协作。 After Effects中的任何剪裁产品视频都暗含了这一点。

即使每个人都知道“刷新”按钮的作用，但没人知道他们要求我们构建的Web应用程序通常受其自身的限制。而且，如果不再需要它们，那么用户体验将完全不同。基本上，他们注意到您可以通过向对话者留下笔记来“聊天”，因此他们想知道它与Slack有何不同。f！

日常同步设计

如果您已经有软件开发方面的经验，那么您应该动动神经，记住大多数人不能只看界面图片并弄清楚与界面进行交互时会做什么。更不用说程序本身内部发生了什么。知道会发生什么在很大程度上是知道什么不会发生，什么不应该发生的结果。这不仅需要软件的功能，而且还需要软件各个部分之间如何协调和相互沟通的思维模型。

一个典型的例子是用户在二十分钟内看到spinner.gif想知道工作何时最终结束。开发人员将了解该过程可能已冻结，并且gif永远不会从屏幕上消失。该动画模拟了工作的执行，但与工作状态无关。在这种情况下，一些技术人员喜欢睁大眼睛，对用户的困惑程度感到惊讶。但是，注意其中的哪一个指向旋转的时钟并说它们实际上是静止的吗？

这是实时价值的本质。如今，实时数据库仍很少使用，许多人对此表示怀疑。这些数据库大多数都倾向于NoSQL风格，这就是为什么它们通常使用基于Mongo的解决方案更好的原因。但是，对我来说，这意味着与CouchDB一起工作的舒适性，以及对设计结构的研究，不仅某些官僚能够填充数据。我想我会把时间花得更好。

但是这篇文章的真正主题是我今天使用的内容。不是出于选择，而是因为公司政策无动于衷。因此，我将为您提供两个紧密相关的Google实时数据库产品的完全诚实和公正的比较。

两者的名字都带有“火”这个词。我记得一件事。对我来说第二个是另一种火。我不急说他们的名字，因为一旦这样做，我们就面临着第一个大问题-名字。

第一个称为Firebase实时数据库，第二个称为Firebase Cloud Firestore。两者都是Google Firebase套件的产品。它们的API分别命名为firebase.database(…)和firebase.firestore(…)。

这是因为实时数据库只是Google在2014年购买它之前的原始Firebase。然后Google决定创建一个副本Firebase基于公司的大数据，并使用云将其命名为Firestore。希望您不要感到困惑。如果您感到困惑，请放心，我本人已将本文的这一部分重写了十次。

因为需要在Firebase问题中引用Firebase，在Firebase问题中引用Firestore，至少在几年前在Stack Overflow上可以理解。

如果获得了最差的软件产品命名奖，那么这种情况肯定会成为竞争者之一。这些名称之间的汉明距离很小，以至于即使是经验丰富的工程师也难以理解，尽管他们的手指在想另一个名称，但他们的手指正在键入一个名称。这些计划是失败的，是出于最好的意图而发明的；他们兑现了数据库将大火的预言。而且我不是在开玩笑。提出此命名方案的人引起了流血，汗水和眼泪。

止血的胜利

有人会认为Firestore是Firebase的下一代产品Firebase的替代品，但这是一个误解。保证Firestore不能替代Firebase。看起来好像有人从中切出了所有有趣的东西，其余的大部分以不同的方式混淆了。

但是，快速浏览这两种产品可能会造成混淆：它们似乎通过大多数相同的API甚至在相同的数据库会话中都在做相同的事情。差异是细微的，只有对大量文档进行仔细的比较研究才能发现差异。或者，当尝试将完全适合Firebase的代码移植到Firestore上时。即使这样，您仍会发现，尝试进行实时拖放时，数据库界面会立即亮起。再说一次，我不是在开玩笑。

从某种意义上说，Firebase客户端会缓冲更改并自动重试更新，因此优先级是最后一次写入，因此具有礼貌。但是，Firestore的限制是每个用户每秒每个用户每个文档1个写操作，并且此限制是由服务器施加的。使用它时，即使您只是尝试构建应用程序，您自己也必须找到解决它的方法并实现刷新率限制器。也就是说，Firestore是没有实时客户端的实时数据库，它使用API伪装成实时数据库。

这样，我们开始看到Firestore存在意义的最初迹象。我可能是错的，但我怀疑Google领导层中的某个高层人士在Firebase上买了东西后，才说：“不，天哪。这是无法接受的。只是不在我的领导下。”

他从会议厅出来，并宣称：

“一个大的JSON文档？没有。您将数据分成单独的文档，每个文档的大小不超过1 MB。”

看起来，这样的限制将无法在任何有合理动机的用户群中首次遇到。你知道的。例如，在工作中，我们有1500多个演示文稿，这是完全正常的。

有了这个限制，您将不得不接受这样一个事实，即数据库中的一个“文档”将不同于用户可以调用文档的任何对象。

“可以递归包含其他元素的数组的数组吗？没有。数组将只包含固定长度的对象或数字，这是上帝所希望的。”

因此，如果您希望将GeoJSON放在Firestore中，则会发现这是不可能的。不允许出现任何不一致的情况。我希望您喜欢JSON中的Base64和/或JSON。

通过HTTP，命令行工具或管理面板进行JSON导入和导出？没有。您将只能将数据导出和导入到Google Cloud Storage。因此，它似乎现在被称为。当我说“您”时，我仅指那些拥有项目所有者权力的人。其他所有人都可以去创建票。”

如您所见，FireBase数据模型很容易描述。它包含一个巨大的JSON文档，该文档将JSON密钥链接到URL路径。如果您HTTP PUT在/FireBase中编写以下内容：

{
  "hello": "world"
}

它将GET /hello返回"world"。它基本上可以完全按照您的期望工作。 FireBase对象的集合/my-collection/:id等效于{"my-collection": {...}}根目录下的JSON字典，其内容可在/my-collection以下位置找到：

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

如果每个插入物都有一个非冲突ID，这是正常的，这是系统中对此的标准解决方案。

换句话说，该数据库是100％JSON（*）兼容的，并且可以像CouchDB这样与HTTP一起很好地工作。但是大多数情况下，您是通过抽象Websocket，授权和订阅的实时API来使用它的。管理面板具有这两种功能，允许实时编辑和JSON导入/导出。如果在代码中坚持使用相同的代码，当您意识到补丁和差异JSON解决了90％的常规持久状态任务时，您会浪费大量的自定义代码，您会感到惊讶。

Firestore数据模型与JSON类似，但在某些关键方面与JSON不同。我已经提到了数组内部缺少数组。子集合模型是与包含的JSON文档分开的一流概念。由于没有开箱即用的序列化功能，因此需要专用的代码路径来获取和写入数据。要处理自己的集合，您需要编写自己的脚本和工具。管理面板仅允许您一次在一个字段中进行小的更改，并且没有导入/导出功能。

他们采用了实时的NoSQL数据库，并将其转换为具有自动联接和单独的非JSON列的慢速非SQL。具有GraftQL精神的东西。

热Java

如果要使Firestore变得更加可靠和可扩展，则具有讽刺意味的是，与开箱即用地选择FireBase相比，普通开发人员将获得较不可靠的解决方案。脾气暴躁的数据库管理员需要的软件需要如此高的工作水平和专家才能，以至于对于产品被认为不错的利基市场来说，这根本是不现实的。这类似于如果没有开发工具和播放器，HTML5 Canvas根本不能替代Flash。此外，Firestore陷入了对数据清洁度和无菌验证的追求，这根本不符合普通业务用户喜欢的工作方式：对他而言，一切都是可选的，因为一切都是最终的草稿。

FireBase的主要缺点是，甚至在大多数Web开发人员都不了解不变性之前，就已经提前几年创建了客户端。因此，FireBase假定您将要修改数据，因此不会利用用户提供的不变性。此外，它不会重复使用发送给用户的快照中的数据，这使得diff变得更加困难。对于大型文档，其可变的基于diff的事务处理机制根本不足。伙计们，我们已经有了WeakMapJavaScript。好舒服

通过根据需要调整数据的形状并且不使树木变得太大，可以解决此问题。但是我很好奇，如果开发人员开发出一个真正好的客户端API，它使用不变性并结合一些可靠的数据库设计建议，那么FireBase是否会更有趣。相反，他们似乎试图修复未损坏的问题，这使情况变得更糟。

我不知道创建Firestore的所有逻辑。对黑匣子内部产生的动机进行推理也很有趣。两个极为相似但无可比拟的数据库的并置很少见。好像有人在想：“ Firebase只是我们可以在Google Cloud中模仿的功能。”但尚未发现定义实际需求或创建满足所有这些需求的有用解决方案的概念。“让开发人员考虑一下。只需使UI变得漂亮即可...您可以添加更多火力吗？”

我了解有关数据结构的几件事。我可以清楚地看到“一棵大JSON树中的所有内容”的概念是一种尝试从数据库中抽象出任何大规模结构的想法。期望软件简单地处理任何可疑的数据结构分形是疯狂的。我什至无需想象一切都会变得多么糟糕，我进行了严格的代码审核，并看到了人们从未梦想过的东西。但是我也知道好的结构是什么样的，如何使用它们以及为什么应该做。我可以想象一个世界，在这个世界中，Firestore看起来很合乎逻辑，而创建它的人则认为他们做得很好。但是我们不生活在这个世界上。

从任何标准来看，在FireBase中对构建查询的支持都是糟糕的，实际上不存在。它肯定需要改进或至少需要修订。但是Firestore并没有更好，因为它仅限于在普通SQL中找到的相同一维索引。如果要查询人们对混乱数据执行的查询，则需要全文搜索，多个范围的过滤器以及任意用户定义的排序。经过仔细检查，普通SQL的功能本身就受到限制。而且，人们只能在生产环境中运行的SQL查询是快速查询。您将需要具有复杂数据结构的专业索引解决方案。对于其他所有内容，至少应该有一个递增的map-reduce或类似的东西。

如果您在Google文档中查找有关此问题的信息，那么希望您会指出诸如BigTable和BigQuery之类的方向。但是，所有这些决定都伴随着大量的公司销售术语，您很快就会回头开始寻找其他东西。

在实时数据库的情况下，您需要做的最后一件事是由人和为领导制定薪级表的人员制作的东西。

（*）这是个玩笑，没有100％JSON兼容性之类的东西。

该数据库着火了...

日常同步设计

止血的胜利

热Java

广告

More articles: