Cassandra выбирает запрос с проблемой часового пояса

У нас есть два разных кластера cassandra в двух разных часовых поясах.

  • Cluster1: версия 2.1.8, с IST TZ
  • Cluster2: версия 2.1.9, с UTC TZ

В кластере 1 для запроса на выборку со столбцом метки времени мне не нужно упоминать значение tz[+0530], тогда как в другом кластере я должен указать значение TZ в запросе на выборку для получения строки. Это связано с версией Кассандры?

Я использую cqlsh для выполнения части запроса. Я попробовал параметр файла cqlshrc, который меняет только формат вывода.

кластер1:

select * from test.check where row_timestamp = '1970-01-01 00:00:00';

кластер2:

select * from test.check where row_timestamp = '1970-01-01 00:00:00+0000';

ЕСЛИ TZ не упоминается, я получаю «0» строк. Я не хочу давать TZ в кластере 2, пожалуйста, посоветуйте, как это сделать.


person anand    schedule 10.12.2015    source источник


Ответы (1)


Должен признать, это немного странно, но между 2.1.8 и 2.1.9 могли быть некоторые изменения в управлении часовыми поясами. Это из списка изменений:

(cqlsh) Исправлены отметки времени до 1970 года в Windows, всегда используйте UTC для отображения отметки времени (CASSANDRA-10000)

С другой стороны, документация совершенно ясна по этому вопросу:

Если часовой пояс не указан, используется часовой пояс узла-координатора Cassandra, передающего запрос на запись. Для точности DataStax рекомендует указывать часовой пояс, а не полагаться на часовой пояс, настроенный на узлах Cassandra.

Итак, моя искренняя рекомендация — указать часовой пояс, причем указать тот же, предположительно GMT (или время UTC). Спасите себя от головной боли. Обратите внимание, GMT не совсем совпадает с UTC, есть небольшая разница в значении. Таким образом, вы должны игнорировать настройки часового пояса в кластерах. Отметка времени в конечном итоге сохраняется как количество миллисекунд (с определенной точки). Информация о часовом поясе - это чисто "рендеринг". Количество переданных миллисекунд одинаково, например, 2015/03/05 14:00:00+0100 и 2015/03/05 16:00:00+0300.

Если вы ничего не указываете и получаете 0 результатов, в то время как вы получаете результаты при использовании +0000, убедитесь, что данные, которые вы ожидаете изначально, записаны с ожидаемым часовым поясом. Возможно, из-за этого на самом деле нет никаких данных в диапазоне, или отметка времени координирующего узла отличается.

person Aleksandar Stojadinovic    schedule 10.12.2015
comment
Спасибо за это, оказалось, что это изменение версии. - person anand; 23.02.2016