すべてのプロダクト
Search

このプロダクト

    Time Series Database:よくある質問

    ドキュメントセンター

    Time Series Database:よくある質問

    最終更新日:May 28, 2026

    TSDB for InfluxDB® について、シリーズカーディナリティ、管理、データクエリ、書き込み、CLI の使用、データ型、InfluxQL 関数、移行に関するよくある質問とその回答をまとめています。

    トラブルシューティング

    シリーズとシリーズカーディナリティ

    管理

    データクエリ

    データ書き込み

    コマンドラインインターフェイス (Influx CLI)

    データ型

    InfluxQL 関数

    InfluxDB データ移行

    シリーズとシリーズカーディナリティ

    シリーズカーディナリティの重要性

    TSDB for InfluxDB® は、シリーズごとにインメモリインデックスを保持します。シリーズ数が増加すると、RAM 使用量も増加します。カーディナリティが過度に高くなると、メモリ不足 (OOM) 例外をトリガーし、プロセスが終了する可能性があります。「InfluxQL Reference」

    モデリングの方法と注意事項

    時系列の数を 100 万未満に保つようにしてください。大規模な時系列シナリオの場合は、LindormTSDB の概要を使用してください。InfluxDB のスキーマとデータレイアウトガイドを確認してください。InfluxDB はタグにインデックスを付けてクエリを高速化しますが、タグが多すぎるとシリーズ数が増加し、読み取りと書き込みが遅くなります。主な考慮事項は次のとおりです。

    • ID、ハッシュ値、ランダムな文字列など、高カーディナリティ値を持つタグの使用は避けてください。

    • メジャーメント名やタグ名にデータを格納しないでください。データはタグとフィールドに格納してください。

    • 1 つのタグに複数の情報を格納しないでください。情報を複数のタグに分割してください。

    • GROUP BY 句でフィールドを頻繁に使用する場合は、そのフィールドをタグとしてモデル化してください。

    管理

    システムの安定性のために注意すべき点は何ですか？

    メジャーメントのディスク使用率を確認するにはどうすればよいですか？

    ディスク使用率はメジャーメントレベルでは確認できません。メジャーメントは論理的な概念であり、同じデータベース内のすべてのメジャーメントは、基礎となるデータファイルを共有します。

    データを効率的かつ安全に削除するにはどうすればよいですか？

    InfluxDB の drop measurement、drop series、および delete 操作は論理削除を行いますが、これらには次の欠点があります。

    • InfluxDB 1.x は、コード実装レベルでデッドロックが発生する可能性があります。

    • クエリでは削除された時系列を除外する必要があり、クエリ効率に深刻な影響を与えます。

    • 論理削除ではディスク領域をすぐに解放できません。バックグラウンドでのデータマージスケジューリングを待つ必要があり、これにより領域の解放が遅くなります。

    保持ポリシーを変更して古いデータを削除するか、drop shard または drop database を使用して物理削除を実行してください。

    変更した保持ポリシーが有効にならないのはなぜですか？

    v1.8.13 以降では、保持ポリシーの変更はすぐに有効になります。変更が有効にならない場合は、以下を確認してください。

    • バージョンが v1.8.12 以前かどうかを確認してください。以前のバージョンでは、保持ポリシーの変更にはバックグラウンドスケジューリングが必要です。30 分から 60 分お待ちください。

    • シャードが広い時間範囲をカバーしています。show shardsを実行して確認してください。シャードは、現在時刻がシャードの終了時刻を超えた後にのみ削除できます。

    サービスが頻繁に中断するのはなぜですか？

    メモリ使用量を確認してください。80% を超えると、OOM エラーによってプロセスが停止する可能性があります。FAQ: メモリ使用量が高いのはなぜですか？ で原因を特定するか、インスタンスをアップグレードしてください。

    メモリ使用量が高い場合、アップグレードは必要ですか？

    メモリ使用量が高くなる一般的な原因は次のとおりです。

    • 時系列の数が多い。インデックスのマージには大量のメモリが消費されます。時系列数は 100 万未満にしてください。大規模な時系列シナリオの場合は、LindormTSDB の概要 をご検討ください。

    • データ量が多い、またはシャードが多い。データが多いほど、ファイルマージによるメモリへの負荷が増加し、再起動時間が長くなります。FAQ: データを効率的かつ安全に削除する方法 に従ってデータを削減してください。大規模ストレージの場合は、LindormTSDB の概要 をご検討ください。

    • 大規模なクエリ。大規模なクエリは避けてください。タグと時間フィルターを追加して、スキャン範囲を縮小してください。

    • Grafana をクエリに使用する場合、グラフの設定時に Grafana が show tag keys クエリを発行することで、OOM エラーが発生する可能性があります。show tag keys クエリを無効にするには、v1.8.13 以降にアップグレードしてください。

    それでもメモリ使用量が 80% を超える場合は、インスタンスをアップグレード してください。インスタンスのアップグレードまたはダウングレード。

    ストレージのスケールインはサポートされていますか？

    InfluxDB のディスクはスケールインをサポートしていません。

    ディスクを拡張すると再起動が発生しますか？

    ディスクを拡張すると、InfluxDB プロセスが再起動します。Basic Edition インスタンスは短時間利用できなくなる可能性があります。High-availability Edition インスタンスはローリングリスタートを実行するため、通常はサービスへの影響はありません。

    再起動にはどのくらいの時間がかかりますか？

    再起動時間はデータ量に依存します。データが多いほど再起動に時間がかかります。

    InfluxDB の内蔵 Grafana はサポートされていますか？

    代わりに Alibaba Cloud の Managed Service for Grafana を使用してください。InfluxDB の内蔵 Grafana は古く、現在はメンテナンスされていません。

    アクセス時に ip block エラーが発生するのはなぜですか？

    v1.8.12 以前のバージョンでは、パスワードの試行失敗が多すぎると、一時的に IP アドレスがブロックされます。v1.8.13 以降にアップグレードしてください。

    TSDB for InfluxDB® のバージョンを識別するにはどうすればよいですか？

    次のいずれかの方法で確認できます。

    • 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

    • TSDB for InfluxDB® のコマンドラインインターフェイスを開始します

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

Connected to https://<endpoint>:3242 version 1.7.x

    シャードグループ期間と保持ポリシーの関係

    TSDB for InfluxDB® は、シャードグループにデータを格納します。シャードグループは、特定の期間を対象とします。TSDB for InfluxDB® は、関連する保持ポリシー (RP) の DURATION を確認して期間を決定します。次の表に、RP の DURATION とシャードグループの期間のデフォルトの関係を示します。

    RP 期間

    シャードグループの時間間隔

    < 2 日

    1 時間

    >= 2 日かつ <= 6 か月

    1 日

    > 6 か月

    7 日

    保持ポリシーのシャードグループの期間を表示するには、SHOW RETENTION POLICIES を使用します。

    保持ポリシーを変更してもデータが失われないのはなぜですか？

    保持ポリシーを変更しても、次の理由によりデータがすぐに失われない場合があります。

    • 考えられる最初の理由 (最も可能性の高いシナリオ): デフォルトでは、TSDB for InfluxDB® は 30 分ごとに RP をチェックして適用します。RP の新しい DURATION の範囲外にあるデータは、次回の RP チェックが行われるまで TSDB for InfluxDB® によって削除されないため、待機する必要がある場合があります。

    • 2つ目の考えられる理由: RP の DURATION と SHARD DURATION を変更すると、予期しないデータ保持が発生する可能性があります。 TSDB for InfluxDB® は、データをシャードグループに格納します。 各シャードグループは、特定の RP と時間間隔を対象とします。 TSDB for InfluxDB® が RP を適用する際、個々のデータポイントではなく、シャードグループ全体を削除します。 TSDB for InfluxDB® はシャードグループを分割できません。 RP の新しい DURATION が古い SHARD DURATION よりも短く、かつ TSDB for InfluxDB® がより長い DURATION を持つ古いシャードグループにデータを書き込んでいる場合、システムはそのシャードグループ内のすべてのデータを格納せざるを得なくなります。 これは、シャードグループ内の一部のデータが新しい DURATION の範囲外であっても発生します。 シャードグループ内のすべてのデータが新しい DURATION の範囲外になると、TSDB for InfluxDB® はシャードグループ全体を削除します。 その後、システムは新しい、より短い SHARD DURATION を持つシャードグループへのデータの書き込みを開始します。 これにより、それ以上の予期しないデータ保持が回避されます。

    TSDB for InfluxDB® がマイクロ秒単位を解析できないのはなぜですか？

    マイクロ秒の時間単位を指定するための構文は、TSDB for InfluxDB® のコマンドラインインターフェイス (Influx CLI) での書き込み、クエリ、精度の設定で異なります。次の表に、各カテゴリでサポートされている構文を示します。

    HTTP API によるデータ書き込み

    すべてのクエリ

    Influx CLI での精度設定

    u

    √

    √

    √

    us

    ❌

    ❌

    ❌

    µ

    ❌

    √

    ❌

    µs

    ❌

    ❌

    ❌

    データクエリ

    低速クエリのトラブルシューティング方法

    低速クエリは、通常、スキャンする時系列や生データが多すぎることが原因で発生します。すべてのクエリにタグおよび時間範囲フィルターを追加してください。EXPLAIN ANALYZE コマンドを使用してパフォーマンスを診断します。execution_time はデータの読み取りと計算を、planning_time は系列のスキャンを反映します。

    GROUP BY time() クエリで返される時間間隔を決定する要素

    GROUP BY time() クエリが返す時間間隔は、TSDB for InfluxDB® のプリセットの時間バケット、またはユーザー指定のオフセット間隔と一致します。以下の例をご参照ください。

    • 事前設定された時間バケット

      次のクエリは、午後 6:15 から 7:45 までの sunflowers の平均を計算し、1 時間ごとにグループ化します。

      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® が事前設定された時間バケットを維持する方法を示しています。

      この例では、午後 6 時はあらかじめ設定された時間バケットであり、午後 7 時もあらかじめ設定された時間バケットです。WHERE 句がクエリの時間範囲を指定しているため、午後 6 時の時間バケットの平均を計算する際に、午後 6 時 15 分より前のデータは含まれません。ただし、午後 6 時の時間バケットの平均を計算するために使用されるデータは、午後 6 時台に発生したものでなければなりません。午後 7 時の時間バケットにも同じことが当てはまります。午後 7 時の時間バケットの平均を計算するために使用されるデータは、午後 7 時台に発生したものでなければなりません。破線は、各平均の計算に使用されたデータポイントを示しています。

      結果の最初のタイムスタンプは 2016-08-29T18:00:00Z ですが、そのタイムバケットのクエリ結果には、WHERE 句で指定された開始時刻 2016-08-29T18:15:00Z より前のデータは含まれない点にご注意ください。

      生データ：

      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

    • オフセット間隔

      次のクエリでは、午後 6:15 から 7:45 までの sunflowers の平均を計算して 1 時間ごとにグループ化し、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 分前方にシフトします。この結果、午後 6 時のタイムバケットの平均値には、午後 6 時 15 分から午後 7 時 15 分までのデータが含まれるようになります。午後 7 時のタイムバケットの平均値には、午後 7 時 15 分から午後 8 時 15 分までのデータが含まれるようになります。破線は、各平均値の計算に使用されたデータポイントを示しています。

      結果の最初のタイムスタンプが 2016-08-29T18:00:00Z ではなく 2016-08-29T18:15:00Z になったことにご注意ください。

      生データと結果：

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

    クエリでデータが返されない、または一部のデータしか返されないのはなぜですか？

    一般的な原因は次のとおりです：

    • 保持ポリシー

      最も一般的な最初の説明は、保持ポリシー (RP) に関するものです。 TSDB for InfluxDB® は、データベースの DEFAULT RP からデータを自動的にクエリします。 データがデフォルトの RP に保存されていない場合、使用する RP を明示的に指定しない限り、TSDB for InfluxDB® は結果を返しません。

    • SELECT 句のタグキー

      クエリがデータを返すには、SELECT 句に少なくとも 1 つのフィールドキーを含める必要があります。SELECT 句に 1 つ以上のタグキーのみが含まれている場合、クエリは空の結果を返します。詳細については、「データ探索」をご参照ください。

    • クエリの時間範囲

      考えられるもう 1 つの説明は、クエリの時間範囲に関連しています。 デフォルトでは、ほとんどの 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() 以降に発生するデータがある場合は、時間範囲の上限を指定する必要があります。

    • 識別子名

      最後によくある原因として、スキーマにおいてフィールドとタグが同じ名前を持つケースが挙げられます。フィールドキーとタグキーが同一の場合、すべてのクエリでフィールドが優先されます。クエリでタグキーを指定するには、::tag 構文を使用する必要があります。

    GROUP BY time() クエリで now() 以降のタイムスタンプが返されないのはなぜですか？

    ほとんどの 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() 以降のタイムスタンプを持つデータをクエリするために、SELECT 文で GROUP BY time() 句を使用する場合、WHERE 句に時間の上限を指定する必要があります。

    以下の例では、最初のクエリはタイムスタンプが 2015-09-18T21:30:00Z から now() までのデータを対象とします。2 番目のクエリは、タイムスタンプが 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)
>

    time 構文の詳細については、「Data exploration」をご参照ください。

    タイムスタンプに対して数学演算を実行できますか？

    TSDB for InfluxDB® は、タイムスタンプに対する数学演算をサポートしていません。時間計算はクライアント側で実行してください。

    TSDB for InfluxDB® では、タイムスタンプに対して使用できる InfluxQL 関数は限定されています。ELAPSED() 関数は、単一フィールド内のタイムスタンプ間の差分を返します。

    返されるタイムスタンプから書き込み精度を特定できますか？

    TSDB for InfluxDB® は、書き込み精度にかかわらず、すべてのタイムスタンプをナノ秒で保存します。データベースは、返されるタイムスタンプの末尾の 0 を暗黙的に削除するため、元の書き込み精度を特定することは困難です。

    次の例では、タグ precision_supplied および timestamp_supplied は、ユーザーがデータを書き込むときに指定した時間精度とタイムスタンプを示します。 TSDB for InfluxDB® は返されたタイムスタンプから末尾のゼロを自動的に削除するため、返されたタイムスタンプから書き込み精度を特定することは困難です。

    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

    データをクエリする際、シングルクォーテーションとダブルクォーテーションはいつ使用しますか？

    タグ値などの文字列値は、シングルクォーテーションで囲みます。識別子はシングルクォーテーションで囲まないでください。識別子には、データベース名、保持ポリシー名、ユーザー名、メジャメント名、タグキー、フィールドキーが含まれます。

    識別子が数字で始まる場合、[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"

    time 構文の詳細については、「Data exploration」をご参照ください。

    新しい DEFAULT 保持ポリシーを作成した後にデータが失われるのはなぜですか？

    データベースで新しいデフォルト保持ポリシー (RP) を作成した場合、古いデフォルト RP のデータは古い RP に残ります。RP を指定しないクエリは、新しいデフォルト RP からデータを自動的にクエリするため、古いデータがすべて失われたように見える場合があります。古いデータをクエリするには、クエリでデータを完全修飾する必要があります。次の例をご参照ください：

    メジャーメント fleeting 内のすべてのデータは、one_hour という名前のデフォルト RP に属します:

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

    次に、新しいデフォルト 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:00Z     8

    WHERE OR time 句を含むクエリで結果が空になるのはなぜですか？

    TSDB for InfluxDB® は、OR を WHERE 句で使用して複数の時間範囲を指定することをサポートしていません。クエリの 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:00Z   3
2016-07-12T16:50:10Z   2
2016-07-12T16:50:40Z   12
2016-07-12T16:50:50Z   11

    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

    INTO クエリでデータが失われるのはなぜですか？

    デフォルトでは、INTO クエリはソースデータのタグを新しく書き込まれたデータのフィールドに変換します。これにより、TSDB for InfluxDB® が、以前はタグによって区別されていたデータポイントを上書きする可能性があります。新しく書き込まれたデータ内のタグを保持するには、すべての INTO クエリに GROUP BY * を含めます。

    説明

    この方法は、TOP() または BOTTOM() クエリには適用されません。これらの関数は、InfluxDB 関数に記載されています。

    サンプルデータ

    メジャーメント french_bulldogs には、タグ color とフィールド 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 クエリ

      INTO クエリに GROUP BY * 句がない場合、タグ color は新しく書き込まれたデータ内のフィールドに変換されます。 ソースデータでは、データポイント nugget と rumple は、タグ color によってのみ区別されます。 color がフィールドになると、TSDB for InfluxDB® はデータポイント nugget と rumple を重複とみなします。 その結果、データポイント nugget はデータポイント 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                <---- no more nugget
2016-05-25T00:10:00Z  black  prince

    • GROUP BY * ありの INTO クエリ

      GROUP BY * 句を含む INTO クエリは、新しく書き込まれたデータ内でタグ color を保持します。この場合、データポイント nugget と rumple は別個のデータポイントとして残り、TSDB for InfluxDB® はデータを上書きしません。

      > 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

    タグキーとフィールドキーの名前が同じ場合、データをどのようにクエリしますか？

    キーがフィールドキーかタグキーかを指定するには、:: 構文を使用します。サンプルデータ:

    > 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

    • キーがフィールドであることを指定

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

    • キーがタグであることを指定

      > 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

    メジャメントをまたいでデータをクエリするにはどうすればよいですか？

    メジャメントをまたいだ数値演算やグループ化はサポートされていません。すべてのデータは同じメジャメント内にある必要があります。TSDB for InfluxDB® はリレーショナルデータベースではありません。メジャメントをまたいでデータをマッピングすることは避けてください。

    タイムスタンプの順序は重要ですか？

    いいえ。テスト結果から、TSDB for InfluxDB® が次のクエリを完了するまでにかかる時間には、ほとんど差がないことがわかっています：

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

    SELECT タグキーはあるがタグ値がないデータを取得する方法

    空のタグ値を指定するには、'' を使用します。例：

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

    データ書き込み

    書き込みジッターが定期的に発生するのはなぜですか？

    書き込みジッターは、TSDB for InfluxDB® がパーティションを切り替える際に発生します。ジッターの周期が保持ポリシーのシャードグループ期間と同じかどうかを確認できます。メジャメント数と時系列数を減らすことで、ジッターの振れ幅を抑えられます。

    ラインプロトコル書き込み時の注意事項

    ラインプロトコルで書き込む際は、次の点に注意してください：

    • 整数を指定するには、数値に i を付加します。 たとえば、 value=100i は整数であり、 value=100 は浮動小数点数です。

    • ダブルクォーテーションは、文字列のフィールド値にのみ使用します。メジャメント、タグキー、タグ値、フィールドキーに含まれるダブルクォーテーションは、名前の一部として扱われます。

    • 特殊文字は、クォーテーションで囲むのではなく、バックスラッシュでエスケープしてください。

    書き込み後にデータが表示されないのはなぜですか？

    InfluxDB は、リテンションポリシーに従って期限切れのデータを破棄します。partial write: points beyond retention policy が表示された場合は、書き込みタイムスタンプをリテンションポリシーの TTL と照らし合わせて確認してください。

    ディスクがフルの状態から空き容量を確保しても書き込みが再開されないのはなぜですか？

    InfluxDB のディスクがフルになると、書き込みが失敗し、空き容量を確保しても自動的には再開されません。スケールアウトするかデータを削除した後、コンソールからプロセスを再起動してください。

    整数のフィールド値はどのように書き込みますか？

    整数を書き込むには、フィールド値の末尾に i を付加します。i を付加しない場合、TSDB for InfluxDB® はフィールド値を浮動小数点数として扱います。

    整数を書き込むには、value=100i とします。 浮動小数点数を書き込むには、value=100 とします。

    TSDB for InfluxDB® は重複するデータポイントをどのように処理しますか？

    データポイントは、メジャメント名、タグセット、およびタイムスタンプによって一意に識別されます。既存のデータポイントと同じメジャメント、タグセット、タイムスタンプを持ち、かつフィールドセットが異なるデータポイントを送信した場合、そのデータポイントのフィールドセットは、古いフィールドセットと新しいフィールドセットの和集合になります。競合がある場合は、新しいフィールドセットが優先されます。これは想定される動作です。

    例：

    古いデータポイント：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® によって 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.24  7

    両方のデータポイントを保存するには、次のいずれかを実行します：

    • 一意性を確保するために、新しいタグを追加します。

      古いデータポイント: 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   1      24.5    7
1970-01-15T06:56:07.89Z   us_west   server02   2      5.24

    • タイムスタンプを 1 ナノ秒インクリメントします。

      古いデータポイント：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.5   7
1970-01-15T06:56:07.890000001Z   us_west   server02   5.24

    HTTP API に必要なラインフィードは何ですか？

    TSDB for InfluxDB® のラインプロトコルでは、改行文字 (\n、ASCII 0x0A) が 1 行の終わりと新しい行の始まりを示します。\n 以外の改行文字を使用するファイルまたはデータでは、bad timestamp または unable to parse エラーが発生します。

    Windows では \r\n (キャリッジリターン + ラインフィード) を使用するため、互換性がありません。

    TSDB for InfluxDB® にデータを書き込む際、避けるべき単語や文字は何ですか？

    • InfluxQL キーワード

      InfluxQL キーワードを識別子として使用する場合は、すべてのクエリでその識別子をダブルクォーテーションで囲む必要があります。使用しないとエラーになります。識別子には、継続クエリ名、データベース名、フィールドキー、メジャメント名、保持ポリシー名、タグキー、ユーザー名が含まれます。

    • Time

      キーワード time は特殊なケースです。time は、継続的なクエリ名、データベース名、メジャメント名、リテンションポリシー名、およびユーザー名にすることができます。これらのケースでは、クエリで time をダブルクォーテーションマークで囲む必要はありません。time は、フィールドキーまたはタグキーにすることはできません。TSDB for InfluxDB® は、フィールドキーまたはタグキーとして time を使用するデータの書き込みを拒否します。このような書き込みに対して、TSDB for InfluxDB® はエラーを返します。次の例をご参照ください。

      • time をメジャメントとしてデータを書き込み、クエリします。

        > INSERT time value=1

> SELECT * FROM time

name: time
time                            value
---------
2017-02-07T18:28:27.349785384Z  1

        TSDB for InfluxDB® では、time は有効なメジャーメント名です。

      • time をフィールドキーとしてデータを書き込み、クエリを試行します。

        > 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 は有効なフィールドキーではありません。システムはデータポイントを書き込むことができず、400 エラーを返します。

      • time をタグキーとしてデータを書き込み、クエリを試行します。

        > 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 は有効なタグキーではないため、システムはデータポイントを書き込むことができず、400 エラーを返します。

    • 文字

      正規表現とクォーティングを簡潔に保つため、識別子には次の文字を使用しないでください: \ (バックスラッシュ)、^ (キャレット)、$ (ドル記号)、' (単一引用符)、" (二重引用符)、= (等号)、および , (コンマ)。

    データを書き込む際、シングルクォーテーションとダブルクォーテーションはいつ使用しますか？

    • ラインプロトコルで書き込む際は、識別子をクォーテーションで囲まないでください。クエリが複雑になります。識別子には、継続クエリ名、データベース名、フィールドキー、メジャメント名、保持ポリシー名、サブスクリプション名、タグキー、ユーザー名が含まれます。

      • メジャーメント名を二重引用符で囲んで書き込みます: INSERT "bikes" bikes_available=3。 対応するクエリ: SELECT * FROM "\"bikes\""

      • メジャーメントを単一引用符で囲んで書き込みます： INSERT 'bikes' bikes_available=3。 対応するクエリ： SELECT * FROM "\'bikes\'"

      • メジャメントを引用符なしで書き込みます: INSERT bikes bikes_available=3。該当するクエリ: SELECT * FROM "bikes"

    • 文字列のフィールド値は、ダブルクォーテーションで囲みます。

      書き込み: INSERT bikes happiness="level 2"。対応するクエリ: SELECT * FROM "bikes" WHERE "happiness"='level 2'

    • 特殊文字は、クォーテーションで囲むのではなく、バックスラッシュでエスケープしてください。

      書き込み: INSERT wacky va\"ue=4。適用可能なクエリ: SELECT "va\"ue" FROM "wacky"

    タイムスタンプの精度は重要ですか？

    書き込みパフォーマンスを最適化するには、可能な限り粗い時間精度を使用してください。

    次の 2 つの例では、1 つ目のリクエストはデフォルトの精度 (ナノ秒) を使用し、2 つ目のリクエストは精度を秒に設定しています：

    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'

    トレードオフ：精度を粗くすると、タイムスタンプの重複が発生する可能性が高くなり、データの上書きが発生する場合があります。

    コマンドラインインターフェイス (Influx CLI)

    コマンドラインインターフェイスで TSDB for InfluxDB® に接続できない問題

    次の条件を 1 つずつ確認してください：

    • 実行権限が必要です。chmod +x ./influx コマンドを実行して権限を追加できます。

    • 接続ステートメントで -ssl オプションを指定する必要があります。

    • -host オプションには、ts-bp17j28j2y7pm****.influxdata.rds.aliyuncs.com のような接続文字列のみを指定します。プロトコルとポート番号は追加しないでください。

    Influx CLI で人間が判読可能な形式のタイムスタンプを返す方法

    Influx CLI に初めて接続する際に、rfc3339 の精度を指定します：

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

    または、Influx CLI に接続した後に精度を指定します：

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

    詳細については、「コマンドラインインターフェイス (Influx CLI)」をご参照ください。

    非管理者ユーザーが USE ステートメントでデータベースを指定する方法

    非管理者ユーザーが、データベースに対する READ および WRITE 権限、または READ 権限のみを持っている場合、USE <database_name> ステートメントを実行できます。 非管理者ユーザーが USE を使用して、READ および WRITE 権限、または READ 権限のないデータベースを指定しようとすると、システムはエラーを返します:

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

    SHOW DATABASES クエリは、非管理者ユーザーが READ または WRITE 権限を持つデータベースのみを返します。

    Influx CLI を使用してデフォルト以外の保持ポリシーにデータを書き込む方法

    デフォルト以外のリテンションポリシーにデータを書き込むには、構文 INSERT INTO [<database>.]<retention_policy> <line_protocol> を使用します。(このデータベースとリテンションポリシーの指定方法は、Influx 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

    デフォルト以外の保持ポリシーのデータをクエリするには、メジャーメントを次の構文で完全修飾する必要があります：

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

    データ型

    ブール値のフィールド値をクエリできないのはなぜですか？

    ブール値の書き込みとクエリでは、構文が異なります。

    ブール値の構文

    書き込み

    クエリ

    t、f

    √

    ❌

    T、F

    √

    ❌

    true、false

    √

    √

    True、False

    √

    √

    TRUE、FALSE

    √

    √

    たとえば、SELECT * FROM "hamlet" WHERE "bool"=True は、bool が TRUE と等しいすべてのデータポイントを返します。一方、SELECT * FROM "hamlet" WHERE "bool"=T は結果を返しません。

    TSDB for InfluxDB® は、シャード間でフィールド型が一致しない場合をどのように処理しますか？

    フィールド値は、浮動小数点数、整数、文字列、またはブール値です。シャード内では、フィールド値のデータ型は一致している必要があります。一方、異なるシャード間では、フィールド値のデータ型が異なる場合があります。

    • SELECT 文

      SELECT 文は、デフォルトでは同じデータ型のフィールド値をすべて返します。異なるシャード間でフィールド値のデータ型が一致しない場合、TSDB for InfluxDB® は、可能であれば最初に型変換を実行します。その後、浮動小数点数、整数、文字列、ブール値の順に、すべての値を返します。データ内でフィールド値の型が異なる場合は、<field_key>::<type> 構文を使用して、異なるデータ型をクエリします。次の例をご参照ください：

      メジャメント just_my_type には、my_field という名前のフィールドがあります。my_field には、4 つの異なるシャードに 4 つのフィールド値があり、それぞれのフィールド値のデータ型は異なります (浮動小数点数、整数、文字列、ブール値)。

      SELECT は、浮動小数点数と整数のフィールド値のみを返します。結果では、TSDB for InfluxDB® が整数を浮動小数点数に強制的に変換します。

      > 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> [...] は、すべてのデータ型を返します。TSDB for InfluxDB® は、型ごとのデータを個別の列に出力し、列名をインクリメントします。可能な場合、TSDB for InfluxDB® はフィールド値を別のデータ型に変換します。1 列目では整数 7 を浮動小数点数に変換し、2 列目では浮動小数点数 9.87034 を整数に変換します。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:00Z   9.87034   9
2016-06-03T16:45:00Z   7         7
2016-06-03T17:45:00Z                         a string
2016-06-03T18:45:00Z                                     true

    • SHOW FIELD KEYS クエリ

      SHOW FIELD KEYS は、フィールドキーに対応する各シャードのすべてのデータ型を返します。次の例をご参照ください：

      メジャメント just_my_type には、my_field という名前のフィールドがあります。my_field には、4 つの異なるシャードに 4 つのフィールド値があり、それぞれのフィールド値のデータ型は異なります (浮動小数点数、整数、文字列、ブール値)。

      SHOW FIELD KEYS は、4 つすべてのデータ型を返します：

      > 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 の最小および最大の有効値は、それぞれ -9223372036854775808 と 9223372036854775807 です。詳細については、Go builtins をご参照ください。

    最小値または最大値に近い値であっても範囲内の値を使用すると、想定外の結果になる場合があります。一部の関数と演算子は、計算中に int64 データ型を float64 に変換するため、オーバーフローが発生する場合があります。

    TSDB for InfluxDB® が保存できるタイムスタンプの最小値と最大値は何ですか？

    タイムスタンプの最小値は -9223372036854775806 または 1677-09-21T00:12:43.145224194Z、最大値は 9223372036854775806 または 2262-04-11T23:47:16.854775806Z です。この範囲外のタイムスタンプは解析エラーを返します。

    フィールドに保存されているデータ型はどのように確認しますか？

    SHOW FIELD KEYS クエリは、フィールドのデータ型も返します。

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

    フィールドのデータ型を変更できますか？

    TSDB for InfluxDB® は、フィールドのデータ型変更を限定的にサポートしています。<field_key>::<type> 構文では、フィールド値を整数から浮動小数点数に変換する、または浮動小数点数から整数に変換することができます。変換の詳細は Data exploration に記載されています。浮動小数点数または整数を文字列やブール値に変換すること、およびその逆はできません。

    フィールドのデータ型を変更する方法：

    • 別のフィールドにデータを書き込む

      最も簡単な方法は、同じシリーズ内の別のフィールドに、新しいデータ型でデータを書き込むことです。

    • シャードシステムを使用する

      シャード内では、フィールド値のデータ型を変えることはできません。一方、異なるシャード間では、フィールド値のデータ型を変えられます。

      フィールドのデータ型を変更するには、SHOW SHARDS クエリを使用して、現在のシャードの end_time を特定します。データポイントのタイムスタンプが end_time よりも後の場合、TSDB for InfluxDB® は既存のフィールドへの異なるデータ型の書き込みを許可します。たとえば、元々は整数を受け付けていたフィールドでも、end_time の後は浮動小数点数を受け付けられます。

      なお、この操作では、元のシャード内のフィールドのデータ型は変更されません。

    InfluxQL 関数

    関数内で数学演算を実行するにはどうすればよいですか？

    TSDB for InfluxDB® は、関数内での数学演算をサポートしていません。回避策としてサブクエリを使用してください：

    InfluxQL は次の構文をサポートしていません：

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

    代わりに、サブクエリを使用して同じ結果を得ることができます：

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

    サブクエリの詳細については、「データ探索」をご参照ください。

    クエリがタイムスタンプとしてエポック 0 を返すのはなぜですか？

    TSDB for InfluxDB® では、エポック 0 (1970-01-01T00:00:00Z) は、しばしば null タイムスタンプとして使用されます。時間範囲が指定されていない集計関数など、タイムスタンプを返せないクエリをリクエストすると、TSDB for InfluxDB® はタイムスタンプとしてエポック 0 を返します。

    ネストをサポートしている InfluxQL 関数はどれですか？

    次の InfluxQL 関数はネストをサポートしています：

    • ネストされた DISTINCT() を含む COUNT()

    • CUMULATIVE_SUM()

    • DERIVATIVE()

    • DIFFERENCE()

    • ELAPSED()

    • MOVING_AVERAGE()

    • NON_NEGATIVE_DERIVATIVE()

    • HOLT_WINTERS() および HOLT_WINTERS_WITH_FIT()

    ネストされた関数の代わりにサブクエリを使用する方法については、「データ探索」をご参照ください。

    InfluxDB データ移行

    セルフマネージド InfluxDB のクラウドへの移行

    InfluxDB 公式の influx_inspect ツールを使用して、セルフマネージド InfluxDB サーバーからラインプロトコルファイルをエクスポートします。次に、コマンドラインインターフェイス (Influx CLI) を使用して、ファイルを TSDB for InfluxDB® にインポートします。

    クラウド上の異なる InfluxDB インスタンス間でのデータ移行

    InfluxDB インスタンス間に組み込みの移行ツールはありません。クエリを使用してデータをエクスポートし、手動でインポートしてください。時間およびタグフィルターを使用してバッチで移行し、安定性に影響を与える大規模なクエリは避けてください。

    InfluxDB から LindormTSDB へのデータ移行

    TSDB for InfluxDB® インスタンスから LindormTSDB に全量データをインポートします。詳細については、「TSDB for InfluxDB® の履歴データ移行ソリューション」をご参照ください。