当查看索引里的数据，我们意识到一些奇怪的东西。
有些事情看起来有问题，我们在索引里有12个tweets,只有1个包含date 2014-09-15
现在让我们看看这些查询。
GET /_search?q=2014 # 12 results
GET /_search?q=2014-09-15 # 12 results !
GET /_search?q=date:2014-09-15 # 1 result
GET /_search?q=date:2014 # 0 results !
PS:如果你看了上一篇文章，你就知道哪个查询用了_all字段，哪个查询没有用这个字段。
为什么会有这些差别？
可能是因为_all索引数据的方式不同于date字段索引数据的方式。
让我们看一看es如何解释我们的文档结构，这是通过请求gb索引的tweet type的mapping信息。
GET /gb/_mapping/tweet
结果如下：
{
"gb"
: {
"mappings"
: {
"tweet"
: {
"properties"
: {
"date"
: {
"type"
:
"date"
,
"format"
:
"dateOptionalTime"
},
"name"
: {
"type"
:
"string"
},
"tweet"
: {
"type"
:
"string"
},
"user_id"
: {
"type"
:
"long"
}
}
}
}
}
}
es已经为我们自动创建了mapping.当然，这是它自己猜测的。
响应告诉我们date域已经被识别为date类型，
_all字段没有提及是因为它是一个默认字段，当然了，我们知道_all字段是string类型。
这样，日期类型的字段和字符串类型的字段的索引方式是不同的，因为寻找过程也是不同的。
一点也不奇怪。
也许，你希望核心类型：strings,number,booleans,dates都以不同的方式索引，而且事实上，它们之间确实有细微差别。
但是，目前为止，最大的差别在于表示具体值的字段和表示全文的字段之间。
这个区别很重要，这是es跟其它数据的区别之一。
http://my.oschina.net/qiangzigege/blog/264662
数据类型可以分为2类：具体值和全文。
具体值，比如说日期或者一个用户ID,也可以包括具体的字符串比如用户名或者邮箱。
具体值
"Foo"
与具体值
"foo"
不同.
具体值2014 与具体值2014-09-15也不同.
全文，引用文本内容，比如tweet的文本或者email的内容。
全文通常理解为非结构化数据，问题是：自然语言的规则复杂，计算机难以解析，比如，考虑到以下句子：
May is fun but June bores me.
这是说月份还是人？
具体值就容易查询，一个值要么匹配查询要么不匹配。
用SQL表达如下：
WHERE name =
"John Smith"
AND user_id = 2
AND
date
>
"2014-09-15"
查询全文的数据就更微妙，
我们不仅仅问文档是否匹配查询，还要知道文档与查询有多匹配，
换句话来说，相关度如何？
很少情况下，我们想完全匹配文本段，而是在文本域里搜索，我们还希望搜索能够理解我们的意图。
一个针对于
"UK"
的搜索应该可以返回包含
"United Kingdom"
的文档。
一个针对于
"jump"
的搜索应该匹配
"jumped"
,
"jumps"
,
"jumping"
或许甚至匹配
"leap"
"johnny walker"
应该匹配
"Johnnie Walker"
，
"johnnie depp"
应该匹配
"Johnny Depp"
。
"fox news hunting"
应该返回跟
"hunting on Fox News"
有关的故事，
"fox hunting news"
应该返回
"news stories about fox hunting"
有关的。
为了让这些全文字段的搜索便利，es首先分析文本，然后使用结果来建立倒排索引，
我们将讨论倒排索引和分析过程。
http://my.oschina.net/qiangzigege/blog/264761