Lindorm 時系列データベース (LindormTSDB) に関するよくある質問 (データの書き込み、クエリ、削除、モニタリング、パフォーマンス、テーブル設計) を紹介します。ここに記載されていない質問がある場合は、DingTalk (ID: s0s3eg3) で Lindorm のテクニカルサポートにご連絡ください。
データの書き込み
LindormTSDB への最適なデータ書き込み方法
使用する言語によって異なります：
Java：LindormTSDB SDK for Java を使用します。書き込みは自動的にバッチ処理され、失敗した場合は再試行されます。
その他の言語：InfluxDB ラインプロトコルを使用します。
LindormTSDB がサポートする時間精度
LindormTSDB は、ミリ秒単位の精度で時間データを格納します。より高い精度 (マイクロ秒またはナノ秒) のデータは自動的にミリ秒に変換され、元の精度は失われます。
InfluxDB ラインプロトコルでのデータ書き込みに関する注意事項
引用符のルールと型のサフィックスにご注意ください：
タグキーとタグ値：値を一重引用符 (
'') または二重引用符 ("") で囲まないでください。これらはデフォルトで文字列として扱われ、引用符は値の一部になります。フィールドキー：引用符で囲まないでください。フィールドキーは常に文字列です。
フィールド値 (文字列)：二重引用符 (
"") で囲む必要があります。囲まないとエラーが報告されます。フィールド値 (整数)：
iサフィックスを付ける必要があります (例：12iまたは101i)。サフィックスがない場合、値は浮動小数点数として扱われます。
タグ列への NULL の書き込み
いいえ。代わりに、行を書き込む際にタグ列を省略してください。たとえば、sensor テーブルに device_id、region、time、temperature、humidity の列があり、region を null にしたい場合は、insert 文から省略します：
INSERT INTO sensor(device_id, time, temperature, humidity) VALUES ('id123', current_timestamp, 37, 70);データのクエリ
推奨されるクエリメソッド
Java Database Connectivity (JDBC) ドライバーと PreparedStatement を使用して LindormTSDB にクエリを実行することを推奨します。これにより、サーバーのリソース使用量が削減され、クエリのパフォーマンスが向上します。詳細については、「Lindorm の JDBC ドライバーを使用して LindormTSDB に接続し、使用する」をご参照ください。
データ書き込み後に結果が返されない理由
テーブルに生存時間 (TTL) が設定されているか確認してください。データを書き込んだ時刻がすでに TTL を過ぎている場合、データは期限切れとなり自動的に削除されるため、クエリは空の結果を返します。
ORDER BY LIMIT のパフォーマンスリスクとその回避方法
ORDER BY LIMIT は、一致した行をメモリ内でソートします。一致する行が多い場合、サーバーのメモリを大量に消費し、安定性に影響を与える可能性があります。メモリへの影響を最小限に抑えるには、時間範囲を狭めるか、タグ条件を追加して一致する行数を減らしてください。
追加のヒントが 2 つあります：
時系列データは、デフォルトで昇順で返されます。
ORDER BY time ASCは冗長なので追加しないでください。時系列から最新の行を取得するには、
ORDER BY time DESCの代わりにLATEST関数を使用してください。
WHERE 句で同じフィールド列に複数のフィルター条件を指定できるか
いいえ。同じフィールド列、または異なるフィールド列に対する複数のフィルター条件はサポートされていません。各フィールドフィルターのデータ読み取りはコストが高く、複数のフィールド列にまたがって適用することはできません。代わりにタグ列を使用してデータをフィルターしてください。
COUNT クエリの効率化
COUNT クエリで数値型のフィールド列を指定してください。
LindormTSDB SDK for Java でのクエリ実行時に Metaspace エラーが発生した場合の対処法
LindormTSDB SDK for Java を使用してデータをクエリする場合、SQL ステートメントをコンパイルする必要があり、大量の Metaspace を占有します。代わりに JDBC ドライバーと PreparedStatement を使用してデータをクエリするように切り替えてください。詳細については、「Lindorm の JDBC ドライバーを使用して LindormTSDB に接続し、使用する」をご参照ください。
連続クエリ (CQ) が有効にならない理由
一般的な原因は 2 つあります：
INSERT INTO文で指定されたターゲットテーブルが存在しない。ターゲットテーブルは存在するが、そのスキーマが
CREATE CONTINUOUS QUERY文で定義されたスキーマと一致しない。
お使いの LindormTSDB のバージョンが 3.4.41 以降の場合は、LindormTSDB コンソールログを確認して問題を診断してください。
クエリが遅い理由
クエリにタグ列のフィルターや時間範囲の指定がない場合、LindormTSDB は全表スキャンを実行します。これは大規模なデータセットでは低速になります。スキャンするデータを制限するために、タグフィルター、時間範囲、またはその両方を追加してください。
TSDBWorkPoolFullException が報告される理由
考えられる原因は 2 つあります：
非効率なクエリ：全表スキャンやその他の高コストなクエリがスレッドプールのスレッドを占有しています。クエリログを分析して遅いクエリを特定し、クエリ文を最適化してください。
スレッドプールの容量不足：CPU 使用率が 50% 未満の場合は、Lindorm のテクニカルサポート (DingTalk ID: s0s3eg3) に連絡してスレッドプールの容量を増やしてください。CPU 使用率が高い場合は、インスタンスのスペックをアップグレードしてください。
データの削除
時間範囲を指定してデータを削除できますか？
いいえ。削除操作はタグ条件のみをサポートしています。時間範囲やフィールド値によるデータ削除はできません。
多数の削除操作を実行するリスク
LindormTSDB は、削除された行をすぐに削除するのではなく、削除マーカーでマークします。行は TTL の有効期限が切れてデータが物理的に消去されるまで非表示のままです。多数の削除操作を行うと多くの削除マーカーが生成され、クエリのパフォーマンスが低下し、バックグラウンドでのデータマージが遅くなります。深刻な場合には、サービスが利用できなくなる可能性があります。
定期的にデータを消去するには、一括削除リクエストを発行するのではなく、テーブルの TTL 属性を設定してください。
特定のフィールド列のデータのみを削除できるか
いいえ。フィールドレベルの削除はサポートされていません。フィールドが不要になった場合は、そのフィールドのクエリを停止してください。未使用のフィールドをクエリから除外しても、クエリのパフォーマンスには影響しません。
モニタリング
LindormTSDB のホットストレージ使用量が定期的に減少する理由
LindormTSDB は、データ保持ポリシーに基づいて期限切れのデータを自動的にパージします。保持ポリシーが設定されていない場合、ストレージ使用量は定期的に減少することなく継続的に増加します。
機能とパフォーマンス
ディスクサイズ変更時の LindormTSDB の再起動の有無
いいえ。ディスクサイズの変更はどのプロセスも再起動せず、実行中のサービスに影響を与えません。
コールド・ホットデータ分離の境界設定が有効になるタイミング
データは、バックグラウンドのマージ操作中にコールドストレージにアーカイブされます。頻繁なコールドデータマージを防ぐため、LindormTSDB ではデータがアーカイブ可能になるまでに最低 7 日間の経過が必要です。したがって、コールドストレージポリシーは、データがアーカイブ条件を満たしてから 7 日後に有効になります。
コールドストレージからホットストレージへのデータ移動
いいえ。コールドストレージにアーカイブされたデータをホットストレージに戻すことはできません。実際のアクセスパターンに基づいてコールドストレージの保存期間を設定し、頻繁にクエリされるデータのアーカイブは避けてください。
テーブルレベルでのストレージ使用量のクエリ
いいえ。ストレージ使用量はデータベースレベルでのみ確認できます。テーブルレベルのストレージ使用量については、Lindorm のテクニカルサポート (DingTalk: s0s3eg3) にお問い合わせください。
圧縮率が想定より低い理由
圧縮に影響を与える一般的な 3 つの要因があります：
データ型：LindormTSDB は、整数 (
INT) データで最も高い圧縮率を達成します。テストデータセットに浮動小数点数や文字列データがほとんど含まれている場合、圧縮率は低くなります。ログのオーバーヘッド：データはメモリとログの両方に同時に書き込まれます。ログデータは一定量のストレージ領域を占有し、見かけ上の圧縮率を低下させます。
バックグラウンドマージの未完了：新しく書き込まれたデータは、10 時間以上かかるバックグラウンドマージの後にのみ圧縮されます。この期間が経過した後に圧縮率を測定してください。
時系列テーブルの設計
時系列テーブル設計時の注意事項
高カーディナリティを避けるために、タグ値は慎重に選択してください。タイムスタンプやプロセス ID のように頻繁に変化する値をタグとして使用しないでください。タグ値の一意な組み合わせごとに、個別の時系列とインデックスエントリが作成されます。タグのカーディナリティが高いと、追跡対象の時系列の数が増加し、クエリのパフォーマンスとストレージ効率の両方が低下します。