查看原文
其他

数据分布背后的逻辑

蒋步星 数据蒋堂 2023-02-25

在分布式数据库及大数据平台中,数据如何分布到多台机器中是个很关键的问题。因为很多运算是数据密集型的,如果数据分布做得不好,就会导致网络传输量变大,从而影响性能。

一般来讲,分布式数据库会提供两种分布策略:对于大表按某个字段(的HASH值)去分布,大多数情况会使用主键,这样可以把数据分拆到多台机器上;对于小表则采用复制性分布,也就是每个机器上都会复制一份。

但是,表的大小并没有绝对的判定标准,很大很小的表都容易识别并采取相应的策略,而那些数据不多不少的中型数据表又该采取哪种策略呢?


要搞清这个问题,我们就要知道数据分布背后的逻辑,什么样的数据分布才算是好的?

合理的数据分布能够有效地减少JOIN运算过程中的网络传输量!这也是数据分布的关键目标。

大部分常规运算都容易分拆到多个机器上分别执行后再汇总,这样,原则上数据只要尽量平均分布就可以由各节点来分摊计算负担。但是JOIN不一样,它涉及关联计算,如果JOIN的两条记录不在同一个节点上,那就需要把它们先传输到一起才能进行运算,这种事当然越少越好了。


那么怎样才能尽量避免JOIN过程中的数据传输呢?

这又要回到我们已经讨论过多次的JOIN类型。回顾一下去年的文章《JOIN运算剖析》,我们把JOIN分成三类:外键、同维、主子。同维表和主子表的JOIN是在主键(或部分)之间进行的,主键不同的两条记录是不可能发生JOIN的,这样,如果数据已经按主键分布的,就不会发生跨节点JOIN的现象了。而外键表的JOIN,维表记录可能被事实表随意引用,无论怎样将维表分布,都有可能发生跨节点JOIN的现象,只有将维表复制到每个节点上去,才能避免JOIN过程中的网络传输。

这样,我们就知道了:同维表和主子表要按主键字段去分布,而维表则要采用复制性策略,每节点都放一份,这样能有效减少跨节点JOIN运算。


但这和大表小表有什么关系?

一般来讲,记录事件的事实表会随着时间推移而不断增大,常常是大表,而这种表之间的JOIN大多数是同维表或主子表(比如订单及明细)关系。而用于外键指向的维表主要是用于存储一些不常变化的属性信息,相对要小一点。于是,本来是事实表要分拆分布、维表要复制分布的策略,就会表现成“大表”分拆、“小表”复制的特征了。

明白了这一点,我们就不会再纠结大表小表的界限在哪里了,其实没有大小之分,而是在数据结构中的地位决定的。


不过,关系数据库中并没有明确的事实表和维表概念,需要我们主动地去识别,有意识地设置分布方案。而且,一定要用主键去分布,随便找一个无关字段去分布,就起不到减少跨节点JOIN的作用了。

有些大数据平台只提供自动(按大小)分布的方案,不能强制复制维表,也不能让同维表和主子表按主键同步分布,这时候分布式计算的效果就不会好了,在选择这些计算体系时需要特别注意。


数据蒋堂 第二年原创文章

- 从一道招聘考题谈起

为什么我们需要C程序员

报表工具的SQL植入风险

内置的数据无法实现高性能

怎样生成有关联的测试数据

遍历复用

- 一些数据压缩手段

用HBase做高性能键值查询?

BI系统中容易被忽视的数据源功能

这个产品能支持多大数据量?

最简单的大数据性能估算方法

大清单报表应当怎么做?

大清单报表的打印?

大数据技术的4个E

做基础软件很悲壮?

做基础软件要投入很多钱?

- 国产操作系统还能怎么做?

- 国产数据库通通都没戏!

- 人工智能中的“人工”

- 存储和计算技术的选择

- 区块链技术的一些疑问

- 数据蒋堂新一年




润乾软件创始人、首席科学家

中国大数据产业生态联盟 专家委员

1989年国际奥林匹克数学竞赛团体冠军成员,个人金牌

清华大学计算机硕士

发明了非线性报表模型,并著《非线性报表模型原理》

创建离散数据集模型,颠覆四十年关系代数理论体系!

2016、2017年中国软件和信息服务业 • 十大领军人物

2017年度中国数据大工匠

数据领域专业技术讲堂《数据蒋堂》创办者


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存