インデックス レイヤーにはユーザー定義の構造があり、最大 4 つの属性を含めることができます。 1 つは時間属性である必要があります。 インデックス レイヤーには、メタデータ ( インデックス属性の値 ) に加えて、データブロブのデータ ハンドル、データのサイズ、タイムスタンプ、チェックサムなどの追加情報が含まれています。
注
インデックスレイヤー内のデータは暗号化され、レイヤーの保持設定で指定された時間( TTL )で保存されます。
保持
インデックス レイヤーには、存続時間の値( Time-to-Live または TTL )を設定できます。 TTL 値は、レコードがレイヤーに保持され、クエリーに使用できる日数を定義します。 TTL の期限が切れた後、レコードは削除の対象になります ( 実際の削除には有効期限が切れてから 24 時間かかることがあります ) 。 この TTL 値は、レイヤーにパブリッシュされたすべてのレコードに適用されます。
インデックス レイヤーに TTL を設定すると、データ管理作業を自動化して、データの保持とコストをより簡単に維持できます。 無制限の保存期間を選択すると、データがパイプラインによってインジェストおよび処理されている限り、データが蓄積され続けるため、これらの変数を手動で管理する必要があります。 または、 TTL を 7 日に設定すると、データレコードが 7 日経過した時点で削除が開始されます。 すべての新しいデータレコードは、 7 日経過するまで保持されます。
TTL の最小値は 7 日です。 これもデフォルトの TTL 設定です。
注
インデックス レイヤーが作成されたら、 API 、 DCL 、 CLI を使用して、プログラムで保持設定を更新できます。 レイヤがすでに作成された後の TTL の更新は、ポータルを介してはまだ実行できません。 レイヤーの再設定を参照してください。
警告
保持期間を延長すると、インデックス レイヤーとブロッブストア間のレコードの同期で問題が発生する可能性があります。 インデックス レイヤーに、有効期限が切れてから 24 時間以内のレコードがすでに含まれている場合、保持値の更新がブロブストアによってただちに適用されることは保証されません。その結果、ブロブストアのデータの有効期限が切れても、インデックス レイヤーの対応するエントリが永続化される可能性があります。 このため、保持期間を延長する場合は注意が必要です。 元の有効期限に近いタイムスタンプを持つエントリのデータ損失および不整合が発生する可能性があります。 インデックスサービス管理者に連絡してガイダンスを受けてください。
メタ属性は、すべてのインデックスレイヤーにデフォルトで定義されている暗黙的なインデックス属性です。 現在定義されているメタ属性 :
-
id
- Blob API からペイロードにアクセスするためのデータ ハンドルとしても使用されるインデックスレコードの一意の ID 。 一意性はレイヤー内で保証され、 UUID 形式に従う必要があります。 -
size
- 対応するデータペイロードのサイズ (id/data ハンドルを使用 ) ( バイト単位 ) 。 -
checksum
- レイヤー定義で指定されたダイジェストで計算されたデータペイロードのチェックサム。 Query API ではチェックサムを使用できません。 -
metadata
- JSON 形式のユーザー定義のキー / 値のペアのコレクション。 API は、 Query メタデータでは使用できません。 -
timestamp
- インデックス レイヤーによって自動的に生成されたインデックスレコードの挿入時間 (UTC) 。
インデックス属性 ( カスタムキー )
インデックス属性は、インデックス レイヤーでデータを照会するためのキーを定義します。 たとえば、時間、タイル ID 、およびイベントタイプの属性を使用して、自動車のセンサーデータをインデックス化するインデックス レイヤーを定義できます。 次に、 Data Archiving ライブラリを使用してパイプラインを開発し、これらの属性に基づいてデータを集約できます。 メッセージがインデックス レイヤーにインデックス付けされた後、時間、タイル ID 、およびイベントタイプに基づいてデータをクエリーできます。
インデックス レイヤーでは、時間が一般的に重要な要素であるストリームデータのアーカイブおよびクエリーを容易にするための属性として、時間(インジェスト時間またはイベント時間)が必要です。 時間が必要ですが、残りの 3 つのオプション属性を使用して、データの他の側面 ( 場所など ) でインデックスを作成したり、クエリを実行したりできます。
すべてのインデックス属性 ( キーとも呼ばれます ) には、 name
と type
の 2 つのプロパティがあります。 name
この属性は、主にクエリー API でクエリー述部を表現するために使用されます。 type
属性は、属性に保存されているデータ型を定義します。 サポートされているタイプは次のとおりです
- 標準タイプ :
-
bool
- ブール型値。 -
int
- 最大 64 ビットの符号付き整数。 このタイプは廃止されました。 long
代わりにを使用します。 -
long
- 最大 64 ビットの符号付き整数。 -
string
- 最大 40 文字の Unicode 文字列。
- プラットフォームタイプ :
-
heretile
- HERE Tile マップタイリング方式のタイル ID を表します。 heretile
このタイプには、タイルのサイズを表す zoomLevel 属性があります。 変更できません。 -
timewindow
- データのインデックスを作成して後でクエリを実行する最も正確な時間の細分性を表します。 は timewindow
、ポイントインタイムではなく、タイムスライスです。 たとえば、時間帯を 1 時間に指定した場合、特定の 60 分ウィンドウにイベント時間が設定されているすべてのレコードの timewindow
属性の値は、 timewindow
のインデックス値と同じになります。 時間帯の期間を指定できます。時間帯は時間帯の長さを表し、変更できません。 timewindow
値と timewindow
期間の両方がミリ秒単位で表され、時間値はエポックからのミリ秒数です。 timewindow
この値は、ウィンドウの先頭のタイムスタンプとして表されます。
注
レイヤーが作成されると、インデックス付け属性を更新できません。
属性の検証ルール
インデックス属性は、次の規則に準拠している必要があります。
- インデックス属性の最小数は 1 です。
- インデックス属性の最大数は 4 です。
- 属性名の最大長は 64 文字です。
- 各インデックス属性には一意の名前を付ける必要があります。 インデックス属性名には、上記で定義した予約済みのメタ属性名を使用できません。
- 属性名は Unicode 文字で始まる必要があります。 後続の文字には、文字、アンダースコア (_) 、および数字 (0 ~ 9) を使用できます。
heretile
属性は 1 つまで指定できます ( オプティノアル ) 。 heretile
タイプの zoomLevel
属性は、 null および 0 ~ 14 の範囲であってはなりません。 timewindow
属性は 1 つだけである必要があります。 timewindow
タイプの duration
属性は、ヌルおよび 600000 ( 10 分) ~ 86400000 ( 24 時間)の範囲である必要があります。
インデックスを定義するに config
は、 API を使用してペイロードのインデックスを定義します。 HERE はペイロードの例です。
{
"id":"index-1",
"name":"index-1",
"description":"index-1",
"summary":"index-1",
"layerType":"index",
"contentType":"application/octet-stream",
"indexProperties":{
"ttl": "15.days",
"indexDefinitions":[
{
"name":"tileId",
"type":"heretile",
"zoomLevel": 10
},
{
"name":"ingestionTime",
"type":"timewindow",
"duration": 3600000
},
{
"name":"eventType",
"type":"string"
}
]
}
}
注
10 より大きい zoomLevel は指定しないことを強くお勧めします。
この例は説明のみを目的としています。 config
API の詳細については 、『 API リファレンス』を参照してください。
コンテンツタイプ
コンテンツタイプは、レイヤー内のデータの種類を特定するために使用するメディアタイプを指定します。
コンテンツのエンコード
コンテンツのエンコード設定では、圧縮を使用してレイヤーに保存されているデータのサイズを削減するかどうかを指定します。 圧縮を有効にするには 、 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 つだけです。
一般的なアルゴリズムの詳細については、「巡回冗長検査」を参照してください。
チェックサムの追加は任意ですが、このレイヤーのパーティションにチェックサムを提供する場合は、使用するアルゴリズムを指定する必要があります。
警告
HERE Workspace は、 HERE で指定したアルゴリズムが実際のチェックサムの生成に使用されたアルゴリズムであることを確認しません。したがって、 HERE で指定したアルゴリズムが公開プロセスで使用されているものであることを確認するには、データの発行元に依存します。
注
ダイジェストと CRC は 2 つの異なるフィールドです。 ダイジェストは、人間による改ざんを防止するためのセキュリティ上の理由で使用されます。 CRC は、コンピューターのハードウェアまたはネットワークの輸送によって生じるビットの反転を防止するために、安全上の理由から使用されます。 両方のフィールドを使用できます。
カバレッジ
このレイヤーがカバーする地理的領域。 この設定では、プラットフォームポータルのレイヤーのカバレッジマップで強調表示する世界の領域を制御します。
2 文字の ISO 3166-1 アルファ 2 コードを使用して、国と地域のリストを指定します。 任意で、国のサブディビジョンの ISO 3166-2 コードを使用して、 2 文字の国のサブディビジョンコードを追加できます。 たとえば、ドイツの場合は「 D 」、ブラジルの場合は「 BR 」、香港の場合は「 CN-HK 」を指定できます。