ボラタイル レイヤー の設定を行います

カタログ内にレイヤーを作成するときに、ボラタイル レイヤー設定を構成できます。

揮発性レイヤー内のデータは、レイヤーの保持設定で指定された時間( TTL ( Time-to-Live )とも呼ばれます)だけ暗号化および保存されます。

ストレージ容量

レイヤーのストレージサイズを指定できます。 ストレージ容量を選択する場合は、レイヤーストレージにボラタイル レイヤーのデータとメタデータの両方が含まれることを考慮してください。

ストレージ全体が使用されると、 HERE platform によって選択した最大メモリポリシーが適用されます。 最大メモリポリシーの詳細については 、「最大メモリポリシー」を参照してください

有効なストレージ容量の範囲は、 100 MB ~ 21 GB です。 100 MB 単位で指定できます。

必要なストレージサイズを計算できるように、 10,000 パーティションの平均メタデータ サイズは約 2 MB です。 たとえば、 100,000 個のパーティションがある場合は、メタデータ 用に 20MB の追加ストレージを含めることになります。 データの制限およびコストの考慮事項の詳細については、「ストレージとスループットの制限」を参照してください。

データ冗長性

レイヤーにデータ冗長性を設定できます。 次の 2 つのオプションがあります。

  • single-instance: 中程度の可用性。 データ / メタデータを保存するインスタンスは 1 つだけです。 書き込みおよび読み取りの負荷が、互いのパフォーマンスに影響を与える可能性があります。
  • multi-instance: 高可用性。 データ / メタデータの合計コピーが 3 つあります。 1 つのマスターコピーおよび (2) 冗長コピー。 このオプションを使用すると、読み取りの負荷が書き込み操作のパフォーマンスに影響を与えないため、パフォーマンスも向上します。

multi-instance 本番環境での使用を強くお勧めします。 で single-instanceは、レイヤーの基盤となるインフラストラクチャに障害が発生すると、データの復旧不能な損失が発生する可能性があります。

データ冗長性を設定しない場合 multi-instance 、はデフォルトでイネーブルになっています。

警告

single-instanceを選択すると、こちらにドキュメント化されたすべてのボラタイル レイヤー データ耐久性ステートメントが免除されることを確認できます。 データの耐久性の詳細については、「データのセキュリティと耐久性」を参照してください。

最大メモリポリシー

ボラタイル レイヤーがいっぱいになった場合は、どのようなアクションを取るかを決定する必要があります。 次のオプションを使用できます。

  • FailOnWrite: 書き込み操作が失敗し、エラーコードがクライアントに返されます。
  • ReplaceLessRecentlyUsedPartition: ボラタイル レイヤーは、各パーティションの書き込みと読み取りの日時を追跡します。 レイヤー内に空き容量がない場合、最も長い間アクセスされていないパーティションは自動的に削除され、新しいパーティションのためのスペースが作成されます。 1 つのパーティションを削除しても十分なスペースが作成されない場合は、複数のパーティションが削除されることがあります。

最大メモリポリシーを指定しない場合 FailOnWrite 、はデフォルトで使用されます。

保持

ボラタイル レイヤーには、存続時間の値( Time-to-Live または TTL )を設定できます。 TTL 値は、パーティション内のデータが存在する時間の長さを定義します。 保存期間が経過すると、データが削除されます。 TTL 値を指定すると、レイヤー内のパーティションデータの有効期間が事前にわかっている場合に特に便利です。 たとえば、 24 時間以内に期限が切れることがわかっているトラフィックインシデントがレイヤーに保存されている場合、 TTL は 24 時間に設定する必要があります。 ボラタイル レイヤーを作成する場合、デフォルトの TTL は 60 分に設定されます。 この値は、レイヤーの作成時に変更できます。 TTL 値は 1 分 ~ 10080 分( 7 日)の範囲である必要があります。 API を直接使用している場合、この値の設定は ms ( 分 : 600 、 000 ミリ秒、最大: 604800000ms )

TTL はパーティション データにのみ適用されます。 TTL 時間が経過しても、パーティション メタデータは削除されません。 メタデータは 、公開 API を使用して明示的に削除する必要があります。

パーティション分割

パーティション分割方式によって、レイヤー内のパーティションの命名方法が決まります。 マップ データ for HERE Tile Partitioning を使用し、他の種類のデータには汎用パーティションを使用します。 詳細については 、「パーティション」を参照してください。

コンテンツタイプ

コンテンツタイプは、レイヤー内のデータの種類を特定するために使用するメディアタイプを指定します。

コンテンツのエンコード

コンテンツのエンコード設定では、圧縮を使用してレイヤーに保存されているデータのサイズを削減するかどうかを指定します。 圧縮を有効にするには 、 gzip を指定します。

データを圧縮することで、ストレージのサイズ、 I/O の転送、読み取りのコストを最適化できます。 ただし、データを圧縮すると、実際の圧縮で余分な CPU サイクルが発生します。 レイヤーの圧縮を有効にするかどうかを決定する場合は、圧縮のメリットとコストの両方を考慮してください。

一部の形式、特にテキスト、 XML 、 JSON 、 GeoJSON などのテキスト形式では、圧縮率が非常に高くなります。 JPEG または PNG 画像など、他のデータ形式はすでに圧縮されているため、再度 gzip で圧縮してもサイズは小さくなりません。 多くの場合、ペイロードのサイズを増やすこともあります。 Protobuf などの汎用バイナリ形式の場合、圧縮率は実際のコンテンツおよびメッセージサイズに応じて異なります。 実際のデータの圧縮率をテストして、圧縮が有益かどうかを確認することをお勧めします。

寄木細工には圧縮を使用しないでください。 圧縮によって blob データへのランダムなアクセスが切断されます。この圧縮は、寄木細工のデータを効率的に読み取るために必要です。

レイヤーに SDII データが含まれている場合、 ingest API の /layers/<layerID>/sdiimessagelist エンドポイントは圧縮をサポートしていないことに注意してください。 したがって、 SDII データを含むレイヤーの圧縮を有効にする場合は、 ingest API の汎用エンドポイント (/layers/<layerID>) を使用する必要があり、すべての圧縮および圧縮解除をアプリケーションで処理する必要があります。

データ クライアント ライブラリを使用して圧縮レイヤーからデータの読み取りまたは書き込みを行う場合、圧縮および圧縮解除は自動的に処理されます。

Data API を使用して圧縮レイヤーからデータを読み書きする場合は、レイヤーに書き込む前にデータを圧縮する必要があります。 データを読み取る場合、受信したデータは gzip 形式であるため、解凍の責任はお客様にあります。

スキーマ

スキーマを指定すると、他のユーザーがデータをどのように使用するかを定義して、他のユーザーとデータを共有できます。 詳細については 、「スキーマ」を参照してください。

ダイジェスト

digest プロパティは、レイヤー内の各パーティションのハッシュを生成するためにデータ発行者が使用するアルゴリズムを指定します。 レイヤーのダイジェストアルゴリズムを指定することで、レイヤーから取得したデータの整合性を検証するために使用するアルゴリズムをデータ利用者に伝えます。

レイヤーを作成または更新するときに、ダイジェストアルゴリズムを指定できます。 「 undefined 」を指定すると、レイヤーの作成後に別のダイジェストアルゴリズムを指定できます。 ダイジェストアルゴリズムを指定した場合、後で変更することはできません。

ダイジェストアルゴリズムを選択する場合は、次の点を考慮してください。

  • 強力なデータセキュリティが必要なアプリケーションには、 SHA-256 を推奨します
  • ハッシュを適用する目的が転送中のデータの整合性を確認することである場合、 MD5 および SHA-1 は許容されます。

ハッシュのインクルードは任意ですが、このレイヤーのパーティションにハッシュを提供する場合は、使用するアルゴリズムを指定する必要があります。

HERE platform は、 HERE で指定したアルゴリズムが実際のハッシュの生成に使用されたアルゴリズムであることを確認しません。したがって、 HERE で指定したアルゴリズムが公開プロセスで使用されているものであることを確認するには、データの発行元に任されています。

一般的なアルゴリズムの詳細については、「安全なハッシュアルゴリズム」を参照してください。

ダイジェストと CRC は 2 つの異なるフィールドです。 ダイジェストは、人間による改ざんを防止するためのセキュリティに使用されます。 CRC は、コンピューターのハードウェアまたはネットワークの輸送によってビットが反転するのを防ぐために安全に使用されます。 両方のフィールドを使用できます。

CRC

crc このプロパティは、レイヤー内の各パーティションのチェックサムを生成するためにデータ発行者が使用する CRC アルゴリズムを指定します。 レイヤーに CRC アルゴリズムを指定する場合、レイヤーから取得したデータの整合性を検証できるように、どのアルゴリズムを使用するかをデータ利用者に通知します。

レイヤーを作成または更新するときに、 CRC アルゴリズムを指定できます。 「 undefined 」を指定すると、レイヤーの作成後に別の CRC アルゴリズムを指定できます。 CRC アルゴリズムを指定した場合、後で変更することはできません。

注 :

この CRC には、次のプロパティがあります

  • 0 で埋められ、 8 文字の固定長になります
  • たとえば、計算された CRC が uint32 の値である場合、 0x1234aパーティション用に実際に保存されている CRC が文字列 001234afになります。

現在サポートされている CRC アルゴリズムは 1 つだけです。

  • CRC-32C (Castagnoli)

一般的なアルゴリズムの詳細については、「巡回冗長検査」を参照してください。

チェックサムの追加は任意ですが、このレイヤーのパーティションにチェックサムを提供する場合は、使用するアルゴリズムを指定する必要があります。

警告

HERE Workspace は、 HERE で指定したアルゴリズムが実際のチェックサムの生成に使用されたアルゴリズムであることを確認しません。したがって、 HERE で指定したアルゴリズムが公開プロセスで使用されているものであることを確認するには、データの発行元に依存します。

ダイジェストと CRC は 2 つの異なるフィールドです。 ダイジェストは、人間による改ざんを防止するためのセキュリティ上の理由で使用されます。 CRC は、コンピューターのハードウェアまたはネットワークの輸送によって生じるビットの反転を防止するために、安全上の理由から使用されます。 両方のフィールドを使用できます。

カバレッジ

このレイヤーがカバーする地理的領域。 この設定では、プラットフォームポータルのレイヤーのカバレッジマップで強調表示する世界の領域を制御します。

2 文字の ISO 3166-1 アルファ 2 コードを使用して、国と地域のリストを指定します。 任意で、国のサブディビジョンの ISO 3166-2 コードを使用して、 2 文字の国のサブディビジョンコードを追加できます。 たとえば、ドイツの場合は「 D 」、ブラジルの場合は「 BR 」、香港の場合は「 CN-HK 」を指定できます。

」に一致する結果は 件です

    」に一致する結果はありません