ElasticSearch多渗透性能

Question

我只有一个专用的过滤器索引.
那里有3000疑问.这是一个典型的查询:

 {
    "index": "articles_percolators",
    "type": ".percolator",
    "body": {
        "query": {
            "filtered": {
                "query": {
                    "bool": {
                        "should": [
                            {
                                "query_string": {
                                    "fields": [
                                        "title"
                                    ],
                                    "query": "Cities|urban|urbanization",
                                    "allow_leading_wildcard": false
                                }
                            },
                            {
                                "query_string": {
                                    "fields": [
                                        "content"
                                    ],
                                    "query": "Cities|urban|urbanization",
                                    "allow_leading_wildcard": false
                                }
                            },
                            {
                                "query_string": {
                                    "fields": [
                                        "url"
                                    ],
                                    "query": "Cities|urban|urbanization",
                                    "allow_leading_wildcard": false
                                }
                            }
                        ]
                    }
                },
                "filter": {
                    "bool": {
                        "must": [
                            {
                                "terms": {
                                    "feed_id": [
                                        3215,
                                        3216,
                                        10674,
                                        26041
                                    ]
                                }
                            }
                        ]
                    }
                }
            }
        },
        "sort": {
            "date": {
                "order": "desc"
            }
        },
        "fields": [
            "_id"
        ]
    },
    "id": "562"
}

映射(PHP数组).为简洁起见,不包括过滤器,分析器和标记器:

    'index' => 'articles_percolators',
    'body' => [
        'settings' => [
            'number_of_shards' => 8,
            'number_of_replicas' => 0,
            'refresh_interval' => -1,
            'analysis' => [
                'filter' => [
                ],
                'analyzer' => [
                ],
                'tokenizer'=> [
                ]
            ]
        ],
        'mappings' => [
            'article' => [
                '_source' => ['enabled' => false],
                '_all' => ['enabled' => false],
                '_analyzer' => ['path' => 'lang_analyzer'],
                'properties' => [
                    'lang_analyzer' => [
                        'type' => 'string',
                        'doc_values' => true,
                        'store' => false,
                        'index' => 'no'
                    ],
                    'date' => [
                        'type' => 'date',
                        'doc_values' => true
                    ],
                    'feed_id' => [
                        'type' => 'integer'
                    ],
                    'feed_subscribers' => [
                        'type' => 'integer'
                    ],
                    'feed_canonical' => [
                        'type' => 'boolean'
                    ],
                    'title' => [
                        'type' => 'string',
                        'store' => false,
                    ],
                    'content' => [
                        'type' => 'string',
                        'store' => false,
                    ],
                    'url' => [
                        'type' => 'string',
                        'analyzer' => 'simple',
                        'store' => false
                    ]
                ]
            ]
        ]
    ]

然后,我一次将文档发送到mpercolateAPI 100.这是mpercolate请求的一部分(1个文档):

{
    "percolate": {
        "index": "articles_percolators",
        "type": "article"
    }
},
{
    "doc": {
        "title": "Win a Bench Full of Test Equipment",
        "url": "\/document.asp",
        "content": "Keysight Technologies is giving away a bench full of general-purpose test equipment.",
        "date": 1421194639401,
        "feed_id": 12240778,
        "feed_subscribers": 52631,
        "feed_canonical": 1,
        "lang_analyzer": "en_analyzer"
    }
}

100文章~1 second在我的MacBook Pro 2.4 GHz Intel Core i7(4核,8 HT)上处理,所有核心最大:

这对我来说似乎相当缓慢,但我没有与之比较的基础.
我有一个常规索引具有相同的映射(但有6个分片),超过30亿个文档(仍然)存在于具有24 coreXeon和128GBRAM 的单个服务器上.此类查询在整个索引中搜索的内容少于100ms(在热服务器上).

我的设置中是否存在明显错误,是否有其他人对过滤器的性能进行了基准测试？我没有在网上找到任何关于此的内容......

我的ES版本1.4.2使用默认配置,工作负载完全受CPU限制.

编辑

因为John Petrone's评论是关于在生产环境中进行测试的,所以我已经在我们在生产中使用的相同的24核Xeon上进行了测试.如果没有更糟糕的话,渗透的8个分片索引的结果是相同的.时间介于1s和1.2s之间,而网络延迟低于我的笔记本电脑.
这可能可以通过Xeon的每个核心的较慢时钟速度来解释 - 2.0GHz与2.4Ghzi7相比.

它导致几乎恒定的CPU利用率约为800%:

然后我用24个分片重新创建索引,每100个文档的时间减少到0.8秒,但CPU时间超过两倍:

我每秒有大约100个文档的持续流量,将来查询的数量会增加,所以这对我来说有点担心.

Answer 1

所以要明确一点,你不能将24核Xeon和128GB内存的正常Elasticsearch性能与笔记本电脑上的ES渗透性能进行比较 - 非常不同的硬件和非常不同的软件.

有许多大型索引设置(比如你的30亿个文档),在运行查询时,你往往是磁盘或内存绑定.只要您拥有足够的两者,查询性能就会非常高.

渗透是不同的 - 您实际上索引每个文档,然后针对每个文档运行存储在过滤器中的每个查询,所有这些都在内存中的Lucene索引中:

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-percolate.html

渗透水平扩展并且往往是cpu绑定 - 通过添加具有足够cpu的其他节点来扩展它.

通过multi percolate api提交的100份文件针对3000个注册的percolate查询,您基本上运行了300,000个单独的查询.我希望在Macbook上绑定cpu - 我认为你最好在一个更受控制的环境(单独的服务器)中进行基准测试,并且可以通过添加额外的节点进行扩展.

UPDATE

因此,为了更好地了解瓶颈是什么以及如何提高性能,您需要从较少数量的注册查询开始,同时减少文档数量,然后再进行调整.这将使您更清楚地了解幕后发生的事情.

我从单个文档(不是100)开始,注册的查询少得多,然后运行一系列测试,一些提高文档数量,一些提高注册的查询数量,多步骤然后超过100个文档和一次以上3000次查询.

通过查看结果,您可以更好地了解性能如何下降与负载 - 线性与文档数量,与已注册查询的数量呈线性关系.

我将尝试的其他配置变体 - 通过批量percolate api而不是100个文档,尝试多个线程中的单个doc api(以查看它是否是多doc api问题).我还尝试在同一系统上运行多个节点,或者使用许多较小的服务器,以查看是否在多个较小的节点上获得了更好的性能.我还会改变分配给JVM的内存量(更多不一定更好).

最终,您需要一系列数据点来尝试确定查询的缩放方式以及拐点的位置.