我将要建立一个SQL数据库，其中将包含数十万个对象的统计数据计算结果。计划使用Postgres，但问题同样适用于MySQL。
例如，假设我有50万条电话记录。现在，每个PhoneCall将通过后台作业系统计算统计信息。例如，PhoneCall具有以下统计信息：
call_duration：以秒为单位（浮动）setup_time：以秒为单位（浮动）dropouts：检测到音频丢失（数组）的时间段，例如[5.23, 40.92] hung_up_unexpectedly：是或否（布尔值）这些只是简单的例子；实际上，统计数据更为复杂。每个统计信息都有一个与之关联的版本号。
我不确定这些类型的计算数据的哪种存储模式将是最有效的。我没有考虑完全规范化数据库中的所有内容。到目前为止，我已经提出了以下选择：
我将统计名称及其值分别存储在一列中，并引用主交易对象。值列是一个文本字段；该值将被序列化（例如JSON或YAML），以便可以存储不同的类型（字符串，数组等）。统计信息表的数据库布局为：
statistic_id（PK）phone_call_id（FK）statistic_name（字符串）statistic_value（文本，序列化）statistic_version（整数）created_at（日期时间）我使用这种模式已经有一段时间了，它的优点是我可以轻松地根据电话和统计信息名称过滤统计信息。我还可以轻松添加新类型的统计信息，并按版本和创建时间进行过滤。
但是在我看来，值的（反）序列化使其在处理大量数据方面的效率非常低下。另外，我无法在SQL级别执行计算；我总是必须加载和反序列化数据。还是Postgres中的JSON支持很好，所以我仍然可以选择这种模式？
我还可以考虑收集所有类型的统计名称，并将它们作为新列添加到电话对象中，例如：
id（PK）call_duration setup_time dropouts hung_up_unexpectedly 这将非常有效，并且每一列都有其自己的类型，但是我不能再存储不同版本的统计信息，也不能根据创建它们的时间对其进行过滤。统计的整个业务逻辑都消失了。添加名称也不容易，因此添加新统计信息也不容易。
这可能是最复杂的。我仅存储对统计信息类型的引用，并且将根据该查询进行查找：
statistic_id（PK）phone_call_id（FK）statistic_name（字符串）statistic_value_bool（布尔值）statistic_value_string（字符串）statistic_value_float（浮动）statistic_value_complex（序列化或复杂数据类型）statistic_value_type（指示bool，string等的字符串）statistic_version（整数）created_at（日期时间）这将意味着表将非常稀疏，因为仅填充了statistic_value_列之一。会导致性能问题吗？
尝试标准化选项3，我将创建两个表：
statistics
id（PK）version created_at statistic_mapping
phone_call_id（FK）statistic_id（FK）statistic_type_mapping
statistic_id（FK）type（字符串，指示bool，string等）statistic_values_boolean
statistic_id（FK）value（布尔）但是，由于我无法动态连接到另一个表名，所以这没有用，是吗？还是应该基于统计ID联接所有statistic_values_*表？我的应用程序必须确保那时没有重复的条目。
总而言之，在这种用例的情况下，当要求可以添加或更改统计类型以及多个版本时，将最有效的方法存储在关系数据库（例如Postgres）中的数百万个统计值是什么同时存在，并且值的查询应该有点有效？
答案 0 :(得分：2)
IMO，您可以使用以下简单的数据库结构来解决您的问题。
一个非常简单的表-只是统计信息的名称和描述。类型：
create table stat_types (
type text not null constraint stat_types_pkey primary key,
description text
);
（如果元素数量有限，则可以将其替换为enum）
它包含对象的FK和状态的FK。类型（或只是枚举），并且，重要的是，jsonb字段具有任意统计信息。数据与其类型有关。例如，用于电话的电话表：
create table phone_calls_statistics (
phone_call_id uuid not null references phone_calls,
stat_type text not null references stat_types,
data jsonb,
constraint phone_calls_statistics_pkey primary key (phone_call_id, stat_type)
);
我在这里假设表phone_calls的PK类型为uuid：
create table phone_calls (
id uuid not null constraint phone_calls_pkey primary key
-- ...
);
data字段具有不同的结构，具体取决于其状态。类型。 通话时间的示例：
{
"call_duration": 120.0
}
或辍学：
{
"dropouts": [5.23, 40.92]
}
让我们玩数据：
insert into phone_calls_statistics values
('9fc1f6c3-a9d3-4828-93ee-cf5045e93c4c', 'CALL_DURATION', '{"call_duration": 100.0}'),
('86d1a2a6-f477-4ed6-a031-b82584b1bc7e', 'CALL_DURATION', '{"call_duration": 110.0}'),
('cfd4b301-bdb9-4cfd-95db-3844e4c0625c', 'CALL_DURATION', '{"call_duration": 120.0}'),
('39465c2f-2321-499e-a156-c56a3363206a', 'CALL_DURATION', '{"call_duration": 130.0}'),
('9fc1f6c3-a9d3-4828-93ee-cf5045e93c4c', 'UNEXPECTED_HANGUP', '{"unexpected_hungup": true}'),
('86d1a2a6-f477-4ed6-a031-b82584b1bc7e', 'UNEXPECTED_HANGUP', '{"unexpected_hungup": true}'),
('cfd4b301-bdb9-4cfd-95db-3844e4c0625c', 'UNEXPECTED_HANGUP', '{"unexpected_hungup": false}'),
('39465c2f-2321-499e-a156-c56a3363206a', 'UNEXPECTED_HANGUP', '{"unexpected_hungup": false}');
获取平均，最小和最大通话时间：
select
avg((pcs.data ->> 'call_duration')::float) as avg,
min((pcs.data ->> 'call_duration')::float) as min,
max((pcs.data ->> 'call_duration')::float) as max
from
phone_calls_statistics pcs
where
pcs.stat_type = 'CALL_DURATION';
获取意外的挂断次数：
select
sum(case when (pcs.data ->> 'unexpected_hungup')::boolean is true then 1 else 0 end) as hungups
from
phone_calls_statistics pcs
where
pcs.stat_type = 'UNEXPECTED_HANGUP';
我相信该解决方案非常简单和灵活，具有良好的性能潜力和完美的可伸缩性。主表有一个简单的索引；所有查询都将在其中执行。您可以随时扩展统计信息的数量。类型及其计算。