英文原文：
TimescaleDB Data Model
作为一个支撑完好 SQL 的关系型数据库，TimescaleDB 支撑灵敏的数据类型，可依据分歧用户的实践状况实行优化。因而，Timescale 与大大多数其它运用“窄表”模子时序数据库有所分歧。
具来讲来，TimescaleDB 可以支撑宽表模子和窄表模子。我们运用一个物联网（IoT）的示例来会商这两个模子在功能均衡和意义上的分歧的地方。
想象有超越1000个物联网装备被散布在各地，以各类分歧的工夫距离来搜集情况数据。这些数据包括：
标识信息（Identifiers）: 装备id（device_id）, 工夫戳（timestamp）
元数据（Metadata）: 地位id（location_id）, 装备类型（dev_type）, 固件版本（firmware_version）, 客户id（customer_id）
装备目标（Device metrics）: cpu均匀占用（cpu_1m_avg）, 闲暇内存（free_mem）, 已运用内存（used_mem）, 收集旌旗灯号强度（net_rssi）, 收集丢包率（net_loss）, 电池电量（battery）
传感器目标（Sensor metrics）: 温度（temperature）, 湿度（humidity）, 压力（pressure）, 一氧化碳（CO）, 二氧化氮（NO2）, PM10
举例来讲，你接纳到的数据多是下面如许的：
| timestamp | device_id | cpu_1m_avg | free_mem | temperature | location_id | dev_type |
|---|
| 2017-01-01 01:02:00 | abc123 | 80 | 500MB | 72 | 335 | field |
| 2017-01-01 01:02:23 | def456 | 90 | 400MB | 64 | 335 | roof |
| 2017-01-01 01:02:30 | ghi789 | 120 | 0MB | 56 | 77 | roof |
| 2017-01-01 01:03:12 | abc123 | 80 | 500MB | 72 | 335 | field |
| 2017-01-01 01:03:35 | def456 | 95 | 350MB | 64 | 335 | roof |
| 2017-01-01 01:03:42 | ghi789 | 100 | 100MB | 56 | 77 | roof |
如今，我们来看看模仿这些数据的各类办法。
窄表模子
大大多数时序数据库表现数据无外乎以下几种方法：
在这类模子中，每一个目标/标签集的组合可以看作一个自力的包括一个工夫/值的键值对的工夫序列。
运用我们的上述的例子，这个办法将会发生九个分歧的工夫序列，每一个工夫序列都是由一个独一的标签聚集来定义的。
1. {name: cpu_1m_avg, device_id: abc123, location_id: 335, dev_type: field}
2. {name: cpu_1m_avg, device_id: def456, location_id: 335, dev_type: roof}
3. {name: cpu_1m_avg, device_id: ghi789, location_id: 77, dev_type: roof}
4. {name: free_mem, device_id: abc123, location_id: 335, dev_type: field}
5. {name: free_mem, device_id: def456, location_id: 335, dev_type: roof}
6. {name: free_mem, device_id: ghi789, location_id: 77, dev_type: roof}
7. {name: temperature, device_id: abc123, location_id: 335, dev_type: field}
8. {name: temperature, device_id: def456, location_id: 335, dev_type: roof}
9. {name: temperature, device_id: ghi789, location_id: 77, dev_type: roof}这些工夫序列的范畴巨细是与每一个标签的基数的穿插乘积，也就是(# names) × (# device ids) × (# location ids) × (device types)。跟着基数的增加，一些工夫序列数据库会碰到功能问题，终极限制了可以存储在单个数据库中的装备类型和装备的数目。
TimescaleDB 支撑窄表模子，而且不会像其他工夫序列数据库那样遭到类似的基数限制。假如您独自搜集每一个目标，那末窄表模子就成心义。它答应您经过添加新标志来添加新目标，而无需实行正式的架构更改。
可是，假如要搜集具有类似工夫戳的非常多怀抱规范，则窄表模子就不具有高效性，由于它需求为每一个怀抱规范写入工夫戳。这终极会招致更高的存储和获得请求。另外，联系关系分歧怀抱规范的查询也更庞杂，由于要联系关系的每个额定怀抱规范都需求一个 JOIN。假如您想同时查询多个目标，用宽表格局存储会愈加便捷，这个我们将鄙人一节中实行引见。
宽表模子
TimescaleDB 可以轻松支撑宽表模子。因为该模子不需求 JOIN，所以逾越多个怀抱规范的查询更加轻易。另外，因为该模子只为多个怀抱规范编写了一个工夫戳，因而提取速度也更快。
一个典范的宽表模子将适配一个在给按时间戳中搜集的多个怀抱目标的典范数据流：
| timestamp | device_id | cpu_1m_avg | free_mem | temperature | location_id | dev_type |
|---|
| 2017-01-01 01:02:00 | abc123 | 80 | 500MB | 72 | 42 | field |
| 2017-01-01 01:02:23 | def456 | 90 | 400MB | 64 | 42 | roof |
| 2017-01-01 01:02:30 | ghi789 | 120 | 0MB | 56 | 77 | roof |
| 2017-01-01 01:03:12 | abc123 | 80 | 500MB | 72 | 42 | field |
| 2017-01-01 01:03:35 | def456 | 95 | 350MB | 64 | 42 | roof |
| 2017-01-01 01:03:42 | ghi789 | 100 | 100MB | 56 | 77 | roof |
在这里，每行都是一个新的读数，在给定的工夫内有一组丈量和元数据。这使我们可以保存数据中的关系，并提出比之前更多风趣或探究性的问题。
固然，这不是一种新格局：它是人们在关系数据库中所常常见到的内容。
关系型数据中的 JOINs
TimescaleDB 的数据模子与关系型数据库有着非常多类似的地方：它支撑 JOINs。详细的来讲，它可以在副表中存储其他元数据，然后在查询时运用该数据。
在我们的示例中，有一个独自的地位表，可以将 location_id 映照到该地位的其他元数据中。例如：
| location_id | name | latitude | longitude | zip_code | region |
|---|
| 42 | Grand Central Terminal | 40.7527° N | 73.9772° W | 10017 | NYC |
| 77 | Lobby 7 | 42.3593° N | 71.0935° W | 02139 | Massachusetts |
然后在查询时，经过联系关系这两个表，可以提出以下问题： 在 zip_code 为 10017 时，我们装备的 free_mem 均匀值是几多？
假如没有 JOINs，我们需求对其数据实行反标准化，并将每一个丈量行存储在一切元数据中。这会形成数据收缩，并使数据管理变得愈加艰苦。
有了 JOINs，我们可以自力存储元数据，而且更快捷地更新映照。
例如，假如我们想更新 location_id 为 77 的"region"的数据（例如将"Massachusetts"修正为"Boston"），我们可以间接实行更改，而无需前往并掩盖汗青数据。
本文中的一切译文仅用于进修和交换目标，转载请务必注明文章译者、出处、和本文链接。
2KB翻译任务按照
CC 协议，假如我们的任务有进犯到您的权益，请实时联络我们。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
