Create a section to explain some conventions used in ECS. Explain 2 conventions. #89
Conversation
…onventions. Explaining the multi-fields convention will help keep each field description more to the point. Right now there's an inconsistent quick explainer in many of the multi-fields, which is redundant. Having this section to explain it a bit better will let us clean these descriptions up later.
README.md
Outdated
|
|
||
| ElasticSearch can index text multiple ways: | ||
|
|
||
| * `text` indexing allows for full text search, or searching arbitrary words that |
There was a problem hiding this comment.
Do you want to link to the ES docs here?
There was a problem hiding this comment.
Yes I'll link to the docs in a few places, good point
README.md
Outdated
|
|
||
| * `text` indexing allows for full text search, or searching arbitrary words that | ||
| are part of the field. | ||
| * `keyword` indexing allows for exact match search (much faster) and allows for |
There was a problem hiding this comment.
And prefix which is pretty nice for version fields for example: https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-prefix-query.html
README.md
Outdated
| aggregations (what Kibana visualizations are built on). | ||
|
|
||
| In some cases only one type of indexing makes sense for a field. E.g. no need to | ||
| do full text search on an id, and nobody needs to do an exact match search on |
There was a problem hiding this comment.
normally there is no need for an exact match search on 2 kb stack trace. Nobody is a bit strong :-)
There was a problem hiding this comment.
I'm actually thinking of taking out that whole sentence.
README.md
Outdated
| Whenever both types of indexing are helpful, we use multi-fields indexing. The | ||
| convention used is the following: | ||
|
|
||
| * `foo`: `text` indexing. The top level of the field (its plain name) is used |
There was a problem hiding this comment.
Will this convention change any of the existing fields we have? Mainly curious.
In general +1 on the convention.
There was a problem hiding this comment.
Well most of the non-multi-fields text fields are actually keyword. That's why I follow all this immediately with a mention to that effect.
But any time we do multi-field, we need to follow this convention, otherwise it will get confusing :-)
Also, this PR is a side-effect of the thinking/discussion that's happening around #87. And obviously we will need to tweak the wording here if we go with .keyword instead of .raw, but I'm fine with that :-)
|
This is ready to be reviewed again |
|
Thanks for adding the convention. Let's see what #87 will have as an affect on this. |
Explaining the multi-fields convention will help keep each field description more to the point. Right now there's an inconsistent quick explainer in many of the multi-fields, which is redundant. Having this section to explain it a bit better will let us clean these field descriptions up later.
I also like that we're already using
keywordfor most IDs (I haven't checkedthem all out). But it's something I would have pushed for if that hadn't
been the case already.