Time Series Database:FAQ

Series dan kardinalitas series

• Bagaimana cara melakukan pemodelan dan apa saja hal yang perlu diperhatikan?

• Mengapa Kardinalitas Seri Penting?

Administrasi

• Apa yang perlu diperhatikan untuk menjaga stabilitas sistem?

• Bagaimana cara melihat penggunaan disk untuk suatu measurement?

• Bagaimana cara menghapus data secara efisien dan aman?

• Mengapa kebijakan retensi yang telah diubah tidak berlaku?

• Mengapa layanan sering terputus?

• Mengapa penggunaan memori tinggi dan apakah saya perlu melakukan upgrade?

• Apakah skala-masuk penyimpanan didukung?

• Apakah memperluas disk menyebabkan restart?

• Berapa lama waktu yang dibutuhkan untuk restart?

• Apakah Grafana bawaan untuk InfluxDB didukung?

• Mengapa saya mendapatkan error ip block saat mengakses?

• Bagaimana cara mengidentifikasi versi TSDB for InfluxDB®?

• Apa hubungan antara durasi grup shard dan kebijakan retensi?

• Mengapa tidak ada data yang hilang setelah saya mengubah kebijakan retensi?

• Mengapa TSDB for InfluxDB® tidak dapat mengurai satuan mikrodetik?

Kueri data

• Bagaimana cara memecahkan masalah kueri lambat?

• Apa yang menentukan interval waktu yang dikembalikan oleh kueri GROUP BY time()?

• Mengapa kueri tidak mengembalikan data atau hanya sebagian data?

• Mengapa kueri GROUP BY time() tidak mengembalikan timestamp yang terjadi setelah now()?

• Apakah saya dapat melakukan operasi matematika pada timestamp?

• Dapatkah saya mengidentifikasi presisi penulisan dari timestamp yang dikembalikan?

• Kapan saya harus menggunakan tanda kutip tunggal dan ganda saat mengkueri data?

• Mengapa data hilang setelah saya membuat kebijakan retensi DEFAULT baru?

• Mengapa kueri dengan klausa WHERE OR time mengembalikan hasil kosong?

• Mengapa fill(previous) mengembalikan hasil kosong?

• Mengapa kueri INTO kehilangan data?

• Bagaimana cara mengkueri data ketika kunci tag dan kunci field memiliki nama yang sama?

• Bagaimana cara mengkueri data lintas measurement?

• Apakah urutan timestamp penting?

• Bagaimana cara SELECT data yang memiliki tag tetapi tidak memiliki nilai tag?

Penulisan data

• Mengapa jitter penulisan terjadi secara periodik?

• Hal-hal yang perlu diperhatikan saat menulis dengan protokol baris

• Mengapa data tidak terlihat setelah ditulis?

• Mengapa penulisan tidak dilanjutkan setelah ruang disk dibebaskan dari kondisi penuh?

• Bagaimana cara menulis nilai field integer?

• Bagaimana TSDB for InfluxDB® menangani titik data duplikat?

• Jenis line feed apa yang dibutuhkan oleh HTTP API?

• Kata dan karakter apa saja yang harus dihindari saat menulis data ke TSDB for InfluxDB®?

• Kapan saya harus menggunakan tanda kutip tunggal dan ganda saat menulis data?

• Apakah presisi timestamp penting?

Antarmuka baris perintah (Influx CLI)

• Mengapa saya tidak dapat terhubung ke TSDB for InfluxDB® menggunakan antarmuka baris perintah?

• Bagaimana cara membuat Influx CLI untuk TSDB for InfluxDB® mengembalikan timestamp yang mudah dibaca manusia?

• Bagaimana pengguna non-admin dapat menggunakan USE untuk menentukan database?

• Bagaimana cara menggunakan Influx CLI untuk TSDB for InfluxDB® menulis data ke kebijakan retensi non-default?

Tipe data

• Mengapa saya tidak dapat mengkueri nilai field Boolean?

• Bagaimana TSDB for InfluxDB® menangani perbedaan tipe field di berbagai shard?

• Apa bilangan bulat minimum dan maksimum yang dapat disimpan oleh TSDB for InfluxDB®?

• Apa timestamp minimum dan maksimum yang dapat disimpan oleh TSDB for InfluxDB®?

• Bagaimana cara mengetahui tipe data yang disimpan dalam suatu field?

• Dapatkah saya mengubah tipe data suatu field?

Fungsi InfluxQL

• Bagaimana cara melakukan operasi matematika dalam fungsi?

• Mengapa kueri mengembalikan epoch 0 sebagai timestamp?

• Fungsi InfluxQL mana saja yang mendukung nesting?

Migrasi data InfluxDB

• Bagaimana cara memigrasikan InfluxDB yang dikelola sendiri ke cloud?

• Bagaimana cara memigrasikan data antar instans InfluxDB yang berbeda di cloud?

• Bagaimana cara memigrasikan data dari InfluxDB ke LindormTSDB?

Mengapa kardinalitas seri penting?

TSDB for InfluxDB® memelihara indeks di memori untuk setiap deret waktu. Seiring bertambahnya jumlah deret waktu, penggunaan RAM juga meningkat. Kardinalitas yang terlalu tinggi dapat memicu pengecualian kehabisan memori (OOM) yang menghentikan proses. Referensi InfluxQL

Bagaimana cara melakukan pemodelan dan apa saja hal yang perlu diperhatikan?

Batasi jumlah deret waktu di bawah satu juta. Untuk skenario deret waktu dalam jumlah besar, gunakan Pengantar LindormTSDB. Tinjau panduan skema dan tata letak data InfluxDB. InfluxDB mengindeks tag untuk mempercepat kueri, tetapi terlalu banyak tag menyebabkan inflasi deret waktu yang memperlambat pembacaan dan penulisan. Pertimbangan utama:

• Hindari penggunaan tag dengan nilai kardinalitas tinggi, seperti ID, nilai hash, dan string acak.

• Jangan menyimpan data dalam nama measurement atau nama tag. Simpan data dalam tag dan field.

• Jangan menyimpan beberapa informasi dalam satu tag. Pisahkan informasi tersebut menjadi beberapa tag.

• Jika Anda sering menggunakan suatu field dalam klausa GROUP BY, modelkan sebagai tag.

Bagaimana cara mengidentifikasi versi TSDB for InfluxDB®?

Gunakan salah satu metode berikut:

• curl /ping

  $ curl -i 'https://<endpoint>:3242/ping?u=<username>&p=<password>'
  HTTP/1.1 204 No Content
  Content-Type: application/json
  X-Influxdb-Build: OSS
  X-Influxdb-Version: 1.7.x

• Jalankan antarmuka baris perintah untuk TSDB for InfluxDB®

  $ influx -ssl -username <username> -password <password> -host <endpoint> -port 3242
  
  Connected to https://<endpoint>:3242 version 1.7.x

Apa hubungan antara durasi grup shard dan kebijakan retensi?

TSDB for InfluxDB® menyimpan data dalam grup shard. Grup shard mencakup interval waktu tertentu. TSDB for InfluxDB® menentukan interval waktu tersebut dengan memeriksa DURATION dari kebijakan retensi (RP) yang relevan. Tabel berikut mencantumkan hubungan default antara DURATION RP dan interval waktu grup shard:

Gunakan SHOW RETENTION POLICIES untuk melihat durasi grup shard dari suatu kebijakan retensi.

Mengapa tidak ada data yang hilang setelah saya mengubah kebijakan retensi?

Data mungkin tidak langsung hilang setelah Anda mengubah kebijakan retensi karena alasan berikut:

• Alasan pertama (skenario paling mungkin): Secara default, TSDB for InfluxDB® memeriksa dan menerapkan RP setiap 30 menit. Anda mungkin perlu menunggu pemeriksaan RP berikutnya sebelum TSDB for InfluxDB® menghapus data yang berada di luar DURATION baru RP.

• Alasan kedua: Mengubah DURATION dan SHARD DURATION RP dapat menyebabkan retensi data yang tidak terduga. TSDB for InfluxDB® menyimpan data dalam grup shard. Setiap grup shard mencakup RP dan interval waktu tertentu. Saat TSDB for InfluxDB® menerapkan RP, sistem menghapus seluruh grup shard, bukan titik data individual. TSDB for InfluxDB® tidak dapat membagi grup shard. Jika DURATION baru RP lebih pendek daripada SHARD DURATION lama, dan TSDB for InfluxDB® sedang menulis data ke grup shard lama dengan DURATION yang lebih panjang, sistem terpaksa menyimpan semua data dalam grup shard tersebut. Hal ini terjadi meskipun beberapa data dalam grup shard berada di luar DURATION baru. Setelah semua data dalam grup shard berada di luar DURATION baru, TSDB for InfluxDB® menghapus seluruh grup shard. Sistem kemudian mulai menulis data ke grup shard dengan SHARD DURATION yang lebih pendek. Hal ini mencegah retensi data yang tidak terduga di masa depan.

Mengapa TSDB for InfluxDB® tidak dapat mengurai satuan mikrodetik?

Sintaks untuk menentukan satuan waktu mikrodetik berbeda untuk penulisan, kueri, dan pengaturan presisi di antarmuka baris perintah TSDB for InfluxDB® (Influx CLI). Tabel berikut menunjukkan sintaks yang didukung untuk setiap kategori:

Bagaimana cara memecahkan masalah kueri lambat?

Kueri lambat biasanya disebabkan oleh pemindaian terlalu banyak deret waktu atau terlalu banyak data mentah. Tambahkan filter tag dan rentang waktu pada setiap kueri. Gunakan perintah EXPLAIN ANALYZE untuk mendiagnosis kinerja: execution_time mencerminkan pembacaan dan komputasi data, sedangkan planning_time mencerminkan pemindaian deret waktu.

Apa yang menentukan interval waktu yang dikembalikan oleh kueri GROUP BY time()?

Interval waktu yang dikembalikan oleh kueri GROUP BY time() sesuai dengan bucket waktu preset TSDB for InfluxDB® atau interval offset yang ditentukan pengguna. Lihat contoh berikut:

• Bucket waktu preset

  Kueri berikut menghitung rata-rata sunflowers antara pukul 18.15 dan 19.45, dan mengelompokkan rata-rata tersebut per jam:

  SELECT mean("sunflowers")
  FROM "flower_orders"
  WHERE time >='2016-08-29T18:15:00Z' AND time <='2016-08-29T19:45:00Z' GROUP BY time(1h)

  Hasil berikut menunjukkan bagaimana TSDB for InfluxDB® mempertahankan bucket waktu preset-nya.

  Dalam contoh ini, pukul 18.00 adalah bucket waktu preset, dan pukul 19.00 juga merupakan bucket waktu preset. Karena klausa WHERE menentukan rentang waktu kueri, data sebelum pukul 18.15 tidak termasuk saat menghitung rata-rata untuk bucket waktu pukul 18.00. Namun, data yang digunakan untuk menghitung rata-rata untuk bucket waktu pukul 18.00 harus terjadi dalam jam 18.00. Hal yang sama berlaku untuk bucket waktu pukul 19.00. Data yang digunakan untuk menghitung rata-rata untuk bucket waktu pukul 19.00 harus terjadi dalam jam 19.00. Garis putus-putus menunjukkan titik data yang digunakan untuk menghitung setiap rata-rata.

  Perhatikan bahwa meskipun timestamp pertama dalam hasil adalah 2016-08-29T18:00:00Z, hasil kueri untuk bucket waktu tersebut tidak mencakup data yang terjadi sebelum 2016-08-29T18:15:00Z, yaitu waktu mulai yang ditentukan dalam klausa WHERE.

  Data mentah:

  name: flower_orders                                name: flower_orders
  —————————-------------------
  time                    sunflowers                 time                  mean
  2016-08-29T18:00:00Z    34                         2016-08-29T18:00:00Z    22.332
  |--|                                               2016-08-29T19:00:00Z    62.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:00Z    70

• Interval offset

  Kueri berikut menghitung rata-rata sunflowers antara pukul 18.15 dan 19.45, dan mengelompokkan rata-rata tersebut per jam. Kueri ini juga menggeser bucket waktu preset TSDB for InfluxDB® sebesar 15 menit:

  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)
                                                                                    ---
                                                                                     |
                                                                                    interval offset

  Dalam contoh ini, interval offset yang ditentukan pengguna menggeser bucket waktu preset TSDB for InfluxDB® maju sebesar 15 menit. Sekarang, rata-rata untuk bucket waktu pukul 18.00 mencakup data antara pukul 18.15 dan 19.15. Rata-rata untuk bucket waktu pukul 19.00 mencakup data antara pukul 19.15 dan 20.15. Garis putus-putus menunjukkan titik data yang digunakan untuk menghitung setiap rata-rata.

  Perhatikan bahwa timestamp pertama dalam hasil sekarang adalah 2016-08-29T18:15:00Z, bukan 2016-08-29T18:00:00Z.

  Data mentah dan hasil:

  name: flower_orders                                name: flower_orders
  —————————-------------------
  time                    sunflowers                 time                  mean
  2016-08-29T18:00:00Z    34                         2016-08-29T18:15:00Z    30.75
  |--|                                               2016-08-29T19:15:00Z    65
  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|
  |--|

Mengapa kueri tidak mengembalikan data atau hanya sebagian data?

Alasan umum:

• Kebijakan retensi

  Penjelasan pertama dan paling umum terkait kebijakan retensi (RP). TSDB for InfluxDB® secara otomatis mengkueri data dari RP DEFAULT database. Jika data Anda tidak disimpan dalam RP default, TSDB for InfluxDB® tidak mengembalikan hasil apa pun kecuali Anda secara eksplisit menentukan RP yang akan digunakan.

• Kunci tag dalam klausa SELECT

  Klausa SELECT harus menyertakan setidaknya satu kunci field agar kueri mengembalikan data. Jika klausa SELECT hanya berisi satu atau beberapa kunci tag, kueri mengembalikan hasil kosong. Untuk informasi lebih lanjut, lihat Eksplorasi data.

• Rentang waktu kueri

  Penjelasan lain terkait rentang waktu kueri. Secara default, sebagian besar kueri SELECT mencakup rentang waktu antara 1677-09-21 00:12:43.145224194 UTC dan 2262-04-11T23:47:16.854775806Z UTC. Namun, kueri SELECT yang menyertakan klausa GROUP BY time() mencakup rentang waktu antara 1677-09-21 00:12:43.145224194 dan now(). Jika data Anda terjadi setelah now(), kueri GROUP BY time() tidak mencakup data yang terjadi setelah now(). Jika pernyataan kueri menyertakan klausa GROUP BY time() dan memiliki data yang terjadi setelah now(), Anda perlu memberikan batas atas untuk rentang waktu.

• Nama pengenal

  Penjelasan umum terakhir terkait skema, di mana field dan tag memiliki nama yang sama. Jika kunci field dan kunci tag identik, field diprioritaskan dalam semua kueri. Dalam kueri, Anda perlu menggunakan sintaks ::tag untuk menentukan kunci tag.

Mengapa kueri GROUP BY time() tidak mengembalikan timestamp yang terjadi setelah now()?

Rentang waktu default untuk sebagian besar pernyataan SELECT adalah antara 1677-09-21 00:12:43.145224194 UTC dan 2262-04-11T23:47:16.854775806Z UTC. Untuk pernyataan SELECT dengan klausa GROUP BY time(), rentang waktu default adalah antara 1677-09-21 00:12:43.145224194 dan now().

Untuk mengkueri data dengan timestamp yang terjadi setelah now(), pernyataan SELECT dengan klausa GROUP BY time() harus memberikan batas waktu atas dalam klausa WHERE.

Dalam contoh berikut, kueri pertama mencakup data dengan timestamp antara 2015-09-18T21:30:00Z dan now(). Kueri kedua mencakup data dengan timestamp antara 2015-09-18T21:30:00Z dan 180 minggu setelah now().

> 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)

Perhatikan bahwa klausa WHERE harus memberikan batas waktu atas untuk mengganti batas atas default now(). Kueri berikut hanya mengatur ulang batas bawah ke now(), sehingga rentang waktu kueri menjadi antara now() dan now():

> SELECT MEAN("boards") FROM "hillvalley" WHERE time >= now() GROUP BY time(12m) fill(none)
>

Detail sintaks waktu: Eksplorasi data.

Dapatkah saya melakukan operasi matematika pada timestamp?

TSDB for InfluxDB® tidak mendukung operasi matematika pada timestamp. Lakukan perhitungan waktu di sisi klien.

TSDB for InfluxDB® menawarkan dukungan terbatas untuk menggunakan fungsi InfluxQL pada timestamp. Fungsi ELAPSED() mengembalikan selisih antara timestamp dalam satu field.

Dapatkah saya mengidentifikasi presisi penulisan dari timestamp yang dikembalikan?

TSDB for InfluxDB® menyimpan semua timestamp dalam nanodetik, terlepas dari presisi penulisan. Database diam-diam menghapus angka nol di akhir dari timestamp yang dikembalikan, sehingga sulit mengidentifikasi presisi penulisan asli.

Dalam contoh berikut, tag precision_supplied dan timestamp_supplied menunjukkan presisi waktu dan timestamp yang diberikan pengguna saat menulis data. Karena TSDB for InfluxDB® diam-diam menghapus angka nol di akhir dari timestamp yang dikembalikan, sulit mengidentifikasi presisi penulisan dari timestamp yang dikembalikan.

name: trails
-------------
time                  value  precision_supplied  timestamp_supplied
1970-01-01T01:00:00Z  3      n                   3600000000000
1970-01-01T01:00:00Z  5      h                   1
1970-01-01T02:00:00Z  4      n                   7200000000000
1970-01-01T02:00:00Z  6      h                   2

Kapan saya harus menggunakan tanda kutip tunggal dan ganda saat mengkueri data?

Gunakan tanda kutip tunggal untuk mengapit nilai string, seperti nilai tag. Jangan gunakan tanda kutip tunggal untuk mengapit pengenal. Pengenal mencakup nama database, nama kebijakan retensi, username, nama measurement, kunci tag, dan kunci field.

Gunakan tanda kutip ganda untuk mengapit pengenal jika pengenal tersebut diawali angka, berisi karakter selain [A-z,0-9,_], atau merupakan kata kunci InfluxQL. Jika pengenal tidak termasuk dalam kategori tersebut, Anda tidak perlu mengapitnya dengan tanda kutip ganda. Namun, kami merekomendasikan untuk melakukannya.

Contoh:

Kueri valid: SELECT bikes_available FROM bikes WHERE station_id='9'

Kueri valid: SELECT "bikes_available" FROM "bikes" WHERE "station_id"='9'

Kueri valid: SELECT MIN("avgrq-sz") AS "min_avgrq-sz" FROM telegraf

Kueri valid: SELECT * from "cr@zy" where "p^e"='2'

Kueri tidak valid: SELECT 'bikes_available' FROM 'bikes' WHERE 'station_id'="9"

Kueri tidak valid: SELECT * from cr@zy where p^e='2'

Gunakan tanda kutip tunggal untuk mengapit string tanggal waktu. Jika Anda menggunakan tanda kutip ganda untuk mengapit string tanggal waktu, TSDB for InfluxDB® mengembalikan error (ERR: invalid operation: time and *influxql.VarRef are not compatible).

Contoh:

Kueri valid: SELECT "water_level" FROM "h2o_feet" WHERE time > '2015-08-18T23:00:01.232000000Z' AND time < '2015-09-19'

Kueri tidak valid: SELECT "water_level" FROM "h2o_feet" WHERE time > "2015-08-18T23:00:01.232000000Z" AND time < "2015-09-19"

Detail sintaks waktu: Eksplorasi data.

Mengapa data hilang setelah saya membuat kebijakan retensi DEFAULT baru?

Saat Anda membuat kebijakan retensi (RP) default baru dalam database, data dalam RP default lama tetap berada di RP lama tersebut. Kueri yang tidak menentukan RP akan secara otomatis mengkueri data dari RP default baru, sehingga semua data lama tampak hilang. Untuk mengkueri data lama, Anda harus menentukan data tersebut secara lengkap dalam kueri. Lihat contoh berikut:

Semua data dalam measurement fleeting termasuk dalam RP default, yang bernama one_hour:

> SELECT count(flounders) FROM fleeting
name: fleeting
--------------
time                     count
1970-01-01T00:00:00Z     8

Sekarang kita membuat RP default baru (two_hour) dan menjalankan kueri yang sama:

> SELECT count(flounders) FROM fleeting
>

Untuk mengkueri data lama, kita harus menentukan RP default lama dengan menentukan fleeting secara lengkap:

> SELECT count(flounders) FROM fish.one_hour.fleeting
name: fleeting
--------------
time                     count
1970-01-01T00:00:00Z     8

Mengapa kueri dengan klausa WHERE OR time mengembalikan hasil kosong?

TSDB for InfluxDB® tidak mendukung OR dalam klausa WHERE untuk menentukan beberapa rentang waktu. Jika klausa WHERE kueri menggunakan OR untuk menentukan beberapa rentang waktu, TSDB for InfluxDB® tidak mengembalikan hasil apa pun.

Contoh:

> SELECT * FROM "absolutismus" WHERE time ='2016-07-31T20:07:00Z' OR time ='2016-07-31T23:07:17Z'
>

Mengapa fill(previous) mengembalikan hasil kosong?

Jika nilai sebelumnya berada di luar rentang waktu kueri, fill(previous) tidak mengisi nilai untuk bucket waktu tersebut.

Dalam contoh berikut, TSDB for InfluxDB® tidak mengisi nilai untuk bucket waktu 2016-07-12T16:50:20Z-2016-07-12T16:50:30Z dengan nilai dari bucket waktu 2016-07-12T16:50:00Z-2016-07-12T16:50:10Z karena rentang waktu kueri tidak mencakup bucket waktu sebelumnya.

Data sampel:

> SELECT * FROM "cupcakes"
name: cupcakes
--------------
time                   chocolate
2016-07-12T16:50:00Z   3
2016-07-12T16:50:10Z   2
2016-07-12T16:50:40Z   12
2016-07-12T16:50:50Z   11

Kueri 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:40Z   12
2016-07-12T16:51:00Z   12

Mengapa kueri INTO kehilangan data?

Secara default, kueri INTO mengonversi tag dari data sumber menjadi field dalam data yang baru ditulis. Hal ini dapat menyebabkan TSDB for InfluxDB® menimpa titik data yang sebelumnya dibedakan oleh tag. Sertakan GROUP BY * dalam semua kueri INTO untuk mempertahankan tag dalam data yang baru ditulis.

> 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

• Kueri INTO tanpa GROUP BY *

  Kueri INTO tanpa klausa GROUP BY * mengonversi tag color menjadi field dalam data yang baru ditulis. Dalam data sumber, titik data nugget dan rumple hanya dibedakan oleh tag color. Setelah color menjadi field, TSDB for InfluxDB® menganggap titik data nugget dan rumple sebagai duplikat. Sistem menimpa titik data nugget dengan titik data rumple.

  > SELECT * INTO "all_dogs" FROM "french_bulldogs"
  name: result
  ------------
  time                  written
  1970-01-01T00:00:00Z  3
  
  > SELECT * FROM "all_dogs"
  name: all_dogs
  --------------
  time                  color  name
  2016-05-25T00:05:00Z  grey   rumple                <---- nugget sudah tidak ada
  2016-05-25T00:10:00Z  black  prince

• Kueri INTO dengan GROUP BY *

  Kueri INTO dengan klausa GROUP BY * mempertahankan tag color dalam data yang baru ditulis. Dalam kasus ini, titik data nugget dan rumple tetap menjadi titik data yang berbeda, dan TSDB for InfluxDB® tidak menimpa data apa pun.

  > SELECT "name" INTO "all_dogs" FROM "french_bulldogs" GROUP BY *
  name: result
  ------------
  time                  written
  1970-01-01T00:00:00Z  3
  
  > 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

Bagaimana cara mengkueri data ketika kunci tag dan kunci field memiliki nama yang sama?

Gunakan sintaks :: untuk menentukan apakah kunci tersebut adalah kunci field atau kunci tag. Data sampel:

> INSERT candied,almonds=true almonds=50,half_almonds=51 1465317610000000000
> INSERT candied,almonds=true almonds=55,half_almonds=56 1465317620000000000

> SELECT * FROM "candied"
name: candied
-------------
time                   almonds  almonds_1  half_almonds
2016-06-07T16:40:10Z   50       true       51
2016-06-07T16:40:20Z   55       true       56

• Tentukan kunci sebagai field

  > SELECT * FROM "candied" WHERE "almonds"::field > 51
  name: candied
  -------------
  time                   almonds  almonds_1  half_almonds
  2016-06-07T16:40:20Z   55       true       56

• Tentukan kunci sebagai tag

  > SELECT * FROM "candied" WHERE "almonds"::tag='true'
  name: candied
  -------------
  time                   almonds  almonds_1  half_almonds
  2016-06-07T16:40:10Z   50       true       51
  2016-06-07T16:40:20Z   55       true       56

Bagaimana cara mengkueri data lintas measurement?

Operasi matematika atau pengelompokan lintas measurement tidak didukung. Semua data harus berada dalam measurement yang sama. TSDB for InfluxDB® bukan database relasional — hindari pemetaan data lintas measurement.

Apakah urutan timestamp penting?

Tidak. Hasil pengujian menunjukkan bahwa perbedaan waktu yang dibutuhkan TSDB for InfluxDB® untuk menyelesaikan kueri berikut sangat kecil:

SELECT ... FROM ... WHERE time > 'timestamp1' AND time < 'timestamp2'
SELECT ... FROM ... WHERE time < 'timestamp2' AND time > 'timestamp1'

Bagaimana cara SELECT data yang memiliki tag tetapi tidak memiliki nilai tag?

Gunakan '' untuk menentukan nilai tag kosong. Contohnya:

> SELECT * FROM "vases" WHERE priceless=''
name: vases
-----------
time                   origin   priceless
2016-07-20T18:42:00Z   8

Bagaimana cara menulis nilai field integer?

Saat menulis integer, tambahkan i di akhir nilai field. Jika Anda tidak menambahkan i, TSDB for InfluxDB® memperlakukan nilai field tersebut sebagai bilangan titik mengambang.

Menulis integer: value=100i. Menulis bilangan titik mengambang: value=100.

Bagaimana TSDB for InfluxDB® menangani titik data duplikat?

Titik data diidentifikasi secara unik berdasarkan nama measurement, himpunan tag, dan timestamp. Jika Anda mengirimkan titik data yang memiliki measurement, himpunan tag, dan timestamp yang sama dengan titik data yang sudah ada, tetapi himpunan field berbeda, himpunan field titik data tersebut menjadi gabungan dari himpunan field lama dan baru. Jika terjadi konflik, himpunan field baru yang diutamakan. Ini adalah perilaku yang diharapkan.

Contohnya:

Titik data lama: cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000

Titik data baru: cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000000

Setelah Anda mengirimkan titik data baru, TSDB for InfluxDB® menimpa nilai val_1 dengan nilai field baru, dan nilai val_2 dipertahankan:

> 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

Untuk menyimpan kedua titik data, Anda dapat:

• Memperkenalkan tag baru untuk memastikan keunikan.

  Titik data lama: cpu_load,hostname=server02,az=us_west,uniq=1 val_1=24.5,val_2=7 1234567890000000

  Titik data baru: cpu_load,hostname=server02,az=us_west,uniq=2 val_1=5.24 1234567890000000

  Setelah menulis titik data baru ke 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

• Menambahkan timestamp sebesar satu nanodetik.

  Titik data lama: cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000

  Titik data baru: cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000001

  Setelah menulis titik data baru ke 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

Line feed apa yang dibutuhkan oleh HTTP API?

Protokol baris untuk TSDB for InfluxDB® bergantung pada karakter line feed (\n, yaitu ASCII 0x0A) untuk menandai akhir satu baris dan awal baris baru. File atau data yang menggunakan karakter line feed selain \n akan menyebabkan error bad timestamp atau unable to parse.

Windows menggunakan \r\n (carriage return + line feed), yang tidak kompatibel.

Kata dan karakter apa saja yang harus dihindari saat menulis data ke TSDB for InfluxDB®?

• Kata kunci InfluxQL

  Jika Anda menggunakan kata kunci InfluxQL sebagai pengenal, Anda harus mengapit pengenal tersebut dengan tanda kutip ganda dalam setiap kueri. Hal ini akan menyebabkan error jika Anda tidak menggunakan tanda kutip ganda. Pengenal mencakup nama continuous query, nama database, kunci field, nama measurement, nama kebijakan retensi, kunci tag, dan username.

• Time

  Kata kunci time adalah kasus khusus. time dapat menjadi nama continuous query, nama database, nama measurement, nama kebijakan retensi, dan username. Dalam kasus ini, Anda tidak perlu mengapit time dengan tanda kutip ganda dalam kueri. time tidak dapat menjadi kunci field atau kunci tag. TSDB for InfluxDB® menolak penulisan data yang menggunakan time sebagai kunci field atau kunci tag. Untuk penulisan tersebut, TSDB for InfluxDB® mengembalikan error. Lihat contoh berikut:

  • Menulis dan mengkueri data dengan time sebagai measurement.

    > INSERT time value=1
    
    > SELECT * FROM time
    
    name: time
    time                            value
    ---------
    2017-02-07T18:28:27.349785384Z  1

    Di TSDB for InfluxDB®, time adalah nama measurement yang valid.

  • Menulis dan mencoba mengkueri data dengan time sebagai kunci field.

    > INSERT mymeas time=1
    ERR:{"error":"partial write: invalid field name: input field \"time\" on measurement \"mymeas\" is invalid dropped=1"}

    Di TSDB for InfluxDB®, time bukan kunci field yang valid. Sistem tidak dapat menulis titik data dan mengembalikan error 400.

  • Menulis dan mencoba mengkueri data dengan time sebagai kunci tag.

    > INSERT mymeas,time=1 value=1
    ERR:{"error":"partial write: invalid tag key: input tag \"time\" on measurement \"mymeas\" is invalid dropped=1"}

    Di TSDB for InfluxDB®, time bukan kunci tag yang valid. Sistem tidak dapat menulis titik data dan mengembalikan error 400.

• Karakter

  Untuk menjaga ekspresi reguler dan pengutipan tetap sederhana, hindari penggunaan karakter berikut dalam pengenal: \ (backslash), ^ (caret), $ (dollar sign), ' (tanda kutip tunggal), " (tanda kutip ganda), = (tanda sama dengan), dan , (koma).

Kapan saya harus menggunakan tanda kutip tunggal dan ganda saat menulis data?

• Hindari mengapit pengenal dengan tanda kutip saat menulis dengan protokol baris — hal ini mempersulit kueri. Pengenal mencakup nama continuous query, nama database, kunci field, nama measurement, nama kebijakan retensi, nama langganan, kunci tag, dan username.

  • Menulis measurement dengan tanda kutip ganda: INSERT "bikes" bikes_available=3. Kueri yang berlaku: SELECT * FROM "\"bikes\""

  • Menulis measurement dengan tanda kutip tunggal: INSERT 'bikes' bikes_available=3. Kueri yang berlaku: SELECT * FROM "\'bikes\'"

  • Menulis measurement tanpa tanda kutip: INSERT bikes bikes_available=3. Kueri yang berlaku: SELECT * FROM "bikes"

• Gunakan tanda kutip ganda untuk mengapit nilai field string.

  Menulis: INSERT bikes happiness="level 2". Kueri yang berlaku: SELECT * FROM "bikes" WHERE "happiness"='level 2'

• Escape karakter khusus dengan backslash, bukan dengan mengapitnya dalam tanda kutip.

  Menulis: INSERT wacky va\"ue=4. Kueri yang berlaku: SELECT "va\"ue" FROM "wacky"

Apakah presisi timestamp penting?

Untuk kinerja penulisan optimal, gunakan presisi waktu yang paling kasar (coarsest) yang memungkinkan.

Dalam dua contoh berikut, permintaan pertama menggunakan presisi default (nanodetik), sedangkan permintaan kedua mengatur presisi ke detik:

curl -i -XPOST "https://<endpoint>:3242/write?db=weather&u=<username>&p=<password>" --data-binary 'temperature,location=1 value=90 1472666050000000000'

curl -i -XPOST "https://<endpoint>:3242/write?db=weather&precision=s&u=<username>&p=<password>" --data-binary 'temperature,location=1 value=90 1472666050'

Trade-off: presisi yang lebih kasar meningkatkan kemungkinan timestamp duplikat, yang dapat menyebabkan penimpaan data.

Mengapa saya tidak dapat terhubung ke TSDB for InfluxDB® menggunakan antarmuka baris perintah?

Konfirmasi kondisi berikut satu per satu:

• Anda harus memiliki izin eksekusi. Anda dapat menjalankan perintah chmod +x ./influx untuk menambahkan izin.

• Opsi -ssl harus ditentukan dalam pernyataan koneksi.

• Untuk opsi -host, tentukan hanya string koneksi, seperti ts-bp17j28j2y7pm****.influxdata.rds.aliyuncs.com. Jangan tambahkan protokol dan nomor port.

Bagaimana cara membuat Influx CLI untuk TSDB for InfluxDB® mengembalikan timestamp yang mudah dibaca manusia?

Saat pertama kali terhubung ke Influx CLI, tentukan presisi rfc3339:

$ influx -ssl -username <username> -password <password> -host <endpoint> -port 3242 -precision rfc3339

Atau, tentukan presisi setelah terhubung ke Influx CLI:

$ influx -ssl -username <username> -password <password> -host <endpoint> -port 3242
Connected to https://<endpoint>:3242 version 1.7.x
> precision rfc3339

Detail: Antarmuka baris perintah (Influx CLI).

Bagaimana pengguna non-admin dapat menggunakan USE untuk menentukan database?

Jika pengguna non-admin memiliki izin READ dan WRITE, atau hanya izin READ untuk suatu database, mereka dapat menjalankan pernyataan USE <database_name>. Jika pengguna non-admin mencoba menggunakan USE untuk menentukan database yang tidak memiliki izin READ dan WRITE, atau izin READ, sistem mengembalikan error:

ERR: Database <database_name> doesn't exist. Run SHOW DATABASES for a list of existing databases.

Bagaimana cara menggunakan Influx CLI untuk TSDB for InfluxDB® menulis data ke kebijakan retensi non-default?

Gunakan sintaks INSERT INTO [<database>.]<retention_policy> <line_protocol> untuk menulis data ke kebijakan retensi non-default. (Metode penentuan database dan kebijakan retensi ini hanya diizinkan di Influx CLI. Jika Anda menulis data melalui HTTP, Anda harus menggunakan parameter db dan rp untuk menentukan database dan kebijakan retensi, secara berurutan. Penentuan kebijakan retensi bersifat opsional.) Lihat contoh berikut.

> 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

Anda perlu menentukan measurement secara lengkap untuk mengkueri data dalam kebijakan retensi non-default. Gunakan sintaks berikut untuk menentukan measurement secara lengkap:

"<database>"."<retention_policy>"."<measurement>"

Mengapa saya tidak dapat mengkueri nilai field Boolean?

Sintaks untuk menulis dan mengkueri nilai Boolean berbeda.

Contohnya, SELECT * FROM "hamlet" WHERE "bool"=True mengembalikan semua titik data di mana bool sama dengan TRUE. Namun, SELECT * FROM "hamlet" WHERE "bool"=T tidak mengembalikan hasil apa pun.

Bagaimana TSDB for InfluxDB® menangani perbedaan tipe field di berbagai shard?

Nilai field dapat berupa bilangan titik mengambang, integer, string, atau nilai Boolean. Dalam satu shard, tipe data nilai field harus konsisten. Namun, di berbagai shard yang berbeda, tipe data nilai field dapat berbeda.

• Pernyataan SELECT

  Pernyataan SELECT secara default mengembalikan semua nilai field dengan tipe data yang sama. Jika tipe data nilai field tidak sama di berbagai shard, TSDB for InfluxDB® pertama-tama melakukan konversi tipe, jika berlaku. Kemudian, sistem mengembalikan semua nilai dalam urutan tipe data berikut: bilangan titik mengambang, integer, string, Boolean. Jika tipe nilai field berbeda dalam data Anda, gunakan sintaks <field_key>::<type> untuk mengkueri berbagai tipe data. Lihat contoh berikut:

  Measurement just_my_type memiliki field bernama my_field. my_field memiliki empat nilai field di empat shard berbeda, dan tipe data setiap nilai field berbeda (bilangan titik mengambang, integer, string, dan Boolean, secara berurutan).

  SELECT hanya mengembalikan nilai field bilangan titik mengambang dan integer. Dalam hasilnya, TSDB for InfluxDB® memaksa integer dikonversi menjadi bilangan titik mengambang.

  > SELECT * FROM just_my_type
  
  name: just_my_type
  ------------------
  time                      my_field
  2016-06-03T15:45:00Z      9.87034
  2016-06-03T16:45:00Z      7

  SELECT <field_key>::<type> [...] mengembalikan semua tipe data. TSDB for InfluxDB® menampilkan data setiap tipe ke kolom terpisah dan menggunakan nama kolom yang bertambah. Jika memungkinkan, TSDB for InfluxDB® mengonversi nilai field ke tipe data lain. Sistem mengonversi integer 7 menjadi bilangan titik mengambang di kolom pertama dan bilangan titik mengambang 9.879034 menjadi integer di kolom kedua. TSDB for InfluxDB® tidak dapat mengonversi bilangan titik mengambang atau integer menjadi string atau nilai Boolean.

  > 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

• Kueri SHOW FIELD KEYS

  SHOW FIELD KEYS mengembalikan setiap tipe data di setiap shard yang sesuai dengan kunci field. Lihat contoh berikut:

  Measurement just_my_type memiliki field bernama my_field. my_field memiliki empat nilai field di empat shard berbeda, dan tipe data setiap nilai field berbeda (bilangan titik mengambang, integer, string, dan Boolean, secara berurutan).

  SHOW FIELD KEYS mengembalikan keempat tipe data tersebut:

  > SHOW FIELD KEYS
  
  name: just_my_type
  fieldKey   fieldType
  -----------------
  my_field   float
  my_field   string
  my_field   integer
  my_field   boolean

Apa bilangan bulat minimum dan maksimum yang dapat disimpan oleh TSDB for InfluxDB®?

TSDB for InfluxDB® menyimpan semua integer sebagai tipe data int64 bertanda. Nilai minimum dan maksimum yang valid untuk int64 adalah -9023372036854775808 dan 9023372036854775807, secara berurutan. Referensi: Go builtins.

Menggunakan nilai yang mendekati bilangan bulat minimum atau maksimum tetapi masih dalam batas dapat menyebabkan hasil yang tidak terduga. Beberapa fungsi dan operator mengonversi tipe data int64 ke float64 selama perhitungan, yang dapat menyebabkan masalah overflow.

Apa timestamp minimum dan maksimum yang dapat disimpan oleh TSDB for InfluxDB®?

Timestamp minimum adalah -9223372036854775806 atau 1677-09-21T00:12:43.145224194Z, dan timestamp maksimum adalah 9223372036854775806 atau 2262-04-11T23:47:16.854775806Z. Timestamp di luar rentang ini mengembalikan error parsing.

Bagaimana cara mengetahui tipe data yang disimpan dalam suatu field?

Kueri SHOW FIELD KEYS juga mengembalikan tipe data field tersebut.

> SHOW FIELD KEYS FROM all_the_types
name: all_the_types
-------------------
fieldKey  fieldType
blue      string
green     boolean
orange    integer
yellow    float

Dapatkah saya mengubah tipe data suatu field?

TSDB for InfluxDB® menawarkan dukungan sangat terbatas untuk mengubah tipe data field. Sintaks <field_key>::<type> mendukung konversi nilai field dari integer ke bilangan titik mengambang atau dari bilangan titik mengambang ke integer. Detail konversi ada di Eksplorasi data. Anda tidak dapat mengonversi bilangan titik mengambang atau integer menjadi string atau nilai Boolean, atau sebaliknya.

Metode untuk mengubah tipe data field:

• Menulis data ke field yang berbeda

  Solusi paling sederhana adalah menulis data dengan tipe data baru ke field yang berbeda dalam deret waktu yang sama.

• Menggunakan sistem shard

  Dalam satu shard, tipe data nilai field tidak boleh berbeda. Namun, di berbagai shard yang berbeda, tipe data nilai field dapat berbeda.

  Untuk mengubah tipe data field, pengguna dapat menggunakan kueri SHOW SHARDS untuk mengidentifikasi end_time shard saat ini. Jika timestamp titik data terjadi setelah end_time, TSDB for InfluxDB® mengizinkan data dengan tipe data berbeda ditulis ke field yang sudah ada. Misalnya, field awalnya menerima integer, tetapi setelah end_time, field tersebut dapat menerima bilangan titik mengambang.

  Perhatikan bahwa hal ini tidak mengubah tipe data field di shard asli.

Bagaimana cara melakukan operasi matematika dalam fungsi?

TSDB for InfluxDB® tidak mendukung operasi matematika dalam fungsi. Gunakan subkueri sebagai solusi:

InfluxQL tidak mendukung sintaks berikut:

SELECT MEAN("dogs"-"cats") from "pet_daycare"

Sebagai gantinya, kita dapat menggunakan subkueri untuk mendapatkan hasil yang sama:

> SELECT MEAN("difference") FROM (SELECT "dogs"-"cat" AS "difference" FROM "pet_daycare")

Detail subkueri: Eksplorasi data.

Mengapa kueri mengembalikan epoch 0 sebagai timestamp?

Di TSDB for InfluxDB®, epoch 0 (1970-01-01T00:00:00Z) sering digunakan sebagai timestamp null. Jika Anda meminta kueri yang tidak dapat mengembalikan timestamp, seperti fungsi agregat tanpa rentang waktu yang ditentukan, TSDB for InfluxDB® mengembalikan epoch 0 sebagai timestamp.

Fungsi InfluxQL mana saja yang mendukung nesting?

Fungsi InfluxQL berikut mendukung nesting:

• COUNT() dengan DISTINCT() bersarang

• CUMULATIVE_SUM()

• DERIVATIVE()

• DIFFERENCE()

• ELAPSED()

• MOVING_AVERAGE()

• NON_NEGATIVE_DERIVATIVE()

• HOLT_WINTERS() dan HOLT_WINTERS_WITH_FIT()

Untuk informasi tentang cara menggunakan subkueri sebagai pengganti fungsi bersarang, lihat Eksplorasi data.

Bagaimana cara memigrasikan InfluxDB yang dikelola sendiri ke cloud?

Gunakan tool resmi InfluxDB influx_inspect untuk mengekspor file protokol baris dari server InfluxDB yang dikelola sendiri. Kemudian, gunakan antarmuka baris perintah (Influx CLI) untuk mengimpor file tersebut ke TSDB for InfluxDB®.

Bagaimana cara memigrasikan data antar instans InfluxDB yang berbeda di cloud?

Tidak ada tool migrasi bawaan antar instans InfluxDB. Ekspor data dengan kueri dan impor secara manual. Gunakan filter waktu dan tag untuk membatch migrasi dan hindari kueri besar yang memengaruhi stabilitas.

Bagaimana cara memigrasikan data dari InfluxDB ke LindormTSDB?

Impor data lengkap dari instans TSDB for InfluxDB® Anda ke LindormTSDB. Solusi migrasi data historis TSDB for InfluxDB®.