前置要求:我需要在一个超过40K的查询中找到所有的匹配结果。
要求:两个表-产品和product_category。我正在尝试从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
);Join查询:
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条目。
Usecase :我正在尝试使用crateDB作为持久缓存,但由于给定的查询响应时间,我们真的不能做到这一点。因此,我们将转移到一些内存中的数据库,如REDIS或Memcache。选择crateDB的原因是对持久化数据的查询能力。
发布于 2017-03-28 17:03:11
与在NUMERIC类型上连接相比,在STRING类型列上连接是非常昂贵的(对字符串值进行相等性检查比对数值进行相等性检查要昂贵得多)。如果您没有特殊的原因,我建议您将它们更改为NUMERIC类型(例如INTEGER、LONG等),这将使查询速度提高许多倍。
顺便说一句。index using plain是所有列的默认索引设置,因此您可以省略它。此外,复合索引product_category_index也无助于改进连接查询,如果您要使用包含此索引列的WHERE子句对其进行过滤,这一点很重要。
已更新
您可以做的另一个改进是添加一个ORDER BY p.product_id, pc.product_id子句。这样,当连接算法到达您应用的LIMIT时,它就会停止。
https://stackoverflow.com/questions/42290587
复制相似问题