|
1 | 1 | [[empty-search]]
|
2 | 2 | === The Empty Search
|
3 | 3 |
|
4 |
| -The most basic form of the((("searching", "empty search")))((("empty search"))) search API is the _empty search_, which doesn't |
5 |
| -specify any query but simply returns all documents in all indices in the |
6 |
| -cluster: |
| 4 | +搜索API的最基础的形式是没有指定任何查询的空搜索,它简单地返回集群中所有目录中的所有文档: |
7 | 5 |
|
8 | 6 | [source,js]
|
9 | 7 | --------------------------------------------------
|
10 | 8 | GET /_search
|
11 | 9 | --------------------------------------------------
|
12 |
| -// SENSE: 050_Search/05_Empty_search.json |
13 | 10 |
|
14 |
| -The response (edited for brevity) looks something like this: |
| 11 | +返回的结果(为了解决编辑过的)像这种这样子: |
15 | 12 |
|
16 | 13 | [source,js]
|
17 | 14 | --------------------------------------------------
|
@@ -48,66 +45,39 @@ The response (edited for brevity) looks something like this:
|
48 | 45 |
|
49 | 46 | ==== hits
|
50 | 47 |
|
51 |
| -The most important section of the response is `hits`, which((("searching", "empty search", "hits")))((("hits"))) contains the |
52 |
| -`total` number of documents that matched our query, and a `hits` array |
53 |
| -containing the first 10 of those matching documents--the results. |
| 48 | +返回结果中最重的部分是 `hits` ,它包含与我们查询相匹配的文档总数 `total` ,并且一个 `hits` 数组包含所查询结果的前十个文档。 |
54 | 49 |
|
55 |
| -Each result in the `hits` array contains the `_index`, `_type`, and `_id` of |
56 |
| -the document, plus the `_source` field. This means that the whole document is |
57 |
| -immediately available to us directly from the search results. This is unlike |
58 |
| -other search engines, which return just the document ID, requiring you to fetch |
59 |
| -the document itself in a separate step. |
| 50 | +在 `hits` 数组中每个结果包含文档的 `_index` 、 `_type` 、 `_id` ,加上 `_source` 字段。这意味着我们可以直接从返回的搜索结果中使用整个文档。这不像其他的搜索引擎,仅仅返回文档的ID,获取对应的文档需要在单独的步骤。 |
60 | 51 |
|
61 |
| -Each element also ((("score", "for empty search")))((("relevance scores")))has a `_score`. This is the _relevance score_, which is a |
62 |
| -measure of how well the document matches the query. By default, results are |
63 |
| -returned with the most relevant documents first; that is, in descending order |
64 |
| -of `_score`. In this case, we didn't specify any query, so all documents are |
65 |
| -equally relevant, hence the neutral `_score` of `1` for all results. |
| 52 | +每个结果还有一个 `_score` ,这是衡量文档与查询匹配度的关联性分数。默认情况下,首先返回最相关的文档结果,就是说,返回的文档是按照 `_score` 降序排列的。在这个例子中,我们没有指定任何查询,故所有的文档具有相同的相关性,因此对所有的结果而言 `1` 是中性的 `_score` 。 |
66 | 53 |
|
67 |
| -The `max_score` value is the highest `_score` of any document that matches our |
68 |
| -query.((("max_score value"))) |
| 54 | +`max_score` 值是与查询所匹配文档的最高 `_score` 。 |
69 | 55 |
|
70 | 56 | ==== took
|
71 | 57 |
|
72 |
| -The `took` value((("took value (empty search)"))) tells us how many milliseconds the entire search request took |
73 |
| -to execute. |
| 58 | +`took` 值告诉我们执行整个搜索请求耗费了多少毫秒。 |
74 | 59 |
|
75 | 60 | ==== shards
|
76 | 61 |
|
77 |
| -The `_shards` element((("shards", "number involved in an empty search"))) tells us the `total` number of shards that were involved |
78 |
| -in the query and,((("failed shards (in a search)")))((("successful shards (in a search)"))) of them, how many were `successful` and how many `failed`. |
79 |
| -We wouldn't normally expect shards to fail, but it can happen. If we were to |
80 |
| -suffer a major disaster in which we lost both the primary and the replica copy |
81 |
| -of the same shard, there would be no copies of that shard available to respond |
82 |
| -to search requests. In this case, Elasticsearch would report the shard as |
83 |
| -`failed`, but continue to return results from the remaining shards. |
| 62 | +`_shards` 部分告诉我们在查询中参与分片的总数,以及这些分片成功了多少个失败了多少个。正常情况下我们不希望分片失败,但是分片失败是可能发生的。如果我们遭遇到一种较常见的灾难,在这个灾难中丢失了相同分片的原始数据和副本,那么对这个分片将没有可用副本来对搜索请求作出响应。假若这样,Elasticsearch 将报告这个分片是失败的,但是会继续返回剩余分片的结果。 |
84 | 63 |
|
85 | 64 | ==== timeout
|
86 | 65 |
|
87 |
| -The `timed_out` value tells((("timed_out value in search results"))) us whether the query timed out. By |
88 |
| -default, search requests do not time out.((("timeout parameter", "specifying in a request"))) If low response times are more |
89 |
| -important to you than complete results, you can specify a `timeout` as `10` |
90 |
| -or `10ms` (10 milliseconds), or `1s` (1 second): |
| 66 | +`timed_out` 值告诉我们查询是否超时。默认情况下,搜索请求不会超时。如果低响应时间比完成结果更重要,你可以指定 `timeout` 为10或者10ms(10毫秒),或者1s(1秒): |
91 | 67 |
|
92 | 68 | [source,js]
|
93 | 69 | --------------------------------------------------
|
94 | 70 | GET /_search?timeout=10ms
|
95 | 71 | --------------------------------------------------
|
96 | 72 |
|
97 |
| - |
98 |
| -Elasticsearch will return any results that it has managed to gather from |
99 |
| -each shard before the requests timed out. |
| 73 | +在请求超时之前,Elasticsearch 将返回从每个分片聚集来的结果。 |
100 | 74 |
|
101 | 75 | [WARNING]
|
102 | 76 | ================================================
|
103 | 77 |
|
104 |
| -It should be noted that this `timeout` does not((("timeout parameter", "not halting query execution"))) halt the execution of the |
105 |
| -query; it merely tells the coordinating node to return the results collected |
106 |
| -_so far_ and to close the connection. In the background, other shards may |
107 |
| -still be processing the query even though results have been sent. |
| 78 | +应当注意的是 `timeout` 不是停止执行查询,它仅仅是告知正在协调的节点返回到目前为止收集的结果并且关闭连接。在后台,其他的分片可能仍在执行查询即使是结果已经被发送了。 |
108 | 79 |
|
109 |
| -Use the time-out because it is important to your SLA, not because you want |
110 |
| -to abort the execution of long-running queries. |
| 80 | +使用超时是因为对你的SLA是重要的,不是因为想去中止长时间运行的查询。 |
111 | 81 |
|
112 | 82 | ================================================
|
113 | 83 |
|
0 commit comments