ElasticSearch
Elastic Search报错：Fielddata is disabled on text fields by default
Linux • 发表了文章 • 0 个评论 • 3920 次浏览 • 2020-09-16 19:26
在使用 ElasticSearch 的时候，如果索引中的字段是 text 类型，针对该字段聚合、排序和查询的时候常会出现 Fielddata is disabled on text fields by default. Set fielddata=true 的错误。本文总结这个错误出现的原因，可能的修复方法等。
常见原因
在 ElasticSearch 中，Fielddata 默认在 text 类型的字段时是不启用的。设想，如果默认打开，那么你的数据中，每个字符串大概率不一样的话，那么这个字段需要的集合大小（Cardinality）会非常大。
而这个字段是需要存在内存中的 (heap)，因此不可能默认打开。所以如果你从一个 script 来对一个 text 字段进行排序、聚合或者查询的话，就会出现这个错误。Fielddata is disabled on text fields by default. Set `fielddata=true` on [`你的字段名字`] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory.
Fielddata is disabled on text fields by default 解答方法看这篇：
ES 如何解决 Fielddata is disabled on text fields by default 错误
查看全部
常见原因
在 ElasticSearch 中，Fielddata 默认在 text 类型的字段时是不启用的。设想，如果默认打开，那么你的数据中，每个字符串大概率不一样的话，那么这个字段需要的集合大小（Cardinality）会非常大。
而这个字段是需要存在内存中的 (heap)，因此不可能默认打开。所以如果你从一个 script 来对一个 text 字段进行排序、聚合或者查询的话，就会出现这个错误。Fielddata is disabled on text fields by default. Set `fielddata=true` on [`你的字段名字`] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory.
Fielddata is disabled on text fields by default 解答方法看这篇：
ES 如何解决 Fielddata is disabled on text fields by default 错误
查看全部
在使用 ElasticSearch 的时候，如果索引中的字段是 text 类型，针对该字段聚合、排序和查询的时候常会出现 Fielddata is disabled on text fields by default. Set fielddata=true 的错误。本文总结这个错误出现的原因，可能的修复方法等。
常见原因
在 ElasticSearch 中，Fielddata 默认在 text 类型的字段时是不启用的。设想，如果默认打开，那么你的数据中，每个字符串大概率不一样的话，那么这个字段需要的集合大小（Cardinality）会非常大。
而这个字段是需要存在内存中的 (heap)，因此不可能默认打开。所以如果你从一个 script 来对一个 text 字段进行排序、聚合或者查询的话，就会出现这个错误。Fielddata is disabled on text fields by default. Set `fielddata=true` on [`你的字段名字`] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory.
Fielddata is disabled on text fields by default 解答方法看这篇：
ES 如何解决 Fielddata is disabled on text fields by default 错误
常见原因
在 ElasticSearch 中，Fielddata 默认在 text 类型的字段时是不启用的。设想，如果默认打开，那么你的数据中，每个字符串大概率不一样的话，那么这个字段需要的集合大小（Cardinality）会非常大。
而这个字段是需要存在内存中的 (heap)，因此不可能默认打开。所以如果你从一个 script 来对一个 text 字段进行排序、聚合或者查询的话，就会出现这个错误。Fielddata is disabled on text fields by default. Set `fielddata=true` on [`你的字段名字`] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory.
Fielddata is disabled on text fields by default 解答方法看这篇：
ES 如何解决 Fielddata is disabled on text fields by default 错误
在Docker中配置Kibana连接ElasticSearch的一些小坑
数据库 • 李魔佛 发表了文章 • 0 个评论 • 11579 次浏览 • 2020-08-09 01:49
之前编译部署的时候只需要在config/kibana.yaml 中修改host ,把默认的 http://elasticsearch:9200 改为 http://127.0.0.1:9200 , 如果你的ElasticSearch带密码访问，只需在下面加多2行
elasticseacrh.user='elastic'
elasticsearch.password='xxxxxx' # 你之前配置ES时设置的密码
BUT, 上面的配置在docker环境下无法正常启动使用kibana， 通过docker logs 容器ID， 查看的日志信息：
log [17:39:09.057] [warning][data][elasticsearch] No living connections
log [17:39:09.058] [warning][licensing][plugins] License information could not be obtained from Elasticsearch due to Error: No Living connections error
log [17:39:09.635] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:09.636] [warning][admin][elasticsearch] No living connections
log [17:39:12.137] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:12.138] [warning][admin][elasticsearch] No living connections
log [17:39:14.640] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:14.640] [warning][admin][elasticsearch] No living connections
log [17:39:17.143] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:17.143] [warning][admin][elasticsearch] No living connections
log [17:39:19.645] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/使用curl访问127.0.0.1:920也是正常的，后来想到docker貌似没有配置桥接网络，两个docker可能无法互通，故把kibana.yaml里面的host改为主机的真实IP（内网172网段ip），然后问题就得到解决了。 查看全部
elasticseacrh.user='elastic'
elasticsearch.password='xxxxxx' # 你之前配置ES时设置的密码
BUT, 上面的配置在docker环境下无法正常启动使用kibana， 通过docker logs 容器ID， 查看的日志信息：
log [17:39:09.057] [warning][data][elasticsearch] No living connections
log [17:39:09.058] [warning][licensing][plugins] License information could not be obtained from Elasticsearch due to Error: No Living connections error
log [17:39:09.635] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:09.636] [warning][admin][elasticsearch] No living connections
log [17:39:12.137] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:12.138] [warning][admin][elasticsearch] No living connections
log [17:39:14.640] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:14.640] [warning][admin][elasticsearch] No living connections
log [17:39:17.143] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:17.143] [warning][admin][elasticsearch] No living connections
log [17:39:19.645] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/使用curl访问127.0.0.1:920也是正常的，后来想到docker貌似没有配置桥接网络，两个docker可能无法互通，故把kibana.yaml里面的host改为主机的真实IP（内网172网段ip），然后问题就得到解决了。 查看全部
之前编译部署的时候只需要在config/kibana.yaml 中修改host ,把默认的 http://elasticsearch:9200 改为 http://127.0.0.1:9200 , 如果你的ElasticSearch带密码访问，只需在下面加多2行
elasticseacrh.user='elastic'
elasticsearch.password='xxxxxx' # 你之前配置ES时设置的密码
BUT, 上面的配置在docker环境下无法正常启动使用kibana， 通过docker logs 容器ID， 查看的日志信息：
elasticseacrh.user='elastic'
elasticsearch.password='xxxxxx' # 你之前配置ES时设置的密码
BUT, 上面的配置在docker环境下无法正常启动使用kibana， 通过docker logs 容器ID， 查看的日志信息：
log [17:39:09.057] [warning][data][elasticsearch] No living connections使用curl访问127.0.0.1:920也是正常的，后来想到docker貌似没有配置桥接网络，两个docker可能无法互通，故把kibana.yaml里面的host改为主机的真实IP（内网172网段ip），然后问题就得到解决了。
log [17:39:09.058] [warning][licensing][plugins] License information could not be obtained from Elasticsearch due to Error: No Living connections error
log [17:39:09.635] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:09.636] [warning][admin][elasticsearch] No living connections
log [17:39:12.137] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:12.138] [warning][admin][elasticsearch] No living connections
log [17:39:14.640] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:14.640] [warning][admin][elasticsearch] No living connections
log [17:39:17.143] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:17.143] [warning][admin][elasticsearch] No living connections
log [17:39:19.645] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
ElasticSearch查看已经存在的文档保存在哪个分片
数据库 • 李魔佛 发表了文章 • 0 个评论 • 4152 次浏览 • 2019-05-26 12:54
比如我有以下的文档：
{
"took" : 3,
"timed_out" : false,
"_shards" : {
"total" : 5,
"successful" : 5,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : 5,
"max_score" : 1.0,
"hits" : [
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "XxyrM2kBVzdNcvl_GHv2",
"_score" : 1.0,
"_source" : {
"name" : "Shiled",
"twitter" : "Sonny sql is awesome",
"date" : "2018-12-27",
"id" : 1240,
"tags" : [
"red",
"shit"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YByrM2kBVzdNcvl_tnvm",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 12357,
"tags" : [
"red"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "7777",
"_score" : 1.0,
"_source" : {
"name" : "Rocky Chen",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 9999
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YhzDN2kBVzdNcvl_enuT",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 888888,
"tags" : [
"red",
"green"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YxzDN2kBVzdNcvl_u3th",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 888888,
"tags" : [
"red",
"green"
]
}
}
]
}
}
如果我想看看id是 "_id" : "YxzDN2kBVzdNcvl_u3th",
这个文档是保存在哪个分片，如何查看？
引用：
路由一个文档到一个分片中编辑
当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？
首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：
shard = hash(routing) % number_of_primary_shards
routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。
这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。
那么可以使用
GET test/_search_shards?routing=ID号 来查看你要查询的id所在的分片
得到的结果：
{
"nodes" : {
"yl-qYmh1SXqzJsfI4d1ddw" : {
"name" : "node-3",
"ephemeral_id" : "UsJ9rFELTiCW07oHE9YMdg",
"transport_address" : "10.18.6.26:9300",
"attributes" : {
"ml.machine_memory" : "6088101888",
"rack" : "r1",
"ml.max_open_jobs" : "20",
"xpack.installed" : "true",
"ml.enabled" : "true"
}
},
"wT7wUd3iTkujYUsbVNVv-w" : {
"name" : "node-1",
"ephemeral_id" : "fP-vgSb0SdemnHDyaJUsWw",
"transport_address" : "10.18.6.102:9300",
"attributes" : {
"ml.machine_memory" : "8256720896",
"rack" : "r1",
"xpack.installed" : "true",
"ml.max_open_jobs" : "20",
"ml.enabled" : "true"
}
}
},
"indices" : {
"test" : { }
},
"shards" : [
[
{
"state" : "STARTED",
"primary" : true,
"node" : "wT7wUd3iTkujYUsbVNVv-w",
"relocating_node" : null,
"shard" : 1,
"index" : "test",
"allocation_id" : {
"id" : "k-8E4dL7QmGgwcsNsUCP6Q"
}
},
{
"state" : "STARTED",
"primary" : false,
"node" : "yl-qYmh1SXqzJsfI4d1ddw",
"relocating_node" : null,
"shard" : 1,
"index" : "test",
"allocation_id" : {
"id" : "lvOpQIKgRUibkulr3nRfEw"
}
}
]
]
}
只需要关注shards字段就可以，从上面可以看到，该文档存在shard 1 分片上。 分别在node1和node3节点，一个是主分片，一个是副本分片 查看全部
{
"took" : 3,
"timed_out" : false,
"_shards" : {
"total" : 5,
"successful" : 5,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : 5,
"max_score" : 1.0,
"hits" : [
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "XxyrM2kBVzdNcvl_GHv2",
"_score" : 1.0,
"_source" : {
"name" : "Shiled",
"twitter" : "Sonny sql is awesome",
"date" : "2018-12-27",
"id" : 1240,
"tags" : [
"red",
"shit"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YByrM2kBVzdNcvl_tnvm",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 12357,
"tags" : [
"red"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "7777",
"_score" : 1.0,
"_source" : {
"name" : "Rocky Chen",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 9999
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YhzDN2kBVzdNcvl_enuT",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 888888,
"tags" : [
"red",
"green"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YxzDN2kBVzdNcvl_u3th",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 888888,
"tags" : [
"red",
"green"
]
}
}
]
}
}
如果我想看看id是 "_id" : "YxzDN2kBVzdNcvl_u3th",
这个文档是保存在哪个分片，如何查看？
引用：
路由一个文档到一个分片中编辑
当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？
首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：
shard = hash(routing) % number_of_primary_shards
routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。
这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。
那么可以使用
GET test/_search_shards?routing=ID号 来查看你要查询的id所在的分片
得到的结果：
{
"nodes" : {
"yl-qYmh1SXqzJsfI4d1ddw" : {
"name" : "node-3",
"ephemeral_id" : "UsJ9rFELTiCW07oHE9YMdg",
"transport_address" : "10.18.6.26:9300",
"attributes" : {
"ml.machine_memory" : "6088101888",
"rack" : "r1",
"ml.max_open_jobs" : "20",
"xpack.installed" : "true",
"ml.enabled" : "true"
}
},
"wT7wUd3iTkujYUsbVNVv-w" : {
"name" : "node-1",
"ephemeral_id" : "fP-vgSb0SdemnHDyaJUsWw",
"transport_address" : "10.18.6.102:9300",
"attributes" : {
"ml.machine_memory" : "8256720896",
"rack" : "r1",
"xpack.installed" : "true",
"ml.max_open_jobs" : "20",
"ml.enabled" : "true"
}
}
},
"indices" : {
"test" : { }
},
"shards" : [
[
{
"state" : "STARTED",
"primary" : true,
"node" : "wT7wUd3iTkujYUsbVNVv-w",
"relocating_node" : null,
"shard" : 1,
"index" : "test",
"allocation_id" : {
"id" : "k-8E4dL7QmGgwcsNsUCP6Q"
}
},
{
"state" : "STARTED",
"primary" : false,
"node" : "yl-qYmh1SXqzJsfI4d1ddw",
"relocating_node" : null,
"shard" : 1,
"index" : "test",
"allocation_id" : {
"id" : "lvOpQIKgRUibkulr3nRfEw"
}
}
]
]
}
只需要关注shards字段就可以，从上面可以看到，该文档存在shard 1 分片上。 分别在node1和node3节点，一个是主分片，一个是副本分片 查看全部
比如我有以下的文档：
{
"took" : 3,
"timed_out" : false,
"_shards" : {
"total" : 5,
"successful" : 5,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : 5,
"max_score" : 1.0,
"hits" : [
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "XxyrM2kBVzdNcvl_GHv2",
"_score" : 1.0,
"_source" : {
"name" : "Shiled",
"twitter" : "Sonny sql is awesome",
"date" : "2018-12-27",
"id" : 1240,
"tags" : [
"red",
"shit"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YByrM2kBVzdNcvl_tnvm",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 12357,
"tags" : [
"red"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "7777",
"_score" : 1.0,
"_source" : {
"name" : "Rocky Chen",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 9999
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YhzDN2kBVzdNcvl_enuT",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 888888,
"tags" : [
"red",
"green"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YxzDN2kBVzdNcvl_u3th",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 888888,
"tags" : [
"red",
"green"
]
}
}
]
}
}
如果我想看看id是 "_id" : "YxzDN2kBVzdNcvl_u3th",
这个文档是保存在哪个分片，如何查看？
引用：
路由一个文档到一个分片中编辑
当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？
首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：
shard = hash(routing) % number_of_primary_shards
routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。
这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。
那么可以使用
GET test/_search_shards?routing=ID号 来查看你要查询的id所在的分片
得到的结果：
{
"nodes" : {
"yl-qYmh1SXqzJsfI4d1ddw" : {
"name" : "node-3",
"ephemeral_id" : "UsJ9rFELTiCW07oHE9YMdg",
"transport_address" : "10.18.6.26:9300",
"attributes" : {
"ml.machine_memory" : "6088101888",
"rack" : "r1",
"ml.max_open_jobs" : "20",
"xpack.installed" : "true",
"ml.enabled" : "true"
}
},
"wT7wUd3iTkujYUsbVNVv-w" : {
"name" : "node-1",
"ephemeral_id" : "fP-vgSb0SdemnHDyaJUsWw",
"transport_address" : "10.18.6.102:9300",
"attributes" : {
"ml.machine_memory" : "8256720896",
"rack" : "r1",
"xpack.installed" : "true",
"ml.max_open_jobs" : "20",
"ml.enabled" : "true"
}
}
},
"indices" : {
"test" : { }
},
"shards" : [
[
{
"state" : "STARTED",
"primary" : true,
"node" : "wT7wUd3iTkujYUsbVNVv-w",
"relocating_node" : null,
"shard" : 1,
"index" : "test",
"allocation_id" : {
"id" : "k-8E4dL7QmGgwcsNsUCP6Q"
}
},
{
"state" : "STARTED",
"primary" : false,
"node" : "yl-qYmh1SXqzJsfI4d1ddw",
"relocating_node" : null,
"shard" : 1,
"index" : "test",
"allocation_id" : {
"id" : "lvOpQIKgRUibkulr3nRfEw"
}
}
]
]
}
只需要关注shards字段就可以，从上面可以看到，该文档存在shard 1 分片上。 分别在node1和node3节点，一个是主分片，一个是副本分片
elasticsearch在match查询里面使用了type字段 报错
数据库 • 李魔佛 发表了文章 • 0 个评论 • 13014 次浏览 • 2019-05-26 00:26
POST get-together/_search
{
"query":
{
"match": {
"name": {
"type":"phrase",
"query":"enterprise london",
"slop":1
}}
},
"_source": "name"
}
报错：
{
"error": {
"root_cause": [
{
"type": "parsing_exception",
"reason": "[match] query does not support [type]",
"line": 6,
"col": 13
}
],
"type": "parsing_exception",
"reason": "[match] query does not support [type]",
"line": 6,
"col": 13
},
"status": 400
}
在6.x已经不支持在math里面使用type，
可以修改为以下语法：
POST get-together/_search
{
"query":
{
"match_phrase": {
"name": {
"query":"enterprise london",
"slop":1
}}
},
"_source": "name"
}
得到的效果是一致的：
{
"took" : 2,
"timed_out" : false,
"_shards" : {
"total" : 2,
"successful" : 2,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : 1,
"max_score" : 1.3243701,
"hits" : [
{
"_index" : "get-together",
"_type" : "_doc",
"_id" : "5",
"_score" : 1.3243701,
"_source" : {
"name" : "Enterprise search London get-together"
}
}
]
}
} 查看全部
{
"query":
{
"match": {
"name": {
"type":"phrase",
"query":"enterprise london",
"slop":1
}}
},
"_source": "name"
}
报错：
{
"error": {
"root_cause": [
{
"type": "parsing_exception",
"reason": "[match] query does not support [type]",
"line": 6,
"col": 13
}
],
"type": "parsing_exception",
"reason": "[match] query does not support [type]",
"line": 6,
"col": 13
},
"status": 400
}
在6.x已经不支持在math里面使用type，
可以修改为以下语法：
POST get-together/_search
{
"query":
{
"match_phrase": {
"name": {
"query":"enterprise london",
"slop":1
}}
},
"_source": "name"
}
得到的效果是一致的：
{
"took" : 2,
"timed_out" : false,
"_shards" : {
"total" : 2,
"successful" : 2,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : 1,
"max_score" : 1.3243701,
"hits" : [
{
"_index" : "get-together",
"_type" : "_doc",
"_id" : "5",
"_score" : 1.3243701,
"_source" : {
"name" : "Enterprise search London get-together"
}
}
]
}
} 查看全部
POST get-together/_search
{
"query":
{
"match": {
"name": {
"type":"phrase",
"query":"enterprise london",
"slop":1
}}
},
"_source": "name"
}
报错：
{
"error": {
"root_cause": [
{
"type": "parsing_exception",
"reason": "[match] query does not support [type]",
"line": 6,
"col": 13
}
],
"type": "parsing_exception",
"reason": "[match] query does not support [type]",
"line": 6,
"col": 13
},
"status": 400
}在6.x已经不支持在math里面使用type，
可以修改为以下语法：
POST get-together/_search
{
"query":
{
"match_phrase": {
"name": {
"query":"enterprise london",
"slop":1
}}
},
"_source": "name"
}
得到的效果是一致的：
{
"took" : 2,
"timed_out" : false,
"_shards" : {
"total" : 2,
"successful" : 2,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : 1,
"max_score" : 1.3243701,
"hits" : [
{
"_index" : "get-together",
"_type" : "_doc",
"_id" : "5",
"_score" : 1.3243701,
"_source" : {
"name" : "Enterprise search London get-together"
}
}
]
}
}
elasticsearch 更新文档的坑
数据库 • 李魔佛 发表了文章 • 2 个评论 • 10275 次浏览 • 2019-05-24 22:46
POST cnbeta/doc/cUxO42oB9O-zF2ru-rs-/_update
{
"doc":{
"title":"中国操作系统"
}
}
那个body里面的”doc" 不能少
不然会报错：
{
"error": {
"root_cause": [
{
"type": "action_request_validation_exception",
"reason": "Validation Failed: 1: script or doc is missing;"
}
],
"type": "action_request_validation_exception",
"reason": "Validation Failed: 1: script or doc is missing;"
},
"status": 400
} 查看全部
{
"doc":{
"title":"中国操作系统"
}
}
那个body里面的”doc" 不能少
不然会报错：
{
"error": {
"root_cause": [
{
"type": "action_request_validation_exception",
"reason": "Validation Failed: 1: script or doc is missing;"
}
],
"type": "action_request_validation_exception",
"reason": "Validation Failed: 1: script or doc is missing;"
},
"status": 400
} 查看全部
POST cnbeta/doc/cUxO42oB9O-zF2ru-rs-/_update
{
"doc":{
"title":"中国操作系统"
}
}
那个body里面的”doc" 不能少
不然会报错：
{
"error": {
"root_cause": [
{
"type": "action_request_validation_exception",
"reason": "Validation Failed: 1: script or doc is missing;"
}
],
"type": "action_request_validation_exception",
"reason": "Validation Failed: 1: script or doc is missing;"
},
"status": 400
}
ElasticSearch配置集群无法发现节点问题【已解决】
数据库 • 李魔佛 发表了文章 • 0 个评论 • 4282 次浏览 • 2019-05-05 10:00
单个节点可以运行，但是配置为多个服务器集群的时候，总是提示无法发现服务器，花了点时间排查了问题，原来是配置文件的timeout问题，需要把timetout的值设置大一些，然后集群就可以发现到局域网中的其他节点。
修改文件elasticsearch.yml 文件中的timeout参数，改成原来值得10倍就可以了。 查看全部
修改文件elasticsearch.yml 文件中的timeout参数，改成原来值得10倍就可以了。 查看全部
单个节点可以运行，但是配置为多个服务器集群的时候，总是提示无法发现服务器，花了点时间排查了问题，原来是配置文件的timeout问题，需要把timetout的值设置大一些，然后集群就可以发现到局域网中的其他节点。
修改文件elasticsearch.yml 文件中的timeout参数，改成原来值得10倍就可以了。
修改文件elasticsearch.yml 文件中的timeout参数，改成原来值得10倍就可以了。
版本不兼容会增加学习的成本和挫败感-致ElasticSearch和Django
数据库 • 李魔佛 发表了文章 • 0 个评论 • 3010 次浏览 • 2019-04-27 21:59
真是累觉不爱。
看的书或者网上的教程，一步一步下来，发现要一路google。 2018年8月的书，到2019年上机，书上代码已经无法正常运行了。 报的错误就是新版ElasticSearch或者Django已经不支持这个api了。 真是一万字草泥码奔腾而过。
查看全部
看的书或者网上的教程，一步一步下来，发现要一路google。 2018年8月的书，到2019年上机，书上代码已经无法正常运行了。 报的错误就是新版ElasticSearch或者Django已经不支持这个api了。 真是一万字草泥码奔腾而过。
查看全部
真是累觉不爱。
看的书或者网上的教程，一步一步下来，发现要一路google。 2018年8月的书，到2019年上机，书上代码已经无法正常运行了。 报的错误就是新版ElasticSearch或者Django已经不支持这个api了。 真是一万字草泥码奔腾而过。
看的书或者网上的教程，一步一步下来，发现要一路google。 2018年8月的书，到2019年上机，书上代码已经无法正常运行了。 报的错误就是新版ElasticSearch或者Django已经不支持这个api了。 真是一万字草泥码奔腾而过。
Fielddata is disabled on text fields by default. Set fielddata=true
数据库 • 李魔佛 发表了文章 • 0 个评论 • 5617 次浏览 • 2019-04-24 15:37
在ES5.X之后，默认的text类型无法做聚合操作。 比如官方的例子：
{ "size":0,
"aggs":
{
"color":
{
"terms":{
"field":"color"
}
}
}
}
创建数据如下：
curl -X POST "10.18.6.102:9200/cars/transactions/_bulk" -H 'Content-Type: application/json' -d'
{ "index": {}}
{ "price" : 10000, "color" : "red", "make" : "honda", "sold" : "2014-10-28" }
{ "index": {}}
{ "price" : 20000, "color" : "red", "make" : "honda", "sold" : "2014-11-05" }
{ "index": {}}
{ "price" : 30000, "color" : "green", "make" : "ford", "sold" : "2014-05-18" }
{ "index": {}}
{ "price" : 15000, "color" : "blue", "make" : "toyota", "sold" : "2014-07-02" }
{ "index": {}}
{ "price" : 12000, "color" : "green", "make" : "toyota", "sold" : "2014-08-19" }
{ "index": {}}
{ "price" : 20000, "color" : "red", "make" : "honda", "sold" : "2014-11-05" }
{ "index": {}}
{ "price" : 80000, "color" : "red", "make" : "bmw", "sold" : "2014-01-01" }
{ "index": {}}
{ "price" : 25000, "color" : "blue", "make" : "ford", "sold" : "2014-02-12" }
'
那么运行聚合操作会报错，官方的说法是text是会分词，如果text中一个文本为New York，那么就会被分成2个桶，一个New桶，一个York桶，那么显然不能聚合操作，要么你把该类型替换成keyword类型，因为keyword类型是不会分词的，可以用来做聚合操作。
如果实在是想要用text做聚合操作，那么可以手工修改其mapping
PUT my_index/_mapping/_doc
{
"properties": {
"my_field": {
"type": "text",
"fielddata": true
}
}
}上面语句可以在已有d的mapping上修改。
修改完成后就可以正常聚合操作了。
查看全部
{ "size":0,
"aggs":
{
"color":
{
"terms":{
"field":"color"
}
}
}
}
创建数据如下：
curl -X POST "10.18.6.102:9200/cars/transactions/_bulk" -H 'Content-Type: application/json' -d'
{ "index": {}}
{ "price" : 10000, "color" : "red", "make" : "honda", "sold" : "2014-10-28" }
{ "index": {}}
{ "price" : 20000, "color" : "red", "make" : "honda", "sold" : "2014-11-05" }
{ "index": {}}
{ "price" : 30000, "color" : "green", "make" : "ford", "sold" : "2014-05-18" }
{ "index": {}}
{ "price" : 15000, "color" : "blue", "make" : "toyota", "sold" : "2014-07-02" }
{ "index": {}}
{ "price" : 12000, "color" : "green", "make" : "toyota", "sold" : "2014-08-19" }
{ "index": {}}
{ "price" : 20000, "color" : "red", "make" : "honda", "sold" : "2014-11-05" }
{ "index": {}}
{ "price" : 80000, "color" : "red", "make" : "bmw", "sold" : "2014-01-01" }
{ "index": {}}
{ "price" : 25000, "color" : "blue", "make" : "ford", "sold" : "2014-02-12" }
'
那么运行聚合操作会报错，官方的说法是text是会分词，如果text中一个文本为New York，那么就会被分成2个桶，一个New桶，一个York桶，那么显然不能聚合操作，要么你把该类型替换成keyword类型，因为keyword类型是不会分词的，可以用来做聚合操作。
如果实在是想要用text做聚合操作，那么可以手工修改其mapping
PUT my_index/_mapping/_doc
{
"properties": {
"my_field": {
"type": "text",
"fielddata": true
}
}
}上面语句可以在已有d的mapping上修改。
修改完成后就可以正常聚合操作了。
查看全部
在ES5.X之后，默认的text类型无法做聚合操作。 比如官方的例子：
创建数据如下：
那么运行聚合操作会报错，官方的说法是text是会分词，如果text中一个文本为New York，那么就会被分成2个桶，一个New桶，一个York桶，那么显然不能聚合操作，要么你把该类型替换成keyword类型，因为keyword类型是不会分词的，可以用来做聚合操作。
如果实在是想要用text做聚合操作，那么可以手工修改其mapping
修改完成后就可以正常聚合操作了。
{ "size":0,
"aggs":
{
"color":
{
"terms":{
"field":"color"
}
}
}
}创建数据如下：
curl -X POST "10.18.6.102:9200/cars/transactions/_bulk" -H 'Content-Type: application/json' -d'
{ "index": {}}
{ "price" : 10000, "color" : "red", "make" : "honda", "sold" : "2014-10-28" }
{ "index": {}}
{ "price" : 20000, "color" : "red", "make" : "honda", "sold" : "2014-11-05" }
{ "index": {}}
{ "price" : 30000, "color" : "green", "make" : "ford", "sold" : "2014-05-18" }
{ "index": {}}
{ "price" : 15000, "color" : "blue", "make" : "toyota", "sold" : "2014-07-02" }
{ "index": {}}
{ "price" : 12000, "color" : "green", "make" : "toyota", "sold" : "2014-08-19" }
{ "index": {}}
{ "price" : 20000, "color" : "red", "make" : "honda", "sold" : "2014-11-05" }
{ "index": {}}
{ "price" : 80000, "color" : "red", "make" : "bmw", "sold" : "2014-01-01" }
{ "index": {}}
{ "price" : 25000, "color" : "blue", "make" : "ford", "sold" : "2014-02-12" }
'
那么运行聚合操作会报错，官方的说法是text是会分词，如果text中一个文本为New York，那么就会被分成2个桶，一个New桶，一个York桶，那么显然不能聚合操作，要么你把该类型替换成keyword类型，因为keyword类型是不会分词的，可以用来做聚合操作。
如果实在是想要用text做聚合操作，那么可以手工修改其mapping
PUT my_index/_mapping/_doc上面语句可以在已有d的mapping上修改。
{
"properties": {
"my_field": {
"type": "text",
"fielddata": true
}
}
}
修改完成后就可以正常聚合操作了。
postman使用_analyze端点 ElasticSearch
数据库 • 李魔佛 发表了文章 • 0 个评论 • 4139 次浏览 • 2019-04-01 15:31
POSTMAN
ES 6.x如何使用_analyze端点
因为使用curl编辑查询语句很不方便。平时用postman最多，故平时查询ES经常使用postman查询。
_analyze端点是用于查询分析器的分析效果。
文档中使用如下方法查询
curl -XPOST 'localhost:9200/_analyze?analyzer=standard' -d 'I love Bears and Fish.'
只是奇怪，为何post的内容 'I love Bears and Fish.'不需要字段名？
试验了几次后，发现在6.x上，该字段的字段名是text
所以请求body应该是这样的
可以使用get方法来使用_analyze端点 查看全部
ES 6.x如何使用_analyze端点
因为使用curl编辑查询语句很不方便。平时用postman最多，故平时查询ES经常使用postman查询。
_analyze端点是用于查询分析器的分析效果。
文档中使用如下方法查询
curl -XPOST 'localhost:9200/_analyze?analyzer=standard' -d 'I love Bears and Fish.'
只是奇怪，为何post的内容 'I love Bears and Fish.'不需要字段名？
试验了几次后，发现在6.x上，该字段的字段名是text
所以请求body应该是这样的
可以使用get方法来使用_analyze端点 查看全部
POSTMAN
ES 6.x如何使用_analyze端点
因为使用curl编辑查询语句很不方便。平时用postman最多，故平时查询ES经常使用postman查询。
_analyze端点是用于查询分析器的分析效果。
文档中使用如下方法查询
curl -XPOST 'localhost:9200/_analyze?analyzer=standard' -d 'I love Bears and Fish.'
只是奇怪，为何post的内容 'I love Bears and Fish.'不需要字段名？
试验了几次后，发现在6.x上，该字段的字段名是text
所以请求body应该是这样的
可以使用get方法来使用_analyze端点
ES 6.x如何使用_analyze端点
因为使用curl编辑查询语句很不方便。平时用postman最多，故平时查询ES经常使用postman查询。
_analyze端点是用于查询分析器的分析效果。
文档中使用如下方法查询
curl -XPOST 'localhost:9200/_analyze?analyzer=standard' -d 'I love Bears and Fish.'
只是奇怪，为何post的内容 'I love Bears and Fish.'不需要字段名？
试验了几次后，发现在6.x上，该字段的字段名是text
所以请求body应该是这样的
可以使用get方法来使用_analyze端点
Elasticsearch ： Failed to obtain node lock, is the following location writable
数据库 • 李魔佛 发表了文章 • 0 个评论 • 4091 次浏览 • 2019-02-25 18:35
准备运行 Elasticsearch的时候出现报错： Failed to obtain node lock, is the following location writable。
看了下权限，没有问题，可以写。
后来发现后台的ES进程没有的得到释放，使用kill命令杀掉
ps -axu | grep 'java'
找到对应的进程ID，然后杀掉
kill ID号
然后重新调用./elasticsearch 就可以了。
查看全部
看了下权限，没有问题，可以写。
后来发现后台的ES进程没有的得到释放，使用kill命令杀掉
ps -axu | grep 'java'
找到对应的进程ID，然后杀掉
kill ID号
然后重新调用./elasticsearch 就可以了。
查看全部
准备运行 Elasticsearch的时候出现报错： Failed to obtain node lock, is the following location writable。
看了下权限，没有问题，可以写。
后来发现后台的ES进程没有的得到释放，使用kill命令杀掉
ps -axu | grep 'java'
找到对应的进程ID，然后杀掉
kill ID号
然后重新调用./elasticsearch 就可以了。
看了下权限，没有问题，可以写。
后来发现后台的ES进程没有的得到释放，使用kill命令杀掉
ps -axu | grep 'java'
找到对应的进程ID，然后杀掉
kill ID号
然后重新调用./elasticsearch 就可以了。
修改Logstash中的sql_last_value值
数据库 • 李魔佛 发表了文章 • 0 个评论 • 10927 次浏览 • 2019-02-20 19:37
修改syncpoint_table里面的值 就可以了。
这个文件在logstash的第一层目录底下。
不然每次都是从这个最后的值开始执行的。
这个文件在logstash的第一层目录底下。
不然每次都是从这个最后的值开始执行的。
修改syncpoint_table里面的值 就可以了。
这个文件在logstash的第一层目录底下。
不然每次都是从这个最后的值开始执行的。
这个文件在logstash的第一层目录底下。
不然每次都是从这个最后的值开始执行的。
docker下载的ElasticSearch镜像 web/postman访问时需要密码，如何去除
数据库 • 李魔佛 发表了文章 • 0 个评论 • 4248 次浏览 • 2018-11-13 11:40
从docker官方镜像源下载的镜像，可以正常运行。
可是在postman中请求接口：
GET ： 10.18.6.102:9200/_cat/indices?v
爆出下面的错误：
missing authentication token for REST request
然后使用浏览器查询：发现需要输入账户和密码。
账户名：elastic
密码：changeme
如何才能删除这个用户名和密码呢？ 每次请求不需要密码。
进入docker容器
修改这个文件
/usr/share/elasticsearch/config/elasticssearch.yml
添加最后一行：
xpack.security.enabled: false
然后记得commit一下你的修改。
查看全部
可是在postman中请求接口：
GET ： 10.18.6.102:9200/_cat/indices?v
爆出下面的错误：
missing authentication token for REST request
然后使用浏览器查询：发现需要输入账户和密码。
账户名：elastic
密码：changeme
如何才能删除这个用户名和密码呢？ 每次请求不需要密码。
进入docker容器
修改这个文件
/usr/share/elasticsearch/config/elasticssearch.yml
添加最后一行：
xpack.security.enabled: false
然后记得commit一下你的修改。
查看全部
从docker官方镜像源下载的镜像，可以正常运行。
可是在postman中请求接口：
GET ： 10.18.6.102:9200/_cat/indices?v
爆出下面的错误：
然后使用浏览器查询：发现需要输入账户和密码。
账户名：elastic
密码：changeme
如何才能删除这个用户名和密码呢？ 每次请求不需要密码。
进入docker容器
修改这个文件
/usr/share/elasticsearch/config/elasticssearch.yml
添加最后一行：
xpack.security.enabled: false
然后记得commit一下你的修改。
可是在postman中请求接口：
GET ： 10.18.6.102:9200/_cat/indices?v
爆出下面的错误：
missing authentication token for REST request
然后使用浏览器查询：发现需要输入账户和密码。
账户名：elastic
密码：changeme
如何才能删除这个用户名和密码呢？ 每次请求不需要密码。
进入docker容器
修改这个文件
/usr/share/elasticsearch/config/elasticssearch.yml
添加最后一行：
xpack.security.enabled: false
然后记得commit一下你的修改。
Docker ElasticSearch挂载本地数据 报错
数据库 • 李魔佛 发表了文章 • 0 个评论 • 11577 次浏览 • 2018-11-13 10:37
应用场景中需要把数据挂载在本地的目录，以便以后数据的迁移与备份。
挂载命令：docker run -p 9200:9200 -e "http.host=0.0.0.0" -e "transport.host=127.0.0.1" -v /home/myuser/elastic_data/:/usr/share/elasticsearch/data docker.elastic.co/elasticsearch/elasticsearch:5.5.1
其中-v是指定的挂载路径
/home/myuser/elastic_data/
这个是本地路径
运行后报错：[2018-11-13T02:23:33,994][INFO ][o.e.n.Node ] initializing ...
[2018-11-13T02:23:34,010][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] uncaught exception in thread [main]
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: Failed to create node environment
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:127) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:114) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:67) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:122) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.Command.main(Command.java:88) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:91) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:84) ~[elasticsearch-5.5.1.jar:5.5.1]
Caused by: java.lang.IllegalStateException: Failed to create node environment
at org.elasticsearch.node.Node.<init>(Node.java:267) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:244) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:351) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) ~[elasticsearch-5.5.1.jar:5.5.1]
... 6 more
Caused by: java.nio.file.AccessDeniedException: /usr/share/elasticsearch/data/nodes
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) ~[?:?]
at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384) ~[?:?]
at java.nio.file.Files.createDirectory(Files.java:674) ~[?:1.8.0_141]
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781) ~[?:1.8.0_141]
at java.nio.file.Files.createDirectories(Files.java:767) ~[?:1.8.0_141]
at org.elasticsearch.env.NodeEnvironment.<init>(NodeEnvironment.java:221) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:264) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:244) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:351) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) ~[elasticsearch-5.5.1.jar:5.5.1]
... 6 more
原因是权限问题，需要把目录
/home/myuser/elastic_data/ 改为777， 然后问题就解决了chmod 777 /home/myuser/elastic_data/
原创文章
转载请注明出处：
http://30daydo.com/article/369
查看全部
挂载命令：docker run -p 9200:9200 -e "http.host=0.0.0.0" -e "transport.host=127.0.0.1" -v /home/myuser/elastic_data/:/usr/share/elasticsearch/data docker.elastic.co/elasticsearch/elasticsearch:5.5.1
其中-v是指定的挂载路径
/home/myuser/elastic_data/
这个是本地路径
运行后报错：[2018-11-13T02:23:33,994][INFO ][o.e.n.Node ] initializing ...
[2018-11-13T02:23:34,010][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] uncaught exception in thread [main]
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: Failed to create node environment
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:127) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:114) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:67) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:122) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.Command.main(Command.java:88) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:91) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:84) ~[elasticsearch-5.5.1.jar:5.5.1]
Caused by: java.lang.IllegalStateException: Failed to create node environment
at org.elasticsearch.node.Node.<init>(Node.java:267) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:244) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:351) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) ~[elasticsearch-5.5.1.jar:5.5.1]
... 6 more
Caused by: java.nio.file.AccessDeniedException: /usr/share/elasticsearch/data/nodes
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) ~[?:?]
at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384) ~[?:?]
at java.nio.file.Files.createDirectory(Files.java:674) ~[?:1.8.0_141]
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781) ~[?:1.8.0_141]
at java.nio.file.Files.createDirectories(Files.java:767) ~[?:1.8.0_141]
at org.elasticsearch.env.NodeEnvironment.<init>(NodeEnvironment.java:221) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:264) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:244) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:351) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) ~[elasticsearch-5.5.1.jar:5.5.1]
... 6 more
原因是权限问题，需要把目录
/home/myuser/elastic_data/ 改为777， 然后问题就解决了chmod 777 /home/myuser/elastic_data/
原创文章
转载请注明出处：
http://30daydo.com/article/369
查看全部
应用场景中需要把数据挂载在本地的目录，以便以后数据的迁移与备份。
挂载命令：
其中-v是指定的挂载路径
/home/myuser/elastic_data/
这个是本地路径
运行后报错：
原因是权限问题，需要把目录
/home/myuser/elastic_data/ 改为777， 然后问题就解决了
原创文章
转载请注明出处：
http://30daydo.com/article/369
挂载命令：
docker run -p 9200:9200 -e "http.host=0.0.0.0" -e "transport.host=127.0.0.1" -v /home/myuser/elastic_data/:/usr/share/elasticsearch/data docker.elastic.co/elasticsearch/elasticsearch:5.5.1
其中-v是指定的挂载路径
/home/myuser/elastic_data/
这个是本地路径
运行后报错：
[2018-11-13T02:23:33,994][INFO ][o.e.n.Node ] initializing ...
[2018-11-13T02:23:34,010][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] uncaught exception in thread [main]
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: Failed to create node environment
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:127) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:114) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:67) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:122) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.Command.main(Command.java:88) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:91) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:84) ~[elasticsearch-5.5.1.jar:5.5.1]
Caused by: java.lang.IllegalStateException: Failed to create node environment
at org.elasticsearch.node.Node.<init>(Node.java:267) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:244) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:351) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) ~[elasticsearch-5.5.1.jar:5.5.1]
... 6 more
Caused by: java.nio.file.AccessDeniedException: /usr/share/elasticsearch/data/nodes
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) ~[?:?]
at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384) ~[?:?]
at java.nio.file.Files.createDirectory(Files.java:674) ~[?:1.8.0_141]
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781) ~[?:1.8.0_141]
at java.nio.file.Files.createDirectories(Files.java:767) ~[?:1.8.0_141]
at org.elasticsearch.env.NodeEnvironment.<init>(NodeEnvironment.java:221) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:264) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:244) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:351) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) ~[elasticsearch-5.5.1.jar:5.5.1]
... 6 more
原因是权限问题，需要把目录
/home/myuser/elastic_data/ 改为777， 然后问题就解决了
chmod 777 /home/myuser/elastic_data/
原创文章
转载请注明出处：
http://30daydo.com/article/369
elasticsearch-head连接不上elasticsearch服务器
数据库 • 李魔佛 发表了文章 • 0 个评论 • 4093 次浏览 • 2018-11-13 09:21
在git hub上同步下来的代码后，运行Elasticsearch-head，一直连不上去。 后来才发现这个github上的版本有问题，于是在chrome的应用商城下载了一个elasticsearch-head的插件，就可以直接用了。
查看全部
查看全部
在git hub上同步下来的代码后，运行Elasticsearch-head，一直连不上去。 后来才发现这个github上的版本有问题，于是在chrome的应用商城下载了一个elasticsearch-head的插件，就可以直接用了。
MongoDB数据导入到ElasticSearch python代码实现
数据库 • 李魔佛 发表了文章 • 0 个评论 • 4520 次浏览 • 2018-11-12 14:13
ElasticSearch对文本的搜索速度真的是神速呀，基本是毫秒级别的。对于大文本，简直就是秒飞MYSQL十条街。使用python实现：es = Elasticsearch(['10.18.6.26:9200'])
ret = collection.find({})
# 删除mongo的_id字段，否则无法把Object类型插入到Elastic
map(lambda x:(del x['_id']),ret)
actions=
for idx,item in enumerate(ret):
i={
"_index":"jsl",
"_type":"text",
"_id":idx,
"_source":{
# 需要提取的字段
"title":item.get('title'),
"url":item.get('url')
}
}
actions.append(i)
start=time.time()
helpers.bulk(es,actions)
end=time.time()-start
print(end)
运行下来，20W条数据，大概用了15秒左右全部导入ElasticSearch 数据库中。 查看全部
ret = collection.find({})
# 删除mongo的_id字段，否则无法把Object类型插入到Elastic
map(lambda x:(del x['_id']),ret)
actions=
for idx,item in enumerate(ret):
i={
"_index":"jsl",
"_type":"text",
"_id":idx,
"_source":{
# 需要提取的字段
"title":item.get('title'),
"url":item.get('url')
}
}
actions.append(i)
start=time.time()
helpers.bulk(es,actions)
end=time.time()-start
print(end)
运行下来，20W条数据，大概用了15秒左右全部导入ElasticSearch 数据库中。 查看全部
ElasticSearch对文本的搜索速度真的是神速呀，基本是毫秒级别的。对于大文本，简直就是秒飞MYSQL十条街。使用python实现：
运行下来，20W条数据，大概用了15秒左右全部导入ElasticSearch 数据库中。
es = Elasticsearch(['10.18.6.26:9200'])
ret = collection.find({})
# 删除mongo的_id字段，否则无法把Object类型插入到Elastic
map(lambda x:(del x['_id']),ret)
actions=
for idx,item in enumerate(ret):
i={
"_index":"jsl",
"_type":"text",
"_id":idx,
"_source":{
# 需要提取的字段
"title":item.get('title'),
"url":item.get('url')
}
}
actions.append(i)
start=time.time()
helpers.bulk(es,actions)
end=time.time()-start
print(end)
运行下来，20W条数据，大概用了15秒左右全部导入ElasticSearch 数据库中。
Elastic Search报错：Fielddata is disabled on text fields by default
Linux • 发表了文章 • 0 个评论 • 3920 次浏览 • 2020-09-16 19:26
在使用 ElasticSearch 的时候，如果索引中的字段是 text 类型，针对该字段聚合、排序和查询的时候常会出现 Fielddata is disabled on text fields by default. Set fielddata=true 的错误。本文总结这个错误出现的原因，可能的修复方法等。
常见原因
在 ElasticSearch 中，Fielddata 默认在 text 类型的字段时是不启用的。设想，如果默认打开，那么你的数据中，每个字符串大概率不一样的话，那么这个字段需要的集合大小（Cardinality）会非常大。
而这个字段是需要存在内存中的 (heap)，因此不可能默认打开。所以如果你从一个 script 来对一个 text 字段进行排序、聚合或者查询的话，就会出现这个错误。Fielddata is disabled on text fields by default. Set `fielddata=true` on [`你的字段名字`] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory.
Fielddata is disabled on text fields by default 解答方法看这篇：
ES 如何解决 Fielddata is disabled on text fields by default 错误
查看全部
常见原因
在 ElasticSearch 中，Fielddata 默认在 text 类型的字段时是不启用的。设想，如果默认打开，那么你的数据中，每个字符串大概率不一样的话，那么这个字段需要的集合大小（Cardinality）会非常大。
而这个字段是需要存在内存中的 (heap)，因此不可能默认打开。所以如果你从一个 script 来对一个 text 字段进行排序、聚合或者查询的话，就会出现这个错误。Fielddata is disabled on text fields by default. Set `fielddata=true` on [`你的字段名字`] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory.
Fielddata is disabled on text fields by default 解答方法看这篇：
ES 如何解决 Fielddata is disabled on text fields by default 错误
查看全部
在使用 ElasticSearch 的时候，如果索引中的字段是 text 类型，针对该字段聚合、排序和查询的时候常会出现 Fielddata is disabled on text fields by default. Set fielddata=true 的错误。本文总结这个错误出现的原因，可能的修复方法等。
常见原因
在 ElasticSearch 中，Fielddata 默认在 text 类型的字段时是不启用的。设想，如果默认打开，那么你的数据中，每个字符串大概率不一样的话，那么这个字段需要的集合大小（Cardinality）会非常大。
而这个字段是需要存在内存中的 (heap)，因此不可能默认打开。所以如果你从一个 script 来对一个 text 字段进行排序、聚合或者查询的话，就会出现这个错误。Fielddata is disabled on text fields by default. Set `fielddata=true` on [`你的字段名字`] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory.
Fielddata is disabled on text fields by default 解答方法看这篇：
ES 如何解决 Fielddata is disabled on text fields by default 错误
常见原因
在 ElasticSearch 中，Fielddata 默认在 text 类型的字段时是不启用的。设想，如果默认打开，那么你的数据中，每个字符串大概率不一样的话，那么这个字段需要的集合大小（Cardinality）会非常大。
而这个字段是需要存在内存中的 (heap)，因此不可能默认打开。所以如果你从一个 script 来对一个 text 字段进行排序、聚合或者查询的话，就会出现这个错误。Fielddata is disabled on text fields by default. Set `fielddata=true` on [`你的字段名字`] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory.
Fielddata is disabled on text fields by default 解答方法看这篇：
ES 如何解决 Fielddata is disabled on text fields by default 错误
在Docker中配置Kibana连接ElasticSearch的一些小坑
数据库 • 李魔佛 发表了文章 • 0 个评论 • 11579 次浏览 • 2020-08-09 01:49
之前编译部署的时候只需要在config/kibana.yaml 中修改host ,把默认的 http://elasticsearch:9200 改为 http://127.0.0.1:9200 , 如果你的ElasticSearch带密码访问，只需在下面加多2行
elasticseacrh.user='elastic'
elasticsearch.password='xxxxxx' # 你之前配置ES时设置的密码
BUT, 上面的配置在docker环境下无法正常启动使用kibana， 通过docker logs 容器ID， 查看的日志信息：
log [17:39:09.057] [warning][data][elasticsearch] No living connections
log [17:39:09.058] [warning][licensing][plugins] License information could not be obtained from Elasticsearch due to Error: No Living connections error
log [17:39:09.635] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:09.636] [warning][admin][elasticsearch] No living connections
log [17:39:12.137] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:12.138] [warning][admin][elasticsearch] No living connections
log [17:39:14.640] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:14.640] [warning][admin][elasticsearch] No living connections
log [17:39:17.143] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:17.143] [warning][admin][elasticsearch] No living connections
log [17:39:19.645] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/使用curl访问127.0.0.1:920也是正常的，后来想到docker貌似没有配置桥接网络，两个docker可能无法互通，故把kibana.yaml里面的host改为主机的真实IP（内网172网段ip），然后问题就得到解决了。 查看全部
elasticseacrh.user='elastic'
elasticsearch.password='xxxxxx' # 你之前配置ES时设置的密码
BUT, 上面的配置在docker环境下无法正常启动使用kibana， 通过docker logs 容器ID， 查看的日志信息：
log [17:39:09.057] [warning][data][elasticsearch] No living connections
log [17:39:09.058] [warning][licensing][plugins] License information could not be obtained from Elasticsearch due to Error: No Living connections error
log [17:39:09.635] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:09.636] [warning][admin][elasticsearch] No living connections
log [17:39:12.137] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:12.138] [warning][admin][elasticsearch] No living connections
log [17:39:14.640] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:14.640] [warning][admin][elasticsearch] No living connections
log [17:39:17.143] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:17.143] [warning][admin][elasticsearch] No living connections
log [17:39:19.645] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/使用curl访问127.0.0.1:920也是正常的，后来想到docker貌似没有配置桥接网络，两个docker可能无法互通，故把kibana.yaml里面的host改为主机的真实IP（内网172网段ip），然后问题就得到解决了。 查看全部
之前编译部署的时候只需要在config/kibana.yaml 中修改host ,把默认的 http://elasticsearch:9200 改为 http://127.0.0.1:9200 , 如果你的ElasticSearch带密码访问，只需在下面加多2行
elasticseacrh.user='elastic'
elasticsearch.password='xxxxxx' # 你之前配置ES时设置的密码
BUT, 上面的配置在docker环境下无法正常启动使用kibana， 通过docker logs 容器ID， 查看的日志信息：
elasticseacrh.user='elastic'
elasticsearch.password='xxxxxx' # 你之前配置ES时设置的密码
BUT, 上面的配置在docker环境下无法正常启动使用kibana， 通过docker logs 容器ID， 查看的日志信息：
log [17:39:09.057] [warning][data][elasticsearch] No living connections使用curl访问127.0.0.1:920也是正常的，后来想到docker貌似没有配置桥接网络，两个docker可能无法互通，故把kibana.yaml里面的host改为主机的真实IP（内网172网段ip），然后问题就得到解决了。
log [17:39:09.058] [warning][licensing][plugins] License information could not be obtained from Elasticsearch due to Error: No Living connections error
log [17:39:09.635] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:09.636] [warning][admin][elasticsearch] No living connections
log [17:39:12.137] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:12.138] [warning][admin][elasticsearch] No living connections
log [17:39:14.640] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:14.640] [warning][admin][elasticsearch] No living connections
log [17:39:17.143] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
log [17:39:17.143] [warning][admin][elasticsearch] No living connections
log [17:39:19.645] [warning][admin][elasticsearch] Unable to revive connection: http://127.0.0.1:9200/
ElasticSearch查看已经存在的文档保存在哪个分片
数据库 • 李魔佛 发表了文章 • 0 个评论 • 4152 次浏览 • 2019-05-26 12:54
比如我有以下的文档：
{
"took" : 3,
"timed_out" : false,
"_shards" : {
"total" : 5,
"successful" : 5,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : 5,
"max_score" : 1.0,
"hits" : [
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "XxyrM2kBVzdNcvl_GHv2",
"_score" : 1.0,
"_source" : {
"name" : "Shiled",
"twitter" : "Sonny sql is awesome",
"date" : "2018-12-27",
"id" : 1240,
"tags" : [
"red",
"shit"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YByrM2kBVzdNcvl_tnvm",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 12357,
"tags" : [
"red"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "7777",
"_score" : 1.0,
"_source" : {
"name" : "Rocky Chen",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 9999
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YhzDN2kBVzdNcvl_enuT",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 888888,
"tags" : [
"red",
"green"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YxzDN2kBVzdNcvl_u3th",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 888888,
"tags" : [
"red",
"green"
]
}
}
]
}
}
如果我想看看id是 "_id" : "YxzDN2kBVzdNcvl_u3th",
这个文档是保存在哪个分片，如何查看？
引用：
路由一个文档到一个分片中编辑
当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？
首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：
shard = hash(routing) % number_of_primary_shards
routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。
这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。
那么可以使用
GET test/_search_shards?routing=ID号 来查看你要查询的id所在的分片
得到的结果：
{
"nodes" : {
"yl-qYmh1SXqzJsfI4d1ddw" : {
"name" : "node-3",
"ephemeral_id" : "UsJ9rFELTiCW07oHE9YMdg",
"transport_address" : "10.18.6.26:9300",
"attributes" : {
"ml.machine_memory" : "6088101888",
"rack" : "r1",
"ml.max_open_jobs" : "20",
"xpack.installed" : "true",
"ml.enabled" : "true"
}
},
"wT7wUd3iTkujYUsbVNVv-w" : {
"name" : "node-1",
"ephemeral_id" : "fP-vgSb0SdemnHDyaJUsWw",
"transport_address" : "10.18.6.102:9300",
"attributes" : {
"ml.machine_memory" : "8256720896",
"rack" : "r1",
"xpack.installed" : "true",
"ml.max_open_jobs" : "20",
"ml.enabled" : "true"
}
}
},
"indices" : {
"test" : { }
},
"shards" : [
[
{
"state" : "STARTED",
"primary" : true,
"node" : "wT7wUd3iTkujYUsbVNVv-w",
"relocating_node" : null,
"shard" : 1,
"index" : "test",
"allocation_id" : {
"id" : "k-8E4dL7QmGgwcsNsUCP6Q"
}
},
{
"state" : "STARTED",
"primary" : false,
"node" : "yl-qYmh1SXqzJsfI4d1ddw",
"relocating_node" : null,
"shard" : 1,
"index" : "test",
"allocation_id" : {
"id" : "lvOpQIKgRUibkulr3nRfEw"
}
}
]
]
}
只需要关注shards字段就可以，从上面可以看到，该文档存在shard 1 分片上。 分别在node1和node3节点，一个是主分片，一个是副本分片 查看全部
{
"took" : 3,
"timed_out" : false,
"_shards" : {
"total" : 5,
"successful" : 5,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : 5,
"max_score" : 1.0,
"hits" : [
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "XxyrM2kBVzdNcvl_GHv2",
"_score" : 1.0,
"_source" : {
"name" : "Shiled",
"twitter" : "Sonny sql is awesome",
"date" : "2018-12-27",
"id" : 1240,
"tags" : [
"red",
"shit"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YByrM2kBVzdNcvl_tnvm",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 12357,
"tags" : [
"red"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "7777",
"_score" : 1.0,
"_source" : {
"name" : "Rocky Chen",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 9999
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YhzDN2kBVzdNcvl_enuT",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 888888,
"tags" : [
"red",
"green"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YxzDN2kBVzdNcvl_u3th",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 888888,
"tags" : [
"red",
"green"
]
}
}
]
}
}
如果我想看看id是 "_id" : "YxzDN2kBVzdNcvl_u3th",
这个文档是保存在哪个分片，如何查看？
引用：
路由一个文档到一个分片中编辑
当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？
首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：
shard = hash(routing) % number_of_primary_shards
routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。
这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。
那么可以使用
GET test/_search_shards?routing=ID号 来查看你要查询的id所在的分片
得到的结果：
{
"nodes" : {
"yl-qYmh1SXqzJsfI4d1ddw" : {
"name" : "node-3",
"ephemeral_id" : "UsJ9rFELTiCW07oHE9YMdg",
"transport_address" : "10.18.6.26:9300",
"attributes" : {
"ml.machine_memory" : "6088101888",
"rack" : "r1",
"ml.max_open_jobs" : "20",
"xpack.installed" : "true",
"ml.enabled" : "true"
}
},
"wT7wUd3iTkujYUsbVNVv-w" : {
"name" : "node-1",
"ephemeral_id" : "fP-vgSb0SdemnHDyaJUsWw",
"transport_address" : "10.18.6.102:9300",
"attributes" : {
"ml.machine_memory" : "8256720896",
"rack" : "r1",
"xpack.installed" : "true",
"ml.max_open_jobs" : "20",
"ml.enabled" : "true"
}
}
},
"indices" : {
"test" : { }
},
"shards" : [
[
{
"state" : "STARTED",
"primary" : true,
"node" : "wT7wUd3iTkujYUsbVNVv-w",
"relocating_node" : null,
"shard" : 1,
"index" : "test",
"allocation_id" : {
"id" : "k-8E4dL7QmGgwcsNsUCP6Q"
}
},
{
"state" : "STARTED",
"primary" : false,
"node" : "yl-qYmh1SXqzJsfI4d1ddw",
"relocating_node" : null,
"shard" : 1,
"index" : "test",
"allocation_id" : {
"id" : "lvOpQIKgRUibkulr3nRfEw"
}
}
]
]
}
只需要关注shards字段就可以，从上面可以看到，该文档存在shard 1 分片上。 分别在node1和node3节点，一个是主分片，一个是副本分片 查看全部
比如我有以下的文档：
{
"took" : 3,
"timed_out" : false,
"_shards" : {
"total" : 5,
"successful" : 5,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : 5,
"max_score" : 1.0,
"hits" : [
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "XxyrM2kBVzdNcvl_GHv2",
"_score" : 1.0,
"_source" : {
"name" : "Shiled",
"twitter" : "Sonny sql is awesome",
"date" : "2018-12-27",
"id" : 1240,
"tags" : [
"red",
"shit"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YByrM2kBVzdNcvl_tnvm",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 12357,
"tags" : [
"red"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "7777",
"_score" : 1.0,
"_source" : {
"name" : "Rocky Chen",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 9999
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YhzDN2kBVzdNcvl_enuT",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 888888,
"tags" : [
"red",
"green"
]
}
},
{
"_index" : "test",
"_type" : "mydoc",
"_id" : "YxzDN2kBVzdNcvl_u3th",
"_score" : 1.0,
"_source" : {
"name" : "YYerk",
"twitter" : "sql is awesome",
"date" : "2008-12-27",
"id" : 888888,
"tags" : [
"red",
"green"
]
}
}
]
}
}
如果我想看看id是 "_id" : "YxzDN2kBVzdNcvl_u3th",
这个文档是保存在哪个分片，如何查看？
引用：
路由一个文档到一个分片中编辑
当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？
首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：
shard = hash(routing) % number_of_primary_shards
routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。
这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。
那么可以使用
GET test/_search_shards?routing=ID号 来查看你要查询的id所在的分片
得到的结果：
{
"nodes" : {
"yl-qYmh1SXqzJsfI4d1ddw" : {
"name" : "node-3",
"ephemeral_id" : "UsJ9rFELTiCW07oHE9YMdg",
"transport_address" : "10.18.6.26:9300",
"attributes" : {
"ml.machine_memory" : "6088101888",
"rack" : "r1",
"ml.max_open_jobs" : "20",
"xpack.installed" : "true",
"ml.enabled" : "true"
}
},
"wT7wUd3iTkujYUsbVNVv-w" : {
"name" : "node-1",
"ephemeral_id" : "fP-vgSb0SdemnHDyaJUsWw",
"transport_address" : "10.18.6.102:9300",
"attributes" : {
"ml.machine_memory" : "8256720896",
"rack" : "r1",
"xpack.installed" : "true",
"ml.max_open_jobs" : "20",
"ml.enabled" : "true"
}
}
},
"indices" : {
"test" : { }
},
"shards" : [
[
{
"state" : "STARTED",
"primary" : true,
"node" : "wT7wUd3iTkujYUsbVNVv-w",
"relocating_node" : null,
"shard" : 1,
"index" : "test",
"allocation_id" : {
"id" : "k-8E4dL7QmGgwcsNsUCP6Q"
}
},
{
"state" : "STARTED",
"primary" : false,
"node" : "yl-qYmh1SXqzJsfI4d1ddw",
"relocating_node" : null,
"shard" : 1,
"index" : "test",
"allocation_id" : {
"id" : "lvOpQIKgRUibkulr3nRfEw"
}
}
]
]
}
只需要关注shards字段就可以，从上面可以看到，该文档存在shard 1 分片上。 分别在node1和node3节点，一个是主分片，一个是副本分片
elasticsearch在match查询里面使用了type字段 报错
数据库 • 李魔佛 发表了文章 • 0 个评论 • 13014 次浏览 • 2019-05-26 00:26
POST get-together/_search
{
"query":
{
"match": {
"name": {
"type":"phrase",
"query":"enterprise london",
"slop":1
}}
},
"_source": "name"
}
报错：
{
"error": {
"root_cause": [
{
"type": "parsing_exception",
"reason": "[match] query does not support [type]",
"line": 6,
"col": 13
}
],
"type": "parsing_exception",
"reason": "[match] query does not support [type]",
"line": 6,
"col": 13
},
"status": 400
}
在6.x已经不支持在math里面使用type，
可以修改为以下语法：
POST get-together/_search
{
"query":
{
"match_phrase": {
"name": {
"query":"enterprise london",
"slop":1
}}
},
"_source": "name"
}
得到的效果是一致的：
{
"took" : 2,
"timed_out" : false,
"_shards" : {
"total" : 2,
"successful" : 2,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : 1,
"max_score" : 1.3243701,
"hits" : [
{
"_index" : "get-together",
"_type" : "_doc",
"_id" : "5",
"_score" : 1.3243701,
"_source" : {
"name" : "Enterprise search London get-together"
}
}
]
}
} 查看全部
{
"query":
{
"match": {
"name": {
"type":"phrase",
"query":"enterprise london",
"slop":1
}}
},
"_source": "name"
}
报错：
{
"error": {
"root_cause": [
{
"type": "parsing_exception",
"reason": "[match] query does not support [type]",
"line": 6,
"col": 13
}
],
"type": "parsing_exception",
"reason": "[match] query does not support [type]",
"line": 6,
"col": 13
},
"status": 400
}
在6.x已经不支持在math里面使用type，
可以修改为以下语法：
POST get-together/_search
{
"query":
{
"match_phrase": {
"name": {
"query":"enterprise london",
"slop":1
}}
},
"_source": "name"
}
得到的效果是一致的：
{
"took" : 2,
"timed_out" : false,
"_shards" : {
"total" : 2,
"successful" : 2,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : 1,
"max_score" : 1.3243701,
"hits" : [
{
"_index" : "get-together",
"_type" : "_doc",
"_id" : "5",
"_score" : 1.3243701,
"_source" : {
"name" : "Enterprise search London get-together"
}
}
]
}
} 查看全部
POST get-together/_search
{
"query":
{
"match": {
"name": {
"type":"phrase",
"query":"enterprise london",
"slop":1
}}
},
"_source": "name"
}
报错：
{
"error": {
"root_cause": [
{
"type": "parsing_exception",
"reason": "[match] query does not support [type]",
"line": 6,
"col": 13
}
],
"type": "parsing_exception",
"reason": "[match] query does not support [type]",
"line": 6,
"col": 13
},
"status": 400
}在6.x已经不支持在math里面使用type，
可以修改为以下语法：
POST get-together/_search
{
"query":
{
"match_phrase": {
"name": {
"query":"enterprise london",
"slop":1
}}
},
"_source": "name"
}
得到的效果是一致的：
{
"took" : 2,
"timed_out" : false,
"_shards" : {
"total" : 2,
"successful" : 2,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : 1,
"max_score" : 1.3243701,
"hits" : [
{
"_index" : "get-together",
"_type" : "_doc",
"_id" : "5",
"_score" : 1.3243701,
"_source" : {
"name" : "Enterprise search London get-together"
}
}
]
}
}
elasticsearch 更新文档的坑
数据库 • 李魔佛 发表了文章 • 2 个评论 • 10275 次浏览 • 2019-05-24 22:46
POST cnbeta/doc/cUxO42oB9O-zF2ru-rs-/_update
{
"doc":{
"title":"中国操作系统"
}
}
那个body里面的”doc" 不能少
不然会报错：
{
"error": {
"root_cause": [
{
"type": "action_request_validation_exception",
"reason": "Validation Failed: 1: script or doc is missing;"
}
],
"type": "action_request_validation_exception",
"reason": "Validation Failed: 1: script or doc is missing;"
},
"status": 400
} 查看全部
{
"doc":{
"title":"中国操作系统"
}
}
那个body里面的”doc" 不能少
不然会报错：
{
"error": {
"root_cause": [
{
"type": "action_request_validation_exception",
"reason": "Validation Failed: 1: script or doc is missing;"
}
],
"type": "action_request_validation_exception",
"reason": "Validation Failed: 1: script or doc is missing;"
},
"status": 400
} 查看全部
POST cnbeta/doc/cUxO42oB9O-zF2ru-rs-/_update
{
"doc":{
"title":"中国操作系统"
}
}
那个body里面的”doc" 不能少
不然会报错：
{
"error": {
"root_cause": [
{
"type": "action_request_validation_exception",
"reason": "Validation Failed: 1: script or doc is missing;"
}
],
"type": "action_request_validation_exception",
"reason": "Validation Failed: 1: script or doc is missing;"
},
"status": 400
}
ElasticSearch配置集群无法发现节点问题【已解决】
数据库 • 李魔佛 发表了文章 • 0 个评论 • 4282 次浏览 • 2019-05-05 10:00
单个节点可以运行，但是配置为多个服务器集群的时候，总是提示无法发现服务器，花了点时间排查了问题，原来是配置文件的timeout问题，需要把timetout的值设置大一些，然后集群就可以发现到局域网中的其他节点。
修改文件elasticsearch.yml 文件中的timeout参数，改成原来值得10倍就可以了。 查看全部
修改文件elasticsearch.yml 文件中的timeout参数，改成原来值得10倍就可以了。 查看全部
单个节点可以运行，但是配置为多个服务器集群的时候，总是提示无法发现服务器，花了点时间排查了问题，原来是配置文件的timeout问题，需要把timetout的值设置大一些，然后集群就可以发现到局域网中的其他节点。
修改文件elasticsearch.yml 文件中的timeout参数，改成原来值得10倍就可以了。
修改文件elasticsearch.yml 文件中的timeout参数，改成原来值得10倍就可以了。
版本不兼容会增加学习的成本和挫败感-致ElasticSearch和Django
数据库 • 李魔佛 发表了文章 • 0 个评论 • 3010 次浏览 • 2019-04-27 21:59
真是累觉不爱。
看的书或者网上的教程，一步一步下来，发现要一路google。 2018年8月的书，到2019年上机，书上代码已经无法正常运行了。 报的错误就是新版ElasticSearch或者Django已经不支持这个api了。 真是一万字草泥码奔腾而过。
查看全部
看的书或者网上的教程，一步一步下来，发现要一路google。 2018年8月的书，到2019年上机，书上代码已经无法正常运行了。 报的错误就是新版ElasticSearch或者Django已经不支持这个api了。 真是一万字草泥码奔腾而过。
查看全部
真是累觉不爱。
看的书或者网上的教程，一步一步下来，发现要一路google。 2018年8月的书，到2019年上机，书上代码已经无法正常运行了。 报的错误就是新版ElasticSearch或者Django已经不支持这个api了。 真是一万字草泥码奔腾而过。
看的书或者网上的教程，一步一步下来，发现要一路google。 2018年8月的书，到2019年上机，书上代码已经无法正常运行了。 报的错误就是新版ElasticSearch或者Django已经不支持这个api了。 真是一万字草泥码奔腾而过。
Fielddata is disabled on text fields by default. Set fielddata=true
数据库 • 李魔佛 发表了文章 • 0 个评论 • 5617 次浏览 • 2019-04-24 15:37
在ES5.X之后，默认的text类型无法做聚合操作。 比如官方的例子：
{ "size":0,
"aggs":
{
"color":
{
"terms":{
"field":"color"
}
}
}
}
创建数据如下：
curl -X POST "10.18.6.102:9200/cars/transactions/_bulk" -H 'Content-Type: application/json' -d'
{ "index": {}}
{ "price" : 10000, "color" : "red", "make" : "honda", "sold" : "2014-10-28" }
{ "index": {}}
{ "price" : 20000, "color" : "red", "make" : "honda", "sold" : "2014-11-05" }
{ "index": {}}
{ "price" : 30000, "color" : "green", "make" : "ford", "sold" : "2014-05-18" }
{ "index": {}}
{ "price" : 15000, "color" : "blue", "make" : "toyota", "sold" : "2014-07-02" }
{ "index": {}}
{ "price" : 12000, "color" : "green", "make" : "toyota", "sold" : "2014-08-19" }
{ "index": {}}
{ "price" : 20000, "color" : "red", "make" : "honda", "sold" : "2014-11-05" }
{ "index": {}}
{ "price" : 80000, "color" : "red", "make" : "bmw", "sold" : "2014-01-01" }
{ "index": {}}
{ "price" : 25000, "color" : "blue", "make" : "ford", "sold" : "2014-02-12" }
'
那么运行聚合操作会报错，官方的说法是text是会分词，如果text中一个文本为New York，那么就会被分成2个桶，一个New桶，一个York桶，那么显然不能聚合操作，要么你把该类型替换成keyword类型，因为keyword类型是不会分词的，可以用来做聚合操作。
如果实在是想要用text做聚合操作，那么可以手工修改其mapping
PUT my_index/_mapping/_doc
{
"properties": {
"my_field": {
"type": "text",
"fielddata": true
}
}
}上面语句可以在已有d的mapping上修改。
修改完成后就可以正常聚合操作了。
查看全部
{ "size":0,
"aggs":
{
"color":
{
"terms":{
"field":"color"
}
}
}
}
创建数据如下：
curl -X POST "10.18.6.102:9200/cars/transactions/_bulk" -H 'Content-Type: application/json' -d'
{ "index": {}}
{ "price" : 10000, "color" : "red", "make" : "honda", "sold" : "2014-10-28" }
{ "index": {}}
{ "price" : 20000, "color" : "red", "make" : "honda", "sold" : "2014-11-05" }
{ "index": {}}
{ "price" : 30000, "color" : "green", "make" : "ford", "sold" : "2014-05-18" }
{ "index": {}}
{ "price" : 15000, "color" : "blue", "make" : "toyota", "sold" : "2014-07-02" }
{ "index": {}}
{ "price" : 12000, "color" : "green", "make" : "toyota", "sold" : "2014-08-19" }
{ "index": {}}
{ "price" : 20000, "color" : "red", "make" : "honda", "sold" : "2014-11-05" }
{ "index": {}}
{ "price" : 80000, "color" : "red", "make" : "bmw", "sold" : "2014-01-01" }
{ "index": {}}
{ "price" : 25000, "color" : "blue", "make" : "ford", "sold" : "2014-02-12" }
'
那么运行聚合操作会报错，官方的说法是text是会分词，如果text中一个文本为New York，那么就会被分成2个桶，一个New桶，一个York桶，那么显然不能聚合操作，要么你把该类型替换成keyword类型，因为keyword类型是不会分词的，可以用来做聚合操作。
如果实在是想要用text做聚合操作，那么可以手工修改其mapping
PUT my_index/_mapping/_doc
{
"properties": {
"my_field": {
"type": "text",
"fielddata": true
}
}
}上面语句可以在已有d的mapping上修改。
修改完成后就可以正常聚合操作了。
查看全部
在ES5.X之后，默认的text类型无法做聚合操作。 比如官方的例子：
创建数据如下：
那么运行聚合操作会报错，官方的说法是text是会分词，如果text中一个文本为New York，那么就会被分成2个桶，一个New桶，一个York桶，那么显然不能聚合操作，要么你把该类型替换成keyword类型，因为keyword类型是不会分词的，可以用来做聚合操作。
如果实在是想要用text做聚合操作，那么可以手工修改其mapping
修改完成后就可以正常聚合操作了。
{ "size":0,
"aggs":
{
"color":
{
"terms":{
"field":"color"
}
}
}
}创建数据如下：
curl -X POST "10.18.6.102:9200/cars/transactions/_bulk" -H 'Content-Type: application/json' -d'
{ "index": {}}
{ "price" : 10000, "color" : "red", "make" : "honda", "sold" : "2014-10-28" }
{ "index": {}}
{ "price" : 20000, "color" : "red", "make" : "honda", "sold" : "2014-11-05" }
{ "index": {}}
{ "price" : 30000, "color" : "green", "make" : "ford", "sold" : "2014-05-18" }
{ "index": {}}
{ "price" : 15000, "color" : "blue", "make" : "toyota", "sold" : "2014-07-02" }
{ "index": {}}
{ "price" : 12000, "color" : "green", "make" : "toyota", "sold" : "2014-08-19" }
{ "index": {}}
{ "price" : 20000, "color" : "red", "make" : "honda", "sold" : "2014-11-05" }
{ "index": {}}
{ "price" : 80000, "color" : "red", "make" : "bmw", "sold" : "2014-01-01" }
{ "index": {}}
{ "price" : 25000, "color" : "blue", "make" : "ford", "sold" : "2014-02-12" }
'
那么运行聚合操作会报错，官方的说法是text是会分词，如果text中一个文本为New York，那么就会被分成2个桶，一个New桶，一个York桶，那么显然不能聚合操作，要么你把该类型替换成keyword类型，因为keyword类型是不会分词的，可以用来做聚合操作。
如果实在是想要用text做聚合操作，那么可以手工修改其mapping
PUT my_index/_mapping/_doc上面语句可以在已有d的mapping上修改。
{
"properties": {
"my_field": {
"type": "text",
"fielddata": true
}
}
}
修改完成后就可以正常聚合操作了。
postman使用_analyze端点 ElasticSearch
数据库 • 李魔佛 发表了文章 • 0 个评论 • 4139 次浏览 • 2019-04-01 15:31
POSTMAN
ES 6.x如何使用_analyze端点
因为使用curl编辑查询语句很不方便。平时用postman最多，故平时查询ES经常使用postman查询。
_analyze端点是用于查询分析器的分析效果。
文档中使用如下方法查询
curl -XPOST 'localhost:9200/_analyze?analyzer=standard' -d 'I love Bears and Fish.'
只是奇怪，为何post的内容 'I love Bears and Fish.'不需要字段名？
试验了几次后，发现在6.x上，该字段的字段名是text
所以请求body应该是这样的
可以使用get方法来使用_analyze端点 查看全部
ES 6.x如何使用_analyze端点
因为使用curl编辑查询语句很不方便。平时用postman最多，故平时查询ES经常使用postman查询。
_analyze端点是用于查询分析器的分析效果。
文档中使用如下方法查询
curl -XPOST 'localhost:9200/_analyze?analyzer=standard' -d 'I love Bears and Fish.'
只是奇怪，为何post的内容 'I love Bears and Fish.'不需要字段名？
试验了几次后，发现在6.x上，该字段的字段名是text
所以请求body应该是这样的
可以使用get方法来使用_analyze端点 查看全部
POSTMAN
ES 6.x如何使用_analyze端点
因为使用curl编辑查询语句很不方便。平时用postman最多，故平时查询ES经常使用postman查询。
_analyze端点是用于查询分析器的分析效果。
文档中使用如下方法查询
curl -XPOST 'localhost:9200/_analyze?analyzer=standard' -d 'I love Bears and Fish.'
只是奇怪，为何post的内容 'I love Bears and Fish.'不需要字段名？
试验了几次后，发现在6.x上，该字段的字段名是text
所以请求body应该是这样的
可以使用get方法来使用_analyze端点
ES 6.x如何使用_analyze端点
因为使用curl编辑查询语句很不方便。平时用postman最多，故平时查询ES经常使用postman查询。
_analyze端点是用于查询分析器的分析效果。
文档中使用如下方法查询
curl -XPOST 'localhost:9200/_analyze?analyzer=standard' -d 'I love Bears and Fish.'
只是奇怪，为何post的内容 'I love Bears and Fish.'不需要字段名？
试验了几次后，发现在6.x上，该字段的字段名是text
所以请求body应该是这样的
可以使用get方法来使用_analyze端点
Elasticsearch ： Failed to obtain node lock, is the following location writable
数据库 • 李魔佛 发表了文章 • 0 个评论 • 4091 次浏览 • 2019-02-25 18:35
准备运行 Elasticsearch的时候出现报错： Failed to obtain node lock, is the following location writable。
看了下权限，没有问题，可以写。
后来发现后台的ES进程没有的得到释放，使用kill命令杀掉
ps -axu | grep 'java'
找到对应的进程ID，然后杀掉
kill ID号
然后重新调用./elasticsearch 就可以了。
查看全部
看了下权限，没有问题，可以写。
后来发现后台的ES进程没有的得到释放，使用kill命令杀掉
ps -axu | grep 'java'
找到对应的进程ID，然后杀掉
kill ID号
然后重新调用./elasticsearch 就可以了。
查看全部
准备运行 Elasticsearch的时候出现报错： Failed to obtain node lock, is the following location writable。
看了下权限，没有问题，可以写。
后来发现后台的ES进程没有的得到释放，使用kill命令杀掉
ps -axu | grep 'java'
找到对应的进程ID，然后杀掉
kill ID号
然后重新调用./elasticsearch 就可以了。
看了下权限，没有问题，可以写。
后来发现后台的ES进程没有的得到释放，使用kill命令杀掉
ps -axu | grep 'java'
找到对应的进程ID，然后杀掉
kill ID号
然后重新调用./elasticsearch 就可以了。
修改Logstash中的sql_last_value值
数据库 • 李魔佛 发表了文章 • 0 个评论 • 10927 次浏览 • 2019-02-20 19:37
修改syncpoint_table里面的值 就可以了。
这个文件在logstash的第一层目录底下。
不然每次都是从这个最后的值开始执行的。
这个文件在logstash的第一层目录底下。
不然每次都是从这个最后的值开始执行的。
修改syncpoint_table里面的值 就可以了。
这个文件在logstash的第一层目录底下。
不然每次都是从这个最后的值开始执行的。
这个文件在logstash的第一层目录底下。
不然每次都是从这个最后的值开始执行的。
docker下载的ElasticSearch镜像 web/postman访问时需要密码，如何去除
数据库 • 李魔佛 发表了文章 • 0 个评论 • 4248 次浏览 • 2018-11-13 11:40
从docker官方镜像源下载的镜像，可以正常运行。
可是在postman中请求接口：
GET ： 10.18.6.102:9200/_cat/indices?v
爆出下面的错误：
missing authentication token for REST request
然后使用浏览器查询：发现需要输入账户和密码。
账户名：elastic
密码：changeme
如何才能删除这个用户名和密码呢？ 每次请求不需要密码。
进入docker容器
修改这个文件
/usr/share/elasticsearch/config/elasticssearch.yml
添加最后一行：
xpack.security.enabled: false
然后记得commit一下你的修改。
查看全部
可是在postman中请求接口：
GET ： 10.18.6.102:9200/_cat/indices?v
爆出下面的错误：
missing authentication token for REST request
然后使用浏览器查询：发现需要输入账户和密码。
账户名：elastic
密码：changeme
如何才能删除这个用户名和密码呢？ 每次请求不需要密码。
进入docker容器
修改这个文件
/usr/share/elasticsearch/config/elasticssearch.yml
添加最后一行：
xpack.security.enabled: false
然后记得commit一下你的修改。
查看全部
从docker官方镜像源下载的镜像，可以正常运行。
可是在postman中请求接口：
GET ： 10.18.6.102:9200/_cat/indices?v
爆出下面的错误：
然后使用浏览器查询：发现需要输入账户和密码。
账户名：elastic
密码：changeme
如何才能删除这个用户名和密码呢？ 每次请求不需要密码。
进入docker容器
修改这个文件
/usr/share/elasticsearch/config/elasticssearch.yml
添加最后一行：
xpack.security.enabled: false
然后记得commit一下你的修改。
可是在postman中请求接口：
GET ： 10.18.6.102:9200/_cat/indices?v
爆出下面的错误：
missing authentication token for REST request
然后使用浏览器查询：发现需要输入账户和密码。
账户名：elastic
密码：changeme
如何才能删除这个用户名和密码呢？ 每次请求不需要密码。
进入docker容器
修改这个文件
/usr/share/elasticsearch/config/elasticssearch.yml
添加最后一行：
xpack.security.enabled: false
然后记得commit一下你的修改。
Docker ElasticSearch挂载本地数据 报错
数据库 • 李魔佛 发表了文章 • 0 个评论 • 11577 次浏览 • 2018-11-13 10:37
应用场景中需要把数据挂载在本地的目录，以便以后数据的迁移与备份。
挂载命令：docker run -p 9200:9200 -e "http.host=0.0.0.0" -e "transport.host=127.0.0.1" -v /home/myuser/elastic_data/:/usr/share/elasticsearch/data docker.elastic.co/elasticsearch/elasticsearch:5.5.1
其中-v是指定的挂载路径
/home/myuser/elastic_data/
这个是本地路径
运行后报错：[2018-11-13T02:23:33,994][INFO ][o.e.n.Node ] initializing ...
[2018-11-13T02:23:34,010][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] uncaught exception in thread [main]
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: Failed to create node environment
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:127) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:114) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:67) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:122) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.Command.main(Command.java:88) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:91) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:84) ~[elasticsearch-5.5.1.jar:5.5.1]
Caused by: java.lang.IllegalStateException: Failed to create node environment
at org.elasticsearch.node.Node.<init>(Node.java:267) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:244) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:351) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) ~[elasticsearch-5.5.1.jar:5.5.1]
... 6 more
Caused by: java.nio.file.AccessDeniedException: /usr/share/elasticsearch/data/nodes
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) ~[?:?]
at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384) ~[?:?]
at java.nio.file.Files.createDirectory(Files.java:674) ~[?:1.8.0_141]
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781) ~[?:1.8.0_141]
at java.nio.file.Files.createDirectories(Files.java:767) ~[?:1.8.0_141]
at org.elasticsearch.env.NodeEnvironment.<init>(NodeEnvironment.java:221) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:264) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:244) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:351) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) ~[elasticsearch-5.5.1.jar:5.5.1]
... 6 more
原因是权限问题，需要把目录
/home/myuser/elastic_data/ 改为777， 然后问题就解决了chmod 777 /home/myuser/elastic_data/
原创文章
转载请注明出处：
http://30daydo.com/article/369
查看全部
挂载命令：docker run -p 9200:9200 -e "http.host=0.0.0.0" -e "transport.host=127.0.0.1" -v /home/myuser/elastic_data/:/usr/share/elasticsearch/data docker.elastic.co/elasticsearch/elasticsearch:5.5.1
其中-v是指定的挂载路径
/home/myuser/elastic_data/
这个是本地路径
运行后报错：[2018-11-13T02:23:33,994][INFO ][o.e.n.Node ] initializing ...
[2018-11-13T02:23:34,010][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] uncaught exception in thread [main]
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: Failed to create node environment
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:127) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:114) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:67) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:122) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.Command.main(Command.java:88) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:91) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:84) ~[elasticsearch-5.5.1.jar:5.5.1]
Caused by: java.lang.IllegalStateException: Failed to create node environment
at org.elasticsearch.node.Node.<init>(Node.java:267) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:244) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:351) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) ~[elasticsearch-5.5.1.jar:5.5.1]
... 6 more
Caused by: java.nio.file.AccessDeniedException: /usr/share/elasticsearch/data/nodes
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) ~[?:?]
at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384) ~[?:?]
at java.nio.file.Files.createDirectory(Files.java:674) ~[?:1.8.0_141]
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781) ~[?:1.8.0_141]
at java.nio.file.Files.createDirectories(Files.java:767) ~[?:1.8.0_141]
at org.elasticsearch.env.NodeEnvironment.<init>(NodeEnvironment.java:221) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:264) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:244) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:351) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) ~[elasticsearch-5.5.1.jar:5.5.1]
... 6 more
原因是权限问题，需要把目录
/home/myuser/elastic_data/ 改为777， 然后问题就解决了chmod 777 /home/myuser/elastic_data/
原创文章
转载请注明出处：
http://30daydo.com/article/369
查看全部
应用场景中需要把数据挂载在本地的目录，以便以后数据的迁移与备份。
挂载命令：
其中-v是指定的挂载路径
/home/myuser/elastic_data/
这个是本地路径
运行后报错：
原因是权限问题，需要把目录
/home/myuser/elastic_data/ 改为777， 然后问题就解决了
原创文章
转载请注明出处：
http://30daydo.com/article/369
挂载命令：
docker run -p 9200:9200 -e "http.host=0.0.0.0" -e "transport.host=127.0.0.1" -v /home/myuser/elastic_data/:/usr/share/elasticsearch/data docker.elastic.co/elasticsearch/elasticsearch:5.5.1
其中-v是指定的挂载路径
/home/myuser/elastic_data/
这个是本地路径
运行后报错：
[2018-11-13T02:23:33,994][INFO ][o.e.n.Node ] initializing ...
[2018-11-13T02:23:34,010][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] uncaught exception in thread [main]
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: Failed to create node environment
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:127) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:114) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:67) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:122) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.cli.Command.main(Command.java:88) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:91) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:84) ~[elasticsearch-5.5.1.jar:5.5.1]
Caused by: java.lang.IllegalStateException: Failed to create node environment
at org.elasticsearch.node.Node.<init>(Node.java:267) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:244) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:351) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) ~[elasticsearch-5.5.1.jar:5.5.1]
... 6 more
Caused by: java.nio.file.AccessDeniedException: /usr/share/elasticsearch/data/nodes
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) ~[?:?]
at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384) ~[?:?]
at java.nio.file.Files.createDirectory(Files.java:674) ~[?:1.8.0_141]
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781) ~[?:1.8.0_141]
at java.nio.file.Files.createDirectories(Files.java:767) ~[?:1.8.0_141]
at org.elasticsearch.env.NodeEnvironment.<init>(NodeEnvironment.java:221) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:264) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.node.Node.<init>(Node.java:244) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:232) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:351) ~[elasticsearch-5.5.1.jar:5.5.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) ~[elasticsearch-5.5.1.jar:5.5.1]
... 6 more
原因是权限问题，需要把目录
/home/myuser/elastic_data/ 改为777， 然后问题就解决了
chmod 777 /home/myuser/elastic_data/
原创文章
转载请注明出处：
http://30daydo.com/article/369
elasticsearch-head连接不上elasticsearch服务器
数据库 • 李魔佛 发表了文章 • 0 个评论 • 4093 次浏览 • 2018-11-13 09:21
在git hub上同步下来的代码后，运行Elasticsearch-head，一直连不上去。 后来才发现这个github上的版本有问题，于是在chrome的应用商城下载了一个elasticsearch-head的插件，就可以直接用了。
查看全部
查看全部
在git hub上同步下来的代码后，运行Elasticsearch-head，一直连不上去。 后来才发现这个github上的版本有问题，于是在chrome的应用商城下载了一个elasticsearch-head的插件，就可以直接用了。
MongoDB数据导入到ElasticSearch python代码实现
数据库 • 李魔佛 发表了文章 • 0 个评论 • 4520 次浏览 • 2018-11-12 14:13
ElasticSearch对文本的搜索速度真的是神速呀，基本是毫秒级别的。对于大文本，简直就是秒飞MYSQL十条街。使用python实现：es = Elasticsearch(['10.18.6.26:9200'])
ret = collection.find({})
# 删除mongo的_id字段，否则无法把Object类型插入到Elastic
map(lambda x:(del x['_id']),ret)
actions=
for idx,item in enumerate(ret):
i={
"_index":"jsl",
"_type":"text",
"_id":idx,
"_source":{
# 需要提取的字段
"title":item.get('title'),
"url":item.get('url')
}
}
actions.append(i)
start=time.time()
helpers.bulk(es,actions)
end=time.time()-start
print(end)
运行下来，20W条数据，大概用了15秒左右全部导入ElasticSearch 数据库中。 查看全部
ret = collection.find({})
# 删除mongo的_id字段，否则无法把Object类型插入到Elastic
map(lambda x:(del x['_id']),ret)
actions=
for idx,item in enumerate(ret):
i={
"_index":"jsl",
"_type":"text",
"_id":idx,
"_source":{
# 需要提取的字段
"title":item.get('title'),
"url":item.get('url')
}
}
actions.append(i)
start=time.time()
helpers.bulk(es,actions)
end=time.time()-start
print(end)
运行下来，20W条数据，大概用了15秒左右全部导入ElasticSearch 数据库中。 查看全部
ElasticSearch对文本的搜索速度真的是神速呀，基本是毫秒级别的。对于大文本，简直就是秒飞MYSQL十条街。使用python实现：
运行下来，20W条数据，大概用了15秒左右全部导入ElasticSearch 数据库中。
es = Elasticsearch(['10.18.6.26:9200'])
ret = collection.find({})
# 删除mongo的_id字段，否则无法把Object类型插入到Elastic
map(lambda x:(del x['_id']),ret)
actions=
for idx,item in enumerate(ret):
i={
"_index":"jsl",
"_type":"text",
"_id":idx,
"_source":{
# 需要提取的字段
"title":item.get('title'),
"url":item.get('url')
}
}
actions.append(i)
start=time.time()
helpers.bulk(es,actions)
end=time.time()-start
print(end)
运行下来，20W条数据，大概用了15秒左右全部导入ElasticSearch 数据库中。
