Clickhouse 時區轉換
ClickHouse是一個用於聯機分析(OLAP)的列式數據庫管理系統(DBMS)。
OLAP場景的關鍵特征
- 大多數是讀請求
- 數據總是以相當大的批(> 1000 rows)進行寫入
- 不修改已添加的數據
- 每次查詢都從數據庫中讀取大量的行，但是同時又僅需要少量的列
- 寬表，即每個表包含着大量的列
- 較少的查詢(通常每台服務器每秒數百個查詢或更少)
- 對於簡單查詢，允許延遲大約50毫秒
- 列中的數據相對較小： 數字和短字符串(例如，每個URL 60個字節)
- 處理單個查詢時需要高吞吐量（每個服務器每秒高達數十億行）
- 事務不是必須的
- 對數據一致性要求低
- 每一個查詢除了一個大表外都很小
- 查詢結果明顯小於源數據，換句話說，數據被過濾或聚合后能夠被盛放在單台服務器的內存中
我們知道在mysql 進行時間的時區轉換，可以通過 CONVERT_TZ(dt,from_tz,to_tz),其中dt 是datetime 數據類型；從from_tz 時區轉換為to_tz時區，from_tz 可以是任何時區,其中數據庫默認時區是UTC
1 /*Mysql從UTC 時區轉換成 香港時區（+08:00）*/
SELECT CONVERT_TZ('2020-04-06 02:00:00','UTC','Asia/Hong_Kong') as DateTime
2020-04-06 10:00:00
2 /*Mysql從 香港時區轉換美國紐約時區 */
SELECT CONVERT_TZ('2020-04-06 02:00:00','Asia/Hong_Kong','America/New_York') as DateTime
2020-04-05 14:00:00
Clickhoue 的from_tz 是默認系統時區，比如UTC 是系統的時區：
Select toString(toDateTime('2020-04-06 02:00:00'), 'Asia/Hong_Kong') AS time_Hong_Kong
2020-04-06 10:00:00
Clickhouse 如果系統默認時間是跟from_tz 時區是一樣的，可以不寫
select toTimeZone(toDateTime('2020-04-06 02:00:00', 'UTC'), 'Asia/Hong_Kong') , toString(toDateTime('2020-04-06 02:00:00','UTC'), 'Asia/Hong_Kong') , toTimeZone(toDateTime('2020-04-06 02:00:00'), 'Asia/Hong_Kong') ,/*系統默認時間是UTC時區，可以不用寫UTC 時間*/ toString(toDateTime('2020-04-06 02:00:00'), 'Asia/Hong_Kong') ,/*系統默認時間是UTC時區，可以不用寫UTC 時間*/ toTimeZone(toDateTime('2020-04-06 02:00:00', 'America/New_York'), 'Asia/Hong_Kong') /*其中2020-04-06 02:00:00 所屬時區是America/New_York*/
通過上面的例子，大家會發現toTimeZone,與toString 的功能很像，其實我們通過toTypeName這個函數就可以知道它們的區別
select toTypeName(toTimeZone(toDateTime('2020-04-06 02:00:00', 'UTC'), 'Asia/Hong_Kong')) , toTypeName(toString(toDateTime('2020-04-06 02:00:00','UTC'), 'Asia/Hong_Kong')) , toTypeName(formatDateTime(toTimeZone(toDateTime('2020-04-06 02:00:00', 'UTC'), 'Asia/Hong_Kong'),'%F %T')) ;
嘻嘻，運行一下上面的代碼，你就會知道了。
toTimeZone函數還是比較強大，通過可以實現時區轉換，通過toTypeName還可以獲知字段類型，以及該字段對應的時區。