web.php5.sk

Elasticsearch - dátové typy

21. apríl 2020 / Čamo

Už ma tieto perexy prestávajú baviť. Takže poďme rovno k veci. Porzime sa, aké dátové typy sa dajú v Elasticsearch použiť.

Datatypes

 

Typy stringové

Text datatype

Určený na fulltextové indexovanie. Tieto stringy prechádzajú pred indexovaním cez analyzer, ktroých ich tokenizuje a prefiltruje pred uložením do indexu. Tento typ nieje určený pre radenie alebo agregácie. Výnimkou je significant text aggregation.

Ak potrebujete indexovať štruktúrované dáta ako emaily, tagy ... asi by bolo lepšie indexovať ich ako typ keyword.

{
  "mappings": {
    "_doc": {
      "properties": {
        "product_description": {
          "type":  "text"
        }
      }
    }
  }
}

Niekedy je potrebné jeden field indexovať dvojakým spôsobom. Ako text pre fulltext a ako keyword pre radenie a agregácie. To je možné dosiahnuť použitím multi-fields.

Parametre pre typ text

  • analyzer:  analyzery sa rozoberali už pri mappingu
  • boost: Query time boosting. Akceptuje desatinné číslo default je 1.0. boost
  • eager_global_ordinals: Toto je interná mágia Elasticsearchu, ktorá umožnuje efektívne sortovanie a agregovanie. Výnimkou sú analyzované polia pre fulltext. Default je TRUE a nechajte to radšej tak. eager_global_ordinals
  • fielddata: Toto nastavenie sa týka typu text, kde je defaultná hodnota FALSE. Miesto tejto možnosti je lepšie použíť fields, ktorá je vysvetlená nižšie fielddata
  • fielddata_frequency_filter: Expert settings which allow to decide which values to load in memory when fielddata is enabled. By default all values are loaded.
  • fields: Multi-field umožňujú jeden reťazec indexovať viacerými spôsobmi pre rôzne potreby. Napr. hlavný field pre fulltext a multifield pre redenie a agregácie. Alebo jeden string analyzovaný viacerými analyzermi. fields
  • index: Určuje či sa field bude indexovať. Akceptuje TRUE/FALSE default je TRUE
  • index_options: Aké informácie by mali byť uložené v indexe index_options
  • index_prefixes: Ak je táto voľba povolená budú sa indexovať prefixy default od 5 do 20 aby sa zrýchlilo vyhľadávanie index_prefixes
  • index_phrases: Ak je voľba povolená dvoj-slovné (tokenové) kombinácie (shingels) budú indexované do separátneho fieldu. Toto umožňuje vyhľadávať exaktné frázy oveľa efektívnejšie vo veľkých indexoch. Je lepšie ponechať aj stopwords. Akceptuje TRUE/FALSE default FALSE  index_phrases
  • norms: Určuje či sa dlžka stringu bude brať do úvahy pri vypočítavaní score. Default TRUE norms
  • position_increment_gap: Používa sa pri poliach reťazcov. Medzi jednotlivé reťazce sa v indexe pridáva fake token, ktorý zabezpečí, že sa pri vyhľadávaní nebudú spájať dva stringy dohromady. Lepšie to vidno na príklade viď.  position_increment_gap
  • store: viď store
  • search_analyzer: Definícia analyzera, ktroý sa použije pri search time na analýzu requestu. search_analyzer
  • search_quote_analyzer: Použije sa ak je pri requeste detekovaná fráza v úvodzovkách search_quote_analyzer
  • similarity: Určuje, ktorý algoritmus pre score sa použije. Default je BM25. similarity
  • term_vector: Určuje či sa má ukladať term vector pre analyzované fieldy term_vector

 

Keyword datatype

Typ na ukladanie komplexných dát ako sú emailly, poštové smerovacie čísla, tagy, status kódy...

Typicky sa používajú pri filtrovaní (status: "published"), agregáciách, radení. Keywords je možné vyhľadať iba podľa jeho exaktnej hodnoty nie ako fulltext tokeny. 

Príklad:

{
  "mappings": {
    "_doc": {
      "properties": {
        "tags": {
          "type":  "keyword"
        }
      }
    }
  }
}

Parametre typu keyword:

  • boost: Váha fieldu pri vyhľadávaní. Akceptuje float. Default je 1.0 boost
  • doc_values: Používa sa pri radení, scriptovaní a agregáciách. Default je TRUE a nieje dôvod to meniť. doc_values
  • eager_global_ardinals:  eager_global_ordinals
  • fields: Multi-field umožňuje jeden reťazec indexovať viarerými spôsobmi. Napr. pre fulltext a pre radenie. fields
  • ignore_above: Nezaindexuje reťazec, ktroý je dlhší ako táto hodnota. Default je 2147483647 čo by malo stačiť. Pri dynamickom mapovaní sa táto hodnota zmení na 256 ignore_above
  • index: Určuje či sa field má indeovať alebo nie. Default TRUE. index
  • index_options: Aké informácie budú uložené v indexe pre výpočet score. DEfault je doc. Ale môže byť napr. freqs kde sa vyhodnocuje frekvencia hľadaného výrazu. index_options
  • norms: Určuje či sa dlžka fieldu bude brať  do úvahy pri vápočte score. Default FALSE. norms
  • null_value: Akceptuje string hodnotu, ktorá sa vloží ako hodnota v prípade že field má hodnotu NULL. Default je NULL, čo znamená že field je považovaný za chýbajúci missing. null_value
  • store: Či sa field value bude ukladať a vracať separátne od _source fieldu. Default je FALSE. store
  • similarity: Ktroý algoritmus sa použije pri výpočte score. Default je BM25. similarity
  • normalizer: Je niečo podobné ako analyzer pri type text. Určuje ako bude upravená hodnota keyword pred indexovaním. Výsledkom je ale vždy len jeden token. Normalizer sa použije pri indexovaní a tiež pri vyhľadávaní. Default je null, čo znamená že keyword sa uloží tak ako je. Môže sa prefiltrovať tak ako u typu text cez filter ako lowercase, asciifolding... Je dôležité vedieť že agregácia vráti tiež normalizovanú hodnotu viď. normalizer
  • split_queries_on_whitespace: Určuje či sa full text queries rozdelia input cez whitespace keď sa skladá query pre daný field. Akceptuje TRUE/FALSE. Default je FALSE.

 

Typy numerické

long

64-bit integer. Min. hodnota -263 a max. hodnota 263-1.

interger

32-bit integer. Min. hodnota -231 a max. hodnota of 231-1.

short

16-bit integer. Min. hodnota -32,768 a max. hodnota 32,767.

bite

8-bit integer. Min hodnota -128 a max. hodnota 127.

double

Desatinné číslo 64-bit IEEE 754 restricted to finite values.

float

Desatinné číslo 32-bit IEEE 754 restricted to finite values.

half_float

Desatinn číslo 16-bit IEEE 754 restricted to finite values.

scaled_float

Konečné desatinné číslo, ktroé sa ukladá ako long, vynásobené cez hodnotu scaling_factor. Napr. ak ukladáte cenu, uložte ju ako scaled_float so scaling_factor s hodnotou 100. Elasticsearch sa bude chovať ako keby číslo bolo double, ale na pozadí s ním bude pracovať ako s číslom ako price*100, tj. centy budú v rozsahu celého čísla. Ušetríte tým miesto na disku. 

"price": {
     "type": "scaled_float",
     "scaling_factor": 100
}

Parametre číselných typov

  • coerce: Pokúsi sa konvertovať stringové hodnoty na číslo a pri celočíselných typoch odstráni desatinnú hodnotu. coerce
  • boost: Váha fieldu pri vyyhľadávaní. Default je 1.0. boost
  • doc_values: Vytvorí tzv. inverzný index. Default TRUE. doc_values
  • ignore_malformed: Ak je TRUE nečíselné hodnoty sa ignorujú. Ak je FALSE čo je aj default vyhodí sa výnimka a zahodí sa celý dokument. ignore_malformed
  • index: Určuje či sa má field indexovať. Default TRUE. index
  • null_value: Akceptuje číslo takého typu ako je field, ktoré sa vloží miesto NULLových hodnôt. Default je NULL tj. hodnota sa pokladá za chýbajúcu. null_value
  • store: Či má byť hodnota vrátená separátne od _source fieldu. Default FALSE. store
  • scaling_factor: IBA pre typ scaled_float. Hodnoty vkladaného fieldu bude vynásobená hodnotou tohoto parametra a zaokrúhlená na najbližšiu hodnotu typu long. Napr. ak je scaling_factor 10 a ukladaná hodnota je 2.34 elastic interne uloží číslo 23. A pri vyhľadávaní sa Elastic chová ako by hodnota bola 2.3 
 
 

Typ dátum

JSON nepozná dátumové typy, takže dátumy v Elasticsearch môžu byť buď:

  • string obsahujúci formátovaný dátum napr. "2015-01-01" alebo "2015/01/01 12:10:30".
  • typ long reprezentujúci millisekundy ako unix timestamp.
  • integer reprezentujúci sekundy ako unix timestamp.

Interne sú dátumy konvertované na UTC ak je špecifikovaná timezóna a uložené ako typ long reprezentujúci milisekundy ako unix timestamp. 

Queries na dátumové typy sú interne konvertované na typ long a result agregácii a uložených fieldov je konvertovaný na string v závislosti na formáte, ktrorý je definovaný k fieldu. Dátum sa vždy vracia ako naformátovaný string aj keď bol ukladaná ako long.

Input formát môže byť customizovateľný a ak nieje definovaný tak sa použije default:

"strict_date_optional_time||epoch_millis"

To znamená, že bude akceptovať dátumy s voliteľným časom kompatibilné s podporovanými formátmi pre strict_date_optional_time alebo millisekundami ako unix timestam. Okrem podporovaných formátov je možné použiť aj custom formats použitím syntaxe yyyy/MM/dd. 

"properties": {
   "date": {
     "type":   "date",
     "format": "epoch_second"
   }
}
Je možné definovať viac formátov naraz. Oddeľujeme ich paipou ||. Pre návratovú hodnotu sa použije prvý formát.  
"properties": {
   "date": {
     "type":   "date",
     "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
   }
}

Parametre pre typ date

  • boost: Váha fieldu. Default 1.0 boost
  • doc_value: Default TRUE doc_values
  • format: formát cez ktroý sa parsuje vstupná a výstupná hodnota format
  • locale: Prečo by toto niekto použil...? The locale to use when parsing dates since months do not have the same names and/or abbreviations in all languages. The default is the ROOT locale,
  • ignore_malformed: Ak je TRUE neplatne formátovaný dátum sa zahodí. Ak je FALSE čo je default tak sa vyhodí vínimka a celý dokument sa neuloží ignore_malformed
  • index: Určuje či sa bude field indexovať index
  • null_value: String s dátumom formátovanám podľa format parametra, ktroý sa vloží miesto NULLových hodnôt. Default je NULL. null_value
  • store: Whether the field value should be stored and retrievable separately from the _source field. Accepts true or false (default).
 

Typ boolean

Boolean field akceptuje json true/false hodnoty, ale akceptuje aj string "true" alebo "false".

"properties": {
   "is_published": {
     "type": "boolean"
   }
}


POST my_index/_doc/1
{
  "is_published": "true" 
}

GET my_index/_search
{
  "query": {
    "term": {
      "is_published": true 
    }
  }
}
Oba zápisy true aj "true" sú platné.
 
Parametre pre Boolean typ
 
  • boost: Váhy pre field počas queery time boosting. Default 1.0 boost
  • doc_value: Default TRUE doc_values
  • index: Určuje či sa má field indexovať alebo nie. Default TRUE. index
  • null_value: Hodnota ktorá sa použuje miesto NULLových hodnôt. Default je NULL null_value
  • store: Default FALSE store
 

Typ binárny

Typ binary akceptuje binárne hodnoty ako napr. Base64 stringy. Podľa tohoto poľa sa nedá vyhľadávať. Base64 string nesmie obsahovať znak nového riadku \n
 
Parametre 
 

Typy range - rozsahy

Integer_range

32 bit integer min. -231 max. 231-1.

long_range

64 bit min. -263 max. 263-1.

float_range

32 bit IEEE 754 desatinné čísla.

doble_range

64 bit IEEE 754 desatinné čísla.

date_range

Rozsah kladných celých čísel reprezentujúcich milisekundy unix epochy.

ip_range

Rozsah IP adries podporujúci IPv4 alebo IPv6

Parametre pre range fieldy
 
  • coerce: Pokúsi sa skonvertovať string na integer a odstráni desatinnú časť pre typ integer range  coerce
  • boost: Váha fieldu pre query boost
  • index: Určuje či sa field bude indexovať index
  • store: store
 

Príklady rozsahov

PUT range_index
{
  "settings": {
    "number_of_shards": 2
  },
  "mappings": {
    "_doc": {
      "properties": {
        "expected_attendees": {
          "type": "integer_range"
        },
        "time_frame": {
          "type": "date_range", 
          "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
        }
      }
    }
  }
}

PUT range_index/_doc/1?refresh
{
  "expected_attendees" : { 
    "gte" : 10,
    "lte" : 20
  },
  "time_frame" : { 
    "gte" : "2015-10-31 12:00:00", 
    "lte" : "2015-11-01"
  }
}

Príklad requestov. 

GET range_index/_search
{
  "query" : {
    "term" : {
      "expected_attendees" : {
        "value": 12
      }
    }
  }
}

Príklad na range request

GET range_index/_search
{
  "query" : {
    "range" : {
      "time_frame" : { 
        "gte" : "2015-10-31",
        "lte" : "2015-11-01",
        "relation" : "within" 
      }
    }
  }
}

Nastavenie relation môže nadobúdať hodnoty within, contains, intersect. V tomto prípade within znamená že rozsah v indexe sa musí celý nachádzať v rozsahu v requeste.

Príklad IP range

PUT range_index/_mapping/_doc
{
  "properties": {
    "ip_whitelist": {
      "type": "ip_range"
    }
  }
}

PUT range_index/_doc/2
{
  "ip_whitelist" : "192.168.0.0/16"
}
 

Typ object

JSON dokument je hierarchická štruktúra. Dokument môže obsahovať vnorené objekty, ktroé môžu obsahovať ďalšie vnorené objekty.

PUT my_index/_doc/1
{ 
  "region": "US",
  "manager": { 
    "age":     30,
    "name": { 
      "first": "John",
      "last":  "Smith"
    }
  }
}

Interne je takýto dokuemnt indexovaný ako jednorozmerný zoznam párov kľúč-hodnota. Približne takto:

{
  "region":             "US",
  "manager.age":        30,
  "manager.name.first": "John",
  "manager.name.last":  "Smith"
}
Explicitný mapping pre tento dokument by vyzeral takto:
PUT my_index
{
  "mappings": {
    "_doc": { 
      "properties": {
        "region": {
          "type": "keyword"
        },
        "manager": { 
          "properties": {
            "age":  { "type": "integer" },
            "name": { 
              "properties": {
                "first": { "type": "text" },
                "last":  { "type": "text" }
              }
            }
          }
        }
      }
    }
  }
}
Ako vidno field name nemusí mať definovaný typ object, pretože to je defaultný typ.
 
Parametre typu object:
 
  • dynamic: Určuje či nové fieldy objektu budú pridané dynamicky do objektu alebo nie. Default je TRUE. dynamic
  • enabled: Určuje či JSON hodnota pre daný objekt field bude parsovaná a indexovaná alebo ignorovaná. Default TRUE. enabled
  • properties: Obsahuje definície fieldov vo vnútri objektu. 
 

Typ nested

Nested je špeciálna verzia typu object, ktorá umožňuje aby bolo možné indexovať pole objektov, tak aby bolo možné dotazovať sa na každý objekt v poli nezávisle na ostatných objektoch, ktoré toto pole obsahuje. 

Lucene nemá koncept vnorených objektov. Pole vnorených objektov je indexované ako jednoduchý (jednoúrovňový) zoznam ako kľúč-hodota. Na vysvetlenie príklad:
PUT my_index/_doc/1
{
  "group" : "fans",
  "user" : [ 
    {
      "first" : "John",
      "last" :  "Smith"
    },
    {
      "first" : "Alice",
      "last" :  "White"
    }
  ]
}
Tento dokument bude interne  indexovaný ako
{
  "group" :        "fans",
  "user.first" : [ "alice", "john" ],
  "user.last" :  [ "smith", "white" ]
}

z čoho je vidieť že sa stratilo prepojenie medzi firs a last name. Preto je nutné definovať pole objektov ako typ nested

Takže ak potrebuje definovať pole objektov a zachovať nezávislosť medzi nimi, musíte použiť nested datatype miesto typu objekt. Interne sú nested objekty indexované ako hidden dokumenty a na každý objekt je možné zacieliť podmienkami v requeste viď nested query

PUT my_index
{
  "mappings": {
    "_doc": {
      "properties": {
        "user": {
          "type": "nested" 
        }
      }
    }
  }
}

PUT my_index/_doc/1
{
  "group" : "fans",
  "user" : [
    {
      "first" : "John",
      "last" :  "Smith"
    },
    {
      "first" : "Alice",
      "last" :  "White"
    }
  ]
}

GET my_index/_search
{
  "query": {
    "nested": {
      "path": "user",
      "query": {
        "bool": {
          "must": [
            { "match": { "user.first": "Alice" }},
            { "match": { "user.last":  "Smith" }} 
          ]
        }
      }
    }
  }
}

GET my_index/_search
{
  "query": {
    "nested": {
      "path": "user",
      "query": {
        "bool": {
          "must": [
            { "match": { "user.first": "Alice" }},
            { "match": { "user.last":  "White" }} 
          ]
        }
      },
      "inner_hits": { 
        "highlight": {
          "fields": {
            "user.first": {}
          }
        }
      }
    }
  }
}

Nested dokumenty môžu byť

Petože nested dokumenty sú indexované separátne, je môžné sa na ne dotazovať IBA cez nested query, nested/reverse_nested aggregácie, alebo nested inner hits.

Parametre typu nested

  • dynamic: Určuje či nové fieldy v nested objektoch budú dynamicky pridávané alebo nie. Default TRUE. Akceptuje TRUE, FALSE a STRICT
  • properties: Fieldy vnoreného objektu, ktoré môžu byť roznych typov vrátane typu nested. Nové properties môžu byť pridávané do už existujúceho nested objektu.

Obmedzenia typu nested

Ako bolo už povedané, nested objekty sú indexované separátne. Ak teba vytvoríme podľa predošlého príkladu dokument, ktorý bude obsahovať 100 user objektov Lucene vytvorí 101 objektov. Elastica preto obsahuje nastavenie, ktoré zamedzuje prípadným performace problémom.

index.mapping.nested_fields.limit

Typ nested by mal byt použitý v špeciálnych prípadoch, keď objekty v poli musia byť dotazované nezávisle jeden na druhom. Toto nastavenie limituje unikátne nested typy v indexe. V predošlom príklade users bude ako číslo jedna tohoto limitu. Default limit je 50. Settings to prevent mappings explosion

 

Typ array

 

V Elasticsearch je možné do ktoréhokoľvek fieldu vložiť nula alebo viacero hodnôt bez akejkoľvek konfigurácie. Jediná podmienka je že všetky hodnoty musia mať rovnaký typ.

Pole objektov si vyžaduje trocha pochopenia. Nefunguje to totiž ako by ste asi čakali. Nieje možné dotazovať sa na jednotlivé objekty v poli separátne. Podrobnejšie sa tomuto problému venuje predošlý typ nested, ktorý v tomto prípade treba použiť. 

Keď sa pridáva field do indexu dynamicky, prvá hodnota v poli určuje typ fieldu. Všetky ostatné hodnoty musia mať rovnaký typ alebo minimálne musí byť možné pretypovať pomocou coerce hodnotu na potrebný typ.

Polia zmiešaných typov sú neni podporované: [ 10"some string" ]

Pole môže obsahovať null hodnoty, ktoré sú buď nahradené cez null_value alebo preskočené celkom. Prázdne pole sa považuje za chýbajúcu hodnotu tj. field bez hodnoty.

PUT my_index/_doc/1
{
  "message": "some arrays in this document...",
  "tags":  [ "elasticsearch", "wow" ], 
  "lists": [ 
    {
      "name": "prog_list",
      "description": "programming list"
    },
    {
      "name": "cool_list",
      "description": "cool stuff list"
    }
  ]
}

 

Typ fields - multifield

Často je užitočné indexovať field viacerými spôsobmi pre rôzne účely. To je zmysel multi-fields. Napr. typ string môže byť mapovaný ako text kôli fulltextovému vyhľadávaniu a ako keyword pre potreby radenia a agegácií. 

PUT my_index
{
  "mappings": {
    "_doc": {
      "properties": {
        "city": {
          "type": "text",
          "fields": {
            "raw": { 
              "type":  "keyword"
            }
          }
        }
      }
    }
  }
}

PUT my_index/_doc/1
{
  "city": "New York"
}

PUT my_index/_doc/2
{
  "city": "York"
}

GET my_index/_search
{
  "query": {
    "match": {
      "city": "york" 
    }
  },
  "sort": {
    "city.raw": "asc" 
  },
  "aggs": {
    "Cities": {
      "terms": {
        "field": "city.raw" 
      }
    }
  }
}
city.raw je verzia fieldu city typu keyword a použije sa pri radení a agregáciách.
city je field typu text a použije sa pri fulltext vyhľadávaní.  
 
Multi-fields nemenia originálny _source field.
 
Nové multi-fields môžu byť pridané do už existujúcich fields použitím PUT mapping API.

Multi-fields s viacerými analyzermi. 

Iný prípad použitia multi-fields je analyzovanie jedného fieldu viacerými analyzermi pre dosiahnutie lepšiej relevancie. Napr. môžeme indexovať field cez standard analyzer ktorý rozdelí text na slová a paralelne ho indexovať cez english analyzer ktorý použije stemming na základ (koreň) slov a odstráni stopwords. 

PUT my_index
{
  "mappings": {
    "_doc": {
      "properties": {
        "text": { 
          "type": "text",
          "fields": {
            "english": { 
              "type":     "text",
              "analyzer": "english"
            }
          }
        }
      }
    }
  }
} 

Veta: "The quick brown foxes run to the wood"
sa do fieldu text uloží ako tokeny: the, quick, brown, foxes, run, to, the, wood
a do fieldu text.english ako tokeny: quick, brown, fox, run, wood

Query string je tiež analyzovaný cez field analyzery takže je možné sa dotazovať zároveň aj na výraz fox aj na foxes čoposkytuje lepšiu relevanciu pre výsledky, ktroé obsahujú obydve formy.  

 

Typ geo_point

Polia typu geo_point akceptujú latitude-longitude páry, ktoré môžu byť použité k

Existujú štyri spôsoby ako môžu byť geo_pointy ukladané viď. príklad

PUT my_index
{
  "mappings": {
    "_doc": {
      "properties": {
        "location": {
          "type": "geo_point"
        }
      }
    }
  }
}

PUT my_index/_doc/1
{
  "text": "Geo-point as an object",
  "location": { 
    "lat": 41.12,
    "lon": -71.34
  }
}

PUT my_index/_doc/2
{
  "text": "Geo-point as a string",
  "location": "41.12,-71.34" 
}

PUT my_index/_doc/3
{
  "text": "Geo-point as a geohash",
  "location": "drm3btev3e86" 
}

PUT my_index/_doc/4
{
  "text": "Geo-point as an array",
  "location": [ -71.34, 41.12 ] 
}

Príklad requestu na geo_bounding_box

GET my_index/_search
{
  "query": {
    "geo_bounding_box": { 
      "location": {
        "top_left": {
          "lat": 42,
          "lon": -72
        },
        "bottom_right": {
          "lat": 40,
          "lon": -74
        }
      }
    }
  }
}
WARNING
 
U geo_pointov vladaných ako string sa predpokladá poradie lat, long zatiaľčo u pointov vkladaných ako pole je to obrátene long, lat!!!  
 
Parametre typu geo_point
 
  • ignore_malformeed: Ak je TRUE chybné pointy budú ignorované. Ak je FALSE (default) vyhodí výnimku a zamietne celý dokument.
  • ignore_z_value: Ak je TRUE (default) bude field akceptovať trojdimenzionálny. Ale bude uložený iba do _source a iba latitude a longitude budú indexované. Tretia dimenzia bude ignorovaná. Ak je FALSE geo_point obsahujúci viac ako dve dimenzie vyhodí výnimku a zamietne celý dokument. 
  • null_value: Akceptuje geo_point hodnotu ktorá sa vloží v prípade že vkladaná hodnota je NULL.

Ak sa ku geo_point typu pristuje v scipte hodnota je reprezentovaná ako GeoPoint object s kľučmy lat a lon;

def lat      = geopoint.lat;
def lon      = geopoint.lon;

Kôli výkone je lepšie pristupovať k lat a lon priamo:

def lat      = doc['location'].lat;
def lon      = doc['location'].lon;

 

Typ geo_shape

geo_shape datatyp uľahčuje vyhľadávanie a indexovanie ľubovoľných geo útvarov od štvoruholníkov až po polygony. Tento sa použije vždy keď dáta obsahujú viac ako len jeden geo point.

Query na typ geo_shape popisuje geo_shape Query.

Mapping options

Geo_shape mapping mapuje geo_json objekty do geo_shape typu. Aby to bolo možné musí user explicitne mapovať fieldy do geo_shape typu.

Parametre

  • tree: [6.6Deprecated in 6.6. PrefixTrees no longer used. Name of the PrefixTree implementation to be used: geohash for GeohashPrefixTree and quadtree for QuadPrefixTree. Note: This parameter is only relevant for term and recursive strategies. Default quadtree
  • precision: Deprecated in 6.6. PrefixTrees no longer used. This parameter may be used instead of tree_levels to set an appropriate value for the tree_levels parameter. The value specifies the desired precision and Elasticsearch will calculate the best tree_levels value to honor this precision. The value should be a number followed by an optional distance unit. Valid distance units include: ininchydyardmimileskmkilometersm,meterscm,centimetersmmmillimeters. Note: This parameter is only relevant for term and recursive strategies. Default 50m
  • tree_levels: Deprecated in 6.6. PrefixTrees no longer used. Maximum number of layers to be used by the PrefixTree. This can be used to control the precision of shape representations andtherefore how many terms are indexed. Defaults to the default value of the chosen PrefixTree implementation. Since this parameter requires a certain level of understanding of the underlying implementation, users may use the precision parameter instead. However, Elasticsearch only uses the tree_levels parameter internally and this is what is returned via the mapping API even if you use the precision parameter. Note: This parameter is only relevant for term and recursive strategies. Default various
  • strategy: Deprecated in 6.6. PrefixTrees no longer used. The strategy parameter defines the approach for how to represent shapes at indexing and search time. It also influences the capabilities available so it is recommended to let Elasticsearch set this parameter automatically. There are two strategies available: recursive, and term. Recursive and Term strategies are deprecated and will be removed in a future version. While they are still available, the Term strategy supports point types only (the points_only parameter will be automatically set to true) while Recursive strategy supports all shape types. (IMPORTANT: see Prefix trees for more detailed information about these strategies) Default recursive
  • distance_error_pct: Deprecated in 6.6. PrefixTrees no longer used. Used as a hint to the PrefixTree about how precise it should be. Defaults to 0.025 (2.5%) with 0.5 as the maximum supported value. PERFORMANCE NOTE: This value will default to 0 if a precision or tree_level definition is explicitly defined. This guarantees spatial precision at the level defined in the mapping. This can lead to significant memory usage for high resolution shapes with low error (e.g., large shapes at 1m with < 0.001 error). To improve indexing performance (at the cost of query accuracy) explicitly define tree_level or precision along with a reasonable distance_error_pct, noting that large shapes will have greater false positives. Note: This parameter is only relevant for term and recursive strategies. Default 0.025
  • orientation: Optionally define how to interpret vertex order for polygons / multipolygons. This parameter defines one of two coordinate system rules (Right-hand or Left-hand) each of which can be specified in three different ways. 1. Right-hand rule: rightccwcounterclockwise, 2. Left-hand rule: leftcwclockwise. The default orientation (counterclockwise) complies with the OGC standard which defines outer ring vertices in counterclockwise order with inner ring(s) vertices (holes) in clockwise order. Setting this parameter in the geo_shape mapping explicitly sets vertex order for the coordinate list of a geo_shape field but can be overridden in each individual GeoJSON or WKT document. Default ccw
  • points_only: Deprecated in 6.6. PrefixTrees no longer used. Setting this option to true (defaults to false) configures the geo_shape field type for point shapes only (NOTE: Multi-Points are not yet supported). This optimizes index and search performance for the geohash and quadtree when it is known that only points will be indexed. At present geo_shape queries can not be executed on geo_point field types. This option bridges the gap by improving point performance on a geo_shape field so that geo_shape queries are optimal on a point only field. Default FALSE
  • ignore_malformed: If true, malformed GeoJSON or WKT shapes are ignored. If false (default), malformed GeoJSON and WKT shapes throw an exception and reject the entire document. Default FALSE
  • ignore_z_values: Default TRUE
  • coerce: If true unclosed linear rings in polygons will be automatically closed.

Indexovanie

GeoShapes typy sú indexované tak že polygon je rozložený na sieť trojuholníkov tomu sa hovorí tiringulácia viď odkaz 
 
Importand

The following features are not yet supported with the new indexing approach:

  • geo_shape query with MultiPoint geometry types - Elasticsearch currently prevents searching geo_shape fields with a MultiPoint geometry type to avoid a brute force linear search over each individual point. For now, if this is absolutely needed, this can be achieved using a bool query with each individual point.
  • CONTAINS relation query - when using the new default vector indexing strategy, geo_shape queries with relation defined as contains are not yet supported. If this query relation is an absolute necessity, it is recommended to set strategy to quadtree and use the deprecated PrefixTree strategy indexing approach.
Príklad na geo_shape mapping
PUT /example
{
    "mappings": {
        "doc": {
            "properties": {
                "location": {
                    "type": "geo_shape"
                }
            }
        }
    }
}

Štruktúra vkladaných údajov

už ale nemám náladu to prekladať takže tu je link na dokumntáciu https://www.elastic.co/guide/en/elasticsearch/reference/6.8/geo-shape.html#input-structure

 

Špecializované typy

IP datatype:  for IPv4 and IPv6 addresses

Completion datatype:  to provide auto-complete suggestions

Token count datatype:  to count the number of tokens in a string

mapper-murmur3:  to compute hashes of values at index-time and store them in the index

mapper-annotated-text:  to index text containing special markup (typically used for identifying named entities)

Percolator type: Accepts queries from the query-dsl

join datatype: Defines parent/child relation for documents within the same index

Alias datatype: Defines an alias to an existing field

 

Ak chcete pridávať komentáre musíte sa prihlásiť