#009 - Scaling MySQL with Brian Morrison from PlanetScale
43:23 Share

Lane和Brian讨论了数据库扩展，特别是MySQL、Vitess和PlanetScale平台。Brian是PlanetScale的开发者教育家，他分解了如何考虑为自己的项目或工作的公司扩展数据库。PlanetScale用于Boot.dev上新发布的CI/CD课程中的云MySQL部署！Brian的Twitter：https://twitter.com/brianmmdev PlanetScale：https://planetscale.com/</context> <raw_text>0 Vitess最初是在2010年代初期创建的，用于扩展YouTube。YouTube当时资源耗尽，他们将MySQL推到了极限，甚至他们的副本中存储的数据量也超过了MySQL能够处理的范围。这就是Vitess诞生的原因。它是在那个时间段内为了处理YouTube的扩展问题而创建的。

Brian，我很高兴你能来参加节目。你想花一点时间向听众介绍一下自己吗？

是的，我叫Brian Morrison。我是一名前端和后端全栈开发者。我曾在许多不同的行业工作过。前端方面，我做过React和Angular；后端方面，我做过Go和C#。目前，我是PlanetScale的开发者教育家。我做的很多工作包括管理博客、管理YouTube频道，以及更新文档，确保文档根据客户的反馈以及我们内部可能构建的新功能保持最新。

直到现在我才刚刚知道你是一位Go开发者。这对我来说总是非常令人兴奋的。在BootDev，我们主要使用Python和Go，但非常重视Go。比例大概是30-70。很好，非常酷。

酷。我请你来的主要原因是讨论PlanetScale，因为PlanetScale是我刚刚完成编写并将在本播客剧集发布时发布的CI/CD课程的关键部分。请告诉我们PlanetScale是什么，大概介绍一下。

好的，概括来说，我们是一个托管的、与MySQL兼容的无服务器数据库平台。这就是它的核心。重点在于“平台”这个词，因为我们提供的不仅仅是MySQL，即使那是主要产品。我们提供数据库分支，这与你在Git环境中使用的非常相似，我相信大多数开发者都熟悉Git。

我们有功能可以实现零停机时间数据库迁移。因此，如果你在该分支设置中对数据库进行更改，你可以合并更改，而无需关闭生产环境或数据库本身，你

我们提供数据缓存、API和CLI。我们还与许多其他合作伙伴集成。这就是为什么强调“平台”的原因。MySQL只是冰山一角，它更深入。你的用户交互的核心是MySQL，但PlanetScale构建的所有功能都是你如果部署基本MySQL时必须手动完成的事情。我的理解就是这样。

是的，差不多。我想提供一些背景信息。我最近为Boot Dev平台编写了这个学习CI/CD课程。它将是这个后端学习路径中的最后一个课程之一。

在整个课程中，学生们使用GitHub Actions来测试他们的代码，对吧？他们在GitHub和GitHub Actions中进行自动化测试和自动化格式化。课程的最后一步是将他们一直在进行CI和CD的Web服务器连接到生产数据库。当我四处寻找不同的数据库解决方案时，我显然在我的职业生涯中使用了许多不同的数据库，但我从未专门购买过数据库。

这对于学生在云中启动开发实例来说将非常棒，因为通常你是在本地启动数据库进行测试，而这正是学生通常会做的。

通常会做的。但是持续集成和持续部署课程的重点在于，在某些时候会进行部署。我真的很惊讶PlanetScale的易用性，以及它有一个无需信用卡即可使用的免费试用版。你可以获得这个非常短暂、非常小的数据库，对我来说，这非常适合教育目的。我不知道为什么其他人

没有这样做，你能谈谈PlanetScale是如何考虑数据库扩展的，或者说PlanetScale在数据库扩展方面的价值主张是什么吗？我既对它可以扩展到多大印象深刻，因为这是PlanetScale的主要功能，你可以将数据库扩展到非常大的规模，也对它可以扩展到多小印象深刻。

是的。为了确保我理解正确，我想重复一下你的问题，你只是想了解我们在PlanetScale是如何扩展的，或者说我们围绕扩展的理念是什么，对吗？我想对于我的听众来说，扩展数据库意味着什么？很多收听这个播客的人可能对数据库本身非常陌生，只是将数据库视为存储数据的地方。比如，

扩展或缩减数据库究竟意味着什么？这对你的项目有什么业务影响？我明白了。

好的，我将给出非常学术性的答案，并说有两种主要的扩展方式。我认为这对于一般的架构都是如此，这与数据库完全无关，但你可以横向扩展或纵向扩展。大多数数据库都支持纵向扩展方法，这意味着如果你在服务器上运行数据库，你只需向其投入更多资源，例如更多的硬盘空间、更多的内存、更多的RAM，然后它会变得更快，因为数据库有额外的资源可以使用。

