ElasticSearch Дата Поле Mapping Пороки

Question

В моей ElasticHQ отображения:

@timestamp date yyyy-MM-dd HH:mm:ssZZZ 
... 
date date yyyy-MM-dd HH:mm:ssZZZ 

В вышеприведенном у меня есть два типа поля даты каждого с отображением в том же формате.

В данных:

"@timestamp": "2014-05-21 23:22:47UTC" 
.... 
"date": "2014-05-22 05:08:09-0400", 

Как и выше, формат даты не отображает того, что думает ES У меня есть мои даты в формате. Я предполагаю, что в индексное время произошло что-то странное (меня не было).

Также интересно: При использовании запроса отфильтрованный диапазон как следующий, я получаю Разбор Exception поясняя, что моя дата слишком коротка:

GET _search 
{ 
    "query": { 
     "filtered": { 
      "query": { 
      "match_all": {} 
      }, 
      "filter": { 
       "range": { 
       "date": { 
        "from": "2013-11-23 07:00:29", 
        "to": "2015-11-23 07:00:29", 
        "time_zone": "+04:00" 
       } 
       } 
      } 
     } 
    } 
} 

Но поиск с проверкой ошибок следующих проходов ЭС, но не возвращает результаты, я предполагаю, из-за форматирования даты в документах.

GET _search 
{ 
    "query": { 
     "filtered": { 
      "query": { 
      "match_all": {} 
      }, 
      "filter": { 
       "range": { 
       "date": { 
        "from": "2013-11-23 07:00:29UTC", 
        "to": "2015-11-23 07:00:29UTC", 
        "time_zone": "+04:00" 
       } 
       } 
      } 
     } 
    } 
} 

Мой вопрос заключается в следующем: с учетом вышесказанного, есть ли способ, мы можем избежать того, чтобы Переиндексирование и изменить отображение и продолжают искать искаженные данные? У нас есть около 1 Тбайт данных в этом конкретном кластере и хотелось бы сохранить его, как есть, по понятным причинам.

также попытался был запрос, который прилипает к тому, что в данных:

"query": { 
    "range": { 
     "date": { 
     "gte": "2014-05-22 05:08:09-0400", 
     "to": "2015-05-22 05:08:09-0400" 
     } 
    } 
} 

Answer 1

Даты вы имеете в ваших документах на самом деле соответствовать формату даты, вы имеете в своем отображении, т.е. yyyy-MM-dd HH:mm:ssZZZ

В форматах формата даты ZZZ обозначает часовой пояс RFC 822 (например, -04: 00, +04: 00, EST, UTC, GMT, ...), поэтому даты, которые у вас есть в ваших данных, соответствуют друг другу, t были проиндексированы в первую очередь.

Однако наилучшей практикой является то, чтобы даты всегда были преобразованы в UTC (или любой другой часовой пояс, общий для всей базы документов, который имеет смысл в вашем контексте) перед их индексацией, так что у вас есть общая основа для запроса.

Что касается вашего запроса, который вызывает ошибки, 2013-11-23 07:00:29 не соответствует формату даты, так как в конце отсутствует часовой пояс. Как вы правильно поняли, добавление UTC в конец устраняет проблему синтаксического анализа запроса (т. Е. Недостающую часть ZZZ), но вы все равно не получите никаких результатов.

Теперь, чтобы ответить на ваш вопрос, у вас есть две основные задачи сделать:

1. Fix ваш процесс индексирования/компонент, чтобы убедиться, что все даты в общей часовой пояс (обычно UTC)
2. исправить вашу существующие данные для преобразования дат в индексированных документах в один и тот же часовой пояс

1TB - это много данных для переиндексации для фиксации одного или двух полей. Я не знаю, как выглядят ваши документы, но это не имеет большого значения.То, как я бы подойти к решению проблемы было бы запустить частичное обновление всех документов, и для этого, я вижу два разных решения, в обоих из которых идея заключается в том, чтобы просто исправить @timestamp и date поля:

1. В зависимости от вашей версии ES вы можете использовать update-by-query plugin, но преобразование даты через скрипт немного громоздко.
2. Или вы можете написать клиент adhoc, который будет scroll по всем существующим документам и partial update каждому из них и отправить их обратно in bulk.

Учитывая объем данных, которые у вас есть, решение 2 представляется более подходящим.

Итак ... Ваш АПЧРК скрипт должен первым выдать запрос прокрутки, чтобы получить прокрутки идентификатор вроде этого:

curl -XGET 'server:9200/your_index/_search?search_type=scan&scroll=1m' -d '{ 
    "query": { "match_all": {}}, 
    "size": 1000 
}' 

Как результат, вы получите идентификатор прокрутки, что теперь вы можете использовать для итерации за все ваши данные с

curl -XGET 'server:9200/_search/scroll?_source=date,@timestamp&scroll=1m' -d 'your_scroll_id' 

вы получите 1000 хитов (вы можете отключить/увеличить параметр size в первом запросе выше в зависимости от вашего пробега), что теперь вы можете итерации по.

Для каждого попадания вы получите только два поля даты, которые необходимо исправить. Затем вы можете преобразовать свои даты в стандартный часовой пояс по вашему выбору, например, с помощью solution like this.

Наконец, вы можете отправить 1000 обновленные частичные документы в одном объеме, как это:

curl -XPOST server:9200/_bulk -d ' 
{ "update" : {"_id" : "1", "_type" : "your_type", "_index" : "your_index"} } 
{ "doc" : {"date" : "2013-11-23 07:00:29Z", "@timestamp": "2013-11-23 07:00:29Z"} } 
{ "update" : {"_id" : "2", "_type" : "your_type", "_index" : "your_index"} } 
{ "doc" : {"date" : "2014-09-12 06:00:29Z", "@timestamp": "2014-09-12 06:00:29Z"} } 
... 
' 

полоскание и повторить со следующей итерации ...

Я надеюсь, что это должно дать вам некоторые начальные указатели для начала. Дайте нам знать, если у вас есть какие-либо вопросы.