HUAWEI CLOUD GaussDB（Influx用）の謎を解き明かす：ベストプラクティスのデータモデリング

要約： この問題は、GaussDB（Influx用）データモデルから始まり、GaussDB（Influx用）データモデリングの最良の方法を共有し、使用プロセスにおけるいくつかの一般的な問題を回避します。

この記事は、Huawei CloudCommunity「HuaweiCloudGaussDB（for Influx）Revealing Issue 7：Best Practice Data Modeling」、作成者：GaussDBデータベースから共有されています。

HUAWEI CLOUDのGaussDB（Influx用）時系列データベースは、大量の時系列データを使用する産業用IoTシナリオに、データセキュリティ、高性能、低ストレージコスト、およびO＆Mフリー機能を提供します。企業からますます注目を集めています。シンプルなどの機能SQLのようなクエリステートメントを使用し、スキーマデザインを必要とせず、迅速なビジネスの反復に適していることが、開発者によってますます認識されています。

ただし、ビジネスの規模が拡大し続けると、タイムラインの急増、クエリの待ち時間の長さ、タグやフィールドと同じ名前のデータクエリがときどき発生するなどの問題も発生します。根本的な理由は、適切なデータモデルがないことです。使用中のデザイン。この問題は、GaussDB（Influx用）データモデルから始まり、GaussDB（Influx用）データモデリングの最良の方法を共有し、使用プロセスにおけるいくつかの一般的な問題を回避します。

01データモデルと重要な概念 

データベース

これは、MySQLのデータベースと同じ概念です。

作成コマンド：CREATEDATABASE"mydb"。

ユーザー権限とデータ保持ポリシーは、データベースの粒度で設定されます。たとえば、ユーザーに「mydb」データベースへの読み取り専用権限を付与します。GRANTread ON mydbTOusername。

計測

MySQLのテーブルの概念に似ています。違いは、GaussDB（Influx用）はスキーマレスであり、測定値を事前に作成する必要がなく、テーブルのフィールドとタイプを設計する必要もないことです。データが書き込まれると測定値が自動的に作成され、フィールドは任意に加算または減算できますが、同じフィールドのデータ型は一貫している必要があります。

保持ポリシー（RP）

データ保持ポリシーは、リレーショナルデータベースには存在しない概念であり、時系列シナリオ用に特別に設計されています。つまり、データベース内のデータの最大保持時間が指定され、期限切れのデータが自動的にクリーンアップされます。

鬼ごっこ

データソース識別子、文字列型のみをサポート

分野

インジケーター、サポート文字列、float、int、boolタイプを収集します

ラインプロトコル（データモデル）

図に示すように、GaussDB（Influxの場合）にデータを書き込む場合、1つのデータは、測定、Tag_key、Tag_value、Field_key、Field_value、およびタイムスタンプの6つの部分で構成されます。<Tag_key = Tag_value>は1つ以上、<Field_key = Field_value>は1つ以上にすることができ、各データにはタイムスタンプを付ける必要があります。

点

ポイントには通常、測定+タグ+フィールド+タイムスタンプの4つの部分が含まれます。たとえば、次のデータには2つのポイントが含まれています。

<monitorInfo，area=“葡萄花”，，device=“钻机A” pressure=1.8，level=35 1650443961100400200>
Point1：
<monitorInfo，area=“葡萄花”，device=“钻机A”，pressure=1.8 1650443961100400200>
Point2：
<monitorInfo，area=“葡萄花”，device=“钻机A”，level=35 1650443961100400200>

つまり、データに含まれるフィールドキーの数は、ポイントがいくつ存在するかと単純に見なすことができます。GaussDB（Influxの場合）では、データに1つのポイントまたは複数のポイントを含めることができます。

シリーズ（タイムライン）

GaussDB（Influxの場合）では、インジケーターとタグのセットの組み合わせをタイムラインと呼びます。タイムラインの下では、連続する時点でサンプリングされたデータは時系列データです。たとえば、次のデータがあります。

monitorInfo，area=”葡萄花”，device=”钻机A”，pressure=1.8，1650443961100400200
monitorInfo，area=”葡萄花”，device=”钻机B”，pressure=1.6，1650443961100400200
monitorInfo，area=”榆树林”，device=”钻机B”，pressure=1.7，1650443961100400200
monitorInfo，area=”榆树林”，device=”钻机A”，pressure=1.5，1650443961100400200

4つのタイムラインを表します。

Putaohua油田のリグAの圧力センサー（圧力）

Putaohua油田のリグBの圧力センサー（圧力）

ユシュリン油田のリグBの圧力センサー（圧力）

ユシュリン油田のリグAの圧力センサー（圧力）

02データモデリングのベストプラクティス 

多くの場合、データモデリングは、クエリをより単純かつ効率的にするために行われます。ほとんどのユースケースでは、次の設計ガイドラインをお勧めします。

1.タグとフィールドの合理的なデザイン

• タグは文字列型のみをサポートします。数値データとブールデータはフィールドとして設計する必要があります。
• 一般的なクエリ条件とグループ化条件をタグとして設計します。

タグはインデックスを作成し、フィールドにはインデックスがないためです。たとえば、ビジネスでは、特定のマシンの平均CPU使用率が頻繁に照会されます。

SELECT mean(cpu)
FROM monitor
WHERE host=“192.168.1.1” AND time > now() – 1h

または、風力発電所の各風力タービンの1時間あたりの平均発電量を照会します。

SELECT mean(elect)
FROM monitor
WHERE farm_id=“737f738a-bd63” AND time > now() – 24h
GROUP BY time(1h)，device_id

文字列タイプをTagに設定できる場合は、上記のクエリステートメントのhost、farm_id、device_idをTagに設定する必要があります。

• timeは組み込みのキーワードであり、Tag_keyおよびField_keyとして使用することはできません。
• InfluxQL関数（最大、最小、カウントなど）を使用するフィールドは、フィールドとして保存されます。

2.Tag_KeyおよびField_Keyの命名規則に従います

• タグとフィールドのキー（名前）として予約済みのキーワードを使用しないでください。
• タグとフィールドは同じ名前を使用しません。同じ名前を使用しないと、予期しない問題が発生します。
• タグ名とフィールド名はできるだけ短く明確にする必要があります。これにより、インデックスのメモリスペースを節約し、クエリをより効率的にすることができます。
• IPアドレスやオペレーティングシステム名など、machine ="192.168.2.1-Ubuntu"などのタグでの多層的な意味は避けてください。hostとosの2つのタグに分割することをお勧めします。
• 少し変更を加えたデータをタグとして設定することをお勧めします。たとえば、プロセス名をタグに設定したり、プロセスIDをフィールドに設定したりすることをお勧めします。

3.ノード仕様が処理できるタイムラインの数を超えないようにします

GaussDB（Influxの場合）の仕様とタイムラインの数の対応する関係は次のとおりです。

タイムラインが制限を超えると、パフォーマンスが急激に低下し、業務に影響を与える可能性があります。ノード容量の拡張を検討する必要があります。

4.テーブル内のタグやフィールドが多すぎないようにします

ロジスティクス車両監視データなど、同じタイプのビジネスデータを1つのテーブルに保存することをお勧めします。同じテーブルに配置されるビジネスデータが多すぎると、タグとフィールドの数が急増し、クエリの効率に直接影響します。フィールドが多すぎると、各フィールドの計算が個別に計算されるため、ファジークエリの実行時にクエリタイムアウトが発生する可能性があります。

5.同じ保持ポリシーにマルチユーザーデータを保存しないでください

異なるビジネスデータの有効期限は異なります。ビジネスの特定のニーズに応じて異なるRPに保存する必要があります。そうしないと、期限切れのデータを時間内に削除できず、ストレージスペースを占有するため、データストレージのコストが増加します。クエリの効率に影響します。

6.同じデータベースに複数のユーザーデータを保存しないでください

GaussDB（Influxの場合）の現在のアクセス許可制御の粒度はDBレベルであるため、同じデータベースにマルチユーザーデータが保存され、他のユーザーがデータにアクセスして変更する可能性があります。ユーザーごとに別々のデータベースを使用し、1人のユーザーにのみアクセスを許可することをお勧めします。

03まとめ_ 

製造、エネルギー、農業、電力などの産業用IoT業界では、ほとんどのデジタル情報システムはMySQLなどのリレーショナルデータベースに基づいて構築されています。しかし、エンタープライズビジネスと規模のさらなる拡大、およびデータ量の急速な増加に伴い、MySQLなどのリレーショナルデータベースは、同時実行性、ストレージコスト、クエリパフォーマンス、スケーラビリティ、メンテナンスなどの多くの問題に直面し、徐々に時間に取って代わられています。シリーズデータベース。

GaussDB（Influx用）は、リレーショナルデータベースパラダイムの複雑な設計ルールを放棄し、スキーマレス設計をサポートし、ビジネスをシンプルかつ効率的な方法でモデル化できます。急速なビジネスの変化とアクセスデバイスの深刻な多様化を伴う産業用IoTシナリオに直面して、GaussDB（Influx用）データモデリングはより柔軟で、サービスを変更せずにさまざまなデバイスと互換性があり、産業用IoTシナリオにより適しています。

04終了_ 

この記事の著者：HUAWEICLOUDデータベースイノベーションラボおよびHUAWEICLOUD時空間データベースチーム。ぜひご参加ください。
クラウドデータベースイノベーションラボ（北京、成都）配信再開メール：[email protected]
HUAWEI CLOUD時空間データベースチーム（深セン、西安）配信再開メール：[email protected]

 

[フォロー]をクリックして、HUAWEI CLOUDの新技術について初めて学びましょう〜

{{o.name}}

{{m.name}}