sql中的表分布和表分区有什么区别？

我仍在努力确定azure sql数据仓库中的表分布概念与sql server中的表分区概念有何不同

---

对两者的定义似乎取得了相同的结果

在概念上它们是相同的。其基本思想是将数据分割到多个存储区。然而，实现方式却截然不同。在幕后，Azure SQL Data Warehouse管理和维护您定义的每个表中创建的70个数据库。除了定义关键点，您什么也不做。分发工作已经完成。对于分区，您必须定义和维护几乎所有的东西才能让它工作。还有更多，但你得到了核心思想。这些是不同的过程和机制，它们在宏观层面上达到了相似的终点。然而，这些东西所支持的过程是非常不同的。分布有助于提高性能，而分区主要是一种改进数据管理的方法（滚动窗口等）。这些是非常不同的东西，尽管它们很相似，但目的却不同。

Azure DW有多达60个计算节点作为其功能的一部分。当您在Azure DW上存储表时，您正在这些节点之间存储它。表数据分布在这些节点上（根据需要使用哈希分布或循环分布）。您还可以选择跨这些节点复制表（最好是非常小的表）

这就是分配。每个节点都有自己独特的记录，只有该节点在与数据交互时才会担心这些记录。这是一个没有共享的架构

---

完全脱离了这种分配观念。当我们对一个表进行分区时，我们根据某种方案决定哪些行属于哪些分区（例如，按

顺序对
表进行分区。例如，创建\u date
）。然后，每个
create\u date
的记录块存储在其自己的表中，与任何其他
create\u date
记录集（不可见的幕后）分开

分区很好，因为您可能会发现您只想从表中选择10天的
订单
，因此您只需要针对10个较小的表进行读取，而不必跨
订单
数据的年份进行扫描，以找到您所需要的10天

下面是一个来自Microsoft网站的示例，其中在
名称
列上使用两个基于
名称
字母顺序的“碎片”进行水平分区：



表分发是一个仅在MPP类型的RDBMS（如Azure DW或Teradata）上可用的概念。最容易将其视为一个硬件概念，它在某种程度上脱离了数据。Azure在其他MPP数据库基于主键的分发位置为您提供了很多控制。分区几乎在每个RDBMS（MPP或非MPP）上都可用，最容易将其视为一个由表中的数据定义并依赖于表中数据的存储/软件概念

最后，他们做这两件事是为了解决同一个问题。但是几乎每个RDBMS概念（索引、磁盘存储、优化、分区、分发等）都是用来解决相同的问题的。也就是说：“我如何才能尽快获得所需的准确数据？”当您将这些概念结合在一起以满足您的数据检索需求时，您会使您的SQL请求变得异常快速，即使是面对巨大的数据。
为了好玩，请允许我用一个类比来解释它

假设有一本关于世界历史的巨著。它有42层楼那么大

现在，如果图书管理员每年把那本书分成一本书怎么办。这使得查找特定年份所需的所有信息变得更加容易。因为你可以把其他的书放在书架上。

一本小书也更容易携带

这就是表分区的意义所在。（）

基于对大多数查询有用且具有良好平均分布的键（或列集）将数据块保持在一起。

这可以减少IO，因为只需要访问相关的块

现在，如果图书管理员解开那本书怎么办。并将页面集发送到许多不同的库。
当我们需要某些信息时，我们会要求每个图书馆向我们发送所需页面的副本。

更妙的是，这些图书馆员已经可以汇总他们页面上的信息，然后只将他们的摘要发送给一家为您收集这些信息的图书馆

这就是表格分布的意义所在。（）

将数据分布在不同的节点上。
分区发生在各个分布中。从概念上讲，您可以在每个发行版中使用不同的分区策略，尽管Azure SQL数据仓库中不支持这种策略。@DavidBrowne Microsoft我已删除了建议分发分区的句子。那很有趣。我需要阅读更多关于Azure的MPP实现的细节。我习惯于使用类似的Teradata，但也不是这样。SQL DW术语中的分发或分发数据库实际上是指构成每个SQL DW实例的60个底层数据库之一。SQL DW的一个实例可以由1-60个计算节点供电，而实际节点数必须可以被60整除，因此每个节点将为相同数量的分布式数据库供电。在channel9和youtube上有关于SQL DW最佳实践的演示，涵盖了分区的好、坏和丑，值得回顾。简言之，您需要有大量数据才能使表分区成为SQL DW中的必要部分。这是一个很好的类比。要求每个图书馆发送我们需要的任何页面要比直接去大书慢，如果大书相对来说比较便宜的话