I am receiving an exception when trying to create an index, along with a mapping. I am issuing a PUT to my local ElasticSearch instance (v. 5.1.1) http://127.0.0.1:9200/indexname with the following body
{
"settings": {
"index": {
"number_of_replicas": "1",
"number_of_shards": "1"
}
},
"mappings": {
"examplemapping": {
"properties": {
"titel": {
"type": "text",
"index": false
},
"body": {
"type": "text"
},
"room": {
"type": "text",
"index": false
},
"link": {
"type": "text",
"index": false
}
}
}
}
}
I receive the following error
{
"error": {
"root_cause": [
{
"type": "mapper_parsing_exception",
"reason": "No handler for type [text] declared on field [body]"
}
],
"type": "mapper_parsing_exception",
"reason": "Failed to parse mapping [examplemapping]: No handler for type [text] declared on field [body]",
"caused_by": {
"type": "mapper_parsing_exception",
"reason": "No handler for type [text] declared on field [body]"
}
},
"status": 400
}
From the documentation on index creation it should be possible to create an index, and create one or more mappings at the same time:
https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-create-index.html
I have read https://www.elastic.co/guide/en/elasticsearch/reference/current/string.html and believe that I am correctly using the new datatype, but the exception suggests otherwise.
Any help is greatly appreciated.
Resolution
Thanks to a comment by Val i was pointed in the right direction. Indeed I was not using version 5.1.1, but version 2.4.3
So why the confusion? Well, I have been running both versions (not at once), and startet and stopped them using the respective bat scripts:
call es-2.4.3/bin/service.bat start
call es-5.1.1/bin/elasticsearch-service.bat start
It seems that even though I have been running the latter, it was still ES2.4.3 that was started. This is probably caused by the logic inside the bat script.
Going forward I will keep in mind to check the version response from the service itself, and I'm gonna have to find a proper setup to run multiple versions of ElasticSearch.
Thanks for the answers.
I tried your settings on ElasticSeach 5.0.0 and it worked fine, output of GET indexname :
{
"indexname": {
"aliases": {},
"mappings": {
"examplemapping": {
"properties": {
"body": {
"type": "text"
},
"link": {
"type": "text",
"index": false
},
"room": {
"type": "text",
"index": false
},
"titel": {
"type": "text",
"index": false
}
}
}
},
"settings": {
"index": {
"creation_date": "1488892255496",
"number_of_shards": "1",
"number_of_replicas": "1",
"uuid": "GugRGgllQbCadCTj5oq4ow",
"version": {
"created": "5000099"
},
"provided_name": "testo"
}
}
}
}
Also please note that I would definitely recommend that you set a different value of "number_of_shards": "1" as a rule of thumb consider that Elasticsearch is allocating 1 thread per shard, and thus the bigger your shard will become, the slower the text search will be. Now also bear in mind that some overhead comes from allocating more shards, so don't "overallocate". See this post and this onefor more details.
Thanks to a comment by Val i was pointed in the right direction. Indeed I was not using version 5.1.1, but version 2.4.3
So why the confusion? Well, I have been running both versions (not at once), and startet and stopped them using the respective bat scripts:
call es-2.4.3/bin/service.bat start
call es-5.1.1/bin/elasticsearch-service.bat start
It seems that even though I have been running the latter, it was still ES2.4.3 that was started. This is probably caused by the logic inside the bat script.
Going forward I will keep in mind to check the version response from the service itself, and I'm gonna have to find a proper setup to run multiple versions of ElasticSearch.
Thanks to all who pitched in!
Related
Elasticsearch version: 7.6.2
JVM：13.0.2
OS version：centeros7
This is my code
POST recommend_index/_update_by_query
{
"script": {
"source": "ctx._source.rec_doctor_id = 1"
},
"query": {
"bool": {
"must": [{
"terms": {
"id": ["22222"]
}
}]
}
}
}
This code does not return the result correctly,The error message is
{
"error": {
"root_cause": [
{
"type": "exception",
"reason": "Trying to create too many scroll contexts. Must be less than or equal to: [5000]. This limit can be set by changing the [search.max_open_scroll_context] setting."
}
],
"type": "search_phase_execution_exception",
"reason": "Partial shards failure",
"phase": "query",
"grouped": true,
"failed_shards": [
{
"shard": 1,
"index": "recommend_index",
"node": "XXX",
"reason": {
"type": "exception",
"reason": "Trying to create too many scroll contexts. Must be less than or equal to: [5000]. This limit can be set by changing the [search.max_open_scroll_context] setting."
}
}
]
},
"status": 500
}
I'm sure the current scroll is 0
When I replace _UPDATE_BY_QUERY with _UPDATE, it updates normally
No change has been made in ES since last Friday, and suddenly an error is reported
No configuration changes have been made to the ES server
follow-up:
I set the search.max_open_scroll_context parameter to 5000 and found nothing to do with it.
I looked up the 7.6.2 release and found that someone was having the same problem as me.Link on this
here #71354 #56202
I guess this is due to scrolling triggering the 7.6.2 bug.I restarted the cluster node without upgrading and found that it worked!!
In several pages in Elasticsearch documentation is mentioned how to query a multi-type index.
But I failed to create one at the first place.
Here is my minimal example (on a Elasticsearch 6.x server):
PUT /myindex
{
"settings" : {
"number_of_shards" : 1
}
}
PUT /myindex/people/123
{
"first name": "John",
"last name": "Doe"
}
PUT /myindex/dog/456
{
"name": "Rex"
}
Index creation and fist insert did well, but at the dog type insert attempt:
{
"error": {
"root_cause": [
{
"type": "illegal_argument_exception",
"reason": "Rejecting mapping update to [myindex] as the final mapping would have more than 1 type: [people, dog]"
}
],
"type": "illegal_argument_exception",
"reason": "Rejecting mapping update to [myindex] as the final mapping would have more than 1 type: [people, dog]"
},
"status": 400
}
But this is exactly what I'm trying to do, buddy! Having "more than 1 type" in my index.
Do you know what I have to change in my calls to achieve this?
Many thanks.
Multiple mapping types are not supported from Elastic 6.0.0 onwards. See breaking changes for details.
You can still effectively use multiple types by implementing your own custom type field.
For example:
{
"mappings": {
"doc": {
"properties": {
"type": {
"type": "keyword"
},
"first_name": {
"type": "text"
},
"last_name": {
"type": "text"
}
}
}
}
}
This is described in removal of types.
In my search engine, users can select to search case-sensitively or not. If they choose to, the query will search on fields which use a custom case-sensitive analyser. This is my setup:
GET /candidates/_settings
{
"candidates": {
"settings": {
"index": {
"number_of_shards": "5",
"provided_name": "candidates",
"creation_date": "1528210812046",
"analysis": {
"analyzer": {
"case_sensitive": {
"filter": [
"stop",
"porter_stem"
],
"type": "custom",
"tokenizer": "standard"
}
}
},
...
}
}
}
}
So I have created a custom analyser called case_sensitive taken from this answer. I am trying to define my mapping as follows:
PUT /candidates/_mapping/candidate
{
"properties": {
"first_name": {
"type": "text",
"fields": {
"case": {
"type": "text",
"analyzer": "case_sensitive"
}
}
}
}
}
So, when querying, for a case-sensitive match, I can do:
simple_query_string: {
query: **text to search**,
fields: [
"first_name.case"
]
}
I am not even getting to the last step as I am getting the error described in the title when I am trying to define the mapping. The full stack trace is in the image below:
I initially thought that my error was similar to this one but I think that issue is only related to using the keyword tokenizer and not the standard one
In this mapping definition, I was actually trying to adjust the mapping for several different fields and not just first_name. One of these fields has the type long and that is the mapping definition that was throwing the error. When I remove that from the mapping definition, it works as expected. However, I am unsure as to why this fails for this data type?
I'm working with Apache Nifi and trying to put data in ElasticSearch using the processor PutElasticsearch, and it worked pretty good since i tried to add a child/parent relation in elasticsearch and so add parent in my put request.
here is my mapping elasticsearch :
"mappings": {
"myparent": {
},
"mychild": {
"_parent": {
"type": "myparent"
},
"properties": {
"attr1": {
"type": "string"
},
"attr2": {
"type": "date",
"format": "dateOptionalTime"
},
"attr3": {
"type": "string"
}
}
}
}
here is how i manualy insert data in "mychild" type :
POST /myindex/mychild/1?parent=[IDParent]
{
"attr1" : "02020",
"attr2" : "2016-10-10",
"attr3" : "toto"
}
i didn't find how to spécify the parentID.
Is there any way of doing it using PutElasticsearch other than using the processor InvokHTTP.
Thank you.
This is not possible today (NiFi 1.1.0 and below) with the PutElasticsearch processors, so InvokeHttp is your best option for now. I have written NIFI-3284 to cover this improvement.
The kind of document we want to index and query contains variable keys but are grouped into a common root key as follows:
{
"articles": {
"0000000000000000000000000000000000000001": {
"crawled_at": "2016-05-18T19:26:47Z",
"language": "en",
"tags": [
"a",
"b",
"d"
]
},
"0000000000000000000000000000000000000002": {
"crawled_at": "2016-05-18T19:26:47Z",
"language": "en",
"tags": [
"b",
"c",
"d"
]
}
},
"articles_count": 2
}
We want to able to ask: what documents contains articles with tags "b" and "d", with language "en".
The reason why we don't use list for articles, is that elasticsearch can efficiently and automatically merge documents with partial updates. The challenge however is to index the objects inside under the variable keys. One possible way we tried is to use dynamic_templates as follows:
{
"sources": {
"dynamic": "strict",
"dynamic_templates": [
{
"article_template": {
"mapping": {
"fields": {
"crawled_at": {
"format": "dateOptionalTime",
"type": "date"
},
"language": {
"index": "not_analyzed",
"type": "string"
},
"tags": {
"index": "not_analyzed",
"type": "string"
}
}
},
"path_match": "articles.*"
}
}
],
"properties": {
"articles": {
"dynamic": false,
"type": "object"
},
"articles_count": {
"type": "integer"
}
}
}
}
However this dynamic template fails because when documents are inserted, the following can be found in the logs:
[2016-05-30 17:44:45,424][WARN ][index.codec] [node]
[main] no index mapper found for field:
[articles.0000000000000000000000000000000000000001.language] returning
default postings format
Same for the two other fields as well. When I try to query for the existence of a certain article, or even articles it doesn't return any document (no error but empty hits):
curl -LsS -XGET 'localhost:9200/main/sources/_search' -d '{"query":{"exists":{"field":"articles"}}}'
When I query for the existence of articles_count, it returns everything. Is there a minor error in what we are trying to achieve, for example in the schema: the definition of articles as a property and in the dynamic template? What about the types and dynamic false? The path seems correct. Maybe this is not possible to define templates for objects in variable-keys, but it should be according to the documentation.
Otherwise, what alternatives are possible without changing the document if possible?
Notes: we have other types in the same index main that also have these fields like language, I ignore if it could influence. The version of ES we are using is 1.7.5 (we cannot upgrade to 2.X for now).