我对数据库管理的概念是全新的,所以我没有任何期望的基础。我用大约100GB的数据以五种不同的表格的形式工作。数据的描述以及每个文件的前几行可以找到here。
我目前正在使用flows
表来评估性能。以下是\d flows
的结果:
Table "public.flows"
Column | Type | Modifiers
------------+-------------------+-----------
time | real |
duration | real |
src_comp | character varying |
src_port | character varying |
dest_comp | character varying |
dest_port | character varying |
protocol | character varying |
pkt_count | real |
byte_count | real |
Indexes:
"flows_dest_comp_idx" btree (dest_comp)
"flows_dest_port_idx" btree (dest_port)
"flows_protocol_idx" btree (protocol)
"flows_src_comp_idx" btree (src_comp)
"flows_src_port_idx" btree (src_port)
以下是
EXPLAIN ANALYZE SELECT src_comp, COUNT(DISTINCT dest_comp) FROM flows GROUP BY src_comp;
的结果,我认为这是一个相对简单的查询: GroupAggregate (cost=34749736.06..35724568.62 rows=200 width=64) (actual time=1292299.166..1621191.771 rows=11154 loops=1)
Group Key: src_comp
-> Sort (cost=34749736.06..35074679.58 rows=129977408 width=64) (actual time=1290923.435..1425515.812 rows=129977412 loops=1)
Sort Key: src_comp
Sort Method: external merge Disk: 2819360kB
-> Seq Scan on flows (cost=0.00..2572344.08 rows=129977408 width=64) (actual time=26.842..488541.987 rows=129977412 loops=1)
Planning time: 6.575 ms
Execution time: 1636290.138 ms
(8 rows)
如果我正确地解释了这一点(这可能不是因为我是PSQL新手),这意味着我的查询将需要大约30分钟来执行,这比我预期的要长得多。即使有1.3亿行。
我的电脑运行的是第8代i7四核CPU,16GBs的RAM和2TB的HDD(完整的规格可以找到here)。
我的问题是:1)这是预期的性能,2)有什么我可以做的加速它,除了购买一个外部固态硬盘?
最佳答案
1-查询使用的src_comp和dest_comp都被索引。但是,它们是独立索引的。如果您的索引是'src_comp,dest_comp',那么数据库有可能通过索引处理这一切,从而消除完整的表扫描。
2-src_comp和dest_comp是字符变化的。除非有必要,否则这对于索引字段不是一件好事。这些价值观到底是什么?数字?IP地址?计算机网络名称?如果这些项的数量相对有限,并且在添加到数据库时可以识别它们,请将它们更改为整数,用作其他表中的外键。这将对这个查询产生巨大的影响。如果它们不能以这样的方式存储,但它们至少有一个确定的有限长度——例如,以四点格式的IPv4地址的15个字符——然后为字段设置最大长度,这将有助于一些。