Firestore 功能受限，那么... 2022 年的完美数据库是什么？

Firestore

公平地说，我实际上指的只是 Firestore，而不是 Firebase 平台。好吧，Firestore 并没有死。它很受欢迎。但它应该死了。它应该死，原因我在一年前的帖子里就提到过。团队花了14 个月的时间，为 Firebase 构建了所有可能的 SDK、插件和监控插件。这包括备受争议的 Firebase 9 界面（虽然我很喜欢“更快”这个词）。

但您知道什么还没有更新吗...一点也没有？

消防店！！！

• 如果不编写不考虑当前数据的容易出错的 firebase 函数，我们仍然无法进行任何类型的基本聚合。
• 我们仍然无法进行基本的全文搜索。谷歌……🤨
• 最重要的是，我们仍然无法统计搜索结果。当然，我们可以通过增加一个随机表值来创建自动集合计数（呸！）。试试在一个集合中索引所有可能的 where 子句。

这不可能，马蒂！

我为大多数用例创建了后端解决方案和前端解决方案。我花了几个小时编写后端包，但最近我更喜欢前端解决方案。

我为什么喜欢 Firestore

Firestore 开发起来超级简单。我喜欢它云托管的特性。我不喜欢被供应商锁定。我喜欢它拥有最易用的 JavaScript 客户端 API。我喜欢 Firestore 规则可以保护这些功能。我喜欢它只需添加订阅功能即可轻松获取实时数据。我喜欢 Firestore 可以根据少量或大量用户自动扩展。我不喜欢管理第二个数据库，也不喜欢它缺乏增长能力。

完美的数据库

我想要一个完美的数据库。它具有以下功能：

• 可扩展
• 关系（SQL 或图形）
• 实时数据支持
• JS/TS 客户端 API（或 GraphQL）
• 中间件安全
• 云托管 DbaaS 选项
• 无供应商锁定
• 具有登录方法的 ACL

我一直在研究完美的数据库，但它目前还不存在……不过，有一些选项已经很接近了，也有一些未来的发展前景值得关注。

noSQL

NoSQL 数据库通常非常擅长扩展。你知道它们不擅长什么吗？其他方面……Firestore 建议你使用 Algolia 来添加搜索功能。除了 Google 产品需要你使用非 Google 产品才能正常运行这一显而易见的问题之外，你还需要将数据存储在一个 NoSQL 数据库中，并且为了搜索功能还需要管理另一个 NoSQL 数据库。啊？这说不通，但这就是我们生活的世界。

MongoDB 通过聚合数据来模拟连接操作。然而，你实际上无法进行连接操作。Firestore 只会说，嘿，你自己写代码吧，处理聚合操作可能会有问题。哦，对了，这还有限制！所以，我不能直接在帖子中复制 1,000,000 个用户资料，因为函数会超时。是啊，你必须打破常规，找到一种更复杂、连接更多、更复杂的方法。哦，我有没有提到粉丝动态的问题？如果你关注我的帖子有一段时间了，你就会知道我有很多理论，说除了理论之外，这根本无法实现……至少在用户和粉丝集合方面都无法扩展。我关于这个主题已经有 10 篇帖子了。这是最新的一篇。现在，尝试聚合数据，保持更新，并在以后为随着 Firestore 或 Mongodb 增长的现有数据添加功能。试试用普通的 Redis 吧。😂

所有数据都是关系型的。你根本无法仅使用 NoSQL 数据库来创建现实的可扩展数据库解决方案……除非……

图形数据库建立在 noSQL 数据库之上。

noSQL 数据库作为主流数据库的地位应该消亡。MongoDB，我非常赞赏你的尝试……这里的关键词是“尝试”。

你好，我可爱又非凡的...图形数据库🥰...有一个问题...

人们对图数据库存在着巨大的误解。我曾与一位在 Twitter 工作的计算机博士交谈过，他不明白为什么有人会在不查询分析数据的情况下使用图数据库。

伙计，我有个好消息要告诉你。所有数据都是关系型的！图形比 SQL 更能关联数据。图形数据库比 SQL 更好。

过去，图形数据库确实不具备可扩展性。现在，情况已不再如此。过去，图形数据库比 SQL 慢。现在，情况也不再如此。

每个数据库都可以很棒，这取决于底层架构。一个优秀的数据库可以通过分布式数据实现扩展，使用分片技术，或许还有多租户技术，甚至可以自动部署以适应增长……所有这些都是自动化的。我们无需启动第二个数据库就能拥有所有需要的功能。这通常就是问题所在。

图数据库正在不断发展。实际上有两种经典类型：三元组存储和属性图。三元组存储通常存储 RDF（SPARQL 使用的主谓谓关系），而属性图则包含边和节点。尽管有些文章声称它们都可以实现无索引邻接。这才是图数据库未来发展的真正关键。

记忆位置

想象一下多对多 SQL 表中的外键。在进行连接时，我们经常需要一个连接表（MS 数据透视表）。我们将一个表连接到另一个表，只是为了获取我们想要的实际表的值。我们只需要两次连接就能关联两部分数据。这就是图形数据库令人惊叹的真正原因。我们将要跳转的直接位置存储在内存中，然后我们就可以到达那里。我们不会在中间停留。关系数据在图形数据库中实际上是关系型的。

n + 1

SQL 中也存在n+1 问题。如果我查询连接表，那么我查询的次数就比实际需要的次数多 n + 1。SQLSELECT语句WHERE也要求你查询比实际需要的次数多的次数。这基本上就是过度获取和不足获取。

当然，如果你非常擅长 SQL 查询，并且使用高级 JSON 查询技术，理论上这两个问题都可以解决。然而，大多数情况下，图数据库的速度更快。图数据库就是为这种糟糕的情况而设计的。尝试查询多个深度嵌套的数据对象。如果你不知道什么是嵌套数据对象，那是因为你不懂如何用图来思考。

图形数据库的真正问题......

图形数据库的真正问题不在于它只适用于图形数据。所有数据都是图形数据！

真正的问题和 Svelte 的问题一样……成熟度。大多数图数据库并不具备开发 Web 应用所需的所有功能，例如约束、策略、触发器、全文搜索和安全性。事实上，这个列表非常非常短。

图数据库的定义也在不断发展。最初有图数据库，后来有基于 NoSQL 或其他键值存储构建的图数据库，再后来有基于 SQL（agensgraph）构建的图数据库，现在又有了混合型图数据库，它们在底层使用多个数据库。现在的重点不再是边和节点，因为节点本身也可以用作边。重点在于通过直接存储内存位置而不是另一个中间表的位置来节省速度。重点在于查询。

那么阵容中都有哪些数据库呢？

继续吧！

为了与 Firestore 竞争，你必须拥有预先编写且可定制的中间件。我只会列出拥有这些功能的数据库。在 Firebase 中，这些中间件是客户端 JavaScript API 加上 Firestore 的安全规则。

1. Supabase

Supabase 是迄今为止 Firestore 的头号竞争对手。当然，它也是 Firebase 的竞争对手，因为它具有存储空间和登录方法，但它真正是 Firestore 的竞争对手，因为它具有类似于 Firebase 的客户端安全接口。它使用起来非常简单和可爱。您可能会喜欢无模式数据库的灵活性，但关系的权衡是令人难以置信的。它在后台使用 PostgreSQL。PostgreSQL 处理大量数据的速度更快，而 mySQL 处理较小数据集的速度更快。它现在甚至支持安全订阅。您必须习惯使用策略和约束，但坦率地说，Supabase 让编写这些成为一种乐趣。他们还在研究GraphQL 层，理论上它可以自动处理 n+1 问题。有一个小小的警告。PostgreSQL 虽然是为大型数据集而设计的，但并不适用于可扩展数据。当然，你可以通过增加计算能力进行垂直扩展，但你无法通过增加更多计算机/虚拟计算机（轻松地）进行水平扩展。也许有一天它们会支持这一点，但这并不容易。而 mySQL可以。

2.动物区系

Fauna 真的太酷了。我承认我还没用它构建过任何东西。它就像那种奇特的混合体。你可以将数据存储在键值存储中，但像图数据库一样进行查询。FQL客户端 API类似于 Firebase 9，需要在函数中导入大量函数。为了安全起见，你会使用内部数据库技术，比如 Supabase。我认为 Fauna 最大的两个问题是：1）供应商锁定 2）学习曲线——创建链接等操作似乎不像图数据库或 SQL 数据库那么简单。

3.哈苏拉

Hasura 为您提供了几种可供构建的 SQL 数据库选择，但专注于 postgres。它还拥有现有的最先进的 GraphQL 引擎，尽管它仍然缺少一些必需的功能。您需要将 Hasura 与 Firebase Auth、auth0 或其他登录系统结合使用，但从技术上讲，中间件已经存在。它遭遇与 DGraph 相同的可扩展问题和功能问题。您还可以使用NHost.io自动设置具有内置登录系统和文件存储的数据库实例。我还没有用 Hasura 构建任何复杂的东西，但我读到过关于缺少嵌套更新等功能的信息。我认为一旦你达到复杂的程度，仅靠 GraphQL 是不够的。老实说，没有 GraphQL 能做到这一点……目前还没有。

荣誉奖

4. Dgraph

Dgraph 被蚕食、被抛弃、被扼杀、被重生，现在又分裂了。一个月前，即使我很喜欢 Dgraph，我也不会列出它。他们基本上拿到了一些风险投资，花掉了这笔钱，解雇了一半的员工，开始产生不错的回报，然后就分裂了。一方得到了创始人和程序员，并分叉了开源部分（现在的 Outcaste），另一方得到了董事会、风险投资以及付费云用户。说实话，一年后，它们的产品会截然不同。我个人花了很多时间与两位 CEO 沟通，向他们汇报我的想法，以及我从用户社区收集到的反馈意见。最近有一个非官方的 Discord 论坛，用户超过 300 人。你会发现两个社区和管理人员都很活跃。我不在乎选边站，我只是相信原产品的潜力。目前也有人在积极讨论第二次分叉。 Dgraph 专注于用 GO 编写的 GraphQL，以实现极致速度，在 GraphQL 方面可以说比 Hasura 好，也可以说是差。我想说，Hasura、Prisma 和 Dgraph 都在争夺最佳 GraphQL 的头衔。我编写了j-dgraph包，使其像 Firebase 一样工作，通过 JS 方法自动查询 GraphQL。Dgraph 满足了我所有的要求，我相信一年后，其中一个版本（甚至两个版本）会在这个榜单上占据第一甚至第二的位置。这款产品在各个方面都非常棒，所以请关注我的更新。

5. Neo4j
Neo4j 是众所周知的“最流行”的图数据库。他们过于关注分析用户，而忽略了 Firebase 用户。他们通过 cypher、数学函数和触发器实现了高级查询功能。虽然他们有一些基本的约束，但没有策略。不过，你可以使用触发器自己编写。Neo4j 真的是一个庞然大物，它与 SQL 数据库的竞争比你想象的还要激烈。然而，他们错失了良机。他们提供了一个云平台，但却要求你托管自己的 GraphQL。他们可以简化这个过程。他们还没有开发订阅功能，尽管人们一直要求这样做。它支持海量数据，但不像 DGraph 那样支持分片。我听说 DGraph 用户因为 Neo4j 无法支持大型数据集而放弃了它。因此，企业版可以扩展以实现高可用性，所以它算是具备一定的扩展性。完全披露：我没有测试过这些，也绝不是专家。

6. Planetscale与Prisma
这实际上是两种不同的产品。实际上，您可以选择任何云托管的 mySQL 数据库并将 Prisma 插件添加到其中，但Fireship 的开发者在 Twitter 上提到了 Planetscale（而且他们在谷歌广告上投入了大量资金），所以我怀疑他们是合法的。我需要花更多时间研究一下。从技术上讲，Prisma 需要一些设置。Prisma 本身位于 GraphQL 的顶层，也像 Firebase 一样拥有自己的 API，但没有像纯 GraphQL 和 URQL 或 Apollo 那样的前端缓存。Prisma 具有订阅功能。这或许应该是您的最佳选择……待定。

崭露头角

7. EdgeDB

Edge 数据库看起来棒极了。它本质上是将 SQL 和图数据库重写在一起，创建了一种颇具新意的编程语言。它解决了 GraphQL 的所有问题，而且似乎是独立构建的，但构建在 Postgres 之上。它确实独特、美观且功能强大。目前他们还没有安全层或云托管环境，但都在开发中。然而，Postgres 仍然存在众所周知的可扩展性问题。如果你喜欢唯一抓取和强类型，也可以看看TypeDB。由于没有云版本、中间件等，它没有进入榜单。不过，它值得一试。

8. 8base

8base 的 UI 或许是最漂亮的。它基于 mySQL，因此无服务器且可扩展。它使用 GraphQL，因此有中间件。除了功能之外，它其他方面都满足。GraphQL 足够用了。它不是最好的，也不是最差的。它需要嵌套过滤器、嵌套更新等等。我很快会用它创建一个应用程序，这样就能真正测试它的功能了。还有一个名为Grafbase的程序可以生成 GraphQL API，但我还不确定它目前的表现如何……

谁赢了？

没人。所有选项都缺少点什么。我目前正在使用 Supabase 构建，因为它太简单了，他们还因为我之前的文章☝送了我一件 T 恤。我喜欢 DGraph，会继续更新它和 Outserv（Outcaste 的产品）。我认为 mySQL 是综合性能最好的数据库。noSQL 扩展性很好，但不是关系型数据库。混合数据库建立在其他数据库之上，或者被赋予了像 newSQL 这样的名字。最终，优秀的数据库都是混合型的，我们只是希望所有管理都能自动完成。8base 和 Edgedb 绝对值得你关注。另外，如果你不需要关注者动态，MongoDB Aura 没有前端客户端系统。

如果我们遵守这些规则：

• 实时数据
• 客户端 API
• 云托管
• 中间件

我们只有：Fauna、Hasura 和 Supabase……

从技术上来说，DGraph 也是如此。8base 还只是个婴儿。

尽管我抱怨过，但 Firebase 团队竟然忘了 Firestore。我们不仅应该感到愤怒，更应该坦白地说，应该感到不敬。他们不再倾听用户的声音。我非常尊重所有团队成员，尤其是社区里的活跃成员，但对于那些选择让 Firestore 停滞不前的人，我却不以为然。如果他们重新开始开发，我很乐意继续传播好消息。希望他们能为真正的关系数据库创建一个云平台。无论如何，这款产品曾经很棒，但现在却被时代淘汰了。Firebase，赶紧行动起来吧！

要记住一件事

分离你的代码。构建你的 React 或 Svelte 应用，确保 Firestore 或 Supabase 代码与关键元素完全分离。使用良好的 DRY、SOLID 和 KISS 技术。当我们找到完美的数据库时，你的应用就会构建完成，并且修改代码也会变得很容易。否则，找到适合你的权衡点。也许你喜欢像 Cassandra 这样的 NoSQL 数据库。也许你想要一个与区块链同步的 Web3 数据库……我有没有提到过 Outserv，它是 Dgraph 的分支？！也许你不介意为了搜索而管理第二个数据库。这也没问题。

我个人已经为未来做好了准备。今年是一个新的开始。

查看我去年的数据库。

直到那时，继续建设。

J