数据库DemyStified第7章 - 分布式数据库第2部分
以下博客文章是底漆系列中的第七章迈克尔·康森斯基在数据库中。你可以阅读第六章如果您错过了分布式数据库的第一课，或在YouTube上观看完整系列。
当您使用分布式数据库时，没有免费的午餐。分布式计算是非常强大的，分布式数据库可以帮助我们解决棘手的问题。然而，在数据体系结构中引入多个节点并通过网络连接多台计算机会增加复杂性和新问题。
分布式计算的墨菲定律告诉我们，如果有可能发生网络中断，我们就会发生网络中断。因此，我们的分布式数据库必须能够优雅地处理这些中断，否则，我们的分布式数据库将在最不合适的时间停止工作。
听从领队
我们要介绍的第一个概念是“领导者”节点的想法。在最后一课中，我们展示了如何运行“大计算”分布式数据库，但我们没有提到此处需要额外的计算机。我们经常将此额外的计算机称为“领导节点”。另一个节点通常被称为“跟随器”或“计算”节点。
领导节点的作业是协调跟随节点的工作。如果向首长节点发送命令或查询，则会决定如何在不同的跟随节点中分发该查询。然后，来自每个跟随节点的结果返回到领导节点，并且领导节点组装最终结果并将它们返回给用户。
The idea of a leader node is really important, and today we’re going to talk about the different types of “decisions” the leader node might need to make in different circumstances, and where and how things might go wrong in the interactions between leader node and compute nodes.
丢失的节点
我要谈论的第一个问题是领导节点失去与一个跟随节点的情况的情况。我们可以想象出现很多可能发生的原因。也许在数据中心中的电源，或该地区的互联网服务提供商下跌。由于网络流量拥塞，它可能是一个临时昙花一现，或者它可能是因为计算机本身具有致命错误并完全关闭。
领导节点必须回答许多问题：
我们应该等待节点恢复在线吗?
在我们把它放弃之前，我们应该等多长时间丢失？
我们是否备份了该跟随节点上的数据？
备份数据在哪里，我们如何协调确保它可以访问它？
那个节点上有什么数据?
如果它只是数据的子集，则领导节点甚至知道现在丢失的数据吗？
等等。
如这些问题在设计和使用分布式数据库时都是至关重要的。当系统的不同部位提前分解时，我们必须思考会发生的事情。不要忘记墨菲的分布式计算定律：如果节点可以下降，它会下降！
更新数据
领导节点要解决的另一个有趣的问题是如何处理分布式设置中的数据变化。在分布式数据库中，我们很少在所有不同的节点上都有完整的数据副本。相反，我们在不同的节点上有部分和重叠的数据副本。
我们如何确保所有这些更改都在所有这些中都进行了正确？我们是否需要每个节点来告诉领导节点的操作成功完成？如果在听到更改之前与节点发生联系，会发生什么？
通常，在这个新的世界中，数据的多个副本可能存在于不同的节点上，而这些节点在与leader节点通信时具有不同的延迟量，我们如何管理事务和锁定?
这在分布式数据库中比单个节点系统更复杂，因为我们必须在更多地点应用锁并在更多地方管理数据的状态，同时记住我们可以随时使用网络中断。
在下一个课程中，当我们谈论共识时，我们将更详细地讨论分布式数据库如何在引擎盖下做出这些决策。
热段
在使用分布式数据库时，我们面临的另一个问题是数据在不同节点上分布不平衡的问题。一个简单的例子是，当一个节点上的数据被访问的频率远高于另一个节点上的数据时。
例如，如果您的数据通过创建数据分布在不同的节点上，就可能发生这种情况。如果更近期的数据被更频繁地访问(在数据库中通常是这样的)，那么一个节点将不得不比其他节点更加努力地工作。
在这种情况下，我们实际上并没有充分使用分布式数据库，因为我们有很多节点根本不做任何工作。我们宁愿让计算负载在节点之间均衡。所以，如果我们在节点之间有数据和访问的不平衡，我们如何在节点之间移动数据?
不幸的是，在节点之间移动数据非常缓慢。
在单节点世界中，我们经常讨论从硬盘访问数据与从RAM访问数据之间的区别。通常，从RAM访问数据是快的，而从硬盘访问数据是慢的。在网络上有多个节点时，我们可以选择通过网络访问数据。不幸的是，这甚至比从本地磁盘访问数据还要慢。
因此，每当我们谈论节点之间的移动数据时，无论如何，我们都必须记住，这是访问数据的最慢的方法，我们可以在我们需要的情况下，我们可以快速损失我们从使用分布式数据库获得的任何提升通过网络发送太多数据。
数据洗牌
让我们来看看这在大计算设置中可能是一个问题。在最后一次课程中，我们研究了一个分析查询，我们计算了每个州中的用户数量，并观察到它非常有效。每个节点都可以单独计算其数据，然后我们可以在最后添加每个节点的结果以获取我们的答案。通过在不同节点上并行计算，我们能够加快我们的查询。
不幸的是，这里我们有一个例子查询，这不起作用如此有效：
SELECT COUNT(DISTINCT user_id) FROM表
在此示例中，我们希望在数据库中获取不同用户的计数。因为不是每个节点都有一个完整的数据副本，所以我们不能只计算每个节点上的不同用户，然后添加它们！如果我们在节点1上占用不同用户的计数，并将其添加到节点2和3上的唯一用户的计数中，我们可能非常适当地包含在多个节点上的任何用户的双计数（或三重计数）。我们需要一种不同的方法。
在此示例中，查询首先将转到领导节点，并且领导节点必须决定将答案返回给用户的最佳方式。由于我们不能单独向每个节点发送“计数不同”查询，因此我们必须向每个节点发送不同的查询：
从表中选择DISTINCT USER_ID
领导节点将询问每个节点不适用于不同用户的计数，但实际上用于该节点上所有不同用户的列表。所以每个节点都会找到它具有的不同用户，并将所有这些都返回到Leader节点。
然后，一旦我们拥有来自每个跟随节点的不同用户列表，我们可以编译在领导节点上的该列表并获得我们的最终计数。
我们可以在这里看到:
领导节点将检查原始查询，使所有跟随器节点发送回到领导节点的所需数据，然后领导节点可以执行最终计算。
不幸的是，这非常缓慢，因为我们必须将每个跟随节点的用户列表发送到领导节点！任何时候数据库必须在节点之间移动数据以响应查询时，我们将具有非常缓慢的响应时间。
如果我们在单节点数据库上执行此操作，这当然比响应时间更慢。除了通过分发作业并并行执行我们的运营而不是节省时间，我们最终会失败的时间，因为我们必须通过网络发送这么多的数据。
帽定理
CAP定理在数据库环境中经常被讨论，尽管对于它的适用程度以及它是否真的是讨论分布式数据库中权衡的最佳框架存在一些争议。
我个人认为这是一个有用的模型，用于定向到分布式数据库。如果您了解CAP定理，那么您了解有关分布式数据库的许多关于分布式数据库以及与分布式数据库一起使用的相关权衡。
帽代表“一致”，“可用”和“分区宽容”：
持续的意味着从数据库中读取的每次读取都会收到最近写入的数据，或者错误（即数据库没有返回“陈旧的”数据）。
可用的意味着每个请求都接收一个响应。
宽容意味着数据库对网络错误是有弹性的。
帽定理是一个Trilemma。你可以选择三个三个中的两个。数据库可以是一致的且可用的，但不可用，可用和分区容忍，但不包含一致的，或不一致的和容忍，但不可用
对于分布式数据库，我们的选择就更少了。由于分布式数据库的墨菲定律，我们必须假设会有网络中断，并选择分区容忍。
因此，对于分布式数据库，选择实际上只是在“一致”和“可用”之间。我们应该确保保证数据库是否返回一致，非陈旧数据，或者我们希望我们的数据库始终返回一些东西，即使它可能是陈旧的吗？
让我们想象一下我们拥有我们分布式数据库的情况。我们的两个节点具有陈旧的数据，一个节点具有新鲜和更正的数据。我们的Leader节点知道哪些节点具有哪些数据，因为它一直在跟踪每个节点上成功完成的数据更新。
不幸的是，当我们的用户想要查看帐户的余额时，具有正确的、新的数据的节点是不可访问的。那么，数据库是从其他节点返回过时的数据，还是出错并等待具有正确数据的节点恢复联机?
选择可能取决于您如何计划使用数据的方式。如果我们实际上在银行中跟踪帐户余额，那么我们可能更愿意我们的数据一致而不是可用。但是，如果我们只是跟踪我们网页的访问数量，那么数据可能有点陈旧，我们更愿意让我们的数据库返回陈旧的数据而不是什么。
上限的替代品
有些人批评了过于简单的帽子定理，特别是在分布式数据库的背景下，我们知道网络分区是生活的事实。事实上，在分布式数据库中，是否存在真正的“中断”，我们将始终面临延迟和一致性之间的权衡。也就是说，我们的不同节点之间会有不同的延迟，因此我们将始终选择返回潜在的陈旧数据与等待所有节点返回。
如果您对更多的学习感兴趣，我建议签出PACELC框架，这使得这种权衡更明确。
概括
分布式数据库功能强大，但它们具有许多额外的并发症。特别是，我们总是必须承担网络中断的最终性（墨菲的分布式数据库定律）。
如何在节点上分布数据可以急剧影响性能，并且对于不同的查询，这种影响将不同。
最后，CAP定理帮助我们分析网络中断时所做的权衡——在分布式数据库的情况下，这意味着一致性和可用性之间的权衡。
在下次安装本系列中，我们将在分布式数据库的上下文中讨论共识。
该系列继续第8章这里。