In most case, and the default actually, is to use both types for strings which Elasticsearch supports through multi-fields, that is the ability to index the same string in multiple ways for example index it both as text for search but also as keyword for sorting and aggregations.Īs SQL requires exact values, when encountering a text field Elasticsearch SQL will search for an exact multi-field that it can use for comparisons, sorting and aggregations. These fields are of type text and are not used for sorting or aggregations as their actual value depends on the analyzer used hence why Elasticsearch also offers the keyword type for storing the exact Such types cannot be loaded from Elasticsearch (as it does not know about them) however can be used inside Elasticsearch SQL in queries or their results.Ī core concept in Elasticsearch is that of an analyzed field, that is a full-text value that is interpreted in order In addition to the types above, Elasticsearch SQL also supports at runtime SQL-specific types that do not have an equivalent in Elasticsearch.
Uses the data type particularities of the former over the latter as ultimately Elasticsearch is the backing store. Obviously, not all types in Elasticsearch have an equivalent in SQL and vice-versa hence why, Elasticsearch SQL Supported by Elasticsearch SQL in queries (with the use ofĬAST/ CONVERT), but don’t correspond to anĪctual mapping in Elasticsearch (see the table below).
This is to avoid confusion with the ANSI SQL types DATE (date only) and TIME (time only), which are also Name in Elasticsearch SQL, with the exception of date data type which is mapped to datetime in Elasticsearch SQL. Most of Elasticsearch data types are available in Elasticsearch SQL, as indicated above.Īs one can see, all of Elasticsearch data types are mapped to the data type with the same
0 kommentar(er)