但也有横向扩展或水平扩展的方法。你可以创建额外的节点，我们称之为节点。然后，这些节点（取决于你拥有的节点数量）可以一起工作，使整个环境运行得更高效、更流畅。因此，在PlanetScale，我们真正专注于横向扩展。我们在所有内容的底层使用一个名为Vitess的平台。Vitess是一种

并且我声称它是一个开源的、水平扩展的MySQL平台。这就是我们现在真正做的事情。这并不是说，如果你使用我们的企业级套餐，我们不能微调一些底层架构来同时进行纵向和横向扩展。但对于大多数将使用该平台的人来说，我们更关注的是横向扩展的实现。明白了。所以纵向扩展或垂直扩展，听起来像是你只是向同一台机器添加更多资源。

所以你有一台物理服务器，如果它内存不足，我们将插入更多内存条；如果处理速度慢，我们将添加更多CPU内核；如果数据库已满，我们将添加更多磁盘空间。对吧，这就是垂直扩展。为什么我不能这样做？这似乎很容易。

因为这会变得很昂贵。在某些时候，随着你的钱包开始缩水，你将无法再升级你的服务器。理论上，你可以尽可能多地向物理机投入资源，直到你无法再投入为止。然后，在某些时候，如果你想象一下类似曲棍球棍形状的图表，你将应用于物理机的资源成本将开始随着你获得的实际回报呈指数级增长。

因此，我通过垂直扩展获得的性能提升开始下降，即使我花了更多的钱。我的意思是，我花了更多的钱，却获得了更少的性能回报。是的。而横向扩展是添加更多机器。所以，与其拥有一台机器，不如拥有两台机器。

基本上是这样。因此，在PlanetScale数据库中，每当你启动一个生产级数据库时，你都会自动获得至少一个额外的节点。这主要作为一种保持数据库在线的方法，因为没有人是完美的。事情会发生，尤其是在使用计算机时。我相信任何使用过计算机的人都告诉你，是的。

事情会发生。因此，我们为你启动的额外节点为你提供了高可用性，同时也为你提供了一个额外的副本进行读取，这反过来又提高了你的应用程序的性能。因为与其从一个内部节点读取和写入，你可以使用多个节点来分配负载。

一个好处是，好吧，如果我都在一台机器上，我只是纵向扩展它，我有一台5万美元的计算机，对吧？但是如果出现问题，我的整个系统现在都不可用了。而如果我的集群中有三个节点，并且一个节点宕机，我的用户仍然可以通过其他两个节点获取他们需要的数据。因此，当你横向扩展时，可靠性更好。另一件事是成本。所以

我估计通过向集群添加新节点，性能提升是否大致呈线性增长？例如，我添加第二个节点，我的读取性能大致提高一倍；添加第三个节点，读取性能提高三倍。同样，我知道这非常粗略，但它是否通常是这样工作的？

在大多数情况下，是的。显然，这取决于你的代码、配置以及配置方式。但正如你所说，大致来说，是的，它更线性地扩展。酷。我记得在学校的时候读过一篇论文。我认为谷歌发表过这篇论文。我很想引用它，但这已经是很多年前的事了，所以我记不起来了。我只是记得读过这篇论文。但这篇论文的内容大致是这样的。在谷歌的早期，科技公司扩展其系统的方式是……

购买非常昂贵的最新型超级计算机，所以当时其他大型科技公司只是在大型垂直扩展系统上花费巨额资金。

而谷歌只是开始购买像被丢弃的普通PC，并将它们连接在一起，构建分布式系统软件，对吧？因此，他们可以利用所有这些普通机器并让它们工作，例如索引互联网。最终，这更具成本效益，因为他们利用了所有这些硬件，在很多情况下，人们甚至都不想要它们了，对吧？没有人想要一台已经过时七年的PC。但是如果你将它们连接起来，那么它突然变得非常强大。

是的，是的，当然。当你开始做这样的事情时，你会遇到更多复杂性，因为你现在必须弄清楚如何让所有机器以正确的方式通信。我认为这就是为什么许多公司传统上会进行纵向扩展的原因。好吧，我认为现在情况正在发生变化。但在我的时代，人们过去常常在硬件上投入巨资进行纵向扩展，因为这很容易理解。对吧，更多功率，更快速度。

但是尝试将所有这些机器连接在一起并使它们协同工作可能是一个挑战。这就是PlanetScale所做的很酷的事情之一，所有这些复杂性都在幕后得到处理，你不需要考虑。对吧，我的意思是，这是一种……

小型科技初创公司现在可以访问的东西。谷歌之所以能够在过去做到这一点，是因为他们拥有惊人的工程资源，对吧？他们拥有一些世界上最好的工程师，他们可以编写真正复杂的软件来正确处理所有这些网络连接和分布式负载。这些都不是容易或简单的算法，对吧？

因此，一般来说，这就是为什么小型软件初创公司总是选择纵向扩展，直到他们无法再扩展为止，因为这很简单，对吧？你只需将你的代码部署到单体架构上，并添加更多硬件，你的问题就解决了。

但是现在，我们确实有工具。我的意思是，PlanetScale就是一个，对吧，用于数据库。Kubernetes是我更多地用于服务器端、应用程序服务器端的东西。但是，现在肯定有方法可以水平扩展你的技术，而无需每次都从头开始编写所有分布式系统算法。让我们再谈谈Vitess。你刚才非常随意地提到了它。Vitess是什么？它是MySQL的一部分吗？还是独立于MySQL？

它独立于MySQL。它是在MySQL之上的一个层。所以首先，你提到谷歌的论文及其方法很有趣，因为Vitess最初是在2010年代初期创建的，用于扩展YouTube。YouTube当时资源耗尽，他们将MySQL推到了极限，甚至他们的副本中存储的数据量也超过了MySQL能够处理的范围。

这就是Vitess诞生的原因。它是在那个时间段内为了处理YouTube的扩展问题而创建的。Vitess本质上是什么，我不是Vitess专家，所以我可能会弄错一些术语。你可以访问Vitess.io获取所有这些信息，如果你真的想深入了解它的话。但本质上，它是一个网关或负载均衡器，位于

多个MySQL节点、多个MySQL实例（实际运行在虚拟机或容器上的守护进程）的前面。然后，每个MySQL实例都有一些sidecar进程与该中央负载均衡器通信，以便将负载均匀地分布到所有这些不同的节点上。它是在MySQL之上的一个抽象层。

我想更深入地探讨一下……

它如何使用Vitess进行横向扩展。让我举一些例子。在我看来，MySQL和Postgres是开源关系数据库的典型代表。对吧。因此，特别谈到MySQL，正如你提到的，Vitess是一个编排层，它允许我们向集群添加多个节点。这很好。我一直认为MySQL和Postgres是你大多数Web应用程序的起点，例如交叉链接。

CRUD应用程序，对吧，创建、读取、更新、删除。如果你有非常传统的用户表和帖子表，对吧？如果你的应用程序符合这个相当标准的模型，那么这些关系数据库就是一个很好的起点。当你拥有不同的数据时，考虑使用关系数据库之外的东西就开始变得有意义了。例如，

网站分析。你跟踪页面上的每次点击。你只是试图将尽可能多的数据转储到磁盘上的某个位置。对于网站分析，你可能会有大量的写入，对吧？每次有人在你的网站上做事情时，你都会将所有这些事件日志写入某个数据存储。你需要一些非常特殊的数据库才能有效地进行所有这些写入，然后对数据进行一些大型聚合查询。

我感兴趣的是，当我们使用Vitess扩展MySQL时，是否存在某些用例

你想要在决定使用MySQL和Vitess以及PlanetScale时坚持使用，以及在哪些用例中你想要考虑使用Redis、Elasticsearch或其他一些更特定于领域的数据库？啊，这是一个非常非常好的问题。让我们解决你提到的关于Redis或内存中键值存储的最后一点。如果你有数据正在被，数据相对一致地被，

可预测地读回。我认为这就是像Redis这样的缓存工具有意义的地方，甚至包括我们自己的Boost。我们有自己的内部数据缓存机制，目前仍处于测试阶段，但它或多或少会将数据预加载到内存存储中，并使访问速度显著加快。如果你两年前问我这个问题，我会说

通常，如果你有非结构化数据，并且你的数据具有非常常见的读取模式，并且你知道如何访问它，那么一些NoSQL数据库是有意义的。而如果你有高度结构化的数据，并且你确切地知道如何查询它等等，那么你的典型关系数据库系统是有意义的。

我认为在过去的几年里，这些界限开始模糊了，因为像MySQL这样的工具现在支持列中的JSON数据结构。因此，你可以很容易地将非结构化数据转储到MySQL数据库中。在传统的配置中，你可能会遇到问题的地方是存储在单个表中的行数或数据量。Vitess的一大优点是，因为它支持水平分片，你实际上可以分解数据

例如，你有一个大型表，你从中存储所有分析数据，对吧？它正在呈指数级增长，最终将达到一个硬性限制，MySQL的引擎根本无法处理读取这些数据。通过实现水平分片，Vitess实际上可以创建一个跨越多个MySQL实例的逻辑表。它将根据其对所有内容的拓扑结构和配置的了解，

访问哪些表以获取你正在访问的特定数据。你要求它拉回。哦，好的。所以，当你开始在传统实现之上添加不同的层时，这些界限开始变得模糊一些。我想这可能就是我的答案。是的。所有东西都使用MySQL。

这很酷。让我，让我读一下，因为我们可能使用了一个可能会让一些人困惑的术语。我们谈到了分片，谈到了数据分片。让我们举一个非常具体的例子。假设你是一个非常坏的人，你记录了访问你网站的每个人敲击的每个键。

对吧。所以当有人在你的网站上打字时，你都会为他们键盘上的每次按键在数据库中记录一个新记录。所以你可以想象，你有1000个并发用户。他们都在打字。你立即拥有数百万行数据需要写入你的数据库。如果我理解正确的话，听起来MySQL的单个节点有一些限制。我不知道这个限制是什么。也许单个节点有10亿条记录，或者100亿条记录，诸如此类。

说实话，我一时半会儿回答不了这个问题。好的，没关系。让我们假设它是10亿。对我们来说这是一个非常非常大的数字，但对于一个获得这么多数据的数据库来说，你可能会很快达到这个限制，这取决于数据被输入的速度。好的，但是任何单个节点都有一个有限的限制。而你告诉我，Vitess充当负载均衡器，你实际上首先将数据发送到……

它会将数据分割。让我们假设它在后台在五个节点之间进行轮询。所以你实际上有五个MySQL实例，每个实例都有自己的表。它说，好的，你得到一个，现在你得到一个，现在你得到一个。他们现在都在存储一行数据，这样当你写入数据时，他们都在……

像同步游泳一样。我们正在深入了解Vitess的细节，我对这些细节并不确定。我相信这种配置是可能的，但我知道Vitess有几种可用的分片配置，这取决于你的用例，你可能能够利用这些配置。

当然。对不起，我不是说这就是它的工作方式，但这是一种大致的想法，你是在后台将数据分割到多个节点，无论算法是逐行分配，还是其他什么。是的，当然。有很多不同的分片算法。但是好的。所以为了让我们从高层次上理解，Vitess允许我们将数据分割

到多个节点。我认为这很重要的原因是，如果你搜索“谷歌MySQL扩展问题”，例如你正在尝试选择一个数据库，并且你搜索了一些关于MySQL的信息，你可能会读到它有所有这些限制，所以你不想使用它。但是了解像PlanetScale这样的工具在幕后使用Vitess是有用的，因此你必须理解，当你将技术堆叠在一起时，会添加额外的功能。

是的，我还认为值得一提的是，如果你在PlanetScale中，并且你已经达到了需要担心分片、应用程序性能以及你的数据如何在多个节点之间分割的程度，那么我们实际上有一个专门的团队来帮助人们解决这个问题。那么这不是我们期望任何刚刚登录到PlanetScale业余级套餐的人能够完成并能够设置的东西。这绝对是，除非你已经有了一个你对此有顾虑的数据库，否则这有点像以后需要考虑的事情。

是的，我完全同意。有趣的是，这个播客的听众为了启动并运行他们自己的业余数据库并连接到它，他们不需要知道如何做这些事情。但是这个播客的听众有兴趣在大型公司获得后端开发工作。能够至少从概念上理解大型项目开始遇到的各种限制，我认为这非常有用。让我们谈谈MySQL……

与Postgres。在我职业生涯的大部分时间里，我都在使用Postgres。我认为我在我的第一份工作中使用过MySQL。然后我很快开始使用Postgres，因为我的下一份工作使用了Postgres，从那以后就一直使用Postgres。老实说，很长一段时间，我甚至没有真正理解其中的区别，因为它们在许多方面非常相似。差异往往非常细微。

我知道你们使用MySQL的主要原因是因为Vitess。它是专门为MySQL构建的。但是，一个可能已经使用Postgres完成了许多项目的学生在第一次迁移到MySQL时可能会遇到哪些问题？

这是一个很好的问题，我认为我没有很好的答案，因为在PlanetScale之前，我的职业生涯实际上是在Microsoft技术栈中。因此，我对数据库的大部分知识都在SQL Server中。话虽如此，我确实知道Postgres除了你通常认为的Varchar或整数或所有数据库中常见的许多标准数据类型之外，还有一些额外的数据类型。

而且我想它们在底层存储方式略有不同，这取决于你向其输入的数据。但是，仅从我个人从SQL Server迁移到MySQL的经验来看，因为这是我

第一次在工作中定期使用MySQL，从SQL Server到MySQL的知识转移量大约是，我估计一下，大约95%。一个让我一直困扰至今的主要区别是，在我长期使用SQL Server之后，分页数据时limit和top之间的区别。但除此之外，我不太，我会说任何有兴趣从Postgres迁移到MySQL的人，

只需检查他们数据库中使用的日期或数据类型。如果有重叠，那就太好了。如果有不同之处，我，有很多策略可以将数据转换为MySQL可以处理的数据类型。你知道，甚至可能不需要将其存储在专用数据类型中。所以肯定有方法可以做到这一点。我想这对于每个人来说都是独一无二的。是的。是的。

我喜欢的一个比喻是，对于任何听众来说，如果熟悉JavaScript，JavaScript是一种技术上只有一种语言的语言，但是根据你运行JavaScript的位置，你可以访问不同的东西，对吧？如果你在浏览器中运行JavaScript，你将可以访问某些DOM API。如果你在Node中运行它，你将拥有其他API。如果你在Dino中运行它，无论如何，它都会根据你运行它的位置而变化。我认为SQL基本上也是一样的，对吧？SQL是一种语言，并且，

总的来说，如果数据库支持SQL，几乎所有东西都能工作。但是不同的数据库支持某些API。例如，当我编写这个课程时，从Postgres迁移到MySQL时，我唯一真正遇到的问题是Postgres有一个本地的UUID类型。因此，它在底层存储UUID的二进制格式。

对于不熟悉它的任何人来说，通用唯一标识符，我经常将其用于数据库中的主键和ID。MySQL没有本机内置该功能。因此，你将其存储为类似二进制16之类的格式，对吧？一种原始字符串。所以肯定有一个对应关系。你可以在两个数据库中都做这两件事。语法会根据你使用的数据库略有不同。是的，是的，非常正确。我只是，我不认为这是，

它不足以让你感觉像是从一种语言到另一种语言。从Postgres到MySQL，我相信即使是95%的知识也会一样地转移，这很好，因为我们有一种通用的语言，它跨越了我们大多数关系数据库平台，老实说。

需要明确的是，当我进行此迁移时，我正在编写原始SQL，我仍然只需要更改几个字段的类型即可使其工作。如果你使用的是ORM，它将你的编程语言代码（例如Go或Python或其他任何代码）映射到你的SQL中。

Lane 和 Brian 讨论了数据库扩展，特别是 MySQL、Vitess 和 PlanetScale 平台。Brian 是 PlanetScale 的开发者教育家，他讲解了如何为自己的项目或工作的公司考虑数据库扩展。PlanetScale 用于 Boot.dev 上新推出的 CI/CD 课程中的云 MySQL 部署！Brian 的 Twitter：https://twitter.com/brianmmdev PlanetScale：https://planetscale.com/</context> <raw_text>0 很可能你不需要更改任何内容，因为在后台，ORM 会进行这些转换。现在你可能必须手动操作，例如，如果你真的要迁移生产数据库，你可能必须在数据库端进行一些更改，但你不太可能需要更改你的代码，我想这就是我表达的方式。我还想谈谈关于 MySQL、Vitesse 和 PlanetScale 规模的一个问题，那就是你怎么看待

写入与读取。当你向 PlanetScale 集群添加节点时，它们都能同样好地扩展吗？或者，Vitesse 中的水平扩展机制是否针对例如许多读取而不是许多写入进行了优化？

同样，我肯定会仔细检查文档，但它是基于配置的。你可以在所谓的 tablets（在 Vitess 行话中）中设置不同的节点，这些节点可以设置不同的属性，这些属性会将特定 tablet 标记为只读、写入，甚至专门用于备份。他们组合在一起的东西非常酷。也就是说，我认为绝大多数应用程序都非常依赖读取，而写入则少一些。

这就是为什么当你在 PlanetScale 中启动数据库时，我们会设置这些标记为只读的副本。这样，你可以将它们用于读取，然后如果需要，可以点击主数据库进行写入。这绝对不是每个人都需要的，但你可以在这两者之间来回切换。

现在我们还提供只读区域，如果你想将你的数据更靠近你的用户，这是另一个功能，你可以在任何你想要的世界任何地方获得一个完全独立的数据库集群。目前，我们在 AWS 和 GCP 中支持多个区域。酷。所以听起来……

现在，我想说明所有注意事项，人们应该真正去检查我接下来要说内容的文档。但从高层次来看，我喜欢讨论这些内容。我们将为任何收听的人声明这一点。我熟悉的一些数据库的分布式架构是……

其基本思想是没有主节点。你可以读取或写入任何节点，然后数据库最终会变得一致。因此，你在某种意义上放弃了数据库中的一些一致性，如果你基本上同时写入一个节点然后从另一个节点读取，它们在那一刻可能不会完全同步。因此，你放弃了一些一致性。但这意味着你可以在两个方向上更好地扩展，因为你可以更好地读取和写入。

当你向集群添加节点时，可以写入任何节点。我的理解是 Vitesse 可能不会采用这种方法。它采用更一致的方法，这意味着你不会遇到这种一致性问题，但你必须可能通过一个节点运行所有写入，然后从其他节点读取。我猜对了吗？

是的，这很准确。这是我在 PlanetScale 工作之前的事情，所以我只是在说我听到的一些事情。但是，当探讨我们是否希望创建这些具有多个读写节点的配置时，复杂性的权衡并没有真正与好处相匹配。大多数

大多数用例实际上只需要一个需要写入的节点。然后只读节点基本上充当故障转移。因此，如果该写入节点发生故障，另一个节点将出现并承担其工作。是的。因此，我想给收听本播客的任何人的一个建议是，如果你刚接触后端开发，我认为有一种倾向，尤其是在新的后端开发人员中，他们喜欢

使用非常通用的术语。哦，Mongo 扩展得非常好。而 Postgres 扩展得不好。这两个说法都是不正确的。你不能用这些模糊的笼统术语来思考它。你需要考虑你的应用程序以及它如何访问数据。就像你提到的那样，大多数应用程序都是读密集型的。我认为，如果你考虑任何网站，就会很清楚为什么是这样。当你加载页面时，你可能正在从数据库读取大量不同的行。每当你浏览页面之间时，你都在进行读取。

对。每当你打开一个下拉菜单时，你可能都在从数据库进行另一次读取。而你真正写入内容的唯一时间是，如果你喜欢在网站上创建新内容。所以想象一下 Twitter。如果你登录 Twitter 并滚动浏览一小时，你可能已经对数据库进行了数千次读取。如果你没有发推文，你甚至没有进行一次写入。

对。因此，每当你遇到规模问题时，考虑这些事情我认为是有帮助的。这可以解释为什么 PlanetScale 针对你们的使用案例（我猜主要是 Web 应用程序和网站）会非常重视读取。是的。而且我绝对认为对你们的一些听众（初级开发人员）的建议是，我建议

避免过早地进行过度优化，对吧？如果你正在启动一个新项目，这可能不是你需要担心的事情。即使你在一家大型企业公司工作，了解很多这些功能和技术的存在就足以让你入门，并且

那里可能会有另一位高级工程师能够指导你。我是一个完全自学的开发人员。我从未获得过专业学位或任何其他学位。我所有的经验都来自该领域的导师，他们指导我了解事物的工作方式。我只是随着时间的推移积累了很多这方面的知识。所以，当你进入技术或开发领域时，记住这一点。

我认为这是一个非常好的建议。根据我的经验，作为一名高级开发人员，你可能会在面试中遇到一些更棘手的问题，例如可扩展性类型的问题。但作为一名初级开发人员，我认为你更有可能遇到这样的问题，例如，你以前使用过 X 技术吗？问题会更简单，但我认为……

是的，不要像鹿一样被车灯照到。是的，是的。

你提到了边缘或地理数据分布，我直到现在才略过它。我认为你所说的意思是，你基本上可以在地理位置上拥有你的数据库集群。让我们选择一个位置，例如纽约市，你可以在世界其他地方拥有一个只读副本。你为什么要这样做？

这取决于情况。你这样做的原因是，如果你在世界某个非常具体的地区有很多用户。例如，以你的例子为例，如果你有，如果你的主要位置是弗吉尼亚州，因为我知道弗吉尼亚州是 AWS 的主要中心。假设你的主要中心是

假设你的主要数据库集群位于 US East 1，它位于弗吉尼亚州的 AWS 上。突然之间，你注意到在欧洲，你的用户数量激增。在这种情况下，所有试图访问你的应用程序或网站的人实际上都在跨越全球，以访问你的应用程序和数据库托管在西弗吉尼亚州的位置。

现在，为了优化这一点，你理想情况下想要做的是将你的架构或应用程序、数据库等更靠近你的用户。所以如果你

我认为爱尔兰或其他地方有一个数据中心。AWS 有很多数据中心。我现在甚至不知道它们都在哪里，但让我们假设是爱尔兰。你可以在爱尔兰放置你的应用程序并在那里存储它，然后放置你的 PlanetScale 数据库，在同一个区域放置你的数据库的只读版本。所以在这种情况下，你的写入仍然会比那些从美国访问它们的人花费更长的时间，对吧？

但至少如果你的应用程序配置得像大多数应用程序一样，其中绝大多数将是读取，这将照顾到 90% 试图从欧洲访问你的应用程序的人，而不是必须跨越整个世界。他们可以更本地地访问数据，这反过来又使你的应用程序更快一些。

是的，这很有道理。我已经加载了……所以，boot.dev 作为一个 Web 应用程序。我已经通过印度的 VPN 体验了 boot.dev。它比连接到数据中心慢得多。我认为，实际上，我在盐湖城托管我的网站。我只是在盐湖城郊外。所以，对我来说总是超级快速。但是……

在某个时候，随着我们公司和项目的扩展，我们可能需要进行某种地理分布。就像现在，我们共有 40,000 名注册用户。我们可能在任何特定地理区域的用户数量不足以保证这种复杂性。但我认为在某个时候，我们探索这些事情肯定是有意义的。是的，就像……

许多人意识到，尤其是在他们进入开发领域时，这是一个不断发展的野兽，你只是像事情出现一样，你只是想出如何解决它们，然后将它们击倒。我的意思是，如果你问我，这确实是这个领域的乐趣所在，就是这些小事情会突然出现，你现在必须找到一个好的解决方案来进行工程设计，以解决这些用户问题。是的。

是的，对于大多数应用程序来说，这种延迟不会成为障碍。我在印度有用户使用 boot.dev，他们很高兴使用 boot.dev。而且它比他们在美国数据中心旁边使用它时慢一些。但这并不是说它慢得无法忍受。它可能只有大约一秒的延迟，而不是 100 毫秒。

或多或少。但是，我可以肯定地想到，有些应用程序从一开始就可能需要更多地考虑地理分布。例如在游戏中，如果你的 ping 时间为一秒半，那可能会非常糟糕。所以这取决于你正在构建什么。早些时候，你提到 PlanetScale 除了它为你自动执行的所有这些扩展功能之外，还有一些你添加的其他功能。所以我想你提到了 CI/CD 或分支。你能谈谈这个吗？

是的。而且我真的，这是 PlanetScale 最酷的功能之一。当我经历面试过程时，它让我对公司的未来感到非常兴奋。使用 Vitess 的强大功能，我们可以创建数据库模式的隔离副本，在用户界面中我们称之为分支。这使我们能够做到这一点，因为这些分支是隔离的，我们可以

你可以创建一个分支，创建一个到该分支的连接字符串，然后在该分支上试验构建功能或测试内容，而不会对你的生产数据库产生任何影响，这真的很棒。现在，我们开发的功能与你在 Git 和 GitHub 中进行代码合并、代码分支和代码合并的方式非常相似。因此，PlanetScale 中的分支类似于 GitHub 中的分支，但我们也有部署请求的概念。

因此，一旦你完成对开发分支的更改，你可以打开一个部署请求，这实际上允许你的团队中的其他开发人员评论更改、审查更改，就像你在 GitHub 中进行拉取请求一样。

然后，一旦所有内容都检查完毕并准备就绪，你就可以合并这些更改。然后我们在幕后做一些很酷的魔法，这使你可以在不中断应用程序的情况下合并这些更改。你可以在更改完成后立即合并它们，或者你实际上可以推迟合并，并说，嘿，我不，如果你启动一个部署请求并开始合并，比如说下午 5 点，对吧？当你准备下班回家时。

你不想突然在工作时间之后将内容投入生产。因此，你实际上可以说，嘿，等等，让我们早上再回来检查一下，确保没有问题等等。然后切换。切换几乎是实时的，这非常酷。除此之外，我们还提供回滚功能，这

一旦这些合并已更改，你将拥有 30 分钟的窗口来有效地说，没关系。出了点问题。通常更改数据库很难，我们试图使这些更改尽可能简单，但不可避免的是，事情可能会出错。因此，我们有另一个功能，可以让你快速撤消这些更改，以便你可以尽快恢复应用程序的运行。你的数据库的小型控制 Z。是的。酷。

好的，我有一个关于分支的问题，因为它听起来非常棒。我在上一家公司遇到的一个大问题是，我们有不同的登台环境。因此，显然，我们不仅仅是在进行更改并直接部署到生产环境。我们会部署到登台环境。然后我们的质量保证团队会在登台环境上检查应用程序。一个很大的痛点是……

我的意思是，正如你提到的那样，模式是一个方面，但另一个很大的痛点是数据本身。就像你需要数据库中的数据副本一样。分支是否解决了数据和模式问题，还是只解决了模式更改问题？

在我们的基本层中，它只是模式更改。因此，如果你愿意，你可以自己播种数据，这很容易使用我们的 CLI 完成。你实际上可以直接连接，你可以使用我们的 CLI 连接到任何分支，并获得一个 MySQL CLI 连接，以运行与你在常规 MySQL 数据库上使用 MySQL CLI 时相同的命令。

现在，一旦你开始使用我们产品的一些更高层级，我们提供一个名为数据分支的功能，它基本上会获取源分支的最新备份，并直接将其恢复到数据库。这需要花费更长的时间，因为显然你正在向其传输数据。因此，这取决于你的数据库有多大。

但是，结合分支和数据分支部分，你实际上可以获得生产数据库的完整副本，该副本与你的生产数据库完全隔离，以便构建、测试、修改并执行大多数开发人员在扩展数据库时所做的一切。

是的，这对我来说听起来很令人兴奋，因为它听起来基本上是为我们公司构建以使事情正常工作的那些手动垃圾提供了一种开箱即用的解决方案，对吧？就像我们有所有这些脚本一样，这些脚本会克隆数据库，启动一个新的数据库。这只是很多工作。我还没有尝试过这个功能。听起来很酷。我对此感到非常兴奋。

好的。人们在哪里可以找到更多关于 PlanetScale 的信息，或者让我们先从 PlanetScale 开始。然后我还想宣传你的东西，因为我知道你在 Twitter 和 YouTube 上做了很多事情，但是人们在哪里可以找到 PlanetScale？他们应该首先查看哪些资源？是的。要开始使用，请访问 planetscale.com/docs。我的很多工作都在那里。我们对所有功能进行了完美的记录。

非常彻底。因此，如果你想了解某些功能的工作方式，这是第一个检查的地方。我们的博客也是一个极好的资源，可以了解如何在 PlanetScale 之上构建某些应用程序，例如即将发布的内容的抢先预览。好吧，我想在本播客发布时，它已经发布了，但是例如如何在 PlanetScale 之上构建 Laravel 应用程序。我们即将发布一篇新的博客文章。这将向你展示如何做到这一点并构建一些内容

你可以，它不仅仅是一个简单的 hello world 应用程序。你可以点击周围，你可以在应用程序中执行一些操作。除了我们拥有的常规高度深入的技术博客文章之外，我们还有几篇这样的文章。我会说这些是一些最好的资源。我们的 YouTube 频道，也去看看吧。你会看到我的脸经常出现在那里，我试图向你展示如何使用该平台的某些功能。

我们的业余计划是免费的。你将获得 5GB 的数据库。我们的层级现在都是基于使用情况的。因此，如果我的记忆没错的话，对于免费层级，你每月可以读取 10 亿行，写入 1000 万行，这在数据库产品的大环境中非常慷慨。是的，然后

联系我们，让我们知道。提交联系请求或在 Twitter 上关注 PlanetScale 是与我们联系的最佳方式之一。我也是实际管理该 Twitter 通信的人之一。因此，你最终甚至可能在幕后与我聊天而不知道。太棒了。人们在哪里可以具体在 Twitter 或你经常出没的其他地方找到你？

说实话，我最近在 Twitter 上的时间少了一些。如果你想关注我，我的用户名是 BrianMMDev。如果你想关注我在 BrianMMDev 上的其他作品，我几乎无处不在，但我也在 YouTube 上。我的网站是 BrianMorrison.me。我在那里写博客。你也可以在那里找到我过去的所有作品以及我在职业生涯中所做的一切。我喜欢写我过去参与的项目。我参与了一些我认为非常有趣的事情。

是的，我认为这总结了它。哦，还有一个个人宣传。下个月，我将参加威斯康星州戴尔斯举行的那个会议。我实际上将进行我的第一次演讲。我将讨论如何入门。这实际上与你的 CI/CD 课程非常吻合。我甚至不是故意这样做的，但我将分解一个完整的管道，并模拟类似于……

像 Netlify 那样，你推送代码到生产环境。我将对其进行分解，并向你展示如何使用许多不同类型的工具构建你自己的管道，并为你提供一些起点等等。所以是的，

来打个招呼。太棒了。我们很乐意结识大家。祝贺你第一次在会议上做演讲。如果任何听众都在会议上，显然应该去看演讲。我猜演讲也可能会上传到 YouTube。会议通常会这样做。我不知道。这不是主要的演讲之一，但我并不完全确定。该会议每年举办两次。夏季在威斯康星州举行。1 月份在德克萨斯州举行。他们没有录制德克萨斯州的一些小型会议。所以……

好的。我不知道。即使我必须在我的电脑前自己录制它，它最终也会出现在那里。酷。听起来很棒，伙计。如果有人感到困惑，它实际上被称为那个会议。就像那是会议的名称一样。我们并不是在开玩笑。每个人都应该知道我们正在谈论的会议。是的。

很有创意，但可能会有点令人困惑。That.us 是网站。运行它的人非常好。这是一个很棒的会议。它比我参加过的任何其他会议都更有乐趣。太酷了。我需要参加更多会议。也许这将是我接下来参加的会议之一。非常感谢你来到节目中，伙计。回头见。是的，很高兴和你聊天。感谢你的邀请，Lane。再见。