使用日期模式的多个表与使用日期索引的单个表

时间:2018-08-21 13:15:21

标签: sql postgresql database-design

我正在使用Postgres对财务数据(交易和报价)进行分析。

对我来说,一个常见的用例是在特定的时间戳范围内查询交易/报价/两者。

我当前实现db结构的方式是在每个交易日保留一个架构(例如schema_20180821),该架构包含一个包含相关数据(对timestamp列进行索引)的报价和交易表。

所以,从某种意义上说,这对我有好处:

  1. 这是“更有条理”(我的看法)。
  2. 明确访问特定日期更加容易。
  3. 如果我出于任何原因决定删除特定日期,则不会弄乱ID主键。
  4. 不同的模式-锁在模式级别而不在表级别。

但是现在我得到了90天的数据(即90个模式),并且发现要跨越不同的日期进行查询很复杂(将其保存在带有date列的一个表上会更加容易)进行查询,但我认为执行起来会比较慢。

我的问题是,是否有一种更好的方式来组织数据库结构。

下面的表DDL(单笔交易约持有表约200万行,单引号持有约1.2亿行)

CREATE TABLE md_20180727.trades
(
  id serial NOT NULL,
  date date,
  symbol character varying(20),
  exchange_time timestamp without time zone,
  last numeric,
  last_size integer,
  CONSTRAINT trades_pkey PRIMARY KEY (id)
);

CREATE TABLE md_20180727.quotes
(
  id serial NOT NULL,
  date date,
  symbol character varying(20),
  exchange_time timestamp without time zone,
  bid numeric,
  bid_size integer,
  ask numeric,
  ask_size integer,
  status character varying(10),
  spread numeric,
  mid numeric,
  CONSTRAINT quotes_pkey PRIMARY KEY (id)
);

谢谢。

1 个答案:

答案 0 :(得分:1)

您要分区!在documentation中详细了解它。

拥有多个具有相同数据结构的表几乎不是一个好主意。如您所见,查询几天的数据是。 。 。一场噩梦。

这是我对您的观点的反应:

  
      
  1. 这是“更有条理”(我的看法)。
  2.   

一点也不。数不胜数的并行表没有组织得更好。从美观和维护角度来看,一张桌子都更干净。

  
      
  1. 明确访问特定日期更加容易。
  2.   

更改表名比添加where子句“容易”吗?即使我同意它们对于一个日期是等效的,但对于多个表来说,多个日期显然很痛苦。

  
      
  1. 如果我出于任何原因决定删除特定日期,则不会弄乱ID主键。
  2.   

我不明白“ id主键的含义”是什么意思。相对于未分区表,这无疑是一个优势。从单个表中删除行会导致大量日志记录和锁定开销。但是,删除分区几乎就像删除表一样简单。

  

不同的模式-锁在模式级别而不在表级别。

这是一个正当的理由。使用单表解决方案时,可以使用以下选项:

  • 使用JSON列存储灵活的其他数据列。
  • 更改表中的新列。

但是,对数据的更改(大概)非常罕见,因此在使用它来指导整体方法时我会保持谨慎。

多个表格还有其他缺点:

  • 多个表可能会更多地填充数据页和索引页,从而增加内存使用量。
  • 多个表使您很难查看一段时间内的数据-这可能就是为什么您仍要存储历史时间序列的原因。
  • 多个表需要更多的工作来进行备份和恢复。
  • 多个表需要动态SQL才能在存储过程和应用程序中进行概括。

使用“表多重性”方法是有正当理由的。我能想到的是:

  • 随着时间的推移,架构发生了重大变化。
  • 不同的用户级别访问要求。