springboot elasticsearch 集成注意事項

相關內容簡體繁體

springboot elasticsearch 集成注意事項

本文轉載自查看原文 2018-04-02 09:44 60719 elasticsearch/ es中date/ springboot

　　文章來源： http://www.cnblogs.com/guozp/p/8686904.html

一 elasticsearch基礎

　　這里假設各位已經簡單了解過elasticsearch，並不對es進入更多的，更深層次的解釋，如有必要，會在寫文章專門進行es講解。

　　Elasticsearch是一個基於Apache Lucene(TM)的開源搜索引擎。無論在開源還是專有領域，Lucene可以被認為是迄今為止最先進、性能最好的、功能最全的搜索引擎庫。

　　但是，Lucene只是一個庫。想要使用它，你必須使用Java來作為開發語言並將其直接集成到你的應用中，更糟糕的是，Lucene非常復雜，你需要深入了解檢索的相關知識來理解它是如何工作的。

　　Elasticsearch也使用Java開發並使用Lucene作為其核心來實現所有索引和搜索的功能，但是它的目的是通過簡單的RESTful API來隱藏Lucene的復雜性，從而讓全文搜索變得簡單。

　　index ==》索引 ==》Mysql中的一個庫，庫里面可以建立很多表，存儲不同類型的數據，而表在ES中就是type。

　　 type ==》類型 ==》相當於Mysql中的一張表，存儲json類型的數據

　　 document ==》文檔 ==》一個文檔相當於Mysql一行的數據

　　 field ==》列 ==》相當於mysql中的列，也就是一個屬性

這里多說下：

在Elasticsearch6.0.0或者或者更新版本中創建的索引只會包含一個映射類型（mappingtype）。在5.x中創建的具有多個映射類型的索引在Elasticsearch6.x中依然會正常工作。在Elasticsearch7.0.0中，映射類型type將會被完全移除。

原文鏈接

　　開始的時候，我們說“索引（index）”類似於SQL數據庫中的“數據庫”，將“類型（type）”等同於“表”。

　　這是一個糟糕的類比，並且導致了一些錯誤的假設。在SQL數據庫中，表之間是相互獨立的。一個表中的各列並不會影響到其它表中的同名的列。而在映射類型（mappingtype）中卻不是這樣的。

　　在同一個Elasticsearch索引中，其中不同映射類型中的同名字段在內部是由同一個Lucene字段來支持的。換句話說，使用上面的例子，user類型中的user_name字段與tweet類型中的user_name字段是完全一樣的，並且兩個user_name字段在兩個類型中必須具有相同的映射（定義）。

　　這會在某些情況下導致一些混亂，比如，在同一個索引中，當你想在其中的一個類型中將deleted字段作為date類型，而在另一個類型中將其作為boolean字段。

　　在此之上需要考慮一點，如果同一個索引中存儲的各個實體如果只有很少或者根本沒有同樣的字段，這種情況會導致稀疏數據，並且會影響到Lucene的高效壓縮數據的能力。

　　基於這些原因，將映射類型的概念從Elasticsearch中移除。

二 springboot 對應的Es版本關系

springboot	elasticsearch
2.0.0.RELEASE	2.2.0
1.4.0.M1	1.7.3
1.3.0.RELEASE	1.5.2
1.2.0.RELEASE	1.4.4
1.1.0.RELEASE	1.3.2
1.0.0.RELEASE	1.1.1

　　1、None of the configured nodes are available 或者org.elasticsearch.transport.RemoteTransportException: Failed to deserialize exception response from stream

　　原因：spring data elasticSearch 的版本與Spring boot、Elasticsearch版本不匹配。

這是版本之間的對應關系。Spring boot 1.3.5默認的elasticsearch版本是1.5.2，此時啟動1.7.2版本以下的Elasticsearch客戶端連接正常。

　　注：注意java的es默認連接端口是9300，9200是http端口，這兩個在使用中應注意區分。

　　2、Caused by: java.lang.IllegalArgumentException: @ConditionalOnMissingBean annotations must specify at least one bean (type, name or annotation)

　　原因：spring boot是1.3.x版本，而es采用了2.x版本。在es的2.x版本去除了一些類，而這些類在spring boot的1.3.x版本中仍然被使用，導致此錯誤

　　 以上解決參考下面的對應關系：

Spring Boot Version (x)	Spring Data Elasticsearch Version (y)	Elasticsearch Version (z)
x <= 1.3.5	y <= 1.3.4	z <= 1.7.2*
x >= 1.4.x	2.0.0 <=y < 5.0.0**	2.0.0 <= z < 5.0.0**

　　　請一定注意版本兼容問題。這關系到很多maven依賴。Spring Data Elasticsearch Spring Boot version matrix

ik 分詞對應的版本關系：

　　elasticsearch-analysis-ik

Analyzer:

　　ik_smart , ik_max_word , Tokenizer: ik_smart , ik_max_word

Versions

IK version	ES version
master	6.x -> master
6.2.2	6.2.2
6.1.3	6.1.3
5.6.8	5.6.8
5.5.3	5.5.3
5.4.3	5.4.3
5.3.3	5.3.3
5.2.2	5.2.2
5.1.2	5.1.2
1.10.6	2.4.6
1.9.5	2.3.5
1.8.1	2.2.1
1.7.0	2.1.1
1.5.0	2.0.0
1.2.6	1.0.0
1.2.5	0.90.x
1.1.3	0.20.x
1.0.0	0.16.2 -> 0.19.0

三環境構建

maven依賴：前提是依賴

<parent>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-parent</artifactId>
   <version>1.5.9.RELEASE</version>
   <relativePath/> <!-- lookup parent from repository -->
</parent>

<dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-data-elasticsearch</artifactId>
</dependency>

配置文件：

# ES
#開啟 Elasticsearch 倉庫(默認值:true)
spring.data.elasticsearch.repositories.enabled=true
#默認 9300 是 Java 客戶端的端口。9200 是支持 Restful HTTP 的接口
spring.data.elasticsearch.cluster-nodes = 127.0.0.1:9300
#spring.data.elasticsearch.cluster-name Elasticsearch 集群名(默認值: elasticsearch)
#spring.data.elasticsearch.cluster-nodes 集群節點地址列表，用逗號分隔。如果沒有指定，就啟動一個客戶端節點
#spring.data.elasticsearch.propertie 用來配置客戶端的額外屬性
#存儲索引的位置
spring.data.elasticsearch.properties.path.home=/data/project/target/elastic
#連接超時的時間
spring.data.elasticsearch.properties.transport.tcp.connect_timeout=120s

四 es索引實體類

Spring-data-elasticsearch為我們提供了@Document、@Field等注解，如果某個實體需要建立索引，只需要加上這些注解即可

1.類上注解：@Document (相當於Hibernate實體的@Entity/@Table)(必寫)，加上了`@Document`注解之后，默認情況下這個實體中所有的屬性都會被建立索引、並且分詞。

類型	屬性名	默認值	說明
String	indexName	無	索引庫的名稱，建議以項目的名稱命名
String	type	“”	類型，建議以實體的名稱命名
short	shards	5	默認分區數
short	replica	1	每個分區默認的備份數
String	refreshInterval	“1s”	刷新間隔
String	indexStoreType	“fs”	索引文件存儲類型

2.主鍵注解：@Id (相當於Hibernate實體的主鍵@Id注解)(必寫)

只是一個標識，並沒有屬性。

3.屬性注解 @Field (相當於Hibernate實體的@Column注解)

@Field默認是可以不加的，默認所有屬性都會添加到ES中。加上@Field之后，@document默認把所有字段加上索引失效，只有家@Field 才會被索引(同時也看設置索引的屬性是否為no)

類型	屬性名	默認值	說明
FieldType	type	FieldType.Auto	自動檢測屬性的類型
FieldIndex	index	FieldIndex.analyzed	默認情況下分詞
boolean	store	false	默認情況下不存儲原文
String	searchAnalyzer	“”	指定字段搜索時使用的分詞器
String	indexAnalyzer	“”	指定字段建立索引時指定的分詞器
String[]	ignoreFields	{}	如果某個字段需要被忽略

五相關查詢方法

官網參考

　　實現方式比較多，已經存在的接口，使用根據需要繼承即可：

　　1、CrudRepository接口　

public interface CrudRepository<T, ID extends Serializable>
  extends Repository<T, ID> {

  <S extends T> S save(S entity);      

  Optional<T> findById(ID primaryKey); 

  Iterable<T> findAll();               

  long count();                        

  void delete(T entity);               

  boolean existsById(ID primaryKey);   

  // … more functionality omitted.
}

　　2、PagingAndSortingRepository接口

public interface PagingAndSortingRepository<T, ID extends Serializable>
  extends CrudRepository<T, ID> {

  Iterable<T> findAll(Sort sort);

  Page<T> findAll(Pageable pageable);
}

例子：

分頁：

PagingAndSortingRepository<User, Long> repository = // … get access to a bean
Page<User> users = repository.findAll(new PageRequest(1, 20));

計數：

interface UserRepository extends CrudRepository<User, Long> {

  long countByLastname(String lastname);
}

　　3、其他，參考官網

　　自定義查詢實現

那么我們如何自定義方法呢？我們只要使用特定的單詞對方法名進行定義，那么Spring就會對我們寫的方法名進行解析，

該機制條前綴find…By，read…By，query…By，count…By，和get…By從所述方法和開始分析它的其余部分。引入子句可以包含進一步的表達式，如Distinct在要創建的查詢上設置不同的標志。然而，第一個By作為分隔符來指示實際標准的開始。在非常基礎的層次上，您可以定義實體屬性的條件並將它們與And和連接起來Or。

interface PersonRepository extends Repository<User, Long> {

  List<Person> findByEmailAddressAndLastname(EmailAddress emailAddress, String lastname);

  // Enables the distinct flag for the query
  List<Person> findDistinctPeopleByLastnameOrFirstname(String lastname, String firstname);
  List<Person> findPeopleDistinctByLastnameOrFirstname(String lastname, String firstname);

  // Enabling ignoring case for an individual property
  List<Person> findByLastnameIgnoreCase(String lastname);
  // Enabling ignoring case for all suitable properties
  List<Person> findByLastnameAndFirstnameAllIgnoreCase(String lastname, String firstname);

  // Enabling static ORDER BY for a query
  List<Person> findByLastnameOrderByFirstnameAsc(String lastname);
  List<Person> findByLastnameOrderByFirstnameDesc(String lastname);
}

　　構建查詢屬性算法原理：

如上例所示。在查詢創建時，確保解析的屬性是托管類的屬性。但是，你也可以通過遍歷嵌套屬性來定義約束。假設Person x有一個Address和 ZipCode。在這種情況下，方法名稱為

List<Person> findByAddressZipCode(ZipCode zipCode);

創建屬性遍歷x.address.zipCode。解析算法首先將整個part（AddressZipCode）作為屬性進行解釋，然后檢查具有該名稱屬性的類。如果皮匹配成功，則使用該屬性。如果不是屬性，則算法拆分從右側的駝峰部分頭部和尾部，並試圖找出相應的屬性，在我們的例子，AddressZip和Code。如果算法找到具有該頭部的屬性，它將采用尾部並繼續從那里構建樹，然后按照剛剛描述的方式分割尾部。如果第一個分割不匹配，則算法將分割點移動到左側（Address，ZipCode）並繼續。

雖然這應該適用於大多數情況，但算法仍可能會選擇錯誤的屬性。假設這個Person類也有一個addressZip屬性。該算法將在第一輪拆分中匹配，並且基本上選擇錯誤的屬性並最終失敗（因為addressZip可能沒有code屬性的類型）。

為了解決這個歧義，你可以\_在你的方法名稱中使用手動定義遍歷點。所以我們的方法名稱會像這樣結束：

List<Person> findByAddress_ZipCode(ZipCode zipCode);

由於我們將下划線視為保留字符，因此我們強烈建議遵循標准的Java命名約定（即，不要在屬性名稱中使用下划線，而應使用駝峰大小寫）

其他分頁查詢

Page<User> findByLastname(String lastname, Pageable pageable);

Slice<User> findByLastname(String lastname, Pageable pageable);

List<User> findByLastname(String lastname, Sort sort);

　　也可以用Java8 Stream查詢和sql語句查詢

@Query("select u from User u")
Stream<User> findAllByCustomQueryAndStream();

Stream<User> readAllByFirstnameNotNull();

@Query("select u from User u")
Stream<User> streamAllPaged(Pageable pageable);

　　有些在復雜的可以使用es查詢語句

　　我們可以使用@Query注解進行查詢，這樣要求我們需要自己寫ES的查詢語句

public interface BookRepository extends ElasticsearchRepository<Book, String> {
    @Query("{"bool" : {"must" : {"field" : {"name" : "?0"}}}}")
    Page<Book> findByName(String name,Pageable pageable);
}

方法和es查詢轉換：

Keyword Sample Elasticsearch Query String

Keyword	Sample	Elasticsearch Query String
`And`	`findByNameAndPrice`	`{"bool" : {"must" : [ {"field" : {"name" : "?"}}, {"field" : {"price" : "?"}} ]}}`
`Or`	`findByNameOrPrice`	`{"bool" : {"should" : [ {"field" : {"name" : "?"}}, {"field" : {"price" : "?"}} ]}}`
`Is`	`findByName`	`{"bool" : {"must" : {"field" : {"name" : "?"}}}}`
`Not`	`findByNameNot`	`{"bool" : {"must_not" : {"field" : {"name" : "?"}}}}`
`Between`	`findByPriceBetween`	`{"bool" : {"must" : {"range" : {"price" : {"from" : ?,"to" : ?,"include_lower" : true,"include_upper" : true}}}}}`
`LessThanEqual`	`findByPriceLessThan`	`{"bool" : {"must" : {"range" : {"price" : {"from" : null,"to" : ?,"include_lower" : true,"include_upper" : true}}}}}`
`GreaterThanEqual`	`findByPriceGreaterThan`	`{"bool" : {"must" : {"range" : {"price" : {"from" : ?,"to" : null,"include_lower" : true,"include_upper" : true}}}}}`
`Before`	`findByPriceBefore`	`{"bool" : {"must" : {"range" : {"price" : {"from" : null,"to" : ?,"include_lower" : true,"include_upper" : true}}}}}`
`After`	`findByPriceAfter`	`{"bool" : {"must" : {"range" : {"price" : {"from" : ?,"to" : null,"include_lower" : true,"include_upper" : true}}}}}`
`Like`	`findByNameLike`	`{"bool" : {"must" : {"field" : {"name" : {"query" : "?*","analyze_wildcard" : true}}}}}`
`StartingWith`	`findByNameStartingWith`	`{"bool" : {"must" : {"field" : {"name" : {"query" : "?*","analyze_wildcard" : true}}}}}`
`EndingWith`	`findByNameEndingWith`	`{"bool" : {"must" : {"field" : {"name" : {"query" : "*?","analyze_wildcard" : true}}}}}`
`Contains/Containing`	`findByNameContaining`	`{"bool" : {"must" : {"field" : {"name" : {"query" : "?","analyze_wildcard" : true}}}}}`
`In`	`findByNameIn(Collection<String>names)`	`{"bool" : {"must" : {"bool" : {"should" : [ {"field" : {"name" : "?"}}, {"field" : {"name" : "?"}} ]}}}}`
`NotIn`	`findByNameNotIn(Collection<String>names)`	`{"bool" : {"must_not" : {"bool" : {"should" : {"field" : {"name" : "?"}}}}}}`
`Near`	`findByStoreNear`	`Not Supported Yet !`
`True`	`findByAvailableTrue`	`{"bool" : {"must" : {"field" : {"available" : true}}}}`
`False`	`findByAvailableFalse`	`{"bool" : {"must" : {"field" : {"available" : false}}}}`
`OrderBy`	`findByAvailableTrueOrderByNameDesc`	`{"sort" : [{ "name" : {"order" : "desc"} }],"bool" : {"must" : {"field" : {"available" : true}}}}`

And

findByNameAndPrice

{"bool" : {"must" : [ {"field" : {"name" : "?"}}, {"field" : {"price" : "?"}} ]}}

Or

findByNameOrPrice

{"bool" : {"should" : [ {"field" : {"name" : "?"}}, {"field" : {"price" : "?"}} ]}}

Is

findByName

{"bool" : {"must" : {"field" : {"name" : "?"}}}}

Not

findByNameNot

{"bool" : {"must_not" : {"field" : {"name" : "?"}}}}

Between

findByPriceBetween

{"bool" : {"must" : {"range" : {"price" : {"from" : ?,"to" : ?,"include_lower" : true,"include_upper" : true}}}}}

LessThanEqual

findByPriceLessThan

{"bool" : {"must" : {"range" : {"price" : {"from" : null,"to" : ?,"include_lower" : true,"include_upper" : true}}}}}

GreaterThanEqual

findByPriceGreaterThan

{"bool" : {"must" : {"range" : {"price" : {"from" : ?,"to" : null,"include_lower" : true,"include_upper" : true}}}}}

Before

findByPriceBefore

{"bool" : {"must" : {"range" : {"price" : {"from" : null,"to" : ?,"include_lower" : true,"include_upper" : true}}}}}

After

findByPriceAfter

{"bool" : {"must" : {"range" : {"price" : {"from" : ?,"to" : null,"include_lower" : true,"include_upper" : true}}}}}

Like

findByNameLike

{"bool" : {"must" : {"field" : {"name" : {"query" : "?*","analyze_wildcard" : true}}}}}

StartingWith

findByNameStartingWith

{"bool" : {"must" : {"field" : {"name" : {"query" : "?*","analyze_wildcard" : true}}}}}

EndingWith

findByNameEndingWith

{"bool" : {"must" : {"field" : {"name" : {"query" : "*?","analyze_wildcard" : true}}}}}

Contains/Containing

findByNameContaining

{"bool" : {"must" : {"field" : {"name" : {"query" : "?","analyze_wildcard" : true}}}}}

In

findByNameIn(Collection<String>names)

{"bool" : {"must" : {"bool" : {"should" : [ {"field" : {"name" : "?"}}, {"field" : {"name" : "?"}} ]}}}}

NotIn

findByNameNotIn(Collection<String>names)

{"bool" : {"must_not" : {"bool" : {"should" : {"field" : {"name" : "?"}}}}}}

Near

findByStoreNear

Not Supported Yet !

True

findByAvailableTrue

{"bool" : {"must" : {"field" : {"available" : true}}}}

False

findByAvailableFalse

{"bool" : {"must" : {"field" : {"available" : false}}}}

OrderBy

findByAvailableTrueOrderByNameDesc

{"sort" : [{ "name" : {"order" : "desc"} }],"bool" : {"must" : {"field" : {"available" : true}}}}

六 between使用注意

在使用的時候沒有找到直接的例子，由於between是轉換成range，所以需要范圍參數from和to，

舉例如下：

Page<Recruit> findByRecruitWorkAndRecruitCitysAndWorkTypeAndXjTimeBetween(String recruitWork, String recruitCitys, Integer workType, Date fromXjTime, Date toXjTime,Pageable pageable);

　　注意：

　　這里必須要注意的是：只要使用了between參數，****XjTimeBetween(......,from,to) ，使用該方法的時候，必須要傳遞范圍參數from，to，不能同時為空。

　　否則異常

org.springframework.dao.InvalidDataAccessApiUsageException: Range [* TO *] is not allowed
	at org.springframework.data.elasticsearch.core.query.Criteria.between(Criteria.java:304)
	at org.springframework.data.elasticsearch.repository.query.parser.ElasticsearchQueryCreator.from(ElasticsearchQueryCreator.java:127)
	at org.springframework.data.elasticsearch.repository.query.parser.ElasticsearchQueryCreator.and(ElasticsearchQueryCreator.java:76)
	at org.springframework.data.elasticsearch.repository.query.parser.ElasticsearchQueryCreator.and(ElasticsearchQueryCreator.java:46)
	at org.springframework.data.repository.query.parser.AbstractQueryCreator.createCriteria(AbstractQueryCreator.java:109)
	at org.springframework.data.repository.query.parser.AbstractQueryCreator.createQuery(AbstractQueryCreator.java:88)
	at org.springframework.data.repository.query.parser.AbstractQueryCreator.createQuery(AbstractQueryCreator.java:73)
	at org.springframework.data.elasticsearch.repository.query.ElasticsearchPartQuery.createQuery(ElasticsearchPartQuery.java:102)
	at org.springframework.data.elasticsearch.repository.query.ElasticsearchPartQuery.execute(ElasticsearchPartQuery.java:51)
	at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.doInvoke(RepositoryFactorySupport.java:499)
	at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:477)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.data.projection.DefaultMethodInvokingMethodInterceptor.invoke(DefaultMethodInvokingMethodInterceptor.java:56)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.data.repository.core.support.SurroundingTransactionDetectorMethodInterceptor.invoke(SurroundingTransactionDetectorMethodInterceptor.java:57)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213)
	at com.sun.proxy.$Proxy86.findByRecruitWorkAndRecruitCitysAndWorkTypeAndXjTimeBetween(Unknown Source)
	at com.zhimingdeng.service.impl.EsIndexServiceImpl.findByRecruitWorkAndRecruitCitysAndWorkTypeAndXjTimeBetween(EsIndexServiceImpl.java:155)

　　因為底層要求參數不能同時為空

七 es時間類型注意

　　來源： http://www.cnblogs.com/guozp/p/8686904.html

　　對於Elasticsearch原生支持date類型，json格式通過字符來表示date類型。所以在用json提交日期至elasticsearch的時候，es會隱式轉換，把es認為是date類型的字符串直接轉為date類型，間字段內容實際上就是轉換成long類型作為內部存儲的(所以完全可以接受其他時間格式作為時間字段的內容)。至於什么樣的字符串es會認為可以轉換成date類型，參考elasticsearch官網介紹

　　date類型是包含時區信息的，如果我們沒有在json代表日期的字符串中顯式指定時區，對es來說沒什么問題，但是對於我們來說可能會發現一些時間差8個小時的問題。

　　Elastic本身有一種特殊的時間格式，其形式如"2016-01-25T00:00:00"，此格式為ISO8601標准。具體時間日期格式要求可以參見es官方文檔。

　　然而我們在計算日期間隔，甚至按日分類的時候，往往需要把這個String時間轉化為Unix時間戳(Unix Timestamp(時間戳))的形式,再進行計算。而通常，這個時間戳會以毫秒的形式(Java)保存在一個long類型里面，這就涉及到了String與long類型的相互轉化。

　　此外在使用Java Client聚合查詢日期的時候，需要注意時區問題，因為默認的es是按照UTC標准時區算的，所以不設置的聚合統計結果是不正確的。默認不設置時區參數，es是安裝UTC的時間進行查詢的，所以分組的結果可能與預期不一樣。　　

　　JSON 沒有日期類型，因此在 Elasticsearch 中可以表達成:

日期格式化的字符串，比如: "2018-01-01" 或者 "2018/01/01 01:01:30";
毫秒級別的 long 類型或秒級別的 integer 類型，比如: 1515150699465, 1515150699;

　　實際上不管日期以何種格式寫入，在 ES 內部都會先穿換成 UTC 時間並存儲為 long 類型。日期格式可以自定義，如果沒有指定的話會使用以下的默認格式:

　　"strict_date_optional_time||epoch_millis"

　　因此總結來說，不管哪種可以表示時間的格式寫入，都可以用來表示時間

　　所以這里引出多種解決方案：

　　 1、es 默認的是 utc 時間，而國內服務器是 cst 時間，首先有時間上的差距需要轉換。但是如果底層以及上層都統一用時間戳，完美解決時區問題。但是時間戳對我們來說不直觀

　　2、我們在往es提交日期數據的時候，直接提交帶有時區信息的日期字符串，如：“2016-07-15T12:58:17.136+0800”

　　3、還有另外的一種：　　　

　直接設置format為你想要的格式，比如 "yyyy-MM-dd HH:mm:ss" 然后存儲的時候，指定格式，並且Mapping 也是指定相同的format 。

　　第一次使用方式：

　@Field( type = FieldType.Date,
            format = DateFormat.custom,pattern = date_optional_time"
    )
private Date gmtCreate;

我這里是數據是從數據庫直接讀取，使用的datetime類型，原來直接使用的時候，拋異常：

　　MapperParsingException[failed to parse [***]]; nested: IllegalArgumentException[Invalid format: "格式"];

　　原因是： jackson庫在轉換為json的時候，將Date類型轉為為了long型的字符串表示，而我們定義的是date_optional_time格式的字符串，所以解析錯誤，

　　具體的解決辦法：去掉注解中的format=DateFormat.date_optional_time，讓其使用默認的格式，也就是 'strict_date_optional_time||epoch_millis' , 既能接受 date_optional_time格式的，也能接受epoch_millis格式，由於為了查看更直觀感受改為如下：

　　@Field( type = FieldType.Date,
            format = DateFormat.custom,pattern = "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
    )
private Date gmtCreate;

　　　改成這樣后，底層多種格式都可以存儲，如果沒有根據時間進行范圍查找，這里基本上已經就告一段落了。

　　　　 時間范圍查找需求： 存儲Date，和取出來也是Date

　　　　存儲的時候利用各種JSON對象，如 Jackson 等。存儲的時候就可以用JSON Format一下再存儲，然后取出來后

　　@Field( type = FieldType.Date,
            format = DateFormat.custom,pattern = "yyyy-MM-dd HH:mm:ss" ) @JsonFormat (shape = JsonFormat.Shape.STRING, pattern ="yyyy-MM-dd HH:mm:ss",timezone="GMT+8") private Date xjTime;

　　　　有了這個注解后，

　　　　timezone="GMT+8" 主要是因為底層存放的數據日期時區是UTC，這里轉換成GMT

　　　　真實存儲格式如下(高能瞎眼)：

　　　　時間范圍查找需求注意：

　　　　根據條件查詢的時候，時間范圍需要傳入range，這里涉及到了兩種選擇，底層查詢方法實現的時候range的參數為

　　　　1 date:

　　　　　　傳入的是date參數，然后就行查詢的時候，會報異常，因為我把日期轉成了yyyy-MM-dd HH:mm:ss,但是底層數據是2018-03-27T16:00:00.000Z這種格式，導致錯誤，詳細異常如下

org.elasticsearch.action.search.SearchPhaseExecutionException: all shards failed
	at org.elasticsearch.action.search.AbstractSearchAsyncAction.onFirstPhaseResult(AbstractSearchAsyncAction.java:206)
	at org.elasticsearch.action.search.AbstractSearchAsyncAction$1.onFailure(AbstractSearchAsyncAction.java:152)
	at org.elasticsearch.action.ActionListenerResponseHandler.handleException(ActionListenerResponseHandler.java:46)
	at org.elasticsearch.transport.TransportService$DirectResponseChannel.processException(TransportService.java:855)
	at org.elasticsearch.transport.TransportService$DirectResponseChannel.sendResponse(TransportService.java:833)
	at org.elasticsearch.transport.TransportService$4.onFailure(TransportService.java:387)
	at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:39)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: org.elasticsearch.ElasticsearchParseException: failed to parse date field [2018-03-27T16:00:00.000Z] with format [yyyy-MM-dd HH:mm:ss]
	at org.elasticsearch.common.joda.DateMathParser.parseDateTime(DateMathParser.java:203)
	at org.elasticsearch.common.joda.DateMathParser.parse(DateMathParser.java:67)
	at org.elasticsearch.index.mapper.core.DateFieldMapper$DateFieldType.parseToMilliseconds(DateFieldMapper.java:451)
	at org.elasticsearch.index.mapper.core.DateFieldMapper$DateFieldType.innerRangeQuery(DateFieldMapper.java:435)
	at org.elasticsearch.index.mapper.core.DateFieldMapper$DateFieldType.access$000(DateFieldMapper.java:199)
	at org.elasticsearch.index.mapper.core.DateFieldMapper$DateFieldType$LateParsingQuery.rewrite(DateFieldMapper.java:224)
	at org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:278)
	at org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:837)
	at org.elasticsearch.search.internal.ContextIndexSearcher.rewrite(ContextIndexSearcher.java:81)
	at org.elasticsearch.search.internal.DefaultSearchContext.preProcess(DefaultSearchContext.java:231)
	at org.elasticsearch.search.query.QueryPhase.preProcess(QueryPhase.java:103)
	at org.elasticsearch.search.SearchService.createContext(SearchService.java:676)
	at org.elasticsearch.search.SearchService.createAndPutContext(SearchService.java:620)
	at org.elasticsearch.search.SearchService.executeDfsPhase(SearchService.java:264)
	at org.elasticsearch.search.action.SearchServiceTransportAction$SearchDfsTransportHandler.messageReceived(SearchServiceTransportAction.java:360)
	at org.elasticsearch.search.action.SearchServiceTransportAction$SearchDfsTransportHandler.messageReceived(SearchServiceTransportAction.java:357)
	at org.elasticsearch.transport.TransportRequestHandler.messageReceived(TransportRequestHandler.java:33)
	at org.elasticsearch.transport.RequestHandlerRegistry.processMessageReceived(RequestHandlerRegistry.java:75)
	at org.elasticsearch.transport.TransportService$4.doRun(TransportService.java:376)
	at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
	... 3 common frames omitted
Caused by: java.lang.IllegalArgumentException: Invalid format: "2018-03-27T16:00:00.000Z" is malformed at "T16:00:00.000Z"
	at org.joda.time.format.DateTimeParserBucket.doParseMillis(DateTimeParserBucket.java:187)
	at org.joda.time.format.DateTimeFormatter.parseMillis(DateTimeFormatter.java:826)
	at org.elasticsearch.common.joda.DateMathParser.parseDateTime(DateMathParser.java:200)
	... 22 common frames omitted

解決：

　　傳入的date參數格式化成底層的類型　　

實現參考：

Page<Recruit> findByRecruitWorkAndRecruitCitysAndWorkTypeAndXjTimeBetween(String recruitWork, String recruitCitys, Integer workType, Date fromXjTime, Date toXjTime,Pageable pageable);

　2 String

　　　　參數直接使用string，避免上層轉換成不合適的時間格式，使用框架底層自己轉換，避免錯誤。

　　實現參考：

實現參考：

Page<Recruit> findByRecruitWorkAndRecruitCitysAndWorkTypeAndXjTimeBetween(String recruitWork, String recruitCitys, Integer workType, String fromXjTime, String toXjTime,Pageable pageable);

es時間自定義類型

https://stackoverflow.com/questions/29122071/elasticsearch-failed-to-parse-date

https://stackoverflow.com/questions/29496081/spring-data-elasticsearchs-field-annotation-not-working

https://stackoverflow.com/questions/32042430/elasticsearch-spring-data-date-format-always-is-long