短期履歴としてのバックエンド

バックエンドは、Cygnus NGSI によって "無限の"履歴コンテキストデータリポジトリとして使用されます。NGSIソースからのデータフローとして、ますます多くのデータがファイル、テーブル、コレクションに追加されています。そのようなデータフローは決して終わらないかもしれません。したがって、挿入は決して終わらず、利用可能な格納リソースを使い果たします。

したがって、永続性バックエンドに格納されているデータの量を制御し、古いデータを新しいデータに置き換えて削除し、短期履歴の実装を実現するメカニズムを提供することが重要です。

バージョン1.7.0 から、これは、キャッピング(capping)および/または期限切れの機能によって実行できます。

使い方

既存の履歴からどのデータを削除する必要があるかを決定するには、2つのアプローチがあります :

  • 特定のサイズ制限に達すると、データ "レコード"(*)をキャッピングすることによって決定。言い換えれば、最後のN個のレコードだけが格納されるように、キャッピング制限を適時に守ることです
  • 特定のキープアライブ制限に達すると、「レコード」（*）を期限切れにすることによって決定。つまり、最後の N 秒間に追加されたレコードのみを制御するために、古いものを削除します

上記は特定のシンクの特定の設定パラメータによって制御することができます :

パラメータ 必須 デフォルト値 コメント
persistence_policy.max_records no -1 永続化要素(表、リソース、コレクションなど)に上限が設定されるまでに許可されるレコードの最大数。-1は、このポリシーを無効にします
persistence_policy.expiration_time no -1 期限切れになる前に永続性要素(表、リソース、コレクションなど)にレコードが維持される最大秒数。-1は、このポリシーを無効にします
persistence_policy.checking_time no 3600 シンクがレコードの有効期限をチェックする頻度(秒単位)

この種の機能を提供するシンクはどれですか？ 当面 :

  • NGSIMySQLSink
  • NGSICKANSink
  • NGSIMongoSink (ただし、わずかに異なる方法です。次のセクションを参照してください)
  • NGSISTHSink (ただし、わずかに異なる方法です。次のセクションを参照してください)

(*) レコードは、バックエンドの永続性に応じて、HDFS ファイルの Json エントリ、MySQL テーブルの行、CKAN リソースのレコードなど、さまざまなものを意味する場合があります。

トップ

NGSIMongoSink と NGSISTHSink の特殊なケース

NGSIMongoSink と NGSISTHSink は、MongoDB と STH Comet に保存されているデータが最初から短期的な履歴を持ちたいと考えていたため、この種の機能をバージョン 0.13.0 から実装しています。それにもかかわらず、機能を制御するパラメータは上記のものとは大きく異なります :

パラメータ 必須 デフォルト値 コメント
data_expiration no 0 コレクションは、秒単位で指定された値より古い場合は削除されます。時間の参照は、recvTime プロパティに格納されているものです。このポリシーが必要ない場合は、0に設定します
collections_size no 0 データコレクションのサイズがバイトで指定された値より大きくなると、挿入時間に応じて、最も古いデータが削除されます。サイズベースの切り捨てポリシーは時間ベースの切り捨てポリシーよりも優先されることに注意してください。このポリシーが必要ない場合は、0に設定します。最小値(0以外)は4096バイトです。NGSIMongoSink にのみ利用可能です
max_documents no 0 データ収集内のドキュメント数が指定した値を超えた場合、挿入時間に応じて最も古いデータが削除されます。このポリシーが必要ない場合は、0に設定します。NGSIMongoSink にのみ利用可能です

実装にも違いがあります：MongoDB は、ネイティブで、コレクションの作成時(サイズによる、時間による)に増加するコレクションを制御するメカニズムを提供します。MySQL と CKAN は類似のものを提供していません。このような場合、その機能は、Cygnus 自身が計算した削除操作によって API の上に構築されています。

トップ

今後のワーク

おそらく将来、この機能を共有するすべてのシンクでは、パラメータが均質化されているでしょう。概念的には、CKAN および MySQL シンクによって実装されるキャッピング/期限切れ機能は、MongoDB および STH シンクの時間およびサイズベースのデータ管理ポリシーと同じであるためです。

トップ