我应该在以下情况下使用 PostgreSQL 数组类型吗

Question

我正在使用 PostgreSQL。

我意识到 PostgreSQL 有 Array 数据类型。

http://www.postgresql.org/docs/8.1/interactive/arrays.html

目前，我需要使用数据库来存储半导体工厂的测量结果。

他们正在生产半导体单元。每个半导体单元可以有可变数量的测量参数。

我打算按以下方式设计表格。

SemicondutorComponent
=====================
ID |


Measurement
=================
ID | Name | Value | SemicondutorComponent_ID

数据示例：

SemicondutorComponent
=====================
1 |
2 |

Measurement
=================
1 | Width       | 0.001 | 1
2 | Height      | 0.021 | 1
3 | Thickness   | 0.022 | 1
4 | Pad0_Length | 0.031 | 1
5 | Pad1_Width  | 0.041 | 1
6 | Width       | 0.001 | 2
7 | Height      | 0.021 | 2
8 | Thickness   | 0.022 | 2
9 | Pad0_Length | 0.031 | 2
10| Pad1_Width  | 0.041 | 2
11| Pad2_Width  | 0.041 | 2
12| Lead0_Width | 0.041 | 2

假设一家工厂在 1 天内生产 2400 万件产品

SemicondutorComponent 表在 1 天内将有 2400 万行

假设一个 SemicondutorComponent 单元有 50 个测量参数。 （可以更多也可以更少，取决于 SemicondutorComponent 类型）

测量表在 1 天内将有 24 * 5000 万行

这样设计效率高吗？

我希望有超快的写入速度，以及合理的从数据库读取速度。

或者我应该使用 PostgreSQL 数组工具吗？

SemicondutorComponent
=====================
ID | Array_of_measurement_name | Array_of_measurement_value

Answer 1

我无法评论数组与常规表的写入速度，但据我所知，使用 2 个数组的设计对于查询来说会非常麻烦。

我也不知道读取数组的性能，但是通过查看文档可以看出，所有数组访问都是通过位置引用（索引）完成的，所以后面会很痛苦找到一个特定的度量 - 你必须遍历名称数组来找到正确的索引，然后使用它来查找值。我怀疑它可以在纯 SQL 中完成，并且可能需要用户定义的函数。

现在关于表格设计：您似乎关心写入速度。每天 2400 万个组件，即每小时 100 万行，这不算多。乘以 50，在最坏的情况下，测量结果是每小时 5100 万行，因此每分钟不到 100 万行。我认为这应该是可行的，尽管建议批量插入并避免在许多短期事务中执行许多单行插入（最好插入它们并以 10.000 或 100.000 的形式提交）。

我确实认为您还需要设计一个归档和/或聚合解决方案，因为继续插入这些卷似乎不太易于维护。我怀疑它也有用，但也许这只是我不理解这个数据库的目的。我的意思是，在我看来，您似乎不太可能希望能够在一个组件制造后 1 年之后对其进行精确测量。然而，随着时间的推移保持平均值、最小值、最大值和标准差测量值等统计数据似乎很有用。但也许你可以解释一下。

我想到的另一件事是，它可以帮助先将原始测量数据存储在廉价且快速的日志中（只是文本文件说 CSV 格式就可以），然后使用多个阅读器读取并插入它们进入数据库。这些阅读器可以以相当稳定的方式运行。这将减少数据库的瓶颈，并使系统更加健壮（假设您的日志继续工作的可能性高于数据库崩溃）。当然，如果您需要从数据库中实时报告以监控流程，这种方法不太适合（尽管再次，您需要在单个组件级别执行此操作对我来说似乎很奇怪）

Answer 2

这取决于您计划如何访问数据，其次取决于您计划如何存储它。

如果您要将组件的测量值作为一个单元来检查，并且您不打算按值进行搜索，那么使用数组并不是完全不可能的。另一方面，如果您稍后想查看哪些组件的宽度（例如）大于 X 值，那么使用数组会导致您疼痛、脱发和宇宙热。

另一方面，如果您要同时存储所有值，那么使用数组可能没问题。相反，如果您要先存储宽度，然后更新行以设置高度，等等，性能将会扼杀您，因为 Postgres 中的每个 UPDATE 都需要由 VACUUM 清理。

我同意 Roland 的观点，您可能需要某种聚合。您可能还想查看分区，以便您可以截断（或删除）旧分区，而不会因删除旧数据而导致清理死行的开销。