ドキュメントの検索
karat

+

K

APIリファレンス ↗

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

Object Storage V1とObject Storage V2の間の破壊的な変更

Object Storage V1(Phonograph)からObject Storage V2への移行は、多くの破壊的な変更を必要とする大規模なアーキテクチャシフトです。レガシーのObject Storage V1(Phonograph)は広範なAPI表面積を持ち、直接的な低レベルのデータベース機能を大量に公開しています。対して、新しいObject Storage V2アーキテクチャは、Object Data Funnelサービスを通じてオブジェクトを専用のオブジェクトデータベースに同期し、スケール、パフォーマンス、柔軟性、セキュリティの改善を図っています。このアーキテクチャの移行により、主に以下の2種類の破壊的な変更が生じます。

  • 特定のユースケースに対して設計された専用のオブジェクトデータベースは、Object Storage V1と同等の機能を提供しない可能性があります。これにより、OSv2ではOSv1とは異なる方法でワークフローをモデル化する必要があるかもしれません。
  • Object Storage V1で統合されていた懸念の次元を分離することで、OSv1のAPIと直接対話する既存のクエリの一部をリファクタリングする必要が生じます。

これらの破壊的な変更は、一部のOSv1バックアップのオブジェクトタイプがリファクタリングや修正なしでOSv2に移行できない場合があります。OSv2への移行に関するドキュメントには、これらの問題がユーザーにどのように提示されるか、およびOSv1からOSv2への移行方法についての詳細が記載されています。

恒久的な破壊的な変更

このセクションでは、Object Storage V1(Phonograph)とObject Storage V2の間の破壊的な変更のリストを提供します。これらの破壊的な変更は、任意のオブジェクトタイプをOSv2に移行しようとする前に対処する必要があります。OSv1とOSv2の間のこれらのすべての変更は、オントロジーへのデータの品質を改善し、より決定的な動作を保証し、プラットフォーム全体の可読性を高めることを目指しています。

  • OSv2は、ユーザーの編集をActions経由でのみサポートします。OSv1の編集APIに対する既存の直接クエリは、OSv2に移行する前にActionsを使用するようにリファクタリングする必要があります。
  • OSv2は "writeback datasets" を "materializations" と改名します。OSv1では、writeback datasetsは必須ですが、OSv2では、materializationsはオプションです。実体化されたデータセットについての詳細は Materializations をご覧ください。
  • OSv2は、APIを通じてユーザーの編集履歴を取得することをサポートしていません。ユーザーは代わりに Action Log オブジェクトタイプを設定して、構造化されたユーザー編集履歴を受け取るべきです。
  • OSv2は、データソースの一意のオブジェクト主キーを強制します。データソースに主キーが重複している場合、そのデータソースをオントロジーにインデックス付けするとエラーが発生し、失敗します。
  • OSv2は、オントロジーのモデリングのベストプラクティスを推奨するために、一部のデータタイプが主キーとして使用されるのを防ぎます。次のタイプは主キーとして使用できません
    • Geohash
    • Geoshapes
    • 配列
    • Time series properties
    • Real number types (decimal, double, float)
  • OSv2は、データソーススキーマとオブジェクトタイプスキーマの間のデータタイプの一貫性を、すべての同期ごとに強制します。プロパティの互換性のないデータタイプは、ビルドに失敗します。
  • OSv2はネストされた配列を許可しません。
  • OSv2はNaNまたは±無限大をプロパティ値として許可しません。
  • チェンジログデータソースがあるオブジェクトタイプについては、OSv2はレガシーチェンジログデータセットによって使用されていた "最新のタイムスタンプが勝つ" というセマンティクスを考慮しません。
    • OSv2は、すべてのパイプラインをデフォルトでインクリメンタルにインデックス付けします。すべての関連するチェンジログの計算は、Funnelによって自動的にバックグラウンドで行われ、"changelog python decorator"は使用されなくなります。
  • OSv2は、Geohashプロパティに対してより厳格な検証を行います。
    • OSv2では空の文字列は許可されません。OSv1では、空の文字列は無音でnullに変換されました。
    • Lat, Longは括弧なしのカンマ区切りの文字列であるべきです。例えば -29.123, 150.982 です。
  • OSv2では、配列データタイプのプロパティがnull値を持つことは許可されていません。
    • OSv1では現在、インデックス付けされた配列プロパティのnull値をスキップし、配列がnull値を含んでいると返します。したがって、nullをクエリで探すと、null値を持つオブジェクトには一致せず、オブジェクトのロードと検索の間に望ましくない差異が生じます。
  • Object Set Service(OSS)APIはクエリ文字列のサポートを持っていません。OSv1はクエリ文字列のサポートを持っています。
  • OSSの基数メトリックは、Object Storage V1とObject Storage V2の両方からオブジェクトを含むオブジェクトセット、例えばマルチバックエンドのオブジェクトセットではサポートされていません
  • OSv2のオブジェクトタイプは、Monitoring Viewsによってのみ監視できます。これは Object Storage V1(Phonograph)同期ステータスヘルスチェックを置き換えます。

一時的な破壊的な変更

このセクションでは、Object Storage V1(Phonograph)とObject Storage V2の間の現在の機能ギャップをリストアップします。これらの機能は開発中であり、破壊的な変更が解決されるとリストが更新されます。

  • OSv2は現在、ユーザーが見ることが許可されているものよりも少ないデータを検索レスポンスで返すエッジケースを持っています:

    • 以下のすべての条件が満たされたときに問題が発生します:
      • オブジェクトタイプがOSv2にインデックス付けされ、制限付きビューデータソースを使用しています。
      • 制限付きビューデータソースには、配列行に適用されたマーキングがあります。
      • 配列行は、一部の行で空の配列を含んでいます。
    • マーキングの定義によれば、ユーザーは空の配列のある行を見ることが許されるべきですが、OSv2は対応する行を検索レスポンスで返しません。
    • 一時的な解決策の一つは、すべての配列に要素を追加することで、マーキングで使用される配列行が空の配列を含まなくなるようにすることです。例えば、すべてのユーザーがアクセスできるマーキングを追加できます。
  • OSv2は現在、プロパティのデータタイプとしてdecimalをサポートしていません。

  • OSv2は現在、制限付きビューデータソースの粒度の高い許可ポリシーの Not 条件をサポートしていません。

  • OSv2は現在、カスタムアナライザーをサポートしていません。

  • OSv2は現在、インクリメンタルに更新される元データセットのプロジェクションをサポートしていません。

  • Foundry Rules Archetypesは現在、OSv2の全機能セットをサポートしていません。例えば、複数のデータソースにバックアップされたオブジェクトタイプや複数の実体化を持つオブジェクトタイプはサポートされていません。詳細については、Foundry Rules documentation をご覧ください。