Field [price] of type [text] is not supported for aggregation [avg]
timeout和connect_timeout参数 <?php require 'vendor/autoload.php'; use Elasticsearch\ClientBuilder; use Monolog\Logger; use Monolog\Handler\StreamHandler; // 主机 $hosts = [ // 第一个节点配置 [ 'host' => 'localhost', // 必填项 'port' =&g
为了找到所有以W1开始的邮编，可以使用简单的prefix查询：GET /my_index/address/_search{ "query": { "prefix": { "postcode": "W1" } }}prefix查询是一个词级别的底层的查询，它不会在搜索之前分析查询字符串，它假定传入前缀就正是要查找的前缀。默认状态下，prefix查询不做相关度评分计算，它只是将所有匹配的文档返回，并为每条...
update请求最简单的一种形式是接收文档的一部分作为doc的参数， 它只是与现有的文档进行合并。对象被合并到一起，覆盖现有的字段，增加新的字段。 例如，我们增加字段tags和views到我们的博客文章，如下所示： POST /website/blog/1/_update { "doc" : { "tags" : [ "testing" ], "views": 0 } } 如果请求成功，我们看到类似的响应： { "_index": "web...
Elasticsearch 默认按照相关性得分排序，即每个文档跟查询的匹配程度。1.请求方式：Get2.请求URL:http://127.0.0.1:9200/megacorp/employee/_search3.请求信息：{ "query" : { "match" : { "about" : "rock climbing" } }}4. 响应信息{ "took": 43, "time...
与prefix前缀查询的特性类似，wildcard通配符查询也是一种底层基于词的查询，与前缀查询不同的是它允许指定匹配的正则式。它使用标准的 shell 通配符查询：?匹配任意字符，*匹配 0 或多个字符。这个查询会匹配包含W1F 7HW和W2F 8HW的文档：GET /my_index/address/_search{ "query": { "wildcard": { "postcode": "W?F*HW" ...
son实体可能是这样索引的：{ "firstname": "Peter", "lastname": "Smith"}或地址：{ "street": "5 Poland Street", "city": "L...
现在讨论一种普遍的搜索模式：跨字段实体搜索（cross-fields entity search）。在如person、product或address（人、产品或地址）这样的实体中，需要使用多个字段来唯一标识它的信息。person实体可能是这样索引的：{ "firstname": "Peter", "lastname": "Smith"}或地址：{ "street": "5 Poland Street", "city": "L...
multi_match查询为能在多个字段上反复执行相同查询提供了一种便捷方式。multi_match多匹配查询的类型有多种，其中的三种：best_fields、most_fields和cross_fields（最佳字段、多数字段、跨字段）。默认情况下，查询的类型是best_fields，这表示它会为每个字段生成一个match查询，然后将它们组合到dis_max查询的内部，如下：{ "dis_max": { "queries": [ { ...
当用户搜索 “quick pets” 时会发生什么呢？在前面的例子中，两个文档都包含词quick，但是只有文档 2 包含词pets，两个文档中都不具有同时包含两个词的相同字段。如下，一个简单的dis_max查询会采用单个最佳匹配字段，而忽略其他的匹配：{ "query": { "dis_max": { "queries": [ { "match": { "title": "Quick pets" }...
假设有个网站允许用户搜索博客的内容，以下面两篇博客内容文档为例：PUT /my_index/my_type/1{ "title": "Quick brown rabbits", "body": "Brown rabbits are commonly seen."}PUT /my_index/my_type/2{ "title": "Keeping pets healthy", "body": "My quick brown fox eats rabbits
bool查询是多语句查询的主干。它的适用场景很多，特别是当需要将不同查询字符串映射到不同字段的时候。问题在于，目前有些用户期望将所有的搜索项堆积到单个字段中，并期望应用程序能为他们提供正确的结果。有意思的是多字段搜索的表单通常被称为高级查询 （Advanced Search）—— 只是因为它对用户而言是高级的，而多字段搜索的实现却非常简单。对于多词（multiword）、多字段（multifield）查询来说，不存在简单的万能方案。为了获得最好结果，需要了解我们的数据，并了解如何使用合...
最简单的多字段查询可以将搜索项映射到具体的字段。如果我们知道War and Peace是标题，Leo Tolstoy 是作者，很容易就能把两个条件用match语句表示，并将它们用bool查询组合起来：GET /_search{ "query": { "bool": { "should": [ { "match": { "title": "War and Peace" }}, { "match": { "author": "Leo...
查询只能查找倒排索引表中真实存在的项，所以保证文档在索引时与查询字符串在搜索时应用相同的分析过程非常重要，这样查询的项才能够匹配倒排索引中的项。尽管是在说文档，不过分析器可以由每个字段决定。每个字段都可以有不同的分析器，既可以通过配置为字段指定分析器，也可以使用更高层的类型（type）、索引（index）或节点（node）的默认配置。在索引时，一个字段值是根据配置或默认分析器分析的。例如为my_index新增一个字段：PUT /my_index/_mapping/my_type{ ...
当然bool查询不仅限于组合简单的单个词match查询，它可以组合任意其他的查询，以及其他bool查询。普遍的用法是通过汇总多个独立查询的分数，从而达到为每个文档微调其相关度评分_score的目的。假设想要查询关于 “full-text search（全文搜索）” 的文档，但我们希望为提及 “Elasticsearch” 或 “Lucene” 的文档给予更高的权重，这里更高权重是指如果文档中出现 “Elasticsearch” 或 “Lucene” ，它们会比没有的出现这些词的文...
目前为止，可能已经意识到多词match查询只是简单地将生成的term查询包裹在一个bool查询中。如果使用默认的or操作符，每个term查询都被当作should语句，这样就要求必须至少匹配一条语句。以下两个查询是等价的：{ "match": { "title": "brown fox"}}{ "bool": { "should": [ { "term": { "title": "brown" }}, { "term": { ...
在组合过滤器中，我们讨论过如何使用bool过滤器通过and、or和not逻辑组合将多个过滤器进行组合。在查询中，bool查询有类似的功能，只有一个重要的区别。过滤器做二元判断：文档是否应该出现在结果中？但查询更精妙，它除了决定一个文档是否应该被包括在结果中，还会计算文档的相关程度。与过滤器一样，bool查询也可以接受must、must_not和should参数下的多个查询语句。比如：GET /my_index/my_type/_search{ ...
如果我们一次只能搜索一个词，那么全文搜索就会不太灵活，幸运的是match查询让多词查询变得简单：GET /my_index/my_type/_search{ "query": { "match": { "title": "BROWN DOG!" } }}上面这个查询返回所有四个文档：{ "hits": [ { "_id": "4", "_score": ..
匹配查询match是个核心查询。无论需要查询什么字段，match查询都应该会是首选的查询方式。它是一个高级全文查询，这表示它既能处理全文字段，又能处理精确字段。这就是说，match查询主要的应用场景就是进行全文搜索，我们以下面一个简单例子来说明全文搜索是如何工作的：索引一些数据首先，我们使用bulkAPI创建一些新的文档和索引：DELETE /my_index PUT /my_index{ "settings": { "number_of_shards": ...
所有查询会或多或少的执行相关度计算，但不是所有查询都有分析阶段。和一些特殊的完全不会对文本进行操作的查询（如bool或function_score）不同，文本查询可以划分成两大家族：基于词项的查询如term或fuzzy这样的底层查询不需要分析阶段，它们对单个词项进行操作。用term查询词项Foo只要在倒排索引中查找准确词项，并且用 TF/IDF 算法为每个包含该词项的文档计算相关度评分_score。记住term查询只对倒排索引的词项精确匹配，这点很重要，它不会...
相关性（Relevance）它是评价查询与其结果间的相关程度，并根据这种相关程度对结果排名的一种能力，这种计算方式可以是 TF/IDF 方法、地理位置邻近、模糊相似，或其他的某些算法。分析（Analysis）它是将文本块转换为有区别的、规范化的 token 的一个过程， 目的是为了创建倒排索引以及查询倒排索引。一旦谈论相关性或分析这两个方面的问题时，我们所处的语境是关于查询的而不是过滤。...
结构化搜索（Structured search）是指有关探询那些具有内在结构数据的过程。比如日期、时间和数字都是结构化的：它们有精确的格式，我们可以对这些格式进行逻辑操作。比较常见的操作包括比较数字或时间的范围，或判定两个值的大小。文本也可以是结构化的。如彩色笔可以有离散的颜色集合：红（red）、绿（green）、蓝（blue）。一个博客可能被标记了关键词分布式（distributed）和搜索（search）。电商网站上的商品都有 UPCs（通用产品码 Universal Prod...
一、使文本可被搜索 必须解决的第一个挑战是如何使文本可被搜索。 传统的数据库每个字段存储单个值，但这对全文检索并不够。文本字段中的每个单词需要被搜索，对数据库意味着需要单个字段有索引多值(这里指单词)的能力。 倒排索引包含一个有序列表，列表包含所有文档出现过的不重复个体，或称为词项，对于每一个词项，包含了它所有曾出现过文档的列表。 Term | Doc 1 | Doc 2 | Doc 3 | ... ------------------------------------ brown | ..
有两种方式管理...
在前面提到的，重建索引的问题是必须更新应用中的索引名称。 索引别名就是用来解决这个问题的！ 索引别名就像一个快捷方式或软连接，可以指向一个或多个索引，也可以给任何一个需要索引名的API来使用。别名带给我们极大的灵活性，允许我们做下面这些： 在运行的集群中可以无缝的从一个索引切换到另一个索引 给多个索引分组 (例如，last_three_months) 给索引的一个子集创建视图 在后面我们会讨论更多关于别名的使用。现在，我们将解释怎样使用别名在零停机下从旧索引切换到新索引。 有两种方式管理...
类型在 Elasticsearch 中表示一类相似的文档。 类型由名称—比如user或blogpost—和映射组成。映射, 就像数据库中的 schema ，描述了文档可能具有的字段或属性、每个字段的数据类型—比如string,integer或date—以及Lucene是如何索引和存储这些字段的。类型可以很好的抽象划分相似但不相同的数据。
类型在 Elasticsearch 中表示一类相似的文档。 类型由名称—比如user或blogpost—和映射组成。 映射, 就像数据库中的 schema ，描述了文档可能具有的字段或属性、每个字段的数据类型—比如string,integer或date—以及Lucene是如何索引和存储这些字段的。 类型可以很好的抽象划分相似但不相同的数据。但由于 Lucene 的处理方式，类型的使用有些限制。 Lucene 如何处理文档 在 Lucene 中，一个文档由一组简单的键值...
果我们的文本是HTML格式的，它会包含像<p>或者<div>这样的HTML标签，这些标签是我们不想索引的...
虽然Elasticsearch带有一些现成的分析器，然而在分析器上Elasticsearch真正的强大之处在于，你可以通过在一个适合你的特定数据的设置之中组合字符过滤器、分词器、词汇单元过滤器来创建自定义的分析器。 一个分析器就是在一个包里面组合了三种函数的一个包装器， 三种函数按照顺序被执行: 字符过滤器 字符过滤器 用来整理一个尚未被分词的字符串。例如，如果我们的文本是HTML格式的，它会包含像<p>或者<div>这样的HTML标签，这些标签是我们不想索引的...
第三个重要的索引设置是analysis部分，用来配置已存在的分析器或针对你的索引创建新的自定义分析器。 standard分析器是用于全文字段的默认分析器，对于大部分西方语系来说是一个不错的选择。 它包括了以下几点： standard分词器，通过单词边界分割输入的文本。 standard语汇单元过滤器，目的是整理分词器触发的语汇单元（但是目前什么都没做）。 lowercase语汇单元过滤器，转换所有的语汇单元为小写。 stop语汇单元过滤器，删除停用词—对搜索相关性影响不大的常用词，...
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
