Data API のベストプラクティス

Data API は、データおよびデータ管理機能へのアクセスを提供する REST インターフェイスです。 堅牢性、拡張性、効率的なストレージ機能、柔軟なクエリー機能を同時に提供するために、 Data API の設計は、データ( blob )をメタデータ(パーティション)から分離するという原則に基づいています。

次に、データが Data API に通常どのように保存されるかの標準フローを示します。

データ消費者フロー :

  • 各パーティションの blob ( データ ) を取得します
  • メタデータの検出 ( パーティション )

データ作成者のフロー :

  • メタデータを公開します
  • データを公開し、メタデータを収集します

データのアップロードまたは取得は、通常、 2 つの手順で行います。 データを取得するには、まずメタデータ API 、 Query API 、または Index API を照会してブロブ ID (dataHandle) を検出し、次にこれらのデータが参照するデータを Blob API または Volatile Blob API を介して取得する必要があります。

Data API にデータをアップロードする場合、プロセスが逆になります。 まず、 API を収集している Blob API または Volatile Blob メタデータにデータをアップロードし、次に Publish API を介してメタデータを(バッチで)アップロードします。

一部のインスタンスでパフォーマンスを向上させるには、メタデータとデータを結合して、ストリーム処理のように単一のメッセージとして渡すか、または必要なワーキングセットを事前に読み込んでキャッシュすることで、 Discover メタデータステップをスキップします。

API ルックアップ

HERE platform では、 REST API のベース URL はカタログごとに一意であり、カタログ間で異なる場合があります。 たとえば、カタログの Blob API の基本 URL は、別のカタログの Blob API とは異なるベース URL を持つことができます。 API ルックアップサービスを使用して、 Data API の実際のベース URL を取得します。

特定のカタログのベース URL を取得したら、 Cache-Control HTTP Header に従ってキャッシュできます。通常は 1 時間です。 データ API へのリクエストを作成するたびに、 API ルックアップリクエストを実行する必要はありません。

設定 API

設定 API は、基本的なカタログ管理操作を提供します。 API ルックアップと同様に、設定 API 応答はキャッシュ可能です。 HERE では、インスタンス / Spark または Flink ワーカーノードごとに 1 回のみカタログ設定を要求し、必要に応じてキャッシュされたカタログ設定オブジェクトを再利用し続けることをお勧めします。

API 検索および設定 API サービスでは、要求レートが低く、応答サイズが小さいため、特別なパフォーマンスの考慮は必要ありません。

/config/v1/status/{status_token} エンドポイントは、要求が成功したか、失敗したか、またはまだ処理中であるかを判断するために使用pendingされます () 。 pending 状態の間は、要求を再試行しないでください。

連続して削除および作成されたリクエストの場合、システムの性質上、 60 秒待機することをお勧めします。

メタデータおよび API

メタデータ API 、 Query API 、および Index API は、特定の使用例に合わせて最適化されたメタデータ ( パーティション ) を柔軟に検出する方法を提供します。

メタデータ API および Query API

バージョン管理されたレイヤーで作業する場合、メタデータ API は、論理的に整合性のある最新バージョンのカタログを表すパーティションの統合ビューをサポートします。 また、複数のカタログバージョン間の変更の発見についても説明し、地図コンテンツのインクリメンタルなコンパイルをサポートします。

Query API は、メタデータ API と非常に似た機能を提供しますが、マップのパンニングや、 4 つのツリーレベルでのクエリを必要とする対話型の UI の使用例に最適化されています。

メタデータおよびクエリー API の場合、クライアント appId あたりのクエリー数は 500 リクエスト / 秒を超えないようにしてください。

インデックス API

インデックス API は、インデックス レイヤーから一致するパーティションを取得するための RSQL クエリをサポートしています。 データモデルを最適化することで、クエリー時間を大幅に短縮できます。 HERE では、データモデルを設計する前に、データのクエリ方法、読み取り / 書き込み比率、その他の類似の要因など、ワークロードを評価することをお勧めします。 Index API では、極めて詳細なデータ取得ワークフローを可能にするカスタムインデックスを 4 つまで定義できます。

Index API は、ライブラリ for Java & Scala の一部である Data Archiving HERE Data SDK と組み合わせて、ストリーム レイヤーを介してインジェストされたメッセージのアーカイブを作成する方法を提供します。

インデックス レイヤーサービス HTTP 429/503 は、サービスの利用率が高い場合に復帰できます。 スロットルは短時間だけ持続する必要があります。

サービスが高使用率に適応している間、クライアントは指数バックオフアルゴリズムを使用して要求を再試行する必要があります。

スロットルと再試行の期間が延長されてもサービスが再開される場合 HTTP 429/503は、 HERE テクニカルサポートに連絡してください。

データと API

Blob API 、 Volatile Blob API 、および Interactive API は、実際のデータを取得するための API を提供します。

Blob API と Volatile Blob API の 2 つのオプションがあります

Thes Blob API および Volatile Blob API は、高負荷および高スループットのワークフローに最適化されています。 究極のパフォーマンスを実現するには、複数の接続を使用してデータを並列に取得またはアップロードする必要があります。 HERE では、 HTTP 接続のプールを使用し、各接続を複数の要求に再利用することを推奨しています。

合理的なサービス品質 (QoS) を維持するため HTTP 408 Request timeout に、 Blob API は、平均アップロード速度が 50 KB/ 秒未満の場合、ステータスコードを含む低速の書き込み要求を拒否します これは、中国地域の Data API で作業する場合に問題になることがあります。

また、バッチワークロードおよびストリーミングワークロードを処理する場合、急激な需要の急増に伴う「トラフィックの急増」を予測することは困難です。この急激な増加により、通常は既存のトラフィックレベルが非常に短期間で 2 倍になります。 既存のサービスレベル契約( SLA HTTP 429/503)を引き続き使用して満たすために、システムはステータスコードを短時間(通常は最大 10 分)で返し、新しいリクエストレートに合わせて 1 人以上のユーザーからのリクエストを抑制できます。

Interactive API

Interactive API では ' プロパティおよび空間クエリによるクエリがサポートされています 1 つの応答に 100 MB を超えるデータが必要な場合は、結果データを反復処理して、後続の要求の一部を取得できます。 ヘッダー「 accept-encoding:gzip 」を使用すると、ネットワークトラフィックを削減できます。

レイヤーを設定するときに、 searchableProperties リストに関連するプロパティを追加することで、クエリー時間を改善できます。 これらのプロパティにはインデックスが付けられます。

レイヤーに含まれるフィーチャーが 10,000 未満の場合、すべてのプロパティが検索可能になります。

インデックス作成は継続的に行われ、データ I/O のコストは発生しません。 ただし、インデックスは保存されているデータに追加されます。

検索可能なプロパティの最大数は 8 つです。 これは、ユーザーが追加して自動的にインデックス化されるプロパティの最大数です。

ストリームと API

Data API には、 REST API を使用してストリームレイヤーを操作するための 2 つのオプションがあります。 Abd ストリーム API を公開して利用できるようにするには、 API を取り込みます。また、バイナリの Kafka プロトコルを使用して Kafka への直接アクセスも可能です。

ストリーム API

完全な制御を行い、最大限のパフォーマンスを得るために、 REST では、直接の Kafka アクセスを使用し、直接の Kafka アクセスが利用できない場合(プロキシ設定またはファイアウォールを使用している場合など)にのみ HERE API にフォールバックすることをお勧めします。

ストリームレイヤーの最大スループットと並列化は、ストリーム レイヤーの作成時に設定されます。 レイヤーに入るデータの最大スループット、およびレイヤーから出るデータの最大スループットを個別に指定できます。

インバウンドレートがインバウンドスループットを超えると、サービスはインバウンドメッセージのスロットリングを開始します。 サービスは、すべてのコンシューマへの合計アウトバウンドレートがアウトバウンドスループットを超えると、アウトバウンドメッセージのスロットリングを開始します。 スロットリングが発生すると、サービスの応答が遅れますが、メッセージはドロップされません。

ストリーム レイヤーの最大メッセージサイズは 1 MB です。 1 MB を超えるメッセージの場合、 HERE ではまず Blob API にデータをアップロードし、ストリーム by reference (データ ハンドル)でメッセージを渡すことをお勧めします。 Java for Scala & HERE Data SDK を使用している場合、この処理は自動的に行われます。

設計の原則

次のガイドラインは、 Data API からデータをアップロードおよび取得するアプリケーションを構築する際のパフォーマンスの最適化に役立ちます。

雑多なやり取りを減らします

アプリケーションが Data API に対して複数の呼び出しを行う必要があるインタラクション ( それぞれが少量のデータを返す ) を設計することは避けてください。 代わりに、複数の関連する操作を 1 つのリクエストに結合して、ラウンドトリップ数とリソースのロックを減らします。

さらに、マップタイルを作成する場合は、低いズームレベルを選択し、高いデータ / メタデータ比率を目指して、データ プロセッシング ライブラリのアダプティブレベリング機能を適用します。

高スループットの要求並列化

Data API は、大規模な分散システムです。 拡張性を活用できるように、 Data API サービスのエンドポイントに対する並列リクエストを水平に拡張することをお勧めします。 高スループットの転送アプリケーションでは、複数の接続を使用してデータを並列に取得またはアップロードする必要があります。 アプリケーションが REST API を使用して Data API に直接リクエストを発行する場合は、 HTTP 接続のプールを使用して、各接続を複数のリクエストに再利用することをお勧めします。 要求ごとの接続設定を回避すると、各要求で TCP スロースタートおよび Secure Sockets Layer ( SSL )ハンドシェイクを実行する必要がなくなります。

パフォーマンスのプロファイリングとロードテスト

開発中、テストルーチンの一部として、および最終リリースの前にパフォーマンスのプロファイリングとロードテストを行い、必要に応じてアプリケーションのパフォーマンスと拡張性を確認します。 パフォーマンスを最適化する場合は、ネットワークのスループット、 CPU 、および RAM の要件を確認してください。

Data API に同時に発行するリクエストの数を調整する場合は、パフォーマンスの測定が重要です。 単一の要求で達成されているネットワーク帯域幅、およびアプリケーションがデータの処理に使用する他のリソースの使用量を測定します。 次に、ボトルネックのリソース(つまり、使用率が最も高いリソース)を特定できます。そのため、役立つ可能性が高いリクエストの数を指定できます。 同時要求の数が少ない場合でも( 20 の同時要求が 50 ~ 80 MB/ 秒の望ましいネットワークスループット)、 10 Gb/ 秒の NIC (ネットワークインタフェースカード)が飽和状態になることがあります。 並列処理が少なすぎると、リソースの使用率が低くなり、リソースの輻輳が多すぎます。

タイムアウトと再試行

再試行が必要であることを示す応答を Data API からアプリケーションが受信する状況があります。 HTTP ステータスコード 408 、 429 、 500 、 502 、 503 の応答、 および 504 がステータスコードを取得できます。 アプリケーションが高いリクエストレートを生成すると、そのような応答を受信する可能性があります。 これらのエラーが発生した場合、 HERE Data SDK for Java & Scala は指数関数的なバックオフを使用して自動再試行ロジックを実装します。 Java for Scala & HERE Data SDK を使用していない場合は、これらのエラーのいずれかを受信したときに同様の再試行ロジックを実装します。

Data API は、継続的な新しいリクエストレートに応じて自動的に拡張され、パフォーマンスを動的に最適化します。 Data API が内部的に新しいリクエストレートに合わせて最適化している間、最適化が完了するまで HTTP エラー応答を一時的に受信します。

バッチ処理では、ネットワークエラーが断続的に発生したり、 HTTP エラーのスパイクが数時間のバッチ処理ジョブに影響を与えないように、再試行時間を長くするか、最大再試行回数を増やすことをお勧めします。

遅延の影響を受けやすいアプリケーションの場合は、タイムアウトを短くして、低速な操作を再試行することをお勧めします。 リクエストを再試行する場合、 HERE では、 Data API への新しい接続を使用して、新しい DNS ルックアップを実行することをお勧めします。

データを圧縮するか、または効率的なバイナリ形式を使用します

アプリケーション内の最大のデータ量は、多くの場合、アプリケーションによって生成され、ネットワーク経由で渡されるクライアント要求に対する HTTP 応答です。 応答サイズを最小化すると、ネットワークの負荷が軽減され、ストレージサイズが最適化され、 I/O が転送されます レイヤー圧縮を有効にすると、レスポンスサイズを大幅に削減できます。

レイヤーを作成した後は、圧縮属性を更新できません。

HERE Data SDK for Java & Scala を使用して、 Data API の圧縮レイヤーからデータを読み書きする場合、圧縮および圧縮解除は自動的に処理されます。

一部の形式、特にテキスト、 XML 、 JSON 、 GeoJSON などのテキスト形式では、圧縮率が非常に高くなります。 JPEG または PNG 画像など、他のデータ形式はすでに圧縮されているため、再度 gzip で圧縮してもサイズが小さくなりません。 多くの場合、再度圧縮するとペイロードのサイズが大きくなります。 Protobuf などの汎用バイナリ形式の場合、圧縮率は実際のコンテンツおよびメッセージサイズに応じて異なります。 寄木細工にはレイヤー圧縮を使用しないでください。これは、寄木細工のデータを効率的に読み取るために必要な blob データへのランダムなアクセスを切断するためです。

データ圧縮によって、送信されるデータ量を削減し、転送時間とコストを最小限に抑えることができます。 ただし、圧縮および圧縮解除プロセスではオーバーヘッドが発生します。 圧縮は、パフォーマンスが明らかに向上した場合にのみ使用してください。

頻繁にアクセスするコンテンツにはキャッシュを使用します

Data API にデータを保存する多くのアプリケーションは、場所を中心としたデータや地理空間データを使用して動作し、通常は「ホットエリア」 ( 都市部、産業エリアなど ) にサービスを提供します。 これらのホット領域はユーザーによって繰り返し要求され、キャッシュの最適な候補になります。 キャッシュを使用するアプリケーションは、 Data API への直接リクエストの送信数も減らします。これにより、転送 I/O コストを削減できます。

Data API で作業するアプリケーションも、 Cache-Control HTTP ヘッダーを遵守する必要があります。このヘッダーには、要求と応答の両方でキャッシュするためのディレクティブ ( 命令 ) が含まれています。

マルチパートアップロードを使用します

Data API のマルチパートアップロード機能を使用すると、大規模なデータブロブ (50MB 以上 ) のアップロードエクスペリエンスを改善できます。 この機能を使用すると、大規模な BLOB の個別の部分を任意の順序で並列にアップロードすることで、アップロードの操作性が向上します。

バイト範囲のフェッチを使用します

Data API では、必要に応じて Range HTTP ヘッダーを使用したデータまたはメタデータの取得がサポートされています。 オブジェクトからバイト範囲を取得し、指定した部分のみを転送できます。 Range HTTP Header を使用すると、リクエストが中断された場合の再試行時間を改善できます。

HERE Data SDK for Java & Scala の最新バージョンを使用してください

HERE Data SDK for Java & Scala は、 Data API のパフォーマンスを最適化するための推奨ガイドラインの多くをビルトインサポートします。

HERE Data SDK for Java & Scala は、アプリケーション内から Data API を利用するためのシンプルな API を提供し、最新のベストプラクティスに従うように定期的に更新されます。 たとえば、 Data SDK には、断続的なネットワークの問題で要求を自動的に再試行するロジックが含まれています。また、 HTTP 5xx エラーには、必要に応じてバイト範囲の要求を使用して、接続の水平方向のスケーリングを自動化し、毎秒数千の要求を達成する機能もあります。 最新のパフォーマンス最適化機能を取得するには、 HERE Data SDK for Java & Scala の最新バージョンを使用することが重要です。

HTTP REST API リクエストを使用している場合は、パフォーマンスを最適化することもできます。 REST API を使用する場合は、このセクションで説明しているのと同じベストプラクティスに従います。

バージョン管理されたレイヤーのデータモデルを設計する場合の考慮事項

Data API は、パーティション分割されたデータへのアクセスを提供します。 ただし、ユースケースに最適なパーティション分割方式を決定する必要があります。 適切に分割されたデータを使用すると、コストを削減し、 Data API 上に構築するアプリケーションのパフォーマンスを向上できます。パーティション分割アプローチを決定する場合は、次の点を考慮してください。

  • アプリケーションのエンドユーザー(エンド ユーザーアプリケーション、マップコンパイルシステム、またはその他)
  • 多数のパーティションのコストに関する考慮事項
  • レイヤー間の相互依存性

ほとんどのアプリケーションは、パーティションのサイズが同じパーティション分割アプローチを利用しています。これにより、データ処理時のアプリケーションのパフォーマンスをより予測可能にし、コンパイルステージ間のダウンタイムを削減できます。 HERE Tile Partitioning スキームでは、マップリージョンごとに複数のズームレベルを使用することを意味します。データ量の多いエリアでは、より密なタイリングが行われます。 詳細については、「パーティション」を参照してください。

極めて詳細なパーティション分割アプローチを使用すると、メタデータのデータアクセスとデータストレージの両方に追加のコストがかかる可能性があり、パフォーマンスの低下につながる可能性があります。 HERE では、可能な限り高いズームレベルを推奨しています。

HERE では、リクエストのテールレイテンシーがポータルおよびデバイスのユーザー体験に悪影響を与える可能性があるため、パーティションのサイズを 100 MB 未満にすることをお勧めします。

アプリケーションが複数のレイヤーを参照している場合は、レイヤー間でのパーティション分割方法を検討してください。頻繁に使用されるレイヤーで同じパーティション分割方法を使用すると便利です。

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

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