散布式 SQL 数据库会将运行程序数据存储在多个节点上，从存储和计算的角度提高了可裁减性。这种散布象征着某些运行程序恳求，包括 JOIN 操作和聚合，或者跨多个数据库节点，或者造成数据在网络中的传输。
为了减轻网络提前对全体运行程序性能的影响，一些数据库支持共置和交织表格。这种优化技术准许将子表格记载与其父行一同存储。因此，在口头查问时，某些须要查问父子记载的恳求或者会更快，由于数据库节点在数据传输环节中的负载较小。
但是，像任何优化技术一样，共置和交织表格也有其优缺陷。让咱们深化了解这些表格类型，以更好地理解它们的好处和掂量。
定义
共置表格（Colocated Tables）和交织表格（Interleaved Tables）是数据库中的优化技术，用于改善数据存储和查问性能。
共置表格（Colocated Tables）
共置表格是一种优化方法，准许将子表格（child table）的记载与其父表格（parent table）的行一同存储在相反的物理位置或相邻的位置。它经过将相关数据搁置在同一节点或相近节点过去提高查问效率，尤其关于须要频繁启动父子表格数据关联的查问来说，可以缩小网络传输和优化查问性能。
交织表格（Interleaved Tables）
交织表格是共置表格的一种不凡类型。与共置表格不同的是，交织表格会在同一物理表结构和数据库文件中将子行与其父行物理地相邻存储，而不是分开存储。逻辑上，这些子表格和父表格依然是不同的表格，但物理上它们的数据行被交织存储，这有助于更快地口头联结查问和缩小数据查找的次数。
总的来说，这些优化技术旨在提高数据库查问效率，缩小数据传输，特意是针对须要频繁启动父子表格数据关联的查问，经过优化数据存储和组织来改善性能。
共置表格
举个例子: 想象一个虚拟公司开发电子商务运行程序，准许各种商家在线开售商品。
该运行程序包括两个关键表格，跟踪Customers（客户）和他们的Orders（订单）（留意，色彩用于辨别来自不同客户的订单）。
公司估量每天会有数百万生动客户，并选择经常使用一个蕴含 3 个节点的散布式数据库集群以增强可裁减性和可用性。
在开发阶段，数据库散布了一切运行程序记载到集群中，确保每个节点存储了可比竞赛的数据并处置了相似的读写上班负载。
在一个架构委员会会议时期，公司选择尝试配置，该配置准许 将子表格记载与父表格的行一同存储 。
结果，Order（子表格）与Customer（父表格）共置，并且数据库开局在相反节点上将订单与其客户记载一同存储。
团队选用了试验表共置技术来评价一些恳求的性能改良，这些恳求须要在Customer和Order表格之间启动 JOIN 操作。例如，当运行程序须要计算客户的总支出时，该恳求将在特定的数据库节点上口头。
公司确实观察到了一些查问的性能改良。
交织表格
在电子商务服务的开发阶段，公司探求了几个散布式 SQL 数据库。其中一个数据库提供了交织表格的支持，促使团队也尝试了这种表格类型。
交织表格是共置表格的一种特定类别。与共置表格相似，交织表格将子表格记载与其父表格记载一同存储。但与经典共置表格不同，经典共置表格在物理表格结构中将子和父记载存储在不同的物理表格结构中，交织表格则在同一表格结构和数据库文件中物理地将子行搁置在其父行旁边（逻辑上，Customer和Order依然是不同的表格）。
经过这种存储级别的优化，公司发现了与之前经典共置表格测试的相反查问的额外性能参与。这种参与是由于客户及其订单存储在内存和磁盘中的同一页面上，须要更少的查找。
共置和交织表格掂量
随着时期的推移，公司凑近电子商务运行程序的预消费测试阶段，出现了新的应战。
当团队加载一个消费级数据集并开局负载测试时，他们遇到了共置表格的第一个掂量 —数据和负载歪斜。此外，由于新的业务需求，工程团队遇到了这些表格特定的另一个掂量 — 选用最佳的父表格启动共置。
数据和负载歪斜掂量
数据歪斜是指集群中的一个节点开局存储比其余节点显着更多的运行程序记载。这种不平衡通常造成负载歪斜，由于过载的节点必定处置更多的运行程序恳求并处置更大的数据量。
在早期开发阶段，团队曾经留意到某些客户比其余客户更频繁地购物。这种客户行为造成某些数据库节点存储的订单比其余节点多。例如，第二个节点最终存储了比第一和
第三个节点算计更多的订单（5 > 2 + 2 = 4）。
当公司开局在经常使用消费级数据集的预消费环境中启动测试时，这些数据和负载歪斜疑问变得愈加显著。虽然某些客户在系统中只要几十个订单，但其余购物频率更高的客户则积攒了数百甚至数千个经过运行程序处置的订单。
这些经常购物的顾客是某些节点存储和处置更少数据的关键要素。
据我所知，针对这种特定的数据歪斜疑问没有繁复的处置方案。共置表格将子记载映射到存储父记载的节点，并且每个父记载一次性只能映射到一个数据库节点。
因此，为了将特定客户的订单散布到多个节点，必定有多个标识该客户的记载。例如，经过在Customer主键(id, bucket)中参与bucketID，你可认为经常购置者创立多个记载 —Customer (1, 1),Customer (1, 2),Customer (1, 3)等。而后，可以将客户的订单参与到特定的桶中，从而准许数据库将它们散布到多个节点。但是，这种方法使运行程序逻辑变得愈加复杂，须要选择桶的数量和每个新订单的适宜桶。
最佳父表格掂量
共置表格的第二个掂量与选用最适宜的父表格启动共置无关。
实践上，电子商务运行程序的数据库架构要复杂得多，涵盖了许多相关和依赖相关。
例如，虽然客户最后计划购置一件商品，但通常会最终在购物车中有几个产品。因此，一个订单或者包括两个或更多已购置的产品。
假定公司引入了SoldProducts表格来跟踪一切客户订单中开售的产品。相似于Orders表格，选择将这个新表格与Customer表格共置。
选用这种共置战略是有要素的。运行程序经常须要口头恳求，这些恳求衔接了Customer、Order和SoldProduct表格的数据。例如 —客户在最近一个月内购置了什么产品？
因此，订单和已售产品的记载如今都与坚持其客户记载的数据库节点一同存储。
但是，在预消费测试的中途，来自业务团队的新要求出现了。他们的指标是优先思考一个专门用于商家和公司物流以及业务增长部门的微服务。该服务旨在使商家和公司能够跟踪和预测各种产品的需求和可用性。经过实施此配置，公司可以经过向具备相似喜好的客户介绍抢手产品来提高开售，而商家则可以被动补充产品。
工程团队选择将表Product（子表格）记载与Merchant表格（父表格）的行共置。
但是，从性能的角度来看，这种方法证实是不够的，由于许多查问须要衔接Merchant、Product和SoldProduct表格的数据。这样一个查问的示例是 —最近 12 小时内购置的最抢手产品是什么？
从技术上讲，将已售产品记载存储在相应的商家左近是可行的。但有一个复杂疑问 —SoldProduct记载曾经与Customer表格共置，以满足另一个微服务的要求。
这是最佳父表格掂量的一个例子。例如，SoldProducts表格一次性只能与一个父表格共置。确定哪种共置战略从久远来看是最好的通常是一项艰巨的义务。
总结
像每一种优化技术一样，表共置和交织都有其优势和掂量。 要确保共置不是你的用例的过早优化，首先在没有共置的状况下运转运行程序上班负载。审核对询口头方案，并运行防止须要共置表格的优化。有时，你只要要创立适当的索引，为 JOIN 操作启用批处置，为页面缓冲区提供更多内存等 — 在看到口头方案之前你永远不会知道。但是，假设什么都不起作用，那么思考共置表格，确保它们的掂量不会对常年发生不良影响。