ElasticSearch의 날짜 저장 방식

Elastic Search에서 가장 자주 사용하는 것은 바로 시간 필드입니다. 자주 그룹에서 몇몇 친구들이 시간에 관한 문제를 제기하는 것을 볼 수 있습니다. 왜es가 조회하는 시간은 제가 실제로 본 시간과 8시간 차이가 날까요?만약 우리가 Elastic Search의 밑바닥 시간 저장 방식을 이해한다면 이 문제를 비교적 쉽게 이해할 수 있을 것이다.
다음은 산선이 먼저 하시구의 지식을 보급하면 여러분도 지리를 낯설게 배운 학우들이 전 세계에 24개의 시구가 있는데 시구마다 경도가 15도라는 것을 알게 될 것입니다.
두 지역의 시간표에 비해 세계 각 시구의 시간과 지명을 나타낼 수 있는 세계 시구표(World Time)는 정밀하고 복잡해 보인다. 보통 세계 시구표의 시계판에는 전 세계 24개 시구의 도시 이름이 표시되지만 도대체 이 24개 시구는 어떻게 생겨났는가?과거에 세계 각지는 원래 각자 현지 시간을 정했지만 교통과 전신이 발달함에 따라 각지의 교류가 날로 빈번해지고 서로 다른 지방 시간으로 인해 많은 어려움을 겪었다. 그래서 서원 1884년 국제회의에서 전 세계적인 기준을 제정했을 때 영국 런던 그리니치 이곳을 영도경선의 출발점(본초자오선이라고도 부른다)으로 정하고 지구가 서쪽에서 동쪽으로 24시간 동안 360°씩 자전하기로 했다.경도 15도, 시차 1시간 간격으로 정하다.한편, 매 15°의 경선은 이 시구의 중앙경선이라고 하는데 전 세계를 24개의 시구로 나눈다. 그 중에서 23개의 정시구와 180°경선 좌우 양측의 2개 반시구를 포함하고 전 세계의 시간을 보면 동경의 시간이 서경보다 빠르다. 즉, 그리니치 시간이 중오 12시라면 중앙경선 15°E의 시구는 오후 1시이고 중앙경선 30°E의 시구는 오후 2시이다.반대로 중앙경선 15°W의 시간대는 오전 11시, 중앙경선 30°W의 시간대는 오전 10시이다.대만을 예로 들면 대만은 동경 121°에 위치하고 환산 후 그리니치와 8시간의 시차가 있다.만약 두 사람이 동시에 그리니치의 0°에서 각각 동쪽, 서쪽으로 전진한다면 그들이 경선이 180°일 때 24시간의 차이가 나기 때문에 경선은 180°에서 국제 환일선으로 정해지고 서쪽에서 동쪽으로 이 선을 통과할 때 날짜는 하루를 빼야 하며, 반대로 동쪽에서 서쪽으로 가면 하루를 늘려야 한다.
몇 개의 시간 명사:
(1) GMT: 그리니치 표준시
(2) UTC: 세계 조정 시간
(3) DST: 여름 절약 시간
(4) CST: 중국 표준 시간
그 중에서 GMT 시간은 UTC 시간과 비슷하다고 생각할 수 있지만 정밀도에서 UTC 시간은 더욱 정확하다.그 오차치는 반드시 0.9초 이내를 유지해야 한다
CST= GMT + 8 =UTC + 8
위에서 알 수 있듯이 중국의 시간은 UTC 시간+8시간과 같다. es 기본 저장 시간의 형식은 UTC 시간이다. 만약에 우리가 es를 조회하고 시간 날짜의 기본 데이터를 얻으면 현재의 시간과 8시간 차이가 나는 것을 발견할 수 있다. 이것은 사실 정상적인 것이다. es 기본 저장은 UTC 시간을 사용하기 때문에 우리가 해야 할 일은 롱형 시간 스탬프를 읽고 다음 시간 스탬프로 다시 포맷하는 것이다.정확한 시간을 얻을 수 있다

yyyy-MM-dd HH:mm:ss  

8개의 시간대 차이와 같이 가장 쉽게 볼 수 있는 것은logstash에서 수집한 로그를 사용하여es에 보내고 헤드 조회를 통해 일치하지 않는 것을 발견할 수 있다는 것이다. 그러나 만약에 우리가kibana로 조회한다면 시간대 문제를 발견하지 못할 것이다. 왜?주소를 가져오는 것은 키바나가 시간대 문제를 처리했기 때문에 키바나의 페이지에 표시된 시간이 정확합니다.또한 자바 클라이언트 집합 조회 날짜를 사용할 때 시간대 문제를 주의해야 한다. 기본적인es는 UTC 표준 시간대에 따라 계산되기 때문에 설정하지 않은 집합 통계 결과는 정확하지 않다.es의 DateHistogramBuilder에는 다음과 같은 몇 가지 중요한 매개변수가 있습니다.

field：   
interval: （ ， ， ， ， ， ， ， ）  
format：   
time_zone:   
offset：   

주의, 기본적으로 시간대 파라미터를 설정하지 않습니다.es는 UTC를 설치한 시간에 조회하는 것이기 때문에 그룹의 결과는 예상과 다를 수 있습니다. 따라서 우리는 시간대를 아시아/Shanghai가 베이징을 대표하는 시간대로 지정해야 정확한 집합 결과를 얻을 수 있습니다.
curl 방식은 다음과 같습니다.

GET my_index/_search?size=0  
{  
  "aggs": {  
    "by_day": {  
      "date_histogram": {  
        "field":     "ctime",  
        "interval":  "day",  
        "time_zone": "Asia/Shanghai"  
      }  
    }  
  }  
}  

Java 코드 검색 주소는 다음과 같습니다.

SearchRequestBuilder search = client.prepareSearch("search2017-02*").setTypes("log"); 
   DateHistogramBuilder dateagg = AggregationBuilders.dateHistogram("dateagg"); 
   dateagg.field("ctime");//  
   dateagg.interval(DateHistogramInterval.DAY);// 0 0  
   dateagg.timeZone("Asia/Shanghai");//  
   dateagg.offset("+8h");// 0 ， offset， 6 6  
   search.addAggregation(dateagg); 

   Histogram hs= search.get().getAggregations().get("dateagg"); 
   List.Bucket> buckets =   (List.Bucket>) hs.getBuckets();//  
   for(Histogram.Bucket bk:buckets){  
   // ， UTC ， ，   
       System.out.println(new DateTime(Long.parseLong(bk.getKeyAsString()+"")).toString("yyyy-MM-dd HH:mm:ss") +" "+bk.getDocCount()); 
   }  
   client.close(); 

위의 이 예는 기본적으로 날짜 집합의 핵심 기능을 포함하는데 그 중에서 시간대와 편이량을 설정할 때 두 가지 매우 유용하고 특별히 주의해야 할 매개 변수가 있다. 시간대를 설정하지 않고 직접 통계한 결과는 틀림없이 정확하지 않다. 오프셋 편이량이라는 매개 변수는 어떤 순간에도 유용하다. 이것은 하루의 시작을 스스로 정의할 수 있다. 예를 들어 첫날의 3시부터 다음날의 3시까지 하루를 설정할 수 있다.기본값은 0시부터 0시까지 하루를 계산합니다. 마지막으로 주의해야 할 것은 출력 시간을 출력할 때도 전환을 고려해야 한다는 것입니다. 기본값도 UTC의 시간이기 때문에 우리는 직접 시간 스탬프를 꺼내서 시간을 포맷하면 됩니다.
색인 시 날짜 형식의 자동 식별이 색인 데이터에 있을 때 ES는 자동으로 날짜 형식을 식별하려고 시도합니다. 기본적으로 ES는 yyy-MM-ddTHH:mm:ssZ 형식의 데이터를 날짜 형식으로 간주하고 날짜 형식으로 저장합니다. 예를 들어 "2014-08-01T03:27:33.730Z"같은 문자열은 날짜 형식으로 식별되고, "2014-08-01 12:00:00"같은 문자열은 문자열로만 식별됩니다.이것도 주의해야 할 점이다.
다음으로 전송:http://blog.csdn.net/linkedin_38160998/article/details/68951075