前置要求:我需要在一次查询中找到所有匹配的结果,且结果超过 40K。
要求:两个表 - 产品和产品类别。我正在尝试从product_category 表中获取具有匹配类别的所有产品。
表结构:
CREATE TABLE catalog.product (
product_id string PRIMARY KEY index using plain,
name string,
sku string,
) clustered by (product_id) into 4 shards;
create table catalog.product_category (
category_id string primary key index using plain,
product_id string primary key index using plain,
INDEX product_category_index using plain(product_id, category_id)
active boolean,
parent_category_id integer,
updated_at timestamp
);
加入查询:
select p.product_id from catalog.product_category pc join catalog.product p on p.product_id=pc.product_id limit 40000;
尝试了多种方法 - 索引product_id(整数和字符串)等。
结果:要显示 35K 结果,每次都需要超过 90 秒。
问题:如何优化查询响应时间?
其他一些信息: - CPU核心-4 - 尝试使用一个或多个节点 - 默认分片 - 产品总数 - 35K,product_category 仅包含 35K 个条目。
用例:我尝试使用 crateDB 作为持久缓存,但在给定的查询响应时间下,我们无法真正做到这一点。因此,我们将转向一些内存数据库,如 REDIS 或 Memcache。选择 crateDB 的原因是对持久数据的查询能力。
最佳答案
与 NUMERIC
类型的联接相比,STRING
类型列的联接非常昂贵(字符串值的相等检查比数字值的相等检查要昂贵得多)。如果您没有特殊原因这样做,我建议将它们更改为 NUMERIC
类型(例如 INTEGER
、LONG
...),这会成倍提高查询速度。
顺便说一句。 index using plain
是所有列的默认索引设置,因此您可以将其省略。
此外,复合索引 product_category_index
无助于改进联接查询,如果您使用包含此索引列的 WHERE
子句对其进行过滤,这一点就很重要。
已更新
您可以做的另一项改进是添加 ORDER BY p.product_id, pc.product_id
子句。这样,连接算法就会在达到您应用的 LIMIT
时停止。
关于java - Crate 连接查询花费太多时间,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42290587/