You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note that if `size` is not specified, it defaults to 10.
490
+
Each search request is self-contained: {es} does not maintain any
491
+
state information across requests. To page through the search hits, specify
492
+
the `from` and `size` parameters in your request.
510
493
511
494
This example does a `match_all` and returns documents 10 through 19:
512
495
@@ -524,65 +507,9 @@ GET /bank/_search
524
507
525
508
The `from` parameter (0-based) specifies which document index to start from and the `size` parameter specifies how many documents to return starting at the from parameter. This feature is useful when implementing paging of search results. Note that if `from` is not specified, it defaults to 0.
526
509
527
-
This example does a `match_all` and sorts the results by account balance in descending order and returns the top 10 (default size) documents.
Now that we have seen a few of the basic search parameters, let's dig in some more into the Query DSL. Let's first take a look at the returned document fields. By default, the full JSON document is returned as part of all searches. This is referred to as the source (`_source` field in the search hits). If we don't want the entire source document returned, we have the ability to request only a few fields from within source to be returned.
541
-
542
-
This example shows how to return two fields, `account_number` and `balance` (inside of `_source`), from the search:
Note that the above example simply reduces the `_source` field. It will still only return one field named `_source` but within it, only the fields `account_number` and `balance` are included.
556
-
557
-
If you come from a SQL background, the above is somewhat similar in concept to the `SQL SELECT FROM` field list.
558
-
559
-
Now let's move on to the query part. Previously, we've seen how the `match_all` query is used to match all documents. Let's now introduce a new query called the {ref}/query-dsl-match-query.html[`match` query], which can be thought of as a basic fielded search query (i.e. a search done against a specific field or set of fields).
@@ -735,9 +662,15 @@ In addition to the `match_all`, `match`, `bool`, and `range` queries, there are
735
662
[[getting-started-aggregations]]
736
663
== Analyze results with aggregations
737
664
738
-
Aggregations provide the ability to group and extract statistics from your data. The easiest way to think about aggregations is by roughly equating it to the SQL GROUP BY and the SQL aggregate functions. In Elasticsearch, you have the ability to execute searches returning hits and at the same time return aggregated results separate from the hits all in one response. This is very powerful and efficient in the sense that you can run queries and multiple aggregations and get the results back of both (or either) operations in one shot avoiding network roundtrips using a concise and simplified API.
665
+
{es} aggregations enable you to get meta-information about your search results
666
+
and answer questions like, "How many account holders are in Texas?" or
667
+
"What's the average balance of accounts in Tennessee?" You can search
668
+
documents, filter hits, and use aggregations to analyze the results all in one
669
+
request.
739
670
740
-
To start with, this example groups all the accounts by state, and then returns the top 10 (default) states sorted by count descending (also default):
671
+
For example, the following request uses a `terms` aggregation to group
672
+
all of the accounts in the `bank` index by state, and returns the ten states
We can see that there are 27 accounts in `ID` (Idaho), followed by 27 accounts
829
-
in `TX` (Texas), followed by 25 accounts in `AL` (Alabama), and so forth.
830
-
831
-
Note that we set `size=0` to not show search hits because we only want to see the aggregation results in the response.
832
757
833
-
Building on the previous aggregation, this example calculates the average account balance by state (again only for the top 10 states sorted by count in descending order):
758
+
You can combine aggregations to build more complex summaries of your data. For
759
+
example, the following request nests an `avg` aggregation within the previous
760
+
`group_by_state` aggregation to calculate the average account balances for
Notice how we nested the `average_balance` aggregation inside the `group_by_state` aggregation. This is a common pattern for all the aggregations. You can nest aggregations inside aggregations arbitrarily to extract pivoted summarizations that you require from your data.
860
-
861
-
Building on the previous aggregation, let's now sort on the average balance in descending order:
787
+
Instead of sorting the results by count, you could sort using the result of
788
+
the nested aggregation by specifying the order within the `terms` aggregation:
This example demonstrates how we can group by age brackets (ages 20-29, 30-39, and 40-49), then by gender, and then finally get the average account balance, per age bracket, per gender:
In addition to basic bucketing and metrics aggregations like these, {es}
818
+
provides specialized aggregations for operating on multiple fields and
819
+
analyzing particular types of data Such as dates, IP addresses, and geo
820
+
data. You can also feed the results of individual aggregations into pipeline
821
+
aggregations for further analysis.
936
822
937
-
There are many other aggregations capabilities that we won't go into detail here. The {ref}/search-aggregations.html[aggregations reference guide] is a great starting point if you want to do further experimentation.
823
+
The core analysis capabilities provided by aggregations enable advanced
824
+
features such as using machine learning to detect anomalies.
0 commit comments