ElasticSearch-Relationshiphotoshop和amp;Geo Queries

目录

---Relationships---

Using the has_child query

Using the has_parent query

Using the nested query

----geo-----

Using the geo_bounding_box query

Using the geo_shape query

Using the geo_distance query

---Relationships---

1.  
    
2.  
    
3.  
   """
4.  
   DELETE /mybooks
5.  
    
6.  
   PUT /mybooks
7.  
   {
8.  
   "mappings": {
9.  
   "properties": {
10.  
    "join_field": {
11.  
    "type": "join",
12.  
    "relations": {
13.  
    "order": "item"
14.  
    }
15.  
    },
16.  
    "position": {
17.  
    "type": "integer",
18.  
    "store": true
19.  
    },
20.  
    "uuid": {
21.  
    "store": true,
22.  
    "type": "keyword"
23.  
    },
24.  
    "date": {
25.  
    "type": "date"
26.  
    },
27.  
    "quantity": {
28.  
    "type": "integer"
29.  
    },
30.  
    "price": {
31.  
    "type": "double"
32.  
    },
33.  
    "description": {
34.  
    "term_vector": "with_positions_offsets",
35.  
    "store": true,
36.  
    "type": "text"
37.  
    },
38.  
    "title": {
39.  
    "term_vector": "with_positions_offsets",
40.  
    "store": true,
41.  
    "type": "text",
42.  
    "fielddata": true,
43.  
    "fields": {
44.  
    "keyword": {
45.  
    "type": "keyword",
46.  
    "ignore_above": 256
47.  
    }
48.  
    }
49.  
    }
50.  
    }
51.  
    }
52.  
    }
53.  
     
54.  
    POST _bulk?refresh
55.  
    {"index":{"_index":"mybooks", "_id":"1"}}
56.  
    {"uuid":"11111","position":1,"title":"Joe Tester","description":"Joe Testere nice guy","date":"2015-10-22","price":4.3,"quantity":50}
57.  
    {"index":{"_index":"mybooks", "_id":"2"}}
58.  
    {"uuid":"22222","position":2,"title":"Bill Baloney","description":"Bill Testere nice guy","date":"2016-06-12","price":5,"quantity":34}
59.  
    {"index":{"_index":"mybooks", "_id":"3"}}
60.  
    {"uuid":"33333","position":3,"title":"Bill Klingon","description":"Bill is not\n nice guy","date":"2017-09-21","price":6,"quantity":33}
61.  
     
62.  
     
63.  
    PUT /mybooks-join
64.  
    {
65.  
    "mappings": {
66.  
    "properties": {
67.  
    "join": { "type": "join", "relations": { "book": "author" } },
68.  
     
69.  
    "uuid": { "store": true, "type": "keyword" },
70.  
    "position": { "type": "integer", "store": true },
71.  
    "title": {
72.  
    "term_vector": "with_positions_offsets", "store": true, "type": "text",
73.  
    "fielddata": true,
74.  
    "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } }
75.  
    },
76.  
    "description": { "term_vector": "with_positions_offsets", "store": true, "type": "text" },
77.  
    "date": { "type": "date" },
78.  
    "price": { "type": "double" },
79.  
    "quantity": { "type": "integer" },
80.  
    "versions": {
81.  
    "type": "nested", "properties": { "color": { "type": "keyword" }, "size": { "type": "integer" } }
82.  
    },
83.  
     
84.  
     
85.  
    "rating": { "type": "double" },
86.  
    "name": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } },
87.  
    "surname": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }
88.  
    }}}
89.  
     
90.  
    POST _bulk?refresh
91.  
    {"index":{"_index":"mybooks-join", "_id":"1"}}
92.  
    {"uuid":"11111","position":1,"title":"Joe Tester","description":"Joe Testere nice guy","date":"2015-10-22","price":4.3,"quantity":50,
93.  
    "join": {"name": "book"}, "versions":[{"color":"yellow", "size":5},{"color":"blue", "size":15}]}
94.  
    {"index":{"_index":"mybooks-join", "_id":"a11", "routing":"1"}}
95.  
    {"name":"Peter","surname":"Doyle","rating":4.5, "join": {"name": "author", "parent":"1"}}
96.  
    {"index":{"_index":"mybooks-join", "_id":"a12", "routing":"1"}}
97.  
    {"name":"Mark","surname":"Twain","rating":4.2, "join": {"name": "author", "parent":"1"}}
98.  
     
99.  
    {"index":{"_index":"mybooks-join", "_id":"2"}}
100.  
     {"uuid":"22222","position":2,"title":"Bill Baloney","description":"Bill Testere nice guy","date":"2016-06-12","price":5,"quantity":34,
101.  
     "join": {"name": "book"}, "versions":[{"color":"red", "size":2},{"color":"blue", "size":10}]}
102.  
     {"index":{"_index":"mybooks-join", "_id":"a2", "routing":"2"}}
103.  
     {"name":"Agatha","surname":"Princeton","rating":2.1, "join": {"name": "author", "parent":"2"}}
104.  
      
105.  
     {"index":{"_index":"mybooks-join", "_id":"3"}}
106.  
     {"uuid":"33333","position":3,"title":"Bill Klingon","description":"Bill is not\n nice guy","date":"2017-09-21","price":6,"quantity":33,
107.  
     "join": {"name": "book"}, "versions":[{"color":"red", "size":2}]}
108.  
     {"index":{"_index":"mybooks-join", "_id":"a3", "routing":"3"}}
109.  
     {"name":"Martin","surname":"Twisted","rating":3.2,"join": {"name": "author", "parent":"3"}}
110.  
      
111.  
     POST /mybooks-join/_refresh
112.  
      
113.  
     """

Using the has_child query

1.    We want to search the parent (book) of the children (author), which has a term in the name field called martin. We can create this kind of query using the following code:

1.  
   POST /mybooks-join/_search
2.  
   { "query": {
3.  
       "has_child": {
4.  
         "type": "author",
5.  
         "query": { "term": { "name": "martin" } },
6.  
         "inner_hits" : {}
7.  
       } } }

The parameters that are used to control this process are as follows:
•    The type parameter describes the type of children. This type is part of the same index as the parent; it's the name provided in the join field parameter at index time.
•    The query parameter can be executed for the selection of the children. Any kind of query can be used.
•    If defined, the score_mode parameter (the default is none; available values are max, sum, avg, and none) allows you to aggregate the children's scores with the parent's ones.
•    min_children and max_children are optional parameters. This is the minimum/maximum number of children that are required to match the parent document.
•    ignore_unmapped (false by default), when set to true, will ignore unmapped types. This is very useful when executing a query on multiple indices and some types are missing. The default behavior is to throw an exception if there is a mapping error.

Using the has_parent query

1.  
   POST /mybooks-join/_search
2.  
   { "query": {
3.  
       "has_parent": {
4.  
         "parent_type": "book",
5.  
         "query": { "term": {"description": "bill" }}}}}

Using the nested query

nested objects are indexed in a special way in Elasticsearch.

1.  
   POST /mybooks-join/_search
2.  
   { "query": {
3.  
       "nested": {
4.  
         "path": "versions",  "score_mode": "avg",
5.  
         "query": {
6.  
           "bool": {
7.  
             "must": [
8.  
               { "term": { "versions.color": "blue" } },
9.  
               { "range":{ "versions.size": { "gt": 10 }}
10.  
                } ] } } } } }

Elasticsearch manages nested objects in a special way. During indexing, they are extracted from the main document and indexed as a separate document, which is saved in the same Lucene chunk of the main document.
The nested query executes the first query on the nested documents, and after gathering the result IDs, they are used to filter the main document. The parameters that are used to control this process are as follows:
•    path: This is the path of the parent document that contains the nested objects.
•    query: This is the query that can be executed to select the nested objects. Every kind of query can be used.
•    score_mode: The default value is avg. The valid values are avg, sum, min, max, and none, which control how to use the score of the nested document matches to improve the query.

----geo-----

1.  
   """
2.  
    
3.  
   DELETE /mygeo-index
4.  
    
5.  
   PUT /mygeo-index
6.  
   {
7.  
     "mappings": {
8.  
       "properties": {
9.  
         "pin": {
10.  
            "properties": {
11.  
              "location": {
12.  
                "type": "geo_point"
13.  
              }
14.  
            }
15.  
          }
16.  
        }
17.  
      }
18.  
    }
19.  
     
20.  
    PUT /mygeo-index/_doc/1
21.  
    {"pin": {"location": {"lat": 40.12, "lon": -71.34}}}
22.  
     
23.  
    PUT /mygeo-index/_doc/2
24.  
    {"pin": {"location": {"lat": 40.12, "lon": 71.34}}}
25.  
     
26.  
    POST /mygeo-index/_refresh
27.  
    """

Using the geo_bounding_box query

One of the most common operations in geo-localization is searching for a box (square). 
The square is usually an approximation of the shape of a shop, a building, or a city.
This kind of query can be used in a percolator for real-time monitoring if users, documents, or events are entering a special place.

1.  
   POST /mygeo-index/_search?pretty
2.  
   { "query": {
3.  
       "geo_bounding_box": {
4.  
         "pin.location": {
5.  
           "bottom_right": { "lat": 40.03, "lon": 72 },
6.  
           "top_left": { "lat": 40.717, "lon": 70.99 }
7.  
         } } } }

Elasticsearch has a lot of optimizations to facilitate searching for a box shape. Latitude and longitude are indexed for fast-range checks, so this kind of filter is executed very quickly.
The parameters that are required to execute a geo-bounding box filter are the following:
•    top_left (the top and left coordinates of the box).
•    bottom_right (the bottom and right coordinates of the box) geo points.
•    validation_method (default STRICT) is used for validating the geo point. The valid values are as follows:
o    IGNORE_MALFORMED is used to accept invalid values for latitude and longitude.
o    COERCE is used to try to correct wrong values.
o    STRICT is used to reject invalid values.
•    type (memory by default) if the query should be executed in memory or indexed.

Using the geo_shape query

1.  
   POST /mygeo-index/_search
2.  
   { "query": {
3.  
       "bool": {
4.  
         "must": { "match_all": {} },
5.  
         "filter": {
6.  
           "geo_shape": {
7.  
             "pin.location": {
8.  
               "shape": {
9.  
                 "type": "polygon",
10.  
                  "coordinates": [
11.  
                    [[-30,50],[-80,30],[-90,80],[-30,50]]
12.  
                  ] },
13.  
                "relation": "within"} } } } } }

Using the geo_distance query

This scenario as the following:
•    Finding the nearest restaurant within a distance of 20 km
•    Finding my nearest friends within a range of 10 km

1.  
   GET /mygeo-index/_search
2.  
   { "query": {
3.  
       "geo_distance": {
4.  
         "pin.location": { "lat": 40, "lon": 70 },
5.  
         "distance": "200km" } } }

The distance query executes a distance calculation between a given geo point and the points in the documents, returning hits that satisfy the distance requirement.
The parameters that control the distance query are as follows:
•    The field and point of reference used to calculate the distance. In the preceding example, we have pin.location and (40,70).
•    distance defines the distance to be considered. It is usually expressed as a string by a number plus a unit.
•    unit (optional) can be the unit of the distance value, if the distance is defined as a number. The valid values are as follows:
    o    in or inch
    o    yd or yards
    o    m or miles
    o    km or kilometers
    o    m or meters
    o    mm or millimeters
    o    cm or centimeters
•    distance_type (arc by default; valid choices are arc, which considers the roundness of the globe, or plane, which simplifies the distance in a linear way) defines the type of algorithm to calculate the distance.
•    validation_method (STRICT by default) is used for validating the geo point. The valid values are as follows:
    o    IGNORE_MALFORMED is used to accept invalid values for latitude and longitude.
    o    COERCE is used to try to correct wrong values.
    o    STRICT is used to reject invalid values.
•    ignore_unmapped is used to safely execute the query in the case of multi-indices, which can have a missing definition of a geo point.

这篇好文章是转载于：学新通技术网