板条箱连接查询需要太多时间答案

【问题标题】：Crate join queries takes too much time板条箱连接查询需要太多时间
【发布时间】：2017-07-06 13:06:42
【问题描述】：

前置要求：我需要在一个超过 40K 的查询中找到所有匹配的结果。

要求：两个表 - product 和 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
);

加入查询：

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 的原因是对持久数据的查询能力。

【问题讨论】：

除了你的引擎和查询之外似乎还有其他问题。
复制查询并在您的数据库中直接检查查询。（例如，我们检查 PHPMYADMIN）
您可以尝试反转您的表连接吗？首先是“产品”，然后是“产品类别”
@VishalKumarSahu 我下载了最新的 Crate1.0.3 并使用 Crash.bat 进行查询。请建议我如何改进它。
@GauravJ 尝试反转联接，仍然是同样的问题。

标签： java database caching memcached cratedb

【解决方案1】：

与加入NUMERIC 类型相比，加入STRING 类型列的成本非常高（对字符串值的相等性检查比对数值的成本高得多）。如果您没有特殊原因，我建议您将它们更改为NUMERIC 类型（例如INTEGER、LONG、...），这将通过多个因素提高查询速度.

顺便说一句。 index using plain 是所有列的默认索引设置，因此您可以忽略它。此外，复合索引 product_category_index 无助于改进连接查询，如果您使用包含此索引列的 WHERE 子句对其进行过滤，这一点很重要。

更新

您可以做的另一项改进是添加ORDER BY p.product_id, pc.product_id 子句。这样，当连接算法到达您应用的LIMIT 时，它可能会停止。

【讨论】：

@SanjayKumar 用ORDER BY 建议更新了我的答案。
我试过你说的，唯一的方法就是把所有的东西都放在一张桌子上。虽然它比内存访问慢，但可比。谢谢@Sabastian。