TDengine 数据模型设计：多列模式与单列模式对比（二）

五、多列模式与单列模式性能大比拼

5.1 写入性能对比

为了对比多列模式与单列模式的写入性能，我们进行了一系列的实验。实验环境配置如下：CPU 为 Intel Core i7-12700K，内存为 32GB DDR4，硬盘为三星 980 PRO NVMe SSD，操作系统为 Ubuntu 20.04。TDengine 版本为 3.0.6.0。

在实验中，我们模拟了物联网设备数据采集的场景，设置了 1000 个数据采集点，每个采集点每分钟采集一次数据，每次采集包含 5 个物理量。在多列模式下，将这 5 个物理量存储在同一张表中；在单列模式下，为每个物理量分别创建一张表。

实验结果表明，在数据量较小时，两种模式的写入速度差异并不明显。随着数据量的不断增大，多列模式的写入速度优势逐渐显现。当数据量达到 100 万条时，多列模式的写入速度比单列模式快了约 30%。这是因为多列模式下，一次写入操作可以同时写入多个物理量的数据，减少了写入操作的次数，从而提高了写入效率。

5.2 存储效率对比

存储效率是衡量数据模型优劣的重要指标之一。在 TDengine 中，数据存储采用了列式存储和压缩技术，以提高存储效率。我们对多列模式和单列模式下不同数据类型的存储占用空间和压缩比进行了分析。

实验数据显示，对于整型数据，多列模式的压缩比约为 8:1，单列模式的压缩比约为 6:1；对于浮点型数据，多列模式的压缩比约为 5:1，单列模式的压缩比约为 4:1。这表明多列模式在存储效率上具有一定的优势，能够更有效地减少数据的存储空间占用。

这是因为多列模式下，同一列的数据具有相似性，更容易被压缩算法识别和压缩。而单列模式下，每个表的数据量相对较小，数据的相似性不如多列模式明显，因此压缩效果相对较差。

5.3 查询性能对比

在实际应用中，查询性能是用户最为关注的指标之一。我们模拟了复杂查询场景，对比了多列模式和单列模式的查询响应时间。查询场景为：查询某一时间段内所有设备的多个物理量的平均值，并按照设备的某个标签进行分组。

实验结果显示，在复杂查询场景下，多列模式的查询响应时间明显短于单列模式。当查询的数据量为 10 万条时，多列模式的平均查询响应时间为 50ms，而单列模式的平均查询响应时间为 120ms。这是因为多列模式下，数据存储在同一张表中，查询时可以通过一次扫描获取所有需要的数据，减少了表连接和数据扫描的次数，从而提高了查询效率。

而单列模式下，由于数据分散在多个表中，查询时需要进行多表连接操作，增加了查询的复杂度和执行时间。此外，随着数据量的增大和表数量的增多，单列模式下的元数据管理和查询优化难度也会相应增加，进一步影响查询性能。

六、实际应用案例深度解读

6.1 案例一：智能工厂中的应用

某大型智能工厂主要生产电子产品，拥有大量的生产设备和传感器。这些设备和传感器每分钟都会采集大量的生产数据，包括设备的运行状态、温度、压力、产量等信息。为了实现对生产过程的实时监控和优化，工厂引入了 TDengine 来存储和管理这些时序数据。

在数据模型设计方面，工厂最初采用了单列模式。为每个物理量创建一个超级表，如temperature超级表用于存储设备温度数据，pressure超级表用于存储设备压力数据等。每个超级表下根据不同的设备创建子表，例如temperature_device1子表用于存储设备 1 的温度数据。

随着业务的发展和数据量的不断增加，工厂发现单列模式在查询多个物理量的数据时效率较低。例如，当需要查询某一时间段内所有设备的温度和压力数据时，需要进行多表关联查询，这导致查询响应时间较长，无法满足实时监控的需求。

为了解决这个问题，工厂对数据模型进行了优化，采用了多列模式。将设备的温度、压力、运行状态等多个物理量存储在同一张超级表中，如下所示：

CREATE STABLE production_data (

ts TIMESTAMP,

temperature FLOAT,

pressure FLOAT,

status INT,

production_count INT

) TAGS (

device_id BINARY(64),

production_line INT

);

在这个超级表中，ts是时间戳列，temperature、pressure、status和production_count是采集量列，分别表示温度、压力、设备状态和产量；device_id和production_line是标签列，分别表示设备 ID 和生产线编号。

采用多列模式后，工厂在查询多个物理量的数据时，只需查询一张表，大大提高了查询效率。同时，由于数据存储在同一张表中，数据的关联性更强，便于进行数据分析和挖掘。例如，通过分析设备温度、压力与产量之间的关系，工厂可以优化生产工艺，提高产品质量和生产效率。

6.2 案例二：车联网系统中的应用

某车联网公司致力于为用户提供车辆远程监控、智能驾驶辅助等服务。公司的车联网系统连接了数百万辆汽车，这些汽车通过车载传感器实时采集车辆的位置、速度、油耗、故障信息等数据，并上传至车联网系统进行存储和分析。

在系统建设初期，车联网公司采用了单列模式来存储数据。为每个物理量创建一个超级表，如location超级表用于存储车辆位置数据，speed超级表用于存储车辆速度数据等。每个超级表下根据不同的车辆创建子表，例如location_car1子表用于存储车辆 1 的位置数据。

随着车辆数量的快速增长和业务需求的不断变化，单列模式逐渐暴露出一些问题。首先，表的数量过多，导致元数据管理难度增大，系统性能受到影响。其次，在进行复杂查询时，多表关联操作使得查询效率低下，无法满足实时性要求。例如，当需要查询某一区域内所有车辆的位置、速度和油耗数据时，查询响应时间较长，无法为用户提供及时的服务。

为了提升系统性能和满足业务需求，车联网公司对数据模型进行了调整，采用了多列模式。将车辆的位置、速度、油耗、故障信息等多个物理量存储在同一张超级表中，如下所示：

CREATE STABLE vehicle_data (

ts TIMESTAMP,

latitude DOUBLE,

longitude DOUBLE,

speed FLOAT,

fuel_consumption FLOAT,

fault_code INT

) TAGS (

vehicle_id BINARY(64),

vehicle_type INT

);

在这个超级表中，ts是时间戳列，latitude、longitude、speed、fuel_consumption和fault_code是采集量列，分别表示车辆的纬度、经度、速度、油耗和故障代码；vehicle_id和vehicle_type是标签列，分别表示车辆 ID 和车辆类型。

采用多列模式后，车联网公司在查询多个物理量的数据时，查询效率得到了显著提升。同时，由于数据的集中存储，便于进行数据的整合和分析，为公司提供了更全面的车辆运行状态信息。例如，通过分析车辆的位置、速度和油耗数据，公司可以为用户提供个性化的驾驶建议，帮助用户降低油耗，提高驾驶安全性。

七、模式选择策略与建议

7.1 根据数据特征选择

• 数据采集频率：如果数据采集频率较高，每秒或每分钟都会产生大量的数据，多列模式在写入性能上具有明显优势。因为多列模式可以将多个物理量的数据一次性写入，减少了写入操作的次数，从而提高了写入效率。例如，在智能电网监测中，电表数据的采集频率通常较高，采用多列模式可以更好地应对大量数据的快速写入需求。而对于采集频率较低的数据，单列模式和多列模式的写入性能差异并不明显，可以根据其他因素进行选择。

• 数据量大小：当数据量较大时，多列模式在存储效率和查询性能上的优势更加突出。多列模式采用列式存储和高效的压缩算法，能够有效减少数据的存储空间占用，同时在查询时可以减少数据扫描的范围，提高查询速度。例如，在车联网系统中，连接的车辆数量众多，产生的数据量巨大，采用多列模式可以更好地管理和分析这些数据。而对于数据量较小的场景，单列模式的灵活性和简单性可能更具优势。

• 数据类型差异：如果采集的数据类型较为单一，如都是整型或浮点型数据，多列模式和单列模式在存储和查询性能上的差异不大。但如果数据类型差异较大，如同时包含整型、浮点型、字符串型等多种数据类型，单列模式可能更适合。因为单列模式下每个表只存储一种数据类型，便于针对不同的数据类型进行优化，提高存储和查询效率。例如，在互联网业务监控中，可能会同时采集用户行为数据（如点击次数、浏览时间等，多为整型）和系统性能指标（如 CPU 使用率、内存占用率等，多为浮点型），采用单列模式可以更好地管理这些不同类型的数据。

7.2 根据业务需求选择

• 实时性要求：对于实时性要求较高的业务场景，如工业自动化控制、智能交通等，多列模式能够更快地处理和查询数据，满足实时监控和决策的需求。多列模式下，数据存储在同一张表中，查询时可以通过一次扫描获取所有需要的数据，减少了查询的时间延迟。而单列模式在查询多个物理量的数据时，需要进行多表关联查询，可能会增加查询的时间，无法满足实时性要求。例如，在工业自动化生产线上，需要实时监控设备的运行状态，一旦发现异常需要立即采取措施，采用多列模式可以更快地获取设备的各项数据，及时发现问题并解决。

• 查询复杂度：如果业务中经常需要进行复杂的查询操作，如同时查询多个物理量的数据，并进行聚合、关联等操作，多列模式更为合适。多列模式下，数据的关联性更强，便于进行复杂的查询和分析。而单列模式在处理复杂查询时，由于数据分散在多个表中，需要进行多表连接操作，增加了查询的复杂度和执行时间。例如，在智能工厂中，需要分析设备的温度、压力、产量等多个物理量之间的关系，以优化生产工艺，采用多列模式可以更方便地进行这些复杂的查询和分析。

• 数据更新频率：如果数据更新频率较低，多列模式和单列模式都可以满足需求。但如果数据更新频率较高，单列模式可能更具优势。因为单列模式下每个表只存储一个物理量，数据更新时只需要更新对应的表，不会影响其他表的数据，从而减少了数据更新的冲突和复杂性。例如，在设备状态监测中，设备的某些参数可能会频繁更新，采用单列模式可以更方便地对这些参数进行更新和管理。

八、总结与展望

8.1 总结对比结果

通过对 TDengine 中多列模式与单列模式的深入分析和对比，我们可以得出以下结论：

• 写入性能：在写入性能方面，多列模式在处理大量数据时具有明显优势。由于多列模式可以将多个物理量的数据一次性写入，减少了写入操作的次数，从而提高了写入效率。而单列模式下，每个物理量都需要单独写入，写入操作次数较多，在数据量较大时，写入性能相对较低。

• 存储效率：多列模式在存储效率上表现更为出色。多列模式采用列式存储和高效的压缩算法，能够有效减少数据的存储空间占用。同时，多列模式下同一列的数据具有相似性，更容易被压缩算法识别和压缩，从而提高了压缩比。单列模式下，每个表的数据量相对较小，数据的相似性不如多列模式明显，因此压缩效果相对较差，存储效率也较低。

• 查询性能：在查询性能方面，两种模式各有优劣。多列模式在查询多个物理量的数据时具有优势，因为数据存储在同一张表中，查询时可以通过一次扫描获取所有需要的数据，减少了表连接和数据扫描的次数，从而提高了查询效率。而单列模式在查询单个物理量的数据时，查询操作只需要扫描对应的表，无需扫描其他无关列的数据，从而减少了数据扫描的范围，提高了查询速度。特别是在查询单个物理量的时间序列数据时，单列模式的查询性能优势明显。

• 适用场景：多列模式适用于数据采集频率高、数据量大、数据类型单一且查询复杂的场景，如物联网、工业自动化、智能电网等领域。在这些场景中，设备通常会同时采集多个物理量，且这些物理量之间具有较强的关联性，需要同时进行分析和处理。单列模式适用于数据采集点的种类和数量经常变化、数据更新频率较高且查询以单个物理量为主的场景，如互联网业务监控、科研实验数据采集、设备状态监测等领域。在这些场景中，数据的灵活性和独立性更为重要，单列模式能够更好地满足业务需求。

8.2 未来发展趋势展望

随着物联网、大数据、人工智能等技术的不断发展，时序数据的规模和复杂性将不断增加，对 TDengine 数据模型的性能和功能也提出了更高的要求。未来，TDengine 数据模型可能会朝着以下几个方向发展：

• 融合创新：未来 TDengine 可能会进一步融合多列模式和单列模式的优点，根据不同的业务场景和数据特点，自动选择最优的数据模型。例如，在某些复杂场景中，可能会同时使用多列模式和单列模式，将关联性较强的物理量存储在多列模式的表中，将独立性较强的物理量存储在单列模式的表中，以充分发挥两种模式的优势。

• 智能化：随着人工智能技术的不断发展，TDengine 数据模型可能会引入人工智能算法，实现智能化的数据管理和优化。例如，通过机器学习算法自动分析数据特征，选择最合适的数据模型和存储策略；利用深度学习算法进行数据预测和异常检测，为业务决策提供支持。

• 云原生：随着云计算技术的普及，云原生数据库成为了发展趋势。TDengine 可能会进一步优化其云原生特性，提供更加便捷、高效的云服务。例如，支持多租户隔离、弹性伸缩、自动备份恢复等功能，满足不同用户的需求。

• 与其他技术的融合：TDengine 可能会与其他技术进行更深入的融合，如区块链、边缘计算等。例如，利用区块链技术保证数据的安全性和不可篡改；结合边缘计算技术，在设备端进行数据的预处理和存储，减少数据传输压力，提高系统的实时性和可靠性。

总之，TDengine 作为一款优秀的时序数据库，其多列模式与单列模式在不同的场景下都有着各自的优势。在实际应用中，我们应根据具体的业务需求和数据特点，选择合适的数据模型，以充分发挥 TDengine 的性能优势。同时，我们也期待 TDengine 在未来能够不断创新和发展，为时序数据处理领域带来更多的惊喜和突破。