我们有一个带有 timescaledb 插件的 postgres 数据库，用于存储基于时间的传感器数据，以千兆字节的数量并不断增长。数据库中有两个表，其中包含索引、外键和所有内容，如用于客户数据库的经典数据库或其他任何内容。问题是存在哪些性能选项可以提高插入性能和查询性能。

传感器数据由传感器 ID、时间戳和浮点值组成。传感器 ID 又由一个 ID 和一个面包屑串组成，通常大约 50 个字符长，但有时可能会更长一些。将此面包屑插入到传感器数据的表中会大大增加表的大小。因此，传感器 ID 位于单独的表中。

传感器数据表具有传感器 ID 表的外键以及传感器 ID 和时间的索引。

每秒从数千台设备中非常频繁地发生插入。所以插入性能很重要。除了清除旧数据之外，传感器数据永远不会更改，也不会发生删除。有时很少有用户执行查询来调查传感器数据。该应用程序定期运行查询以调查当前和以前的传感器数据是否已更改。

现在的问题是如何针对这个用例优化数据库。一种想法是删除外键以提高插入性能。我不确定查询性能是否真的不受此影响或受什么影响。传感器数据库对传感器 ID 和时间具有唯一的键约束。问题是查询需要现有索引，因此无法清除。

任何关于如何针对这种情况进行调整的想法都值得赞赏。

我有看起来像这样的表：

我正在尝试对这两个表进行 INNER JOIN，这样我就会得到这样的结果：

但是当我运行以下查询时：

这就是我得到的：

我不明白这里发生了什么。似乎添加了一些随机的附加行，但我不知道它为什么会发生。原表只有 6 行，但查询表返回 10。

我不知道这个信息是否有帮助，但这是一个 TimescaleDB Hypertable。这是创建表的源代码：

我按照以下手册操作：https ://docs.timescale.com/v1.0/using-timescaledb/backup

当我将它转储到二进制文件中时，一切都按预期进行（可以轻松恢复）。

但是，当我将其转储为纯文本 SQL 时，将创建对超表的插入。是否可以为表本身创建 INSERTION ？

假设我有一个“自动”表，其中包含 id、brand、speed 列并且只有一行：1,Opel,170

转储到 SQL 中的结果如下：

我需要的是这个（让 TS 在后台完成工作）：

这有可能吗？（我知道我可以从 pg_dump 中排除表，但这不会创建所需的插入）

设想：

1. 我正在尝试为船舶操作建立一个实时监控网页
2. 我有 1,000 - 10,000 艘船在运营
3. 所有船舶都向 DB 发送实时数据，24 小时 - 30 天
4. 插入的每个新数据的维度为 1 行 X 100 列
5. 加载网页时，将获取所选船舶的所有历史数据并进行可视化
6. 查询船舶实时数据表的最后一行，并在网页上抓取更新实时画面
7. 每艘船都有自己的非实时数据，如船舶尺寸、货物、乘务员等……

到目前为止，我一直在考虑为每艘船创建一个新模式。像这样的东西：

这是存储单个船舶实时数据并在网络服务器上获取它们的好方法吗？你会推荐什么其他方法？

对于时间序列，我已经在使用名为 Timescale DB 的 PostgreSQL 扩展。我的问题是关于存储时间序列数据，以防我有很多船。在构建新模式时区分每艘船的 RT 数据是个好主意吗？

++ 我对 PostgreSQL 很陌生，我从其他人那里得到的一些建议对我来说太高级了......如果你提出一些方法，我将不胜感激，简要解释一下它是什么

考虑下表，该表记录了属于不同类别的不同公司的不同产品的价格变化。

要明确的列值将是：

category_id- 一个单独的表将 id（唯一的 bigint 值）映射到类别名称 - 100 个类别

（电子、时尚、健康、运动、玩具、书籍）

industry_id- 一个单独的表将 id（唯一的 bigint 值）映射到行业名称 - 一个类别中的数千个行业

（诺基亚、苹果、微软、PeterEngland、Rubik、Nivia、中远）

product_id- 一个单独的表格将 id（唯一的 bigint 值）映射到产品名称 - 一个行业中的数百万种产品

time(unix time as bigint) - 价格被修改的时间，

price- 数千个不同的值 - (200, 10000, 14999, 30599, 450)

product_info- 包含产品额外详细信息的 json（键/值对的数量可能会有所不同）

以多种方式查询该表以分析产品价格在一天/周/月作为小时/天/周/月范围内变化的趋势，作为图表。趋势可能基于否。的产品，正在修改的独特产品。

例如谷歌样本趋势

按原样（as string）存储 JSON 会占用更多存储空间。因此，我尝试在 json 中存储键值，并在单独的表中使用递增的序列 ID，并使用这些 ID。

喜欢

{seller:"ABC Assured", discount:10, model:XYZ, EMIoption:true, EMIvalue:12, festival_offer:28, market_stat:comingsoon, curreny: rupees}

变成

{"1":1, "2":2", "3":3, "4":4, "5":5, "6":6, "7":7, "25":107}

---

{seller:"Prime seller", discount:10, model:XYZ, EMIoption:true, EMIvalue:12, festival_offer:28, market_stat:comingsoon, curreny: "canadian dollars"}

变成

{"1":110, "2":2", "3":3, "4":4, "5":5, "6":6, "7":7, "25":109}

---

对于大约 20M 的数据集，它减少了大约 1.5GB。

增加键值基数，增加序列号。所以我尝试将十进制存储为十六进制。

{"1":1, "2":2", "3":3, "4":4, "5":5, "6":6, "7":7, "25":107}

变成

{"1":1, "2":2", "3":3, "4":4, "5":5, "6":6, "7":7, "19":"6B"}

---

{"1":110, "2":2", "3":106, "4":4, "5":5, "6":6, "7":7, "25":109}

变成

{"1":, "2":2", "3":"6A", "4":4, "5":5, "6":6, "7":7, "19":"6D"}

---

将这些十进制整数存储为十六进制整数也是如此。

1. 进一步节省存储空间？（因为在视觉上它似乎被压缩了）
2. JSON是保留key-value的数据类型，还是存储为字符串？
3. 使数据压缩？
4. 提高读取性能？
5. 或者无论如何它可以改进？（索引，或任何？）

在普通的 psql 应用程序中，查询需要几分钟才能完成。由于它符合时间序列数据，我们使用 TimescaleDB 扩展，它的分片机制提高了查询执行，但我们需要亚秒级的结果。

查询样本: 每天检查给定类别中的所有产品的价格更改为 500 的次数，按月分组。

检查在过去 10 个月中按月分组的给定类别中的所有产品的价格更改为 (100,200,300,400,500,600,700,800,900,1000) 中的任何一个的次数。

在给定的类别中选择在给定时间范围内价格已更改的产品详细信息

在给定类别中选择价格在给定时间范围内发生变化的行业和产品 ID 详细信息

选择产品价格变化详情，在折扣 10% 的时间范围内，在特定类别中

选择产品价格变化详情，在特定卖家销售的时间范围内，在特定类别中

在大多数情况下，查询不会包含category_id在选择列中。

有谁知道这些设置在做什么？我不太可能在 Google 中找不到可以帮助我理解这一点的东西。它在表属性->架构中：

• _timescaledb_cache
• _timescaledb_catalog
• _timescaledb_internal

我尝试在 timescaleDb 1.0.0 中使用自适应分块。但它没有按预期工作。

1. 我正在使用chunk_target_size => 'estimate'.
2. 当我检查 chunk_target_size 时，它​​约为 1.2 亿——这似乎是合理的
3. 现在我开始一个测试程序，它将循环 5k 次并在每个事务中插入 1k 行（所以总共只有 500 万行）
   • 然后当我检查块大小时，我看到大约 3.5k 块只有 152kB（第一个是 88B）！

我错过了什么？

SQL 语句

1-创建超表

2-检查 chunk_target_size

3-检查块大小

附加信息

固定块大小：

当我将 chunk_target_size 设置为 100MB 时，chunk_target_size 将约为 1.04 亿。但是在插入数据后最大。chunk_relation_size 也只有 152kB

块时间间隔

当我设置 chunk_time_interval 而不是 chunk_target_size 时，我会得到更大的 chunk_relation_sizes。

更新 (2.11.2018)

我使用PGTune来改进数据库配置。以前只有 128MB -现在shared_buffers是 1280MB。
随着这个变化，chunk_target_size已经增加到大约 12 亿，但生成的块仍然只有 152kB。

我想使用 TimescaleDB 直接从存储在 PostgreSQL-DB 中的数据中删除峰值。

我的数据存储为间隔为 1 秒的值，我想计算 5 分钟的平均值而没有峰值。

我使用标准偏差确定峰值，并排除所有超过固定 zscore 的数据。

因此，在第一步中，我获取与我的分析相关的所有数据（data_filtered），然后计算每个 5 分钟块的平均值和标准偏差（avg_and_stddev_per_interval），然后将初始数据（data_filtered）与计算的 avg 和 stddev 连接起来，排除所有不符合我的标准的值，最后计算没有峰值的最终 5 分钟平均值。

这一切都很好，但速度非常慢。在没有任何分组 ( select * from data_filtered) 的情况下请求完整数据并在本地计算我的标准要快得多。但是，我想减少数据量，因此在这种情况下这种方法是不可能的。

有什么方法可以加速我的查询？

我想在 JOOQ 中实现一个基本的 time_bucket 语句。

如果我在控制台中运行此语句，它可以正常工作：

如果我尝试使用 JOOQ 实现它，我会遇到生成的例程不起作用的问题，因为我无法添加间隔。

我想要类似下面的代码，但间隔“5分钟”不起作用：

有没有一种简单的方法来实现间隔？

我正在尝试执行高级分析查询来驱动 Web 应用程序。我将 Hapi、Objection、Knex 和 Postgres 与 TimescaleDB 一起使用。对于典型的关系查询，这一切都运行良好。但是，我无法弄清楚如何执行这个涉及加入从 Postgres 生成的匿名表的聚合查询generate_series。我不得不求助于编写原始 SQL，而不是 Objection/Knex 查询生成器。我正在使用一些 Postgres 的内置函数，以及time_bucket来自 Timescale 的函数。time_bucket本质上是根据参数中指定的间隔创建数据的汇总。查看此链接以获取有关我正在尝试执行Gap Filling的更多信息。

这是查询，它使用异议模型上的原始方法工作。我相信像这样进行字符串插值会导致潜在的 SQL 注入。但是，我希望将其转换为 Objection/Knex 使用的查询构建器方法，因此它更多的是 JavaScript，而不是 SQL，这将解决 SQL 注入问题。

我已经用 Objection/Knex 做了几次尝试。这是我制作此查询的最成功尝试。但是，我认为 where 子句不在正确的位置。

使用.debug()，我可以看到下面发布的查询输出。

感谢您提供任何帮助，因为我没有使用 Objection 来执行此操作，并且找不到任何文档。

2018 年 11 月 15 日更新

我得到它来执行带有异议的查询。但是，我得到一个空数组作为结果。与我在上面制作的原始 SQL 查询不同（它确实给了我预期的结果），我只得到一个空数组作为查询生成器的输出。关于我做错了什么的任何想法。我试图将连接翻转为正确的连接，但没有运气。

附件是 Debug 的 SQL 输出。