我正在使用Postgres对财务数据(交易和报价)进行分析。
对我来说,一个常见的用例是在特定的时间戳范围内查询交易/报价/两者。
我当前实现db结构的方式是在每个交易日保留一个架构(例如schema_20180821),该架构包含一个包含相关数据(对timestamp列进行索引)的报价和交易表。
所以,从某种意义上说,这对我有好处:
但是现在我得到了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)
);
谢谢。
答案 0 :(得分:1)
您要分区!在documentation中详细了解它。
拥有多个具有相同数据结构的表几乎不是一个好主意。如您所见,查询几天的数据是。 。 。一场噩梦。
这是我对您的观点的反应:
- 这是“更有条理”(我的看法)。
一点也不。数不胜数的并行表没有组织得更好。从美观和维护角度来看,一张桌子都更干净。
- 明确访问特定日期更加容易。
更改表名比添加where
子句“容易”吗?即使我同意它们对于一个日期是等效的,但对于多个表来说,多个日期显然很痛苦。
- 如果我出于任何原因决定删除特定日期,则不会弄乱ID主键。
我不明白“ id主键的含义”是什么意思。相对于未分区表,这无疑是一个优势。从单个表中删除行会导致大量日志记录和锁定开销。但是,删除分区几乎就像删除表一样简单。
不同的模式-锁在模式级别而不在表级别。
这是一个正当的理由。使用单表解决方案时,可以使用以下选项:
但是,对数据的更改(大概)非常罕见,因此在使用它来指导整体方法时我会保持谨慎。
多个表格还有其他缺点:
使用“表多重性”方法是有正当理由的。我能想到的是: