我有一个 PostgreSQL 数据库，我运行了大量的负载。我希望这个负载尽可能快。我已经在使用复制命令等。

我一直在阅读关于timescaledb以及它如何提供改进的插入性能。但是，如果我只关心插入性能，我想知道使用 hypertables 而不是常规表是否有任何缺点？

我被要求为时间序列数据开发数据存储，尽管进行了大量研究，但我不确定要选择的数据模型和存储技术。

关于数据

要存储在数据存储器中的源数据由物理测量单元提供。每个单元可能有也可能没有不同的变量子集，每个测量站有多达 300 个变量（例如燃料类型、燃料消耗、速度），而所有站的不同信号数量约为 1500。预先知道每个站的预期变量子集。但是，随着时间的推移，可能会向站点添加额外的传感器（随着时间的推移，可能需要更改架构）。所有站都以从 20Hz 到 0.2Hz 的不同速率提供数据。

此外，还有相当数量的元数据可供所有这些测量站使用，最终我们将拥有大约 500 个。

数据通常是批量输入的，而不是“实时”流。批次大小从每小时批次到每月批次不等。

关于查询

进行数据查询主要有两个原因，单测站数据的上报和统计分析，以及跨站比较。大约 80% 的查询与过去 30 天内输入的数据有关。查询每天进行，因此SELECT负载超过INSERT负载。

理想情况下查询像

SELECT var1, var2, ... varN FROM station_data WHERE station_id=X OR station_id=Y AND TIMESTAMP BETWEEN ... AND ...;

非 SQL 专家可以轻松访问数据。此外，简单的基于时间的聚合算法应该是可能的（AVG、MAX 等 pp）。

现在的情况

目前，使用高度规范化的结构将数据存储在 PostgreSQL 数据库中，该数据库现在增长到大约 6TB，每个变量一个表。大约 1500 个数据表中的每一个都是这样的形式

(timestamp, station_id, value)

索引(station_id), (station_id, timestamp), (timestamp)和唯一约束(station_id, timestamp, value)。

这种结构需要大量的外部连接（最多 300 个外部连接），这使得数据检索变得繁琐且计算成本高。

研究

到目前为止，进行了以下考虑：

数据库技术

1. 虽然 NoSQL 将提供所需的架构灵活性，但确保数据完整性、访问控制和元数据管理的工具似乎具有挑战性，并且内部不存在 NoSQL 经验。此外，阅读与此相关的评论和答案似乎有利于我们用例的 …

专门运行 PostgreSQL 11.2 服务器（带有 TimescaleDB 扩展）的 Ubuntu 18.04 服务器将很快耗尽磁盘空间，因此需要向计算机添加新的 SSD 磁盘以支持不断增长的数据库大小。

数据预计将以相同/更高的速率继续增加，因此需要不断增加存储硬件，直到机器用完 2.5 英寸驱动器托架。只有这时才会考虑将数据库分布在多台机器上，因为所涉及的复杂性增加。

想法

1. 联合文件系统mergerfs可以将驱动器集中在一起，轻松解决存储扩展问题。但这会增加数据库操作的延迟，因此不建议这样做。可以通过底层 RAID-1/5/6/10 或使用 SnapRAID 添加冗余。

2. RAID-0 和 RAID-10 允许将 RAID 阵列扩展到新添加的驱动器中，并通过条带化提高性能。然而，每个添加的驱动器都会增加一个故障点。此外，许多人声称镜像 SSD 的用途有限，因为RAID-0 中的两个 SSD 可能会同时发生故障。所以也许这意味着 RAID-10 并不比 RAID-0 更好。此外，故障率随着每增加一个 SSD 而线性增加。

3. RAID-5/6 由于奇偶校验计算和写入 2 个驱动器而降低了性能，从而使有效 IOPS 降低了 75%。对于数据库来说似乎是一个糟糕的选择。

4. PostgreSQLTABLESPACES可用于将每个表分配到特定驱动器。然而，使用表空间会使恢复变得非常复杂。此外，是否可以在新驱动器上创建新表空间并让 Postgres 自动决定将新记录写入何处？

5. ZFS、BTRFS？对他们不熟悉，愿意探索他们是否合适。

问题： 2020年推荐的PostgreSQL机器扩容方法是什么，如果扩容频繁（一年1-2次），性能应该不会受到太大影响，恢复也不会太复杂可能会导致数据丢失？

RAID-10 对我来说似乎是一个好主意，但 RAID-1 的使用似乎有限，同时会导致“损失”一半的磁盘空间，随着驱动器数量的增加，故障点也会增加，情况会变得更糟。

由于预算限制，我们无法一次性将 2U 机箱中的 16 个驱动器托架全部装满 SSD，因此必须逐步完成。

任何意见是极大的赞赏！

编辑：在研究了 ZFS 之后，这似乎可能是我的案例的解决方案之一。

• 仅包含镜像 ZFS vdev（每个 …

我正在尝试解决一个特别困难的问题。我正在 SQL 表 (PostgreSQL) 中存储来自某些传感器的一些遥测数据，我想知道如何编写一个查询，该查询将使用来自其他两个表的关系信息对遥测数据进行分组。

我有一张表存储来自传感器的遥测数据。该表包含三个字段，一为时间戳，一为传感器ID，一为传感器当时的值。值列是一个递增计数（它只会增加，不会重置）

Sensor_Telemetry表

我有另一个表，用于存储传感器的状态（无论是静止还是运动）以及该传感器的特定状态的开始/结束日期：

状态表

传感器位于特定位置。Sensor 表存储以下元数据：

传感器表

在决赛表中，我有每个位置发生的变化。班次表是所有班次发生的列表，即在本例中，班次 A 定义为每天 00:00:00 到 00:30:00 之间发生，班次 B 定义为每天 00:30 …

我正在尝试调查为什么此查询的性能如此不确定。它可能需要 1 秒到 60 秒及以上的任何时间。查询的本质是选择一个“时间窗口”，并从该时间窗口内获取所有行。

这是有问题的查询，在大约 10 亿行的表上运行：

SELECT CAST(extract(EPOCH from ts)*1000000 as bigint) as ts
    , ticks
    , quantity
    , side
FROM order_book
WHERE ts >= TO_TIMESTAMP(1618882633073383/1000000.0)
    AND ts < TO_TIMESTAMP(1618969033073383/1000000.0)
    AND zx_prod_id = 0
ORDER BY ts ASC, del desc;

这就是表的创建方式

CREATE TABLE public.order_book
(
    ts timestamp with time zone NOT NULL,
    zx_prod_id smallint NOT NULL,
    ticks integer NOT NULL,
    quantity integer NOT NULL,
    side boolean NOT NULL,
    del boolean NOT NULL
)

TO_TIMESTAMP当我走整张桌子时，其中的值将继续向前滑动。以下是EXPLAIN ANALYZE两个不同时间窗口上相同查询的输出： …

pg_dump当在本地容器中运行的（时间尺度）数据库上执行时，我有以下内容：

pg_dump: warning: there are circular foreign-key constraints on this table:
pg_dump:   hypertable

我为上述运行的命令：

pg_dump --schema-only -h localhost --port 5432 --dbname db --username user > schema.sql

我不知道如何使用 postgres 检查哪些键是循环的。

我可以浏览所有表格并手动跟踪哪些键指向我猜测的 - 但我希望有一种更直接的方法来确定哪些键是循环的以及在哪里，以便我可以修复它们。