FAQ
本頁面討論了經常容易混淆的內容,以及跟其它數據庫系統相比TSDB For InfluxDB?以意想不到的方式運行的地方。
管理(Administration)
如何識別TSDB For InfluxDB?的版本?
shard group duration和保留策略之間的關系是什么?
當更改保留策略后,為什么數據沒有丟失?
為什么TSDB For InfluxDB?無法解析微秒單位?
命令行界面(CLI)
如何使TSDB For InfluxDB?的CLI返回用戶可讀的時間戳?
非admin用戶如何使用
USE
指定一個數據庫?如何使用TSDB For InfluxDB?的CLI將數據寫入一個非默認的保留策略
數據類型
為什么不能查詢布爾類型的field value?
TSDB For InfluxDB?如何處理多個shard之間的field的類型差異?
TSDB For InfluxDB?可以存儲的最小和最大整數是多少?
TSDB For InfluxDB?可以存儲的最小和最大時間戳是多少?
如何知道存儲在field中的數據類型?
是否可以改變field的數據類型?
InfluxQL函數
如何執行函數中的數學運算?
為什么查詢將epoch 0作為時間戳返回?
哪些InfluxQL函數支持嵌套使用?
查詢數據
什么決定了
GROUP BY time()
查詢返回的時間間隔?為什么查詢沒有返回任何數據或者只返回一部分數據?
為什么
GROUP BY time()
查詢不返回發生在now()
之后的時間戳?是否可以對時間戳執行數學運算?
是否可以從返回的時間戳中識別寫入精度?
當查詢數據時,什么時候應該使用單引號,什么時候應該使用雙引號?
為什么在創建一個新的默認(
DEFAULT
)保留策略后會丟失數據?為什么帶有
WHERE OR
時間子句的查詢返回空結果?為什么
fill(previous)
返回空結果?為什么
INTO
查詢會丟失數據?如何查詢tag key和field key名字相同的數據?
如何跨measurement查詢數據?
時間戳的順序是否重要?
如何
SELECT
有tag但沒有tag value的數據?
序列和序列基數
為什么序列基數很重要?
寫入數據
如何寫入整型的field value?
TSDB For InfluxDB?如何處理重復數據點?
HTTP API需要怎樣的換行符?
當將數據寫入TSDB For InfluxDB?時,應該避免哪些文字和字符?
當寫入數據時,什么時候應該使用單引號,什么時候應該使用雙引號?
時間戳的精度是否重要?
如何識別TSDB For InfluxDB?的版本?
有多種方法可以識別您正在使用的TSDB For InfluxDB?版本:
curl路徑/ping
$ curl -i 'https://<網絡地址>:3242/ping?u=<賬號名稱>&p=<密碼>'
HTTP/1.1204NoContent
Content-Type: application/json
X-Influxdb-Build: OSS
X-Influxdb-Version:1.7.x
啟動TSDB For InfluxDB?的命令行界面:
$ influx -ssl -username <賬號名稱>-password <密碼>-host <網絡地址>-port 3242
Connected to https://<網絡地址>:3242 version 1.7.x
shard group duration和保留策略之間的關系是什么?
TSDB For InfluxDB?將數據存儲在shard group。一個shard group覆蓋一個特定的時間間隔;TSDB For InfluxDB?通過查看相關保留策略的DURATION
來確定時間間隔。下表列出了RP的DURATION
和一個shard group的時間間隔之間的默認關系:
RP持續時間(duration) | Shard group時間間隔 |
---|---|
< 2 days | 1 hour |
>= 2 days and <= 6 months | 1 day |
> 6 months | 7 days |
使用SHOW RETENTION POLICIES
查看保留策略的shard group duration。
當更改保留策略后,為什么數據沒有丟失?
有幾個原因可以解釋為什么保留策略改變后數據沒有馬上丟失。
第一個也是最有可能的原因是,默認情況下,TSDB For InfluxDB?每30分鐘檢查并強制執行一次RP。您可能需要等到下一次RP檢查,TSDB For InfluxDB?才能刪除在RP的新DURATION
之外的數據。
第二個可能的原因是,更改RP的DURATION
和SHARD DURATION
會導致意外的數據保留。TSDB For InfluxDB?將數據存儲在shard group,每個shard group覆蓋一個特定的RP和時間間隔。當TSDB For InfluxDB?強制執行RP時,整個shard group的數據會被刪除,而不是單個數據點。TSDB For InfluxDB?不能拆分shard group。
如果RP的新DURATION
小于舊的SHARD DURATION
,并且TSDB For InfluxDB?正在將數據寫入一個舊的、DURATION
較長的shard group,那么系統將強制把所有數據存儲在該shard group中,即使該shard group中有些數據已經在新的DURATION
之外。一旦shard group中所有數據都在新的DURATION
之外,TSDB For InfluxDB?將會刪除整個shard group,然后系統開始將數據寫入具有新的、更短SHARD DURATION
的shard group,避免進一步意想不到的數據保留。
為什么TSDB For InfluxDB?無法解析微秒單位?
在不同場景下:寫入、查詢以及在TSDB For InfluxDB?命令行界面(CLI)設置精度,用于指定微秒時間單位的語法也不同。下表顯示了每個類別支持的語法:
使用HTTP API寫入數據 | 所有查詢 | 在CLI設置精度 | |
---|---|---|---|
u | √ | √ | √ |
us | ? | ? | ? |
μ | ? | √ | ? |
μs | ? | ? | ? |
如何使TSDB For InfluxDB?的CLI返回用戶可讀的時間戳?
在您首次連接CLI時,請指定rfc3339精度:
$ influx -ssl -username <賬號名稱>-password <密碼>-host <網絡地址>-port 3242-precision rfc3339
或者,在連接CLI后指定精度:
$ influx -ssl -username <賬號名稱>-password <密碼>-host <網絡地址>-port 3242
Connected to https://<網絡地址>:3242 version 1.7.x
> precision rfc3339
>
請查看文檔命令行界面了解更多有用的CLI選項。
非admin用戶如何使用USE
指定一個數據庫?
如果非admin用戶擁有數據庫的READ
和/或WRITE
權限,那么可以執行USE <database_name>
語句。如果非admin用戶嘗試用USE
指定一個他們沒有READ
和/或WRITE
權限的數據庫,那么系統會返回錯誤:
ERR:Database<database_name> doesn't exist. Run SHOW DATABASES for a list of existing databases.
SHOW DATABASES查詢只返回那些非admin用戶有READ或WRITE權限的數據庫。
如何使用TSDB For InfluxDB?的CLI將數據寫入一個非默認的保留策略
請使用語法INSERT INTO [<database>.]<retention_policy> <line_protocol>
將數據寫入一個非默認的保留策略。(只允許在CLI中使用這種方式指定數據庫和保留策略。如果通過HTTP寫入數據,必須使用參數db
和rp
分別指定數據庫和保留策略,指定保留策略是可選的。)
示例:
> INSERT INTO one_day mortality bool=true
Using retention policy one_day
> SELECT * FROM "mydb"."one_day"."mortality"
name: mortality
---------------
time bool
2016-09-13T22:29:43.229530864Z true
請注意,您需要完全限定measurement來查詢非默認保留策略中的數據。使用以下語法完全限定measurement:
"<database>"."<retention_policy>"."<measurement>"
為什么不能查詢布爾類型的field value?
寫入和查詢布爾值的語法不一樣。
布爾值語法 | 寫入 | 查詢 |
---|---|---|
| √ | ? |
| √ | ? |
| √ | √ |
| √ | √ |
| √ | √ |
例如,SELECT * FROM "hamlet" WHERE "bool"=True
返回所有bool
等于TRUE
的數據點,但是,SELECT * FROM "hamlet" WHERE "bool"=T
不會返回任何結果。
TSDB For InfluxDB?如何處理多個shard之間的field的類型差異?
field value可以是浮點數、整數、字符串或者布爾值。在一個shard里面,field value的數據類型不能不一樣,但是在不同的shard,field value的數據類型可以不同。
SELECT語句
SELECT
語句返回所有的field value如果這些值有相同的數據類型。如果在不同的shard里面field value的數據類型不一樣,那么TSDB For InfluxDB?首先會執行類型轉換(如果適用的話),然后返回所有值,并且按以下數據類型的順序返回結果:浮點數,整數,字符串,布爾值。
如果在您的數據中,field value的類型不同,請使用語法<field_key>::<type>
查詢不同的數據類型。
示例
measurement just_my_type
有一個名為my_field
的field,my_field
在四個不同的shard中有四個field value,并且每個field value的數據類型不一樣(分別是浮點數、整數、字符串和布爾值)。
SELECT *
只返回浮點型和整型的field value。請注意,在返回結果中TSDB For InfluxDB?強制將整數轉換成浮點數。
> SELECT * FROM just_my_type
name: just_my_type
------------------
time my_field
2016-06-03T15:45:00Z9.87034
2016-06-03T16:45:00Z7
SELECT <field_key>::<type> [...]
返回所有數據類型。TSDB For InfluxDB?將每種類型的數據輸出到單獨的列中,并且使用遞增的列名表示。在可能的情況下,TSDB For InfluxDB?將field value轉換成另一種數據類型;它將整數7
轉換成第一列中的浮點數,將浮點數9.879034
轉換成第二列中的整數。TSDB For InfluxDB?不能將浮點數或整數轉換成字符串或布爾值。
> SELECT "my_field"::float,"my_field"::integer,"my_field"::string,"my_field"::boolean FROM just_my_type
name: just_my_type
------------------
time my_field my_field_1 my_field_2 my_field_3
2016-06-03T15:45:00Z9.870349
2016-06-03T16:45:00Z77
2016-06-03T17:45:00Z a string
2016-06-03T18:45:00Z true
SHOW FIELD KEYS查詢
SHOW FIELD KEYS
返回field key對應的每個shard中的每種數據類型。
示例
measurement just_my_type
有一個名為my_field
的field,my_field
在四個不同的shard中有四個field value,并且每個field value的數據類型不一樣(分別是浮點數、整數、字符串和布爾值)。
SHOW FIELD KEYS
返回所有四種數據類型:
> SHOW FIELD KEYS
name: just_my_type
fieldKey fieldType
-----------------
my_field float
my_field string
my_field integer
my_field boolean
TSDB For InfluxDB?可以存儲的最小和最大整數是多少?
TSDB For InfluxDB?將所有整數存儲為有符號的int64數據類型。int64有效的最小和最大值分別是-9023372036854775808
和9023372036854775807
。請查看Go builtins獲得更多相關信息。
使用接近最小/最大整數但依舊在限制范圍內的值可能會導致非預期的結果;有些函數和運算符會在計算過程中將數據類型int64轉換成float64,這會引起溢出問題。
TSDB For InfluxDB?可以存儲的最小和最大時間戳是多少?
最小的時間戳是-9223372036854775806
或1677-09-21T00:12:43.145224194Z
,最大的時間戳是9223372036854775806
或2262-04-11T23:47:16.854775806Z
。超出該范圍的時間戳會返回解析錯誤。
如何知道存儲在field中的數據類型?
SHOW FIELD KEYS
查詢還返回field的數據類型。
示例
> SHOW FIELD KEYS FROM all_the_types
name: all_the_types
-------------------
fieldKey fieldType
blue string
green boolean
orange integer
yellow float
是否可以改變field的數據類型?
目前,在改變field的數據類型上面,TSDB For InfluxDB?提供非常有限的支持。語法<field_key>::<type>
支持將field value從整數轉換為浮點數或者從浮點數轉換為整數。請查看文檔數據探索獲得更多關于轉換操作的信息。無法將浮點數或整數轉換為字符串或布爾值(反之亦然)。
我們列出了可用于更改field數據類型的方法:
將數據寫入一個不同的field
最簡單的解決方法就是將具有新數據類型的數據寫入到同一個序列中的不同field。
使用shard系統
在一個shard里面,field value的數據類型不能不一樣,但是在不同的shard,field value的數據類型可以不同。
如果要更改field的數據類型,用戶可以使用SHOW SHARDS
查詢來識別當前shard的end_time
。如果數據點的時間戳發生在end_time
之后,那么TSDB For InfluxDB?允許將不同數據類型的數據寫入到一個現有的field中(例如,field原來接受整數,但是在end_time
之后,該field可以接受浮點數)。
請注意,這不會改變原來shard里面field的數據類型。
如何執行函數中的數學運算?
目前,TSDB For InfluxDB?不支持函數內的數學運算。我們建議使用子查詢作為解決方法。
示例
InfluxQL不支持以下語法:
SELECT MEAN("dogs"-"cats")from"pet_daycare"
相反,我們可以使用子查詢獲得相同的結果:
> SELECT MEAN("difference") FROM (SELECT "dogs"-"cat" AS "difference" FROM "pet_daycare")
請查看文檔數據探索獲得更多關于子查詢的信息。
為什么查詢將epoch 0作為時間戳返回?
在TSDB For InfluxDB?中,epoch 0(1970-01-01T00:00:00Z
)通常用作空時間戳(null timestamp),如果您請求的查詢中沒有時間戳返回,例如,對于沒有規定時間范圍的聚合函數,TSDB For InfluxDB?返回epoch 0作為時間戳。
哪些InfluxQL函數支持嵌套使用?
以下InfluxQL函數支持嵌套使用:
COUNT()
嵌套DISTINCT()
CUMULATIVE_SUM()
DERIVATIVE()
DIFFERENCE()
ELAPSED()
MOVING_AVERAGE()
NON_NEGATIVE_DERIVATIVE()
HOLT_WINTERS()
和HOLT_WINTERS_WITH_FIT()
關于如何使用子查詢代替嵌套函數,請查看文檔數據探索。
什么決定了GROUP BY time()
查詢返回的時間間隔?
GROUP BY time()
查詢返回的時間間隔符合TSDB For InfluxDB?的預設時間段或者符合用戶指定的偏移間隔。
示例
預設時間段
以下查詢計算sunflowers
在6:15pm到7:45pm之間的平均值,并將這些平均值按一小時進行分組:
SELECT mean("sunflowers")
FROM "flower_orders"
WHERE time >='2016-08-29T18:15:00Z' AND time <='2016-08-29T19:45:00Z' GROUP BY time(1h)
下面的結果展示了TSDB For InfluxDB?如何維護它的預設時間段。
在這個示例中,6pm是一個預設的時間段,7pm也是一個預設的時間段。由于WHERE
子句中指定了查詢的時間范圍,所以在計算6pm時間段對應的平均值時不包括在6:15pm之前的數據,但是用于計算6pm時間段平均值的數據必須發生在6pm這個小時里。對于7pm時間段也是一樣;用于計算7pm時間段平均值的數據必須發生在7pm這個小時里。虛線部分展示了用于計算每個平均值的數據點。
請注意,雖然結果中第一個時間戳是2016-08-29T18:00:00Z
,但是在該時間段的查詢結果不包含發生在2016-08-29T18:15:00Z
(WHERE
子句中指定的開始時間)之前的數據。
原始數據: 結果:
name: flower_orders name: flower_orders
—————————-------------------
time sunflowers time mean
2016-08-29T18:00:00Z342016-08-29T18:00:00Z22.332
|--|2016-08-29T19:00:00Z62.75
2016-08-29T18:15:00Z|28|
2016-08-29T18:30:00Z|19|
2016-08-29T18:45:00Z|20|
|--|
|--|
2016-08-29T19:00:00Z|56|
2016-08-29T19:15:00Z|76|
2016-08-29T19:30:00Z|29|
2016-08-29T19:45:00Z|90|
|--|
2016-08-29T20:00:00Z70
偏移間隔
以下查詢計算sunflowers
在6:15pm到7:45pm之間的平均值,并將這些平均值按一小時進行分組,同時,該查詢還將TSDB For InfluxDB?的預設時間段偏移15
分鐘:
SELECT mean("sunflowers")
FROM "flower_orders"
WHERE time >='2016-08-29T18:15:00Z' AND time <='2016-08-29T19:45:00Z' GROUP BY time(1h,15m)
---
|
offset interval
在這個示例中,用戶指定的偏移間隔將TSDB For InfluxDB?的預設時間段前移了15
分鐘?,F在,6pm時間段的平均值包括在6:15pm和7:15pm之間的數據,7pm時間段的平均值包括在7:15pm和8:15pm之間的數據。虛線部分展示了用于計算每個平均值的數據點。
請注意,現在結果中第一個時間戳是2016-08-29T18:15:00Z
,而不是2016-08-29T18:00:00Z
。
原始數據: 結果:
name: flower_orders name: flower_orders
—————————-------------------
time sunflowers time mean
2016-08-29T18:00:00Z342016-08-29T18:15:00Z30.75
|--|2016-08-29T19:15:00Z65
2016-08-29T18:15:00Z|28|
2016-08-29T18:30:00Z|19|
2016-08-29T18:45:00Z|20|
2016-08-29T19:00:00Z|56|
|--|
|--|
2016-08-29T19:15:00Z|76|
2016-08-29T19:30:00Z|29|
2016-08-29T19:45:00Z|90|
2016-08-29T20:00:00Z|70|
|--|
為什么查詢沒有返回任何數據或者只返回一部分數據?
對于為什么查詢沒有返回任何數據或者只返回一部分數據,有幾種可能的解釋。我們在下面列出了一些最常見的原因:
保留策略
第一個也是最常見的解釋與保留策略(RP)有關。TSDB For InfluxDB?自動從數據庫的默認(DEFAULT
)RP中查詢數據。如果您的數據不是存儲在默認的RP,TSDB For InfluxDB?不會返回任何結果,除非您明確指定所使用的RP。
SELECT子句中的tag key
在SELECT
子句中,至少需要包含一個field key,查詢才會返回數據。如果SELECT
子句只包含一個或多個tag key,查詢會返回空的結果。請查看文檔數據探索獲得更多相關信息。
查詢時間范圍
另一個可能的解釋與查詢的時間范圍有關。默認情況下,大多數SELECT
查詢涵蓋在1677-09-21 00:12:43.145224194
UTC和2262-04-11T23:47:16.854775806Z
UTC之間的時間范圍。SELECT
查詢還包括GROUP BY time()
子句,但是,它涵蓋的時間范圍在1677-09-21 00:12:43.145224194
和now()
之間。如果您的數據發生在now()
之后,那么GROUP BY time()
查詢不會覆蓋這些發生在now()
之后的數據。如果查詢語句包括GROUP BY time()
子句,并且有數據發生在now()
之后,您需要為時間范圍提供一個上限。
標識符名字
最后一個常見的解釋與schema有關(field和tag有相同的名字)。如果field key和tag key相同,那么在所有查詢中優先考慮field。在查詢中,你需要使用::tag
語法指定tag key。
為什么GROUP BY time()
查詢不返回發生在now()
之后的時間戳?
大多數SELECT
語句的默認時間范圍在1677-09-21 00:12:43.145224194 UTC
和2262-04-11T23:47:16.854775806Z UTC
之間。對于帶GROUP BY time()
子句的SELECT
語句,默認的時間范圍在1677-09-21 00:12:43.145224194
和now()
之間。
如果要查詢時間戳發生在now()
之后的數據,帶GROUP BY time()
子句的SELECT
語句必須在WHERE
子句中提供一個時間上限。
在下面的示例中,第一個查詢涵蓋時間戳在2015-09-18T21:30:00Z
和now()
之間的數據,第二個查詢涵蓋時間戳在2015-09-18T21:30:00Z
和now()
之后180個星期之間的數據。
> SELECT MEAN("boards") FROM "hillvalley" WHERE time >='2015-09-18T21:30:00Z' GROUP BY time(12m) fill(none)
> SELECT MEAN("boards") FROM "hillvalley" WHERE time >='2015-09-18T21:30:00Z' AND time <= now()+180w GROUP BY time(12m) fill(none)
請注意,WHERE
子句必須提供一個時間上線來覆蓋默認的now()
上限。下面的查詢只是將now()
的下限重置,使得查詢的時間范圍在now()
和now()
之間:
> SELECT MEAN("boards") FROM "hillvalley" WHERE time >= now() GROUP BY time(12m) fill(none)
>
請查看文檔數據探索獲得更多關于時間語法的信息。
是否可以對時間戳執行數學運算?
目前,在TSDB For InfluxDB?中,不能對時間戳執行數學運算。更多關于時間的計算必須由接收查詢結果的客戶端執行。
對時間戳使用InfluxQL函數,TSDB For InfluxDB?僅提供有限的支持。ELAPSED()函數返回單個field中時間戳之間的差值。
是否可以從返回的時間戳中識別寫入精度?
不管提供的寫入精度是多少,TSDB For InfluxDB?將所有時間戳存儲為納秒。需要注意的一個重要事項是,當返回查詢結果時,數據庫會不動聲色地刪除時間戳后面的零,使原始的寫入精度很難識別。
在下面的示例中,tag precision_supplied
和timestamp_supplied
分別顯示了用戶在寫入數據時提供的時間精度和時間戳。因為TSDB For InfluxDB?默默地將返回的時間戳后面的零刪除了,所以從返回的時間戳中很難識別寫入精度。
name: trails
-------------
time value precision_supplied timestamp_supplied
1970-01-01T01:00:00Z3 n 3600000000000
1970-01-01T01:00:00Z5 h 1
1970-01-01T02:00:00Z4 n 7200000000000
1970-01-01T02:00:00Z6 h 2
當查詢數據時,什么時候應該使用單引號,什么時候應該使用雙引號?
用單引號將字符串類型的值括起來(例如,tag value),但是不要用單引號將標識符(數據庫名字、保留策略名字、用戶名、measurement的名字、tag key和field key)括起來。
如果標識符以數字開頭,或包含除[A-z,0-9,_]
外的字符,或者標識符是InfluxQL關鍵字,那么需要使用雙引號將標識符括起來。如果標識符不屬于這些類別之一,可以不需要使用雙引號將它們括起來,但是我們還是建議用雙引號將它們括起來。
示例:
合法的查詢:SELECT bikes_available FROM bikes WHERE station_id='9'
合法的查詢:SELECT "bikes_available" FROM "bikes" WHERE "station_id"='9'
合法的查詢:SELECT MIN("avgrq-sz") AS "min_avgrq-sz" FROM telegraf
合法的查詢:SELECT * from "cr@zy" where "p^e"='2'
非法的查詢:SELECT 'bikes_available' FROM 'bikes' WHERE 'station_id'="9"
非法的查詢:SELECT * from cr@zy where p^e='2'
用單引號將日期時間字符串括起來。如果您使用雙引號將日期時間字符串括起來,TSDB For InfluxDB?會返回錯誤(ERR: invalid operation: time and *influxql.VarRef are not compatible
)。
示例:
合法的查詢:SELECT "water_level" FROM "h2o_feet" WHERE time > '2015-08-18T23:00:01.232000000Z' AND time < '2015-09-19'
非法的查詢:SELECT "water_level" FROM "h2o_feet" WHERE time > "2015-08-18T23:00:01.232000000Z" AND time < "2015-09-19"
請查看文檔數據探索獲得更多關于時間語法的信息。
為什么在創建一個新的默認(DEFAULT
)保留策略后會丟失數據?
當您在數據庫中創建一個新的默認保留策略(RP)后,在舊的默認RP中的數據依舊保存在舊的RP中。對于不指定RP的查詢,將會自動查詢新默認RP中的數據,所有舊數據可能會丟失。為了查詢舊數據,必須完全限定查詢中的數據。
示例:
在measurement fleeting
中的所有數據屬于默認的RP,該RP的名字為one_hour
:
> SELECT count(flounders) FROM fleeting
name: fleeting
--------------
time count
1970-01-01T00:00:00Z8
現在我們創建一個新的默認RP(two_hour
),并執行相同的查詢:
> SELECT count(flounders) FROM fleeting
>
為了查詢舊數據,我們必須通過完全限定fleeting
來指定舊的默認RP:
> SELECT count(flounders) FROM fish.one_hour.fleeting
name: fleeting
--------------
time count
1970-01-01T00:00:00Z8
為什么帶有WHERE OR
時間子句的查詢返回空結果?
目前,TSDB For InfluxDB?不支持在WHERE
子句中使用OR
來指定多個時間范圍。如果查詢中的WHERE
子句使用OR
來指定多個時間范圍,那么TSDB For InfluxDB?不會返回任何結果。
示例:
> SELECT * FROM "absolutismus" WHERE time ='2016-07-31T20:07:00Z' OR time ='2016-07-31T23:07:17Z'
>
為什么fill(previous)
返回空結果?
如果前一個值在查詢的時間范圍之外,那么fill(previous)
不會填充該時間段的值。
在下面的示例中,TSDB For InfluxDB?不會使用時間段2016-07-12T16:50:00Z
-2016-07-12T16:50:10Z
的值填充時間段2016-07-12T16:50:20Z
-2016-07-12T16:50:30Z
,因為該查詢的時間范圍并不包含較早的時間段。
原始數據:
> SELECT * FROM "cupcakes"
name: cupcakes
--------------
time chocolate
2016-07-12T16:50:00Z3
2016-07-12T16:50:10Z2
2016-07-12T16:50:40Z12
2016-07-12T16:50:50Z11
GROUP BY time()
查詢:
> SELECT max("chocolate") FROM "cupcakes" WHERE time >='2016-07-12T16:50:20Z' AND time <='2016-07-12T16:51:10Z' GROUP BY time(20s) fill(previous)
name: cupcakes
--------------
time max
2016-07-12T16:50:20Z
2016-07-12T16:50:40Z12
2016-07-12T16:51:00Z12
為什么INTO
查詢會丟失數據?
默認情況下,INTO
查詢將原始數據中的tag轉換成新寫入數據的field。這會導致TSDB For InfluxDB?覆蓋之前由tag區分的數據點。在所有INTO
查詢中加上GROUP BY *
,可以將tag保留在新寫入的數據中。
請注意,這種方式不適用于使用TOP()
或BOTTOM()
函數的查詢。請查看文檔InfluxDB函數獲得更多關于TOP()
和BOTTOM()
的信息。
示例
原始數據
measurement french_bulldogs
包含一個tag color
和一個field name
。
> SELECT * FROM "french_bulldogs"
name: french_bulldogs
---------------------
time color name
2016-05-25T00:05:00Z peach nugget
2016-05-25T00:05:00Z grey rumple
2016-05-25T00:10:00Z black prince
不使用GROUP BY *的INTO查詢
不使用GROUP BY *
子句的INTO
查詢將tag color
轉換成新寫入數據中的field。在原始數據中,數據點nugget
和rumple
僅由tag color
區分。一旦color
變成field,TSDB For InfluxDB?會認為數據點nugget
和rumple
是重復的,它會用數據點rumple
將數據點nugget
覆蓋。
> SELECT * INTO "all_dogs" FROM "french_bulldogs"
name: result
------------
time written
1970-01-01T00:00:00Z3
> SELECT * FROM "all_dogs"
name: all_dogs
--------------
time color name
2016-05-25T00:05:00Z grey rumple <---- no more nugget
2016-05-25T00:10:00Z black prince
使用GROUP BY *的INTO查詢
使用GROUP BY *
子句的INTO
查詢將tag color
保留在新寫入的數據中。在這種情況下,數據點nugget
和rumple
依舊是不同的數據點,TSDB For InfluxDB?不會覆蓋任何數據。
> SELECT "name" INTO "all_dogs" FROM "french_bulldogs" GROUP BY *
name: result
------------
time written
1970-01-01T00:00:00Z3
> SELECT * FROM "all_dogs"
name: all_dogs
--------------
time color name
2016-05-25T00:05:00Z peach nugget
2016-05-25T00:05:00Z grey rumple
2016-05-25T00:10:00Z black prince
如何查詢tag key和field key名字相同的數據?
使用語法::
指定一個key是field key還是tag key。
示例
示例數據:
> INSERT candied,almonds=true almonds=50,half_almonds=511465317610000000000
> INSERT candied,almonds=true almonds=55,half_almonds=561465317620000000000
> SELECT * FROM "candied"
name: candied
-------------
time almonds almonds_1 half_almonds
2016-06-07T16:40:10Z50 true 51
2016-06-07T16:40:20Z55 true 56
指定key是field:
> SELECT * FROM "candied" WHERE "almonds"::field >51
name: candied
-------------
time almonds almonds_1 half_almonds
2016-06-07T16:40:20Z55 true 56
指定key是tag:
> SELECT * FROM "candied" WHERE "almonds"::tag='true'
name: candied
-------------
time almonds almonds_1 half_almonds
2016-06-07T16:40:10Z50 true 51
2016-06-07T16:40:20Z55 true 56
如何跨measurement查詢數據?
目前,無法跨measurement執行數學運算或分組。所有數據必須在同一個measurement下,才能一起查詢這些數據。TSDB For InfluxDB?不是一個關系型數據庫,跨measurement映射數據目前不是一個推薦的schema。
時間戳的順序是否重要?
不重要。測試結果表明TSDB For InfluxDB?完成以下查詢所需的時間差別非常小:
SELECT ... FROM ... WHERE time >'timestamp1' AND time <'timestamp2'
SELECT ... FROM ... WHERE time <'timestamp2' AND time >'timestamp1'
如何SELECT
有tag但沒有tag value的數據?
使用''
指定一個空的tag value。例如:
> SELECT * FROM "vases" WHERE priceless=''
name: vases
-----------
time origin priceless
2016-07-20T18:42:00Z8
為什么序列基數很重要?
TSDB For InfluxDB?維護系統中每個序列在內存中的索引。隨著序列數量不斷增加,RAM(內存)使用量也在不斷增加。序列基數過大會導致操作系統終止TSDB For InfluxDB?進程,并拋出內存不足(OOM)異常。請查看文檔InfluxQL參考了解關于序列基數的InfluxQL命令。
如何寫入整型的field value?
當寫入整數時,在field value末尾加上i
。如果您不加上i
,TSDB For InfluxDB?會把field value當作浮點數。
寫入整數:value=100i
寫入浮點數:value=100
TSDB For InfluxDB?如何處理重復數據點?
measurement的名字、tag set和時間戳唯一標識一個數據點。如果您提交的數據點跟已有的數據點相比,具有相同measurement、tag set和時間戳,但具有不同field set,那么該數據點的field set會變為舊field set和新field set的并集,如果有任何沖突以新field set為準。這是預期的結果。
例如:
舊數據點:cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000
新數據點:cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000000
當您提交新數據點后,TSDB For InfluxDB?使用新的field value覆蓋val_1
的值,val_2
的值繼續保留:
> SELECT * FROM "cpu_load" WHERE time =1234567890000000
name: cpu_load
--------------
time az hostname val_1 val_2
1970-01-15T06:56:07.89Z us_west server02 5.247
為了存儲這兩個數據點,可以:
引入新的tag保證唯一性。
舊數據點:
cpu_load,hostname=server02,az=us_west,uniq=1 val_1=24.5,val_2=7 1234567890000000
新數據點:
cpu_load,hostname=server02,az=us_west,uniq=2 val_1=5.24 1234567890000000
將新數據點寫入TSDB For InfluxDB?后:
> SELECT * FROM "cpu_load" WHERE time =1234567890000000
name: cpu_load
--------------
time az hostname uniq val_1 val_2
1970-01-15T06:56:07.89Z us_west server02 124.57
1970-01-15T06:56:07.89Z us_west server02 25.24
時間戳增加一納秒。
舊數據點:
cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000
新數據點:
cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000001
將新數據點寫入TSDB For InfluxDB?后:
> SELECT * FROM "cpu_load" WHERE time >=1234567890000000 and time <=1234567890000001
name: cpu_load
--------------
time az hostname val_1 val_2
1970-01-15T06:56:07.89Z us_west server02 24.57
1970-01-15T06:56:07.890000001Z us_west server02 5.24
HTTP API需要怎樣的換行符?
TSDB For InfluxDB?的行協議依賴換行符(\n
,這是ASCII 0x0A
)來表示一行的結束和新的一行的開始。文件或數據使用\n
以外的換行符會導致以下錯誤:bad timestamp
, unable to parse
。
請注意,Windows使用回車鍵和換行符(\r\n
)作為換行符。
當將數據寫入TSDB For InfluxDB?時,應該避免哪些文字和字符?
InfluxQL關鍵字
如果您使用InfluxQL關鍵字作為標識符,您需要在每個查詢中使用雙引號將該標識符括起來。如果不使用雙引號,會導致錯誤。標識符是連續查詢名字、數據庫名字、field key、measurement的名字、保留策略名字、tag key和用戶名。
時間
關鍵字time
是一個特例。time
可以是一個連續查詢名字、數據庫名字、measurement的名字、保留策略名字和用戶名。在這些情況下,不需要在查詢中用雙引號將time
括起來。time
不能是field key或tag key;TSDB For InfluxDB?拒絕寫入將time
作為field key或tag key的數據,對于這種數據寫入,TSDB For InfluxDB?會返回錯誤。
示例
將time作為measurement,寫入數據并查詢它
> INSERT time value=1
> SELECT * FROM time
name: time
time value
---------
2017-02-07T18:28:27.349785384Z1
在TSDB For InfluxDB?中,time
是一個有效的measurement名字。
將time作為field key,寫入數據并嘗試查詢它
> INSERT mymeas time=1
ERR:{"error":"partial write: invalid field name: input field \"time\" on measurement \"mymeas\" is invalid dropped=1"}
在TSDB For InfluxDB?中,time
不是一個有效的field key。系統無法寫入該數據點,并且返回400
錯誤。
將time作為tag key,寫入數據并嘗試查詢它
> INSERT mymeas,time=1 value=1
ERR:{"error":"partial write: invalid tag key: input tag \"time\" on measurement \"mymeas\" is invalid dropped=1"}
在TSDB For InfluxDB?中,time
不是一個有效的tag key。系統無法寫入該數據點,并且返回400
錯誤。
字符
為了保持簡單的正則表達式和引號,避免在標識符中使用以下字符:\
反斜杠^
尖號$
貨幣符號'
單引號"
雙引號=
等號,
逗號
當寫入數據時,什么時候應該使用單引號,什么時候應該使用雙引號?
通過行協議寫入數據時,避免使用單引號和雙引號將標識符括起來;請查看下面的示例,使用引號后的標識符會使查詢變得復雜。標識符是連續查詢名字、數據庫名字、field key、measurement的名字、保留策略名字、subscription的名字、tag key和用戶名。
寫入帶雙引號的measurement:
INSERT "bikes" bikes_available=3
適用的查詢:SELECT * FROM "\"bikes\""
寫入帶單引號的measurement:
INSERT 'bikes' bikes_available=3
適用的查詢:SELECT * FROM "\'bikes\'"
寫入不帶引號的measurement:
INSERT bikes bikes_available=3
適用的查詢:SELECT * FROM "bikes"
用雙引號將字符串類型的field value括起來。
寫入:
INSERT bikes happiness="level 2"
適用的查詢:SELECT * FROM "bikes" WHERE "happiness"='level 2'
應該用反斜杠轉義特殊字符,而不是用引號將其括起來。
寫入:
INSERT wacky va\"ue=4
適用的查詢:SELECT "va\"ue" FROM "wacky"
請查看文檔行協議參考獲得更多相關信息。
時間戳的精度是否重要?
重要。為了最大限度地提高性能,向TSDB For InfluxDB?寫入數據時盡量使用最粗糙的時間精度。
在下面兩個例子中,第一個請求使用默認精度(納秒),而第二個請求將精度設置為秒:
curl -i -XPOST "https://<網絡地址>:3242/write?db=weather&u=<賬號名稱>&p=<密碼>"--data-binary 'temperature,location=1 value=90 1472666050000000000'
curl -i -XPOST "https://<網絡地址>:3242/write?db=weather&precision=s&u=<賬號名稱>&p=<密碼>"--data-binary 'temperature,location=1 value=90 1472666050'
雖然性能會提高,但是代價是精度越粗糙,越有可能出現具有相同時間戳的重復數據點,可能會覆蓋其它數據點。