100
100
levels that affect scoring, analyzers can be used to
101
101
control how text gets tokenized into terms, certain
102
102
fields should not be analyzed at all, and so on... .
103
- elasticsearch allows to completely control how a JSON
103
+ elasticsearch allows you to completely control how a JSON
104
104
document gets mapped into the search engine on a per
105
105
type and per index level.
106
106
</ p >
126
126
< p >
127
127
Indexing data is always done using a unique
128
128
identifier (at the type level). This is very handy
129
- since many time we wish to update or delete the
129
+ since many times we wish to update or delete the
130
130
actual indexed data, or just GET it. Getting data
131
- could not be simpler and all is needed is the index
131
+ could not be simpler and all that is needed is the index
132
132
name, the type and the id. What we get back is the
133
133
< b > actual JSON document</ b > used to index the
134
134
specific data, but please, keep it secret and don't
324
324
we want to restore to the latest state of the
325
325
cluster when it comes back up again.
326
326
elasticsearch provides the gateway module
327
- allowing to do just that, think < b > Time
327
+ allowing you to do just that, think < b > Time
328
328
Machine for search</ b > .
329
329
</ p >
330
330
@@ -333,11 +333,11 @@ <h2>
333
333
transaction log) can either be recreated from
334
334
each node local storage (the default), or
335
335
from a shared storage (like NFS or Amazon
336
- S3). When using a shared storage, the state
336
+ S3). When using shared storage, the state
337
337
is < b > asynchronously</ b > replicated to it.
338
338
</ p >
339
339
< p >
340
- Moreover, when using shared storage long term
340
+ Moreover, when using shared storage for long term
341
341
persistency, the index can be kept completely
342
342
in memory while still being able to perform
343
343
full recovery in the event of cluster
0 commit comments