Question

我们在索引中有60M文档。托管在4个节点集群上。

我想确保为文档上的聚合优化配置。

这是示例查询：

select * from sources * where (sddocname contains ([{"implicitTransforms": false}]"tweet")) | all(group(n_tA_c) each(output(count() as(count))));

字段n_tA_c包含字符串数组。这是示例文档：

        {
            "fields": {
                "add_gsOrd": 63829,
                "documentid": "id:firehose:tweet::815347045032742912",
                "foC": 467,
                "frC": 315,
                "g": 0,
                "ln": "en",
                "m": "ya just wants some fried rice",
                "mTp": 2,
                "n_c_p": [],
                "n_tA_c": [                        
                    "fried",
                    "rice"
                ],
                "n_tA_s": [],
                "n_tA_tC": [],
                "sN": "long_delaney1",
                "sT_dlC": 0,
                "sT_fC": 0,
                "sT_lAT": 0,
                "sT_qC": 0,
                "sT_r": 0.0,
                "sT_rC": 467,
                "sT_rpC": 0,
                "sT_rtC": 0,
                "sT_vC": 0,
                "sddocname": "tweet",
                "t": 1483228858608,
                "u": 377606303,
                "v": "false"
            },
            "id": "id:firehose:tweet::815347045032742912",
            "relevance": 0.0,
            "source": "content-root-cluster"
        }

n_tA_c是模式快速搜索

的属性

    field n_tA_c type array<string> {
        indexing: summary | attribute
        attribute: fast-search
    }

简单的术语聚合查询不会在20年代回归。并且超时。什么是我们需要确保减少此延迟的额外检查清单？

$ curl 'http://localhost:8080/search/?yql=select%20*%20from%20sources%20*%20where%20(sddocname%20contains%20(%5B%7B%22implicitTransforms%22%3A%20false%7D%5D%22tweet%22))%20%7C%20all(group(n_tA_c)%20each(output(count()%20as(count))))%3B' | python -m json.tool
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
    100   270  100   270    0     0     13      0  0:00:20  0:00:20 --:--:--    67
    {
        "root": {
            "children": [
                {
                    "continuation": {
                        "this": ""
                    },
                    "id": "group:root:0",
                    "relevance": 1.0
                }
            ],
            "errors": [
                {
                    "code": 12,
                    "message": "Timeout while waiting for sc0.num0",
                    "source": "content-root-cluster",
                    "summary": "Timed out"
                }
            ],
            "fields": {
                "totalCount": 0
            },
            "id": "toplevel",
            "relevance": 1.0
        }
    }

这些节点是aws i3.4x大盒子。（16核，120 GB）

我可能会错过一些愚蠢的事情。

Answer 1

您要求的每个唯一值及其count（）因为您的分组表达式不包含任何max（x）限制，这是一个非常cpu和网络密集型任务，计算和限制组数量的速度要快得多，例如：

all(group(n_tA_c) max(10) each(output(count() as(count))));

一般评论：使用vespa像任何其他服务引擎一样，重要的是要有足够的内存，例如禁用交换，这样你就可以索引和搜索数据，而不会遇到高内存压力。

每种文档类型使用多少内存取决于几个因素，但每个节点使用属性和文档数定义的字段数量很重要。冗余和可搜索副本的数量也起着重要作用。

对整个语料库进行分组是内存密集型（内存带宽读取属性值），cpu密集型以及网络密集型（如果有高扇出）（请参阅精度此处http://docs.vespa.ai/documentation/grouping.html，这可以限制数量每个节点返回的组）。

Answer 2

总结检查点，在其他答案和更多文档帮助中从对话中进行聚合时要小心。

始终在组中添加max(x)以获取所需的存储桶大小。当数据分布在多个内容节点上时，此结果可能不准确。为了提高准确性，我们还需要使用precision(x)来根据需要调整准确度。
如果你只需要聚合桶而没有命中 - 在yql中传递limit 0;这将保存加载要为容器返回的摘要的步骤。
我们正在过滤/聚合的属性字段处于模式fast-search;否则它不像B树一样索引 - 并且必须遍历。
确保查询中&ranking=unranked的文档得分不变。
启用groupingSessionCache：http://docs.vespa.ai/documentation/reference/search-api-reference.html#groupingSessionCache
调整内容节点的大小以进行延迟与否的权衡。的文档。按max-hits描述：http://docs.vespa.ai/documentation/performance/sizing-search.html
如果内存是瓶颈，可以查看属性刷新策略配置。 http://docs.vespa.ai/documentation/proton.html#proton-maintenance-jobs
如果CPU是瓶颈;增加并行性。确保所有核心都在Searcher中使用。 http://docs.vespa.ai/documentation/content/setup-proton-tuning.html#requestthreads-persearch。 service.xml中的更改：

<persearch>16</persearch>

线程persearch默认为1。

以上更改，确保在超时之前返回带有结果的查询。但是我们了解到Vespa不是为了主要目标的聚合而制作的。写入和搜索的延迟远小于相同硬件上具有相同比例的ES。但是，对于相同的聚合查询，聚合（特别是对于多值字符串字段）更加占用CPU，并且与ES相比具有更多延迟。

如何在Vespa上快速进行聚合？

2 个答案: