ThingWorx でのデータセントリックモデリング
正しいモデルエレメントの選択
このセクションの以降の部分を読み進めるにあたっては、ThingWorx のモデリングの概念についてよく理解しておくことをお勧めします。詳細については、
Composer での ThingWorx モデルの定義を参照してください。ThingWorx のモデルは物理的な情報とソリューションの全体像を論理的に表したものです。この論理的な表現は、Thing、Thing Template、Thing Shape、データシェイプなどの組み込みのモデルエレメントテンプレートのインスタンスを作成することによって実現されます。このセクションでは、ThingWorx モデルベースソリューションのデータストレージの要素をどのように設計するかについての推奨事項を示します。ThingWorx では、データの保管に関連するいくつかのオプションがあります。各オプションについて理解しておくことで、データに最適なストレージソリューションを決定できます。
 |
ThingWorx で要件を満たすために必要な処理量とメモリ量を推定するには、
Sizing Guide を使用するのが便利です。
|
ベースタイプとデータシェイプとは
ThingWorx ベースタイプは ThingWorx アプリケーションの開発環境を Edge の特定のデータ型およびデータストアから分離する抽象化レイヤーを提供します。これにより、ThingWorx アプリケーションはあらゆるデータストアに対応し、基礎となるデータベーススキーマを変更することなくランタイムでベースタイプを変更可能になります。
データシェイプはフィールド定義と関連メタデータの名前付きのセットであり、ここでは各フィールドがベースタイプとなります。データシェイプはリレーショナルデータベーステーブルの概念とほぼ一致し、ここでベースタイプはフィールドのデータ型と類似しています。
Thing プロパティ
ThingWorx 内では接続されているデバイスは Thing としてモデリングされ、ThingWorx Platform へのデータ取得の最も主要なエントリポイントは Thing のプロパティです。一般的な説明については、
Thing プロパティを参照してください。
Thing プロパティを保管するときの各種データストレージオプションについて、以下のユースケースで説明します。ここで、トラクター Thing には Max RPM、Engine Temperature、および Last Oil Service Date プロパティを持つトラクターエンジン Thing Shape が使用されています。
これらのプロパティには読み取り専用、永続化、ログ記録の 3 つのデータストレージオプションがあります。上記の例では、以下が推奨されます。
• Max RPM - これはランタイムで変更してはならない静的な値なので、読み取り専用オプションを使用します。ただし、エンジンがアップグレードされた場合、デフォルトを変更することでこの値を変更できます。
• Last Oil Service Date - このプロパティはランタイムで変更可能であり、関心があるのは最新の日付だけであるため、永続オプションを使用します。永続化オプションを使用すると、ThingWorx サーバーが再起動した後も存続します。
• Engine Temperature - これは絶えず変化する値で基本的には時系列データなので、ログ記録オプションを使用します。
ストリーム
ストリームは時系列データの BLOB を保管するためのものです。各ストリームエントリにはタイムスタンプ、ソース、ソースタイプ、フィールド値、データタグ、および場所のフィールドがあります。一連のフィールドはデータシェイプで定義されてストリームに関連付けられます。一連のフィールドのフィールド値は JSON またはテキスト BLOB としてストリーム内の単一の列に保管されます。この結果、単一のフィールド値がクエリーされた場合、一致するフィールド値が含まれている 1 つまたは複数の行全体が返されます。つまり、特定のソースの短期間のフィールド値についてストリームがクエリーされる場合にデータ読み取りがより速くなります。特定のフィールド値を条件として指定したクエリーでは、アプリケーションレベルでフィールド値のデータをフィルタする必要があります。
最良事例は以下のとおりです。
• ThingWorx モデル内の Thing に直接関連付けられていない任意の時系列データに使用します (値ストリームとの違い)
• 保管されているデータをフィールド値に基づいた広範なフィルタを使用してクエリーする必要がない場合に使用します
• クエリーが短期間に制限されている場合に使用します
• 長期間にわたって複数のソースをクエリーしないようにします
値ストリーム
値ストリームは Thing の個々のプロパティを時系列データとして保管するためのものです。Thing のプロパティは時系列データと見なされるためにはログに記録するものとして定義されなければならず、データストレージには値ストリームを使用しなければなりません。値ストリームの各エントリにはタイムスタンプ、ソース、プロパティタイプ、プロパティ名、プロパティ値があります。値ストリームとストリームではストレージモデルが大きく異なります。ストリームではフィールド値のセット全体が、JSON/テキスト BLOB として単一行のフィールド値の列に保管されるのに対し、値ストリームでは各プロパティ値が、関連付けられているソースとタイムスタンプとともに別個の行に格納されます。値ストリーム内の Thing のプロパティデータをクエリーすると、そのプロパティの値のみが返されます。
値ストリームは Thing 駆動のモデルで役立ちます。最良事例としては、インデックスのパフォーマンスを向上させるため、複数の値ストリームに Thing を分割します。厳密には最良事例ではありませんが、(サイジングガイドで概要を説明している取得レートを上回る) 大容量のデータを取得するシナリオでは、別個のデータベースインスタンスに接続する複数の永続化プロバイダを作成することも検討できます。これにより、データはデータベース内の異なるテーブルに格納されます。複数のデータベースを追加した場合、各永続化プロバイダに固有のデータベースを指定することも可能です。このシナリオではデータマイグレーションも必要です。
RDMS (PostgreSQL、MSSQL、H2) を使用している場合、さまざまな Thing のさまざまな値ストリームのレコードを含むすべてのレコードが、データベース内の同じテーブルに書き込まれます。
PostgreSQL を使用している場合、PostgreSQL データベース内の ValueStream のテーブル内で、各行に 1 つのプロパティのレコードだけが格納されます。つまり、値ストリームは各プロパティの値の変化を個別に追跡し、QueryPropertyHistory サービスを使用すると、Thing 内の各プロパティのデータフローがチェックされ、(更新時刻がそれぞれ異なる) すべての最新の更新がインフォテーブルの 1 つの結果内に収集されます。
データテーブル
データテーブルは基本的には標準のリレーショナルデータベーステーブルの抽象化である ThingWorx エンティティであり、これを使用することで ThingWorx アプリケーションの開発を簡素化および加速化できます。ただし、データテーブルのバックエンド実装はリレーショナルデータベーステーブルと同等ではなく、リレーショナルデータベーステーブルのような本格的なフレキシビリティは備わっていないことに注意する必要があります。ファーストクラス ThingWorx エンティティとしてのデータテーブルを使用することで、ThingWorx モデルレベルでのデータアクセス機能の処理を非常に簡単に行えます。データテーブルの列またはフィールドとそのプライマリキーは、データテーブルに関連付けられているデータシェイプによって定義されます。ただし、これはパフォーマンスとスケーラビリティの点で標準のリレーショナルデータベーステーブルから置き換わるものではありません。