从理论上讲,这个SQL查询是否太大而无法在加载下快速服务？

Question

我有一个SQL查询,可以轻松返回70,000行的关系数据库表(涉及一些连接).此结果集的总大小约为20mb.表本身的总大小约为1000万行.

我在这里缺乏观点,所以我想知道这个大小的查询是否实际上能够快速提供,即使在网页上每秒几百个请求？此外,这不是一个只读表:有相当多的更新/删除(介于3:1和10:1之间的读/写比率取决于一年中的时间)

我知道我需要索引等.我想知道的是,如果单个数据库服务器(比如4gb ram和一个现代的四核CPU)甚至可以在理论上服务于此而不会破坏cpu或磁盘IO的地狱并变得非常糟糕性能？

Answer 1

你没有提供很多关于你的查询实际情况的背景知识,但是我将以PostgreSQL为例,向您介绍如何估计您的期望是否切合实际.

准备一个10M行的虚表,每行80字节的填充数据:

create table foo as select
    generate_series(1,10000000) as foo_id,
    repeat('a', 80) as filler;
create unique index foo_foo_id on foo (foo_id);
vacuum analyze foo;

这个表总共1400 MB,包括索引,所以它完全适合我的操作系统缓存,但不适合PostgreSQL的共享缓冲区.

创建自定义pgbench脚本以获取索引排序的70000行:

\setrandom key 1 9000000
SELECT * FROM foo WHERE foo_id > :key ORDER BY foo_id LIMIT 70000;

以下是在我的4核台式计算机(AMD Phenom II X4 955)上运行基准测试1分钟的结果:

% pgbench -j 4 -c 4 -T 60 -n -f script.pgb
transaction type: Custom query
scaling factor: 1
query mode: simple
number of clients: 4
number of threads: 4
duration: 60 s
number of transactions actually processed: 3922
tps = 65.309954 (including connections establishing)
tps = 65.316916 (excluding connections establishing)

请注意,此处客户端(pgbench)和服务器位于同一台物理计算机上.实际上它们会有所不同,因此网络开销和吞吐量之类的东西会发挥作用.

这种天真的配置每秒可以处理大约65个这样的查询.胜于"几百请求每秒"低,所以你需要很多更强大的服务器来处理这种工作量.可以选择使用多个从站进行复制.

为了获得更真实的结果,您应该调整pgbench脚本并测试数据以更接近您的工作负载.