JP2016536690A - パーティションベースのデータストリーム処理フレームワーク - Google Patents

パーティションベースのデータストリーム処理フレームワーク Download PDF

Info

Publication number
JP2016536690A
JP2016536690A JP2016529942A JP2016529942A JP2016536690A JP 2016536690 A JP2016536690 A JP 2016536690A JP 2016529942 A JP2016529942 A JP 2016529942A JP 2016529942 A JP2016529942 A JP 2016529942A JP 2016536690 A JP2016536690 A JP 2016536690A
Authority
JP
Japan
Prior art keywords
data
node
stream
worker
nodes
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2016529942A
Other languages
English (en)
Other versions
JP6450756B2 (ja
Inventor
サイマー，マーヴィン・マイケル
ガーレ，ガウラヴ・ディ
デュナガン，ジョン・デイヴィッド
バージェス，グレッグ
ション，イン
Original Assignee
アマゾン・テクノロジーズ・インコーポレーテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by アマゾン・テクノロジーズ・インコーポレーテッド filed Critical アマゾン・テクノロジーズ・インコーポレーテッド
Publication of JP2016536690A publication Critical patent/JP2016536690A/ja
Application granted granted Critical
Publication of JP6450756B2 publication Critical patent/JP6450756B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3433—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment for load management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs

Abstract

マルチテナントストリーム処理サービスの制御ノードは、特定のデータストリームのデータレコードに実行される動作を示すリクエストを受信する。制御ノードは、ストリームパーティショニングポリシに基づいて、使用されるワーカーノードの初期の数を決定する。制御ノードは、受信したレコードに動作を実行するためのワーカーノードを構成する。ワーカーノードが不健全な状態にあるという決定に応答して、制御ノードは、取り換えワーカーノードを構成する。【選択図】図２

Description

長年にわたってデータストレージの費用が減少し、かつコンピューティングインフラストラクチャのさまざまな要素を相互接続する能力が改善されたことに伴い、いろいろなアプリケーションに関連するますます多くのデータを収集及び解析できる可能性がある。例えば、携帯電話は、それが存在する位置、電話ユーザによって使用されているアプリケーションなどを示すデータを生成し、それらの少なくともいくつかを収集及び解析して、カスタマイズされたクーポン、広告などをユーザに提示することができる。監視カメラによって収集されたデータの解析は、犯罪を防止及び／または解決するのに有用となり得、航空機エンジン、自動車または複雑な機械装置内のさまざまな位置に埋め込まれたセンサから収集されたデータを、予防保守、能率の改善及び費用の低下などのさまざまな目的に使用することができる。
ストリーミングデータの量の増大は、コモディティハードウェアの使用も増大してきた（場合によっては、その増大によって可能となってきた）。コモディティハードウェアのための仮想化技術の出現は、多くのタイプのアプリケーションに関する大規模なコンピューティングリソースの管理に関する利益を提供してきた。これによりさまざまなコンピューティングリソースを、能率的かつ安全に、複数の顧客によって共用することができる。例えば、仮想化技術によって、単一の物理的コンピューティングマシンによってホストされた一つ以上の仮想マシンを各ユーザに提供して、単一の物理的コンピューティングマシンを複数のユーザ間で共用することができる。各々のそのような仮想マシンは、所与のハードウェアコンピューティングリソースの唯一のオペレータ及び管理者であるという錯覚、その一方で、さまざまな仮想マシン間のアプリケーション隔離及びセキュリティもユーザに与える、異なる論理コンピューティングシステムとして機能するソフトウェアシミュレーションである。さらに、いくつかの仮想化技術は、複数の異なる物理的コンピューティングシステムに及ぶ複数の仮想プロセッサを持つ単一仮想マシンなどの、二つ以上の物理リソースに及ぶ仮想リソースを提供する能力がある。コンピューティングプラットフォームに加えて、いくつかの大きな組織は、仮想化技術を使用して作製されたさまざまなタイプのストレージサービスも提供する。そのようなストレージサービスを使用して、大量のデータを所望の永続レベルで保存することができる。
しかしながら、さまざまなプロバイダからの比較的安価な費用での仮想化されたコンピューティング及び／またはストレージリソースのアベイラビリティにもかかわらず、大きな動的に変動するデータのストリームの収集、保存及び処理の管理及び編成は、様々な理由のために依然として難しい課題である。大きなデータのストリームの処理のために設定されたシステムに追加されるリソースがより多くなるにつれて、例えば、システムの種々の部分間の作業負荷のアンバランスが生じ得る。これに対処しないと、そのようなアンバランスは、他のリソースを十分に活用できないこと（故に、浪費）に加えて、一部のリソースにおいて深刻な性能上の問題を引き起こすことがある。クライアントは、そのようなデータまたは結果が、クライアントが制御しない設備に保存される場合には、ストリーミングデータのセキュリティまたはストリーミングデータの解析結果についても憂慮することがある。ストリームデータの収集、保存または解析の費用のかかる混乱を防止するために、分散システムの大型化に伴い頻度が増加する自然発生的な障害、例えば、接続性の偶発的な損失及び／またはハードウェア障害にも有効に対処する必要が生じ得る。
少なくともいくつかの実施形態に従う、データストリーム概念の簡易化した概観を提供する。 少なくともいくつかの実施形態に従う、ストリーム管理システム（ＳＭＳ）、及びストリーム処理ステージの集合を備えるストリーム処理システム（ＳＰＳ）のさまざまなサブコンポーネント間のデータの流れの概観を提供する。 少なくともいくつかの実施形態に従う、ＳＭＳ及びＳＰＳにおいて実装することができるプログラマチックインターフェースのそれぞれのセットの実施例を示す。 少なくともいくつかの実施形態に従う、ストリーム処理ステージのグラフをＳＰＳクライアントが生成できるように実装することができる実施例のウェブベースのインターフェースを示す。 少なくともいくつかの実施形態に従う、ＳＭＳに実装することができるプログラマチックレコード提示インターフェース及びレコード検索インターフェースの実施例を示す。 少なくともいくつかの実施形態に従う、ＳＭＳの取り込みサブシステムの実施例の要素を示す。 少なくともいくつかの実施形態に従う、ＳＭＳの保存サブシステムの実施例の要素を示す。 少なくともいくつかの実施形態に従う、ＳＭＳの検索サブシステムの実施例の要素、及び検索サブシステムとＳＰＳとの相互作用の実施例を示す。 少なくともいくつかの実施形態に従う、ＳＭＳまたはＳＰＳのノードに応じて設定することができる冗長グループの実施例を示す。 少なくともいくつかの実施形態に従う、所与の冗長グループのノードを複数のデータセンタ間に分配することができるプロバイダネットワーク環境を示す。 少なくともいくつかの実施形態に従う、ＳＭＳまたはＳＰＳのノードに応じて選択することができる複数の配置宛先を示す。 少なくともいくつかの実施形態に従う、ＳＰＳクライアント及びＳＭＳクライアントによって提示することができるセキュリティオプションリクエストの実施例をそれぞれ示す。 少なくともいくつかの実施形態に従う、ストリームデータプロデューサとＳＭＳの取り込みノードとの間の実施例の相互作用を示す。 少なくともいくつかの実施形態に従う、ＳＭＳにおける取り込まれたデータレコードに応じて生成することができるシーケンス番号の実施例の要素を示す。 少なくともいくつかの実施形態に従う、ＳＭＳにおける順序付けられたストレージ及びストリームデータレコードの検索の実施例を示す。 少なくともいくつかの実施形態に従う、ＳＭＳ及びＳＰＳノードに応じて作製することができるストリームパーティションマッピング及び対応する構造決定の実施例を示す。 少なくともいくつかの実施形態に従う、動的ストリームの再パーティションの実施例を示す。 少なくともいくつかの実施形態に従う、ストリームレコード取り込み及びストリームレコード検索のための、プログラマチックインターフェースのそれぞれのセットをサポートするように実行できる動作の態様を示すフロー図である。 少なくともいくつかの実施形態に従う、ストリーム処理ステージを構成するように実行できる動作の態様を示すフロー図である。 少なくともいくつかの実施形態に従う、ストリーム処理ワーカーノードの構成のためのクライアントライブラリのコンポーネントの起動に応答して実行できる動作の態様を示すフロー図である。 少なくともいくつかの実施形態に従う、ストリーム処理のための一つ以上のリカバリポリシを実施するように実行できる動作の態様を示すフロー図である。 少なくともいくつかの実施形態に従う、データストリームのための複数のセキュリティオプションを実施するように実行できる動作の態様を示すフロー図である。 少なくともいくつかの実施形態に従う、データストリームのためのパーティショニングポリシを実施するように実行できる動作の態様を示すフロー図である。 少なくともいくつかの実施形態に従う、データストリームの動的再パーティショニングを実施するように実行できる動作の態様を示すフロー図である。 少なくともいくつかの実施形態に従う、データストリームレコードのための少なくとも１回レコード取り込みポリシを実施するように実行できる動作の態様を示すフロー図である。 少なくともいくつかの実施形態に従う、データストリームのための複数の持続性ポリシを実施するように実行できる動作の態様を示すフロー図である。 少なくともいくつかの実施形態に従う、処理ステージのワーカーノードがデータベーステーブルを使用して作業負荷を調整するストリーム処理システムの実施例を示す。 少なくともいくつかの実施形態に従う、作業負荷調整に使用されるパーティション割当テーブルに保存できる実施例の入力を示す。 少なくともいくつかの実施形態に従う、そこにおいて処理動作を実行するためのパーティションを選択するための、ストリーム処理ステージのワーカーノードによって実行できる動作の態様を例証する。 少なくともいくつかの実施形態に従う、ストリーム管理サービス制御サブシステムから入手した情報に基づいてパーティション割当テーブルを更新するための、ストリーム処理ステージのワーカーノードによって実行できる動作の態様を示す。 少なくともいくつかの実施形態に従う、ストリーム処理ステージのワーカーノードによって実行できる負荷バランシング動作の態様を示す。 少なくともいくつかの実施形態において使用できる実施例のコンピューティングデバイスを示すブロック図である。
実施形態を、いくつかの実施形態の実施例及び実例となる図面として本明細書に記述するが、当業者は、記述した実施形態または図面に実施形態が限定されないことを認識する。図面及びその詳細な説明が、開示した特定の形態に実施形態を限定することは意図せず、むしろ、その意図が、添付の特許請求の範囲に定義されている趣旨及び範囲内に収まるすべての変更物、均等物及び代替物を包含できることを理解すべきである。本明細書に使用される見出しは、組織的な目的のみのためのものであり、記述または特許請求の範囲の範囲を限定するのに使用されることは意味しない。本出願全体を通じて使用される「することができる」という言葉は、許容的な意味（すなわち、可能性があるという意味）において使用され、義務的な意味（すなわち、必須の意味）ではない。同様に、「を含む」、「を含んでいる」及び「を含む（三人称単数）」という言葉は、それを含むが、それに限定されないことを意味する。
何百の、さらには何千もの並行データプロデューサ及びデータコンシューマを処理するように設計された大規模なデータストリームの作製、保存、検索及び処理を管理するための方法及び装置のさまざまな実施形態を記述する。本明細書に使用される「データストリーム」という用語は、一つ以上のデータプロデューサによって生成され、一つ以上のデータコンシューマによってアクセスできる、不変のバイトのシーケンスであると各々が仮定されるデータレコードのシーケンスを指す。ストリーム管理サービス（ＳＭＳ）は、いくつかの実施形態においてストリームの作製、構成及び削除、並びにストリームデータレコードの提示、保存及び検索を可能にするための、プログラマチックインターフェース（例えば、アプリケーションプログラミングインターフェース（ＡＰＩ）、ウェブページもしくはウェブサイト、グラフィカルユーザインターフェース、またはコマンドラインツール）を提供することができる。ＳＭＳ制御コンポーネントとの相互作用を伴う一部のタイプのストリームについての動作（例えば、ストリームの作製もしくは削除、または後述する種類の動的再パーティショニング動作）は、本明細書において「制御プレーン」動作と称され得る。一方で、通常、制御コンポーネントとの相互作用を必要としない（例えば、通常の動作状態下の）データレコードの提示、保存及び検索などの動作は、本明細書において「データプレーン」動作と称され得る。いくつかのそのような実施形態では、計算、保存及びネットワーキングリソースの動的にプロビジョニングされたセットを使用して、さらなる詳細は後述するように、例えば、ストリーム管理の作業負荷をスケーラブルな方式において幾多のサービスコンポーネント間に分配できるさまざまなパーティショニングポリシに基づいてサービスを実施することができる。頭字語ＳＭＳは、ストリーム管理サービス、並びにストリーム管理サービスを実施するのに使用される仮想及び／または物理リソースの収集を含むストリーム管理システムも指すように本明細書において使用され得る。
さまざまな実施形態において、ＳＭＳの一部の顧客は、ＳＭＳプログラマチックインターフェースを直接に呼び出すアプリケーションを開発することができる。しかしながら、少なくともいくつかの実施形態では、ＳＭＳインターフェースに加えて、ＳＭＳによって直接にサポートされたより低レベルのストリーム管理機能を使用してアプリケーションを開発することを望まないクライアントのために、さまざまな態様のストリーム処理を単純化できる、より高レベルの抽出またはアプリケーションレベルの処理フレームワークを顧客に提供することができる。そのようなフレームワークは、顧客が、より低レベルのストリーム管理動作ではなくストリームレコードを使用して実施できるビジネスロジックに、より焦点を合わせることができる（例えば、ＳＭＳインターフェースよりも優位に作製される）特有のプログラマチックインターフェースを提供することができる。いくつかの実施形態において、より高レベルのフレームワークは、特有の制御プレーン及びデータプレーンコンポーネントを持つストリーム処理サービス（ＳＰＳ）として実施することができる。これは例えば、ストリーム処理のためにプロビジョニングする自動リソース、処理ノードの自動フェイルオーバー、任意のストリーム処理ワークフローグラフを構築する能力、一時的なストリームのためのサポート、作業負荷の変更または他のトリガ条件に基づいた動的再パーティショニングなどの高度な機能性を提供することができる。少なくともいくつかの実施形態では、ストリーム管理サービスまたはストリーム処理サービスのいずれかまたはその両方のサービスは、仮想化環境において、マルチテナントの管理されたネットワークアクセス可能サービスとして実施することができる。つまり、さまざまな物理リソース（例えば、コンピュータサーバまたはホスト、ストレージデバイス、ネットワーキングデバイスなど）は、少なくとも場合によっては、そのような実施形態において、リソースが厳密にどの程度共用されているかを顧客に必ずしも認識させることなく、さらには、所与のリソースが全く共用されていないことを顧客に認識させることなく、異なる顧客のストリーム間で共用することができる。管理されたマルチテナントストリーム管理及び／または処理する管理されたサービスの制御コンポーネントは、クライアントがそのいくつかを選択可能なさまざまな適用可能なポリシに基づいて、特定のストリームに使用されるノードまたはリソースを動的に追加、削除または再構成することができる。さらに、制御コンポーネントは、（例えば、たとえ少なくともいくつかのハードウェアまたはソフトウェアを両方のクライアントによって共用できる場合でも、あるクライアントのストリームアプリケーションが別のクライアントのデータにアクセスできないことを保証するための）さまざまなタイプのセキュリティプロトコルの透過的な実施、請求のためのリソース活用の監視、監査またはデバッギングに使用できるロギング情報の生成などにも関与することができる。管理されたマルチテナントサービス（複数可）のクライアントの観点からすれば、サービス（複数可）によって実施される制御上または管理上の機能性は、大規模なストリーミングアプリケーションのサポートに伴う複雑性の大部分を排除することができる。いくつかのシナリオでは、そのようなマルチテナントサービスの顧客は、いくつかの物理リソースを、それらのタイプの動作のためのシングルテナント（すなわち、単独の顧客またはクライアントに代わって実行される動作に限定されたもの）として少なくとも一時的に用意できる場合には、少なくともいくつかのタイプのストリーム関連動作においてリソースの共用を望まないことを示すことができる。
さまざまな実施形態において、ＳＭＳ及び／またはＳＰＳ制御プレーン並びにデータプレーン動作の実施には、多くの異なるアプローチをとることができる。例えば、制御プレーン動作に関しては、いくつかの実施において、制御サーバまたはノードの冗長グループを設定することができる。冗長グループは、複数の制御サーバを含むことができ、そのうちの一つのサーバを、さまざまなストリームについての管理上のリクエストの応答に関与するプライマリサーバとして用意し、一方で、別のサーバを、進行中のプライマリにおける障害（または、それとの接続性の損失）などのトリガ条件の発生時にプライマリを引き継ぐように用意することができる。別の実施では、ネットワークアクセス可能データベースサービスにおいて作製された一つ以上のテーブルを使用して、さまざまなストリームについての制御プレーンメタデータ（例えば、パーティションマップ）を保存し、そしてさまざまな取り込み、保存または検索ノードが、データプレーン動作に必要なメタデータのサブセットを入手するために必要に応じてテーブルにアクセスすることができる。種々の実施形態におけるＳＰＳ及びＳＭＳデータプレーン及び制御プレーンの機能性のさまざまな態様についての詳細を後述する。ストリーム管理サービスが実施されるいくつかの実施形態において、より高レベルのプリミティブを提供するストリーム処理サービスを必ずしも実施しなくてもよいことに留意されたい。他の実施形態では、ストリーム処理サービスの高レベルのプログラマチックインターフェースのみを顧客に公開し、使用されるより低レベルのストリーム管理インターフェースは、クライアントが入手できなくてもよい。
いくつかの実施形態に従い、ストリーム管理システムは、データレコードの入手または収集に主に関与するレコード取り込みサブシステム、適用可能な持続性または永続性ポリシに従うデータレコードコンテンツのセーブに主に関与するレコード保存サブシステム、及び保存されたレコードをターゲットにするリクエストの読み出しの応答に主に関与するレコード検索サブシステムを含む独立して構成可能な複数のサブシステムを備えることができる。いくつかの実施形態では、例えば、仮想または物理的サーバなどの、選択されたリソースにおける取り込み、保存及び検索サブシステムの各々に必要な数のノードを動的に決定及び／または初期化することによって残りのサブシステムの構成に関与する一つ以上の管理的または制御コンポーネントを備える制御サブシステムも実装することができる。取り込み、保存、検索及び制御サブシステムの各々は、サブシステムの「ノード」または「サーバ」として集合的に参照され得るそれぞれの複数のハードウェア及び／またはソフトウェアコンポーネントを使用して実施することができる。それ故に、ＳＭＳのさまざまなリソースは、４つの機能別カテゴリ、すなわち、取り込み、保存、検索または制御のうちの一つに属すると論理的に言うことができる。いくつかの実施では、制御コンポーネントのそれぞれのセットを他のサブシステムの各々について構築する、例えば、独立した取り込み制御サブシステム、保存制御サブシステム及び／または検索制御サブシステムを実装することができる。各々のそのような制御サブシステムは、対応するサブシステムの他のノード及び／またはクライアントもしくは他のサブシステムからの管理上のクエリに対する応答に使用されるリソースの特定に関与することができる。いくつかの実施では、さまざまなタイプのＳＭＳ及び／またはＳＰＳ機能を実行する能力があるノードのプールを事前に設定し、それらのプールのうちの選択された一部を、必要に応じて、新規のストリームまたは新規の処理ステージに割り当てることができる。
少なくともいくつかの実施形態では、例えば、データレコードのサブセットを、取り込み、保存、検索及び／または制御ノードの種々のセット間に分配するために、ストリームパーティショニングポリシ及び関連するマッピングを実施することができる。例えば、特定のデータストリームに対して選択されたパーティショニングポリシ、並びにレコード取り込み速度及び／または検索速度の期待値などの他のファクタに基づいて、制御コンポーネントは、取り込み、保存及び検索のために初期（すなわち、ストリーム作製時）に構築すべきノード（例えば、プロセスまたはスレッド）の数、並びにそれらのノードを仮想及び／または物理マシンにどのようにマッピングすべきかを決定することができる。経時的に、所与のストリームに関連する作業負荷が増大または減少し、（他のトリガ条件の中でも）ストリームの再パーティショニングが引き起こされ得る。そのような再パーティショニングは、レコードのパーティションの決定に使用される機能、使用されるパーティショニングキー、パーティションの合計数、取り込みノード、保存ノードもしくは検索ノードの数、または種々の物理もしくは仮想リソースへのノードの配置などのさまざまなパラメータの変更を伴い得る。少なくともいくつかの実施形態では、再パーティショニングは、さらなる詳細を後述する技術を使用して、データレコードの流れを遮ることなく、動的に実施することができる。いくつかの実施形態では、種々のパーティショニングスキーム及び再パーティショントリガ基準を、例えば、クライアント提供のパラメータまたはＳＭＳ制御ノードのヒューリスティックに基づいて、種々のデータストリームに使用することができる。いくつかの実施形態では、例えば、クライアントの嗜好、ストリームの予期される寿命または他のファクタに基づいて、再パーティションの数及び／または頻度を制限することができる。
種々の実施形態において、多くの異なるレコード取り込みポリシ及びインターフェースを実装することができる。例えば、いくつかの実施形態では、クライアント（例えば、ＳＭＳの顧客に代わってＳＭＳのプログラマチックインターフェースを呼び出すように構成された実行可能コンポーネントまたはモジュール）が、インライン提示インターフェースまたは照会用提示インターフェースのいずれかを利用することができる。そのような実施形態において、インライン提示では、提示リクエストの一部としてデータレコードのコンテンツまたは主部を含ませることができる。対照的に、照会用提示リクエストでは、データレコードのコンテンツまたは主部をそこから入手できるアドレス（例えば、ストレージデバイスアドレス、データベースレコードアドレスまたはＵＲＬ（ユーアールエル））を提供することができる。いくつかの実施では、第一のＮバイトのデータレコードをインラインに含ませ、一方で、（もしあれば）残りのバイトが照会用として提供されるハイブリッド提示インターフェースもまたサポートすることができる、または代わりにサポートすることができる。そのようなシナリオでは、（その主部がＮバイト長未満である）短いレコードは、提示リクエストによって完全に指定され得、一方で、より長いレコードの一部は、対応するアドレスから入手する必要が生じ得る。
いくつかの実施形態では、取り込み中にレコードコンテンツを指定するための種々の代替となるものに加えて、様々な応答または重複排除関連取り込みポリシも実施することができる。例えば、いくつかのストリームアプリケーションにおいて、クライアントは、あらゆるデータレコードがＳＭＳによって確実に取り込まれることを所望することがある。広く分散したストリーム管理環境では、パケットを損失することがあり、または時々、データプロデューサと取り込みノードとの間の経路に沿うさまざまな障害が発生することがあり、これによりいくつかの提示されたデータが損失する可能性がある。したがって、いくつかの実施形態では、ＳＭＳは、取り込みサブシステムから肯定応答が受信されるまでレコード提示者が同じレコードを１回以上提示できることに従う、少なくとも１回取り込みポリシを実施することができる。通常の動作状態下では、レコードは１回提示され得、提示者は、受信する取り込みノードがレコードを入手及び保存した後に、応答を受信することができる。応答が損失もしくは遅延している場合、またはレコード提示リクエストそれ自体が損失している場合には、提示者は、応答が最終的に受信されるまで同じデータレコードを１回以上再提示することができる。例えば、取り込みノードは、それが重複しているか否かにかかわらず、応答が提示者によって既に受信されている場合にはレコードが再提示されないという予想に基づいて、各提示についての応答を生成することができる。しかしながら、少なくともいくつかの実施形態では、取り込みノードは、同じデータレコードが複数回数提示されたことの認識、そして不必要な重複データの新規のコピーの保存の回避に関与することができる。一実施形態において、少なくとも１回取り込みポリシの少なくとも二つのバージョンをサポートすることができる。すなわち、（「少なくとも１回取り込み、重複無」と称され得る）そのうちの一つのバージョンでは、ＳＭＳは、データレコードの重複排除（すなわち、データが二つ以上の提示のセットのうちの一つのみに応答してＳＭＳ保存サブシステムに保存されることが保証される）に関与し、（「少なくとも１回、重複許可」と称され得る）もう一つのバージョンでは、ＳＭＳによるデータレコードの保存の重複が許可される。少なくとも１回の重複が許可されたアプローチは、データレコード重複の否定的な結果が少ないもしくは全くないストリームアプリケーション、及び／または特有の重複削除を実行するストリームアプリケーションに有用であり得る。提示されたデータレコードのすべてには応答が必要とされないベストエフォート取り込みポリシなどの他の取り込みポリシもサポートすることができる。少なくともいくつかの実施形態では、ベストエフォート取り込みポリシが実施される場合には、データレコードの少数の損失は許容範囲にあり得る。クライアントは、さまざまな実施形態において、さまざまなストリームに使用することを所望する取り込みポリシを選択することができる。
少なくともいくつかの実施形態では、ストリームレコードの保存に関して、多くの代替的なポリシもサポートすることができる。例えば、クライアントは、ＳＭＳによってサポートされたいくつかのポリシの中から、レコード保存の態様を規定する持続性ポリシを選ぶことができる。この態様は、保存される所与のデータレコードのコピーの数、コピーに使用される保存技術のタイプ（例えば、揮発性または不揮発性ＲＡＭ、回転円盤ベースのストレージ、ソリッドステートデバイス（ＳＳＤ）、ネットワーク接続ストレージデバイスなど）などが挙げられる。例えば、クライアントが、ディスクベースのストレージにＮ−レプリカ持続性ポリシを選択する場合には、レコードのＮ個のコピーがＮ個のそれぞれのディスクデバイスに安全に書き込まれるまで、データレコード提示は完全であるとみなされ得ない。ディスクベースのストレージデバイスが使用される少なくともいくつかの実施形態では、ＳＭＳ保存サブシステムは、例えば、ディスクの探し出しのパフォーマンスインパクトを回避するために、所与のパーティションの入力データレコードをディスクに連続的に書き込むことを試みることができる。例えば、取り込み順に基づく順序付けられたレコード検索を可能にするタイムスタンプベースの技術を含む後述するようなさまざまな技術を使用してデータレコード（及びその保存）のためのシーケンス番号を生成することができる。少なくともいくつかの実施形態では、所与のパーティションのデータレコードを、例えば、隣接するディスクに、かつ他のパーティションのデータレコードとは別々に、共に保存することができる。いくつかの実施では、（クライアントまたはＳＭＳによって選択された）保持ポリシ、または（いくつかの重複が提示されている場合でさえも、所与の重複するデータレコードがＳＭＳ保存サブシステムに全く保存されていないことを保証するのにＳＭＳが必要とし得る、任意の所与のデータレコードの提示後の期間を示す）重複排除時間窓ポリシに従い、少なくともいくつかのデータレコードを異なるタイプのストレージサービスにアーカイブする、及び／またはＳＭＳからの期間後に削除することができる。そのような削除動作は、本明細書においてストリーム「トリミング」と称され得る。いくつかの実施形態では、クライアントは、例えば、指定されたデータレコードがもはや必要とされておらず、したがって、トリミングリクエストを提示するクライアントの観点からすればそれを削除できることをＳＭＳに通知するストリームトリミングリクエストを提示する、または指定されたデータレコードの削除を明示的にリクエストすることができる。所与のストリームのデータレコードを消費する複数のクライアントが存在するシナリオでは、ＳＭＳは、所与のレコードがすべての関心のあるコンシューマによってアクセスされる前に時期尚早に削除またはトリミングされないことを確実にする役割を果たし得る。いくつかの実施では、所与のストリームのデータコンシューマがＮ個存在する場合には、ＳＭＳは、ストリームの所与のレコードＲを削除する前に、すべてのＮ個のデータコンシューマがＲを読み出したまたは処理したことを確定するまで待機することができる。ＳＭＳは、コンシューマからのそれぞれのトリミングリクエスト、または例えば、データコンシューマがストリームにおいてどの程度まで進行したかのそれぞれの表示に基づいて、すべてのコンシューマによってＲが読み出されたことを確定することができる。いくつかの実施形態において、（試験関連アプリケーションなどの）一部のタイプのデータコンシューマは、アクセスされる前のデータレコードの少なくとも小さいサブセットの削除を受け入れることができる。それ故に、少なくともいくつかの実施形態では、アプリケーションは、検索前のデータ削除の容認性についてＳＭＳに通知し、そしてＳＭＳは、通知に従い削除をスケジュールすることができる。いくつかの実施形態において、例えば、ストリームデータレコードをコピーすべきストレージデバイスのタイプを示すデータ保持ポリシ、及びそのようなコピーに使用されるスケジューリングポリシの一部としてアーカイバルポリシを実施することができる。
少なくともいくつかの実施形態では、レコード検索のための複数のプログラマチックインターフェースもサポートすることができる。一実施形態において、イテレータベースのアプローチを使用することができる。このアプローチでは、一つのプログラマチックインターフェース（例えば、ｇｅｔＩｔｅｒａｔｏｒ）を使用して、ストリームのパーティション内において、（例えば、シーケンス番号またはタイムスタンプに基づいて）指定された論理オフセットにおいてイテレータまたはカーソルをインスタンス化する及び位置付けることができる。そしてその後、異なるプログラマチックインターフェース（例えば、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓ）を使用して、イテレータの現在位置から開始して、指定された数のデータレコードを連続的に読み出すことができる。イテレータのインスタンス化の実施によって、クライアントは、ストリームパーティション内においてレコード検索のための任意のまたはランダムの開始位置を指定することができる。そのような実施形態では、クライアントがランダムアクセスパターンにおいてデータレコードを読み出すことを所望する場合には、クライアントは、新規のイテレータを繰り返し作製する必要が生じ得る。回転円盤ベースのストレージシステムでは、頻繁なランダムアクセスに要求されるディスクの探し出しは、入出力応答時間に著しく影響を及ぼし得る。それ故に、ストリームデータレコードをランダムではなく連続的に読み出すことをクライアントに奨励するので、少なくともいくつかの実施形態では、順次読み出しアクセスとは異なる（例えば、より高い）請求率をランダム読み出しアクセスに適用することができる。それ故に、例えば、クライアントは、Ｘ＞Ｙであるいくつかの実施において、ｇｅｔＩｔｅｒａｔｏｒの呼び出しごとにＸ通貨単位で請求し、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓを通じて検索されたレコードごとにＹ通貨単位で請求され得る。少なくともいくつかの実施形態では、代替的なクライアントインターフェースが他の動作カテゴリ（例えば、取り込み）のためにサポートされるときには、代替的なものについての請求率または値段も異なることがある。例えば、クライアントは、クライアントが順次読み出しよりもランダム読み出しにより多く課金され得るように、オンライン提示リクエストよりも照会用提示リクエストにより多く課金され得る。さまざまな実施形態では、データレコードのサイズ、長期にわたる書き込みリクエスト対読み出しリクエストの配分、選択された持続性ポリシなどの他のファクタも請求額に影響を与え得る。
いくつかの実施形態に従い、ストリーム処理サービス（ＳＰＳ）によって、クライアントは、所与のステージにおいて実行された処理の出力を、ゼロ以上の他のステージの入力として使用することができる幾多の処理ステージを含む、複雑な処理ワークフローを任意に指定することができる。いくつかの実施形態では、（データレコードの取り込み、保存及び検索においてＳＭＳに関連して記述したのに類似する）パーティショニングポリシを使用して、処理作業負荷を、さまざまなステージにおける複数のワーカーノード間に分配することができる。一つのそのような実施形態では、任意の所与のステージについてのさまざまな構成設定をクライアントが指定できるプログラマチックＳＰＳインターフェースを実装することができる。この構成設定は例えば、ステージについての入力データソース（複数可）（例えば、ストリームについてのパーティショニングポリシと共に、データレコードがそこから検索される一つ以上のストリーム）、ステージにおいて実行される処理動作、及びステージからの出力または結果の分配（例えば、出力が保存場所にセーブされる、ネットワークエンドポイントに伝送される、または異なるストリームの形態において一つ以上の他の処理ステージに送り込まるか否か）に関する記述子または仕様を含む。少なくともいくつかの実施形態では、ＳＰＳステージにおいて指定された処理動作は、冪等であってもよい。つまり、所与の処理動作が同じ入力データにおいて複数回数実行される場合には、動作結果は、動作が１回だけ実行された場合に入手された結果と相違しない。さらなる詳細は後述するように、処理動作が冪等である場合には、障害（例えば、ＳＰＳステージにおけるワーカーノード障害）からのリカバリは、簡易化することができる。いくつかの実施形態に従い、いくつかまたはすべてのＳＰＳステージにおいて、非冪等の処理動作が可能である。
さまざまな実施形態では、入力ストリームパーティショニングポリシなどの構成情報、次に、ＳＰＳプログラマチックインターフェースを通じて受信した処理動作の性質に少なくともある程度基づいて、ＳＰＳ制御サーバは、処理ワークフローのさまざまなステージにおいて何個のワーカーノードを初期に設定すべきかを決定することができる。ワーカーノードに使用されるリソース（例えば、使用される仮想または物理マシン）の実行能力も、ワーカーノードの初期の数及び配置を決定するときに考慮に入れることができる。いくつかの実施では、（その各々が実行可能なスレッドまたは実行可能なプロセスを含み得る）選択された数のワーカーノードをインスタンス化することができる。各ワーカーノードは、例えば、適切な入力ソース（例えば、一つ以上のストリームパーティションの検索ノード）からデータレコードを入手し、データレコードについての指定された処理動作を実行し、処理結果を指定された出力宛先（複数可）に伝送するように構成することができる。さらに、少なくともいくつかの実施形態では、パーティションレコードが連続的に処理されるという想定の下に、ワーカーノードにおいて処理されたパーティションの一部を示す進捗レコードまたはチェックポイントを保存するように所与のワーカーノードを構成できることに従う、チェックポイントスキームを実施することができる。例えば、いくつかの実施では、ワーカーノードは、進捗レコードを周期的に（例えば、Ｎ秒ごとに１回またはＲデータレコードが処理されるごとに１回）、かつ／またはＳＰＳ制御サーバからのチェックポイントリクエストに応答して永続ストレージに書き込むことができる。
いくつかの実施形態では、進捗レコードを、ワーカーノード障害からの迅速なリカバリのために使用することができる。例えば、ＳＰＳ制御サーバは、例えば、ハートビートメカニズムを使用して、及び／またはリソース使用レベル（例えば、ＣＰＵ使用レベル、入出力デバイス使用レベルまたはネットワーク使用レベル）を監視することによって、さまざまなワーカーノードの調子状態を長期にわたり監視することができる。特定のワーカーノードが望ましくないまたは不健全な状態にあること（例えば、無反応または過負荷にある場合）のＳＰＳ制御サーバによる決定に応答して、取り換えワーカーノードをインスタンス化して、特定のワーカーノードの責務を引き継ぐことができる。取り換えワーカーノードは、取り換えられたワーカーノードによって保存された最近の進捗レコードにアクセスして、取り換えワーカーノードが処理すべきデータレコードのセットを特定することができる。処理動作が冪等である実施形態では、一部の動作が繰り返される場合でさえも、（例えば、取り換えワーカーのインスタンス化の前のいくらかの時間最近の進捗レコードが書き込まれるので）、全体の処理結果は、障害及び取り換えによる影響を受けない。いくつかの実施では、ワーカーノードは、それ自身によって処理された所与のストリームまたはパーティションのサブセットを示す進捗レコードの保存に加えて、累積されたアプリケーション状態情報を保存するようにも構成できる。例えば、ストリーム処理ワークフローが、サービス利用状況総計値を示すストリーミングデータレコードの解析に基づく、特定のサービスに対するクライアント請求額の決定に関与する場合には、ワーカーノードは、さまざまなクライアントについて決定された累積の請求額を周期的に保存することができる。
少なくともいくつかの実施形態では、ＳＰＳ制御サーバは、さまざまなステージにおける入力ストリームの動的再パーティショニングのリクエスト、所与のステージにおける所与のパーティションに割り当てられたワーカーノードの数の変更、いくつかのステージへのより高性能のワーカーノードの割り当て、またはある物理リソースから異なる実行能力を持つ別の物理リソースへのワーカーノードの転送などの他のアクションの起動による作業負荷レベルの変更または検出された作業負荷アンバランス（例えば、一つのパーティションについての取り込み速度が、他の取り込み速度よりも不釣り合いに高くなる場合）などのさまざまな他のトリガに応答するようにも構成できる。いくつかの実施形態では、例えば、チェックポイントベースのリカバリポリシではなく、ベストエフォートのリカバリポリシを所与のステージについて実施することのＳＰＳ制御サーバによる決定に応答して、前述のタイプの進捗レコードを、少なくともいくつかのＳＰＳステージのワーカーノードによって保存しなくてもよい。そのようなベストエフォートのリカバリポリシのいくつかの実施では、取り換えワーカーノードは、進捗レコードにアクセスする必要なく、受信したときに新規のデータレコードを簡単に処理することができる。いくつかの実施形態において、クライアントがＳＰＳステージにおいてベストエフォートのリカバリポリシの実施を所望する場合には、ステージにおいて実行されるストリーム処理動作は、必ずしも冪等でなくてもよい。非冪等の処理動作をＳＰＳステージにおいてストリームレコードに実行するいくつかの実施形態では、チェックポイントベースのリカバリはサポートされず、ベストエフォートのリカバリなどの異なるリカバリスキームを使用することができる。少なくとも一つの実施形態では、冪等ストリーム処理動作のみをＳＰＳステージにおいて実行することができる。
いくつかのストリームのデータレコードは、機密もしくは秘密情報を含む、またはＳＰＳステージにおいて実行される処理動作は、競合他社による発見が問題となり得る登録商標権を持つアルゴリズムの使用を含むことがある。それ故に、クライアントは、特に、クライアント自身によって完全に制御されないプロバイダネットワークデータセンタに設置されたリソースを使用して動作が実行される場合には、ストリーム管理及び処理動作のさまざまなカテゴリのセキュリティについて憂慮することがある。インターネット及び／または他のネットワークを経由してクライアントの分散集合にアクセス可能な一つ以上のネットワークアクセス可能サービス（例えば、さまざまなタイプのクラウドベースのデータベース、コンピューティングまたはストレージサービス）を提供するための、企業または公営企業組織などによって設定されたネットワークは、本明細書においてプロバイダネットワークと称され得る。いくつかの実施形態において、クライアントは、データストリームのための複数のセキュリティ関連オプションの中からそれを選ぶことができる。前述のように、ＳＰＳ構成とＳＭＳ構成との組み合わせは、多くの異なる機能別カテゴリに属するノード、例えば、ＳＭＳ及び／またはＳＰＳについての制御ノード、ＳＭＳ取り込みノード、ＳＭＳ保存ノード、ＳＭＳ検索ノード、並びにＳＰＳ処理またはワーカーノードを備えることができる。いくつかの実施形態では、クライアントが利用可能なセキュリティ関連の選択は、さまざまなタイプのノードの配置または位置についてのオプションを含むことができる。例えば、一実施形態において、クライアントは、プロバイダネットワークに設置されたリソースを使用してストリームレコードが初期に収集及び／または保存された場合でさえも、ストリームワークフローの一つ以上の処理ステージにおけるＳＰＳワーカーノードを、クライアント所有の設備に設置されたコンピューティングデバイスに実装することをリクエストできる。そのような配置リクエストに応答して、所与のストリームにおける種々の機能別カテゴリのノードを、異なるセキュリティ特性またはプロファイルを利用してそれぞれのリソースセットにおいてインスタンス化することができる。
種々の実施形態において、リソースセットは、例えば、物理的な位置、（例えば、リソースへの物理的アクセスを有する）使用される物理的セキュリティプロトコル、ネットワーク分離レベル（例えば、リソースのネットワークアドレスがさまざまな事業体によって見られる範囲）、マルチテナンシ対シングルテナンシなどを含むさまざまなセキュリティ関連特性に関して互いに異なってもよい。いくつかの実施形態において、クライアントは、プロバイダネットワーク内に隔離された仮想ネットワーク（ＩＶＮ）を構築することができ、これにより所与のクライアントに、そのクライアントのＩＶＮ内に含まれるさまざまなデバイスのネットワーキング構成にわたる実質的な制御が与えられる。特に、クライアントは、そのクライアントのＩＶＮ内のさまざまなサーバまたはコンピュートインスタンスに割り当てられたネットワークアドレス（例えば、インターネットプロトコルまたはＩＰアドレス）へのアクセスを制限することができる。そのような実施形態において、クライアントは、ＳＭＳまたはＳＰＳノードの特定のサブセットを指定されたＩＶＮ内においてインスタンス化することをリクエストできる。（通常、マルチテナントホストとして構成できる）仮想インスタンスホストなどのプロバイダネットワークリソースがＳＭＳまたはＳＰＳノードのさまざまなカテゴリにおいて使用される実施形態では、クライアントは、ノードのいくつかのセットを、そのクライアントのみに属するインスタンスの実装に制限されるインスタンスホストにおいてインスタンス化することをリクエストできる（すなわち、いくつかのＳＭＳまたはＳＰＳノードを、シングルテナントホストとして構成されたインスタンスホストに実装することができる）。
いくつかの実施形態では、別のセキュリティ関連オプションとして、クライアントは、ＳＭＳにおける取り込み前などのネットワークリンクを通じて伝送する前、取り込みサブシステムと保存サブシステムとの間、保存サブシステムと検索サブシステムとの間、検索サブシステムとＳＰＳワーカーノードとの間、及び／またはワーカーノードとＳＰＳ出力宛先との間に、特定のストリームのデータレコードを暗号化することをリクエストできる。いくつかの実施形態では、クライアントは、使用する暗号化アルゴリズムを指定することができる。一実施形態では、ＴＬＳ（トランスポート層セキュリティ）またはＳＳＬ（セキュアソケットレイヤ）プロトコルなどのセキュアネットワーキングプロトコルを、データレコード伝送及び／またはＳＰＳ処理結果の伝送に使用することができる。
データストリーム概念及び概観
図１は、少なくともいくつかの実施形態に従う、データストリーム概念の簡易化した概観を提供する。示すように、ストリーム１００は、ＤＲ１１０Ａ、１１０Ｂ、１１０Ｃ、１１０Ｄ及び１１０Ｅなどの複数のデータレコード（ＤＲ）１１０を備えることができる。データプロデューサ１２０Ａ及び１２０Ｂなどの（データソースとも称され得る）一つ以上のデータプロデューサ１２０が、書き込み動作１５１を実行してストリーム１００のデータレコードのコンテンツを生成することができる。種々の実施形態において、多くの異なるタイプのデータプロデューサが、例えば、携帯電話またはタブレットアプリケーション、センサアレイ、ソーシャルメディアプラットフォーム、ロギングアプリケーションまたはシステムロギングコンポーネント、さまざまな種類のモニタリングエージェントなどのデータのストリームを生成することができる。一個以上のデータコンシューマ１３０（例えば、データコンシューマ１３０Ａ及び１３０Ｂ）が、読み出し動作１５２を実行して、データプロデューサ１２０によって生成されたデータレコードのコンテンツにアクセスすることができる。いくつかの実施形態において、データコンシューマ１３０は、例えば、ストリーム処理ステージのワーカーノードを備えることができる。
少なくともいくつかの実施形態では、ＳＭＳに保存されている所与のデータレコード１１０は、データ部１０１（例えば、ＤＲ１１０Ａ、１１０Ｂ、１１０Ｃ、１１０Ｄ及び１１０Ｅそれぞれのデータ部１０１Ａ、１０１Ｂ、１０１Ｃ、１０１Ｄ及び１０１Ｅ）、及びシーケンス番号ＳＮ１０２（例えば、ＤＲ１１０Ａ、１１０Ｂ、１１０Ｃ、１１０Ｄ及び１１０ＥそれぞれのＳＮ１０２Ａ、１０２Ｂ、１０２Ｃ、１０２Ｄ及び１０２Ｅ）を備えることができる。描写した実施形態では、シーケンス番号１０２は、ストリーム管理システム（または、ストリーム管理システムの特定のノード）においてＤＲが受信された順序を表すことができる。いくつかの実施では、データ部１０１は、不変の解釈されていないバイトシーケンスを含むことができる。つまり、書き込み動作１５２が完了すると、書き込みの結果として生成されたＤＲのコンテンツは、ＳＭＳによって変更されず、通例、ＳＭＳは、データの意味論を認識しない。いくつかの実施では、所与のストリーム１００の種々のデータレコードは、異なる量のデータを含むことができ、一方で、他の実施では、所与のストリームのすべてのデータレコードは、同じサイズであってもよい。少なくともいくつかの実施において、ＳＭＳのノード（例えば、取り込みサブシステムのノード及び／または保存サブシステムのノード）は、ＳＮ１０２の生成の役割を果たし得る。さらなる詳細は後述するように、データレコードのシーケンス番号は、常に連続していなくてもよい。一つの実施において、クライアントまたはデータプロデューサ１２０は、書き込みリクエストの一部として、対応するデータレコードに使用される最小シーケンス番号の表示を提供することができる。いくつかの実施形態において、データプロデューサ１２０は、データレコードのデータ部へのポインタ（または、そのアドレス）を含む書き込みリクエストを提示することができる。これは例えば、データ部をそこから入手できるストレージデバイスアドレス（例えば、デバイス名及びデバイス内のオフセット）またはネットワークアドレス（例えば、ＵＲＬ）を提供することによって提示される。
さまざまな実施形態において、ストリーム管理サービスは、データプロデューサ１２０からのデータの受信、データの保存、及びデータコンシューマ１３０による一つ以上のアクセスパターンにおけるデータへのアクセスの役割を果たし得る。少なくともいくつかの実施形態では、ストリーム１００は、データレコードの受信、保存及び検索の作業負荷を分配するように、パーティショニングまたは「シャード化」されてもよい。そのような実施形態では、パーティションまたはシャードを、データレコードの一つ以上の属性に基づいて入力データレコード１１０に応じて選択し、そしてデータレコードを取り込む、保存するまたは検索するための具体的なノードを、パーティションに基づいて特定することができる。いくつかの実施では、データプロデューサ１２０は、パーティショニング属性としての機能を果たすことができる書き込み動作を持つ明示的なパーティショニングキーを提供することができ、そのようなキーは、パーティション識別子にマッピングすることができる。他の実施では、ＳＭＳは、データプロデューサ１２０のアイデンティティ、データプロデューサのＩＰアドレスなどのファクタ、さらには提示されたデータのコンテンツに基づいて、パーティションＩＤを推測することができる。データストリームがパーティショニングされるいくつかの実施では、シーケンス番号をパーティションごとの基準において割り当てることができる。例えば、シーケンス番号は、特定のパーティションのデータレコードが受信された順序を表し得るが、二つの異なるパーティションにおけるデータレコードＤＲ１及びＤＲ２のシーケンス番号は、ＤＲ１及びＤＲ２が受信された相対的順序を必ずしも表さなくてもよい。他の実施では、シーケンス番号は、パーティションごとの基準ではなく、ストリームワイドにおいて割り当てることができる。これによりデータレコードＤＲ１に割り当てられたシーケンス番号ＳＮ１が、データレコードＤＲ２に割り当てられたシーケンス番号ＳＮ２よりも小さい場合には、ＤＲ１及びＤＲ２が属するパーティションにかかわらず、ＳＭＳによってＤＲ２よりも先にＤＲ１が受信されたことが示唆される。
さまざまな実施形態において、ＳＭＳによってサポートされた検索または読み出しインターフェースによって、データコンシューマ１３０は、連続的にかつ／またはランダムな順序でデータレコードにアクセスすることができる。一実施形態において、読み出しのアプリケーションプログラミングインターフェース（ＡＰＩ）のイテレータベースのセットをサポートすることができる。データコンシューマ１３０は、指定されたシーケンス番号及び／またはパーティション識別子によって示されるイテレータの最初の位置を含む、データストリームについてのイテレータを入手するためのリクエストを提示することができる。開始プログラムのインスタンス化後、データコンシューマは、ストリームまたはパーティション内のその最初の位置から開始した順次順序においてデータレコードを読み出すリクエストを提示することができる。そのような実施形態において、データコンシューマがデータレコードの一部をランダムな順序において読み出すことを所望する場合には、各読み出しにおいて新規のイテレータをインスタンス化する必要が生じ得る。少なくともいくつかの実施において、所与のパーティションまたはストリームのデータレコードは、通常、ディスクの探し出しを回避する順次書き込み動作を使用して、シーケンス番号順にディスクベースのストレージに書き込むことができる。順次読み出し動作は、ディスクの探し出しに伴う諸経費も回避することができる。それ故に、いくつかの実施形態において、データコンシューマは、価格についての動機のためにランダム読み出しではなく順次読み出しを実行するように奨励され得る。例えば、イテレータインスタンス化などのランダムアクセス読み出し動作は、順次アクセス読み出し動作よりも関連する請求率が高くなる可能性がある。
実施例のシステム環境
図２は、少なくともいくつかの実施形態に従う、ストリーム管理システム（ＳＭＳ）、及びストリーム処理ステージの集合を備えるストリーム処理システム（ＳＰＳ）のさまざまなサブコンポーネント間のデータの流れの概観を提供する。示すように、ＳＭＳ２８０は、取り込みサブシステム２０４、保存サブシステム２０６、検索サブシステム２０８、及びＳＭＳ制御サブシステム２１０を備えることができる。ＳＭＳサブシステムの各々は、例えば、後述するようなプロバイダネットワーク（または、クライアント所有のもしくは第三者設備）のさまざまなリソースにおいてインスタンス化された、それぞれの実行可能なスレッドまたはプロセスを使用して実装された一つ以上のノードまたはコンポーネントを含むことができる。取り込みサブシステム２０４のノードは、ストリームに使用されるパーティショニングポリシに基づいて、データプロデューサ１２０（１２０Ａ、１２０Ｂ及び１２０Ｃなど）から特定のデータストリームのデータレコードを（例えば、ＳＭＳ制御サブシステム２１０のノードによって）入手するように構成できる。そして各取り込みノードは、受信したデータレコードを、保存サブシステム２０６の対応するノードに送ることができる。保存サブシステムのノードは、データレコードを、ストリームに対して選択された持続性ポリシに従い、さまざまなタイプのストレージデバイスのいずれかにセーブすることができる。検索サブシステム２０８のノードは、ＳＰＳ２９０のワーカーノードなどのデータコンシューマからの読み出しリクエストに応答することができる。ＳＰＳ２９０のステージ２１５Ａ、２１５Ｂ、１２１５Ｃ及び２１５Ｄなどのストリーム処理ステージ２１５は、ＳＰＳ制御サブシステム２２０の援助を受けて構築することができる。各ステージ２１５は、受信したデータレコードに処理動作のセットを実行するための、ＳＰＳ制御サブシステム２２０によって構成された一つ以上のワーカーノードを含むことができる。示すように、ステージ２１５のいくつか（例えば、２１５Ａ及び２１５Ｂ）は、ＳＭＳ２８０から直接にデータレコードを入手し、一方で、他のステージ（例えば、２１５Ｃ及び２１５Ｄ）は、他のステージからの入力を受信することができる。いくつかの実施形態において、複数のＳＰＳステージ２１５は、並行して動作することができる。例えば、種々の処理動作を、ステージ２１５Ａ及び２１５Ｂにおいて同じストリームから検索されたデータレコードに同時に実行することができる。特定のストリームのための図２に示すものに類似するそれぞれのサブシステム及び処理ステージを、他のストリームにおいても同じようにインスタンス化できることに留意されたい。
少なくともいくつかの実施形態では、図２に示すサブシステム及び処理ステージのノードの少なくともいくつかは、プロバイダネットワークリソースを使用して実装することができる。前述したように、インターネット及び／または他のネットワークを経由してクライアントの分散集合にアクセス可能な一つ以上のネットワークアクセス可能サービス（例えば、さまざまなタイプのクラウドベースのデータベース、コンピューティングまたはストレージサービス）を提供するための、企業または公営企業組織などによって設定されたネットワークは、本明細書においてプロバイダネットワークと称され得る。サービスのいくつかを使用してより高レベルのサービスを構築することができる。例えば、コンピューティング、ストレージまたはデータベースサービスを、ストリーム管理サービスまたはストリーム処理サービスのための基礎的要素として使用することができる。プロバイダネットワークのコアサービスの少なくともいくつかは、「インスタンス」と呼ばれるサービスユニットにおいてクライアント使用のためにパッケージ化することができる。例えば、仮想化されたコンピューティングサービスによってインスタンス化された仮想マシンは、「コンピュートインスタンス」を表し、そしてストレージサービスによってインスタンス化されたブロックレベルボリュームなどのストレージデバイスは、「ストレージインスタンス」と称され得、またはデータベース管理サーバは、「データベースインスタンス」と称され得る。プロバイダネットワークのさまざまなネットワークアクセス可能サービスのそのようなユニットが実装されるサーバなどのコンピューティングデバイスは、本明細書において「インスタンスホスト」、またはより簡単に「ホスト」と称され得る。いくつかの実施形態において、取り込みサブシステム２０４のノード、保存サブシステム２０６、検索サブシステム２０８、ＳＭＳ制御システム２１０、処理ステージ２１５、及び／またはＳＰＳ制御サブシステム２２０は、複数のインスタンスホストにおけるさまざまなコンピュートインスタンスを実行するスレッドまたはプロセスを備えることができる。所与のインスタンスホストは、いくつかのコンピュートインスタンスを備えることができる。特定のインスタンスホストにおけるコンピュートインスタンスの集合を使用して、一つ以上のクライアントのさまざまな異なるストリームにノードを実装することができる。いくつかの実施形態において、ストレージインスタンスは、さまざまなストリームのデータレコードを保存するのに、またはストリーム処理ステージの結果の宛先として使用することができる。制御サブシステムのノードは、経時的に、ノードの追加もしくは除去、プロセスもしくはコンピュートインスタンスまたはインスタンスホストへのノードのマッピングの変更、または図１５及び図１６を参照して後述するような、データレコードの受信、保存及び処理を継続しながらの所与のストリームの再パーティショニングなどのさまざまなトリガ条件に応答して動的に他のサブシステムの個体数を変更することができる。
プロバイダネットワークリソースをストリーム関連動作に使用する実施形態の文脈では、「クライアント」という用語は、所与の通信のソースまたは宛先として使用されるときには、プロバイダネットワークの少なくとも一つのネットワークアクセス可能サービスにアクセスしてそれを活用する能力がある事業体（例えば、組織、複数のユーザによるグループまたは単一のユーザ）によって所有された、管理されたまたはそれに割り当てられたコンピューティングデバイス、プロセス、ハードウェアモジュールまたはソフトウェアモジュールのいずれかを意味し得る。あるサービスのクライアントは、別のサービスのリソースを使用してそれ自身に実装することができる。例えば、ストリームデータコンシューマ（ストリーム管理サービスのクライアント）は、コンピュートインスタンス（仮想化されたコンピューティングサービスによって提供されたリソース）を備えることができる。
所与のプロバイダネットワークは、プロバイダによって提供されるインフラストラクチャ及びサービスを実施、構成及び分配するのに必要である、物理及び／または仮想コンピュータサーバの集合などのさまざまなリソースプールをホストする（種々の地理的地域にわたって分配することができる）幾多のデータセンタ、一つ以上のストレージデバイスを各々が持つ保存サーバ、ネットワーク機器などを含むことができる。さまざまな実施形態において、そのいくつかを種々のデータセンタまたは種々の地理的地域においてインスタンス化または実行することができる多くの異なるハードウェア及び／またはソフトウェアコンポーネントを集合的に使用して、各サービスを実施することができる。クライアントは、プロバイダネットワーク外部のクライアント所有のもしくはクライアント管理の設備もしくはデータセンタに設置されたデバイス、及び／またはプロバイダネットワーク内のデバイスから、プロバイダネットワークにおけるリソース及びサービスと相互作用することができる。プロバイダネットワークが、本明細書に記述するストリーム管理及び処理技術の多くを実施できる一実施例の文脈としての機能を果たすが、それらの技術が、プロバイダネットワーク以外の他のタイプの分散システム、例えば、特有のアプリケーションに関する単一の企業体によって動作される大規模に分配された環境にも適用できることに留意されたい。
プログラマチックインターフェースの実施例
前述のように、少なくともいくつかの実施形態では、ＳＰＳは、ＳＭＳプログラマチックインターフェースを活用して、さまざまなストリームベースのアプリケーションのための所望のビジネスロジックを実施するための、ＳＰＳクライアントがより容易に使用できるより高レベルの機能性を構築することができる。ＳＰＳの機能性とＳＭＳの機能性との差異を考慮すると、類似性が有益となり得る。すなわち、ＳＰＳ機能は、通例、Ｃ＋＋などのより高レベルの言語におけるプログラミング言語構築に匹敵し得、一方で、ＳＭＳ機能は、通例、プログラミング言語構築がコンパイラによって翻訳されるアセンブリ言語教育に匹敵し得る。アセンブリ言語教育を使用して同じ動作を直接に実施することが可能であるが、より高レベルの言語におけるプログラミングは、通常、顧客またはユーザの多くのカテゴリにとってより容易であり得る。同様に、ＳＭＳによって提供されるプリミティブを使用してさまざまなアプリケーションを実施することが可能であるが、そのようなことはＳＰＳ特徴を使用して実行することがより容易であり得る。ＳＰＳ処理動作（例えば、データレコードに実行される冪等処理動作）は、ストリームレコードのデータコンテンツにおいて実施でき、一方で、ＳＭＳ動作は、通常、レコードのコンテンツを考慮せずにレコードそれ自体を取得、保存及び検索するように実行される。図３は、少なくともいくつかの実施形態に従う、ＳＭＳ及びＳＰＳにおいて実装することができるプログラマチックインターフェースのそれぞれのセットの実施例を示す。多くの異なるアプリケーションプログラミングインターフェース（ＡＰＩ）が、一実施例としてＳＭＳ及びＳＰＳの両方のために示される。示したＡＰＩは、任意の所与の実施においてサポートされるそれらの包括的なリストは意図せず、示したＡＰＩのいくつかは、所与の実施においてサポートされない。
矢印３５０に示すように、ＳＰＳクライアント３７５は、ＳＰＳプログラマチックインターフェース３０５を呼び出して処理ステージを構成することができる。種々の実施形態において、さまざまなタイプのＳＰＳプログラマチックインターフェース３０５を実装することができる。例えば、ｃｒｅａｔｅＳｔｒｅａｍＰｒｏｃｅｓｓｉｎｇＳｔａｇｅ ＡＰＩによって、クライアントは、ステージのワーカーノードの各々が、インターフェースの起動において指定された冪等動作のセットを実行し、その結果を、出力分配記述子またはポリシによって示された宛先に分配するように構成されるように、指定された入力ストリームのための新規の処理ステージ２１５の構成をリクエストすることができる。ｃｒｅａｔｅＳｔｒｅａｍＰｒｏｃｅｓｓｉｎｇＳｔａｇｅ ＡＰＩまたはその均等物のいくつかのバージョンでは、クライアントは、入力ストリームの作製もリクエストでき、一方で、他のバージョンでは、処理ステージが作製される前に入力ストリームを作製する必要が生じ得る。リカバリポリシが、ワーカーノードに対して指定され、例えば、チェックポイントベースのリカバリ技術を使用するか、またはベストエフォートのリカバリ技術が好ましいかどうかを示すことができる。いくつかの実施形態において、ｉｎｉｔｉａｌｉｚｅＷｏｒｋｅｒＮｏｄｅ ＡＰＩが、指定されたステージにおけるワーカーノードの明示的インスタンス化のリクエストをサポートすることができる。チェックポイントベースのリカバリを実施する実施形態では、クライアントは、ｓａｖｅＣｈｅｃｋｐｏｉｎｔ ＡＰＩをサポートすることによって、進捗レコードをワーカーノードによって生成することをリクエストすることができる。
種々の実施形態において、さまざまなタイプのＳＰＳ出力管理ＡＰＩがサポートされ得、例えば、クライアントによるｓｅｔＯｕｔｐｕｔＤｉｓｔｒｉｂｕｔｉｏｎ ＡＰＩが、指定されたステージにおいて実行された処理動作の結果を使用して作製された一つ以上のストリーム、及び新規に作製されたストリームにおいて使用される特定のパーティショニングポリシを示すことができる。いくつかの処理ステージを、主として再パーティショニングのために構成することができる。例えば、レコード属性セットＡ１に基づいてデータレコードをＮ１パーティションにマッピングする一つのパーティショニング機能ＰＦ１を入力ストリームＳ１に使用することができ、そして処理ステージを使用して、それらの同じデータレコードをＮ２パーティションにマッピングするために、（異なる属性セットＡ２または同じ属性セットＡ１のいずれかを使用して）異なるパーティショニング機能ＰＦ２を実施することができる。リンクステージなどのいくつかのＳＰＳ ＡＰＩを使用して、複数のステージを含む任意のグラフ（例えば、有向非巡回グラフ）を構成することができる。いくつかの実施形態において、第三者またはオープンソースストリーム処理フレームワークもしくはサービスとのコネクタをサポートすることができる。一つのそのような実施形態では、ＳＰＳステージを使用して、既存の第三者またはオープンソースシステムによる消費のためのデータレコードを、（例えば、ステージにおいて実行される処理動作の結果を適切にフォーマットすることによって）用意することができる。描写した実施形態では、ｃｒｅａｔｅＴｈｉｒｄＰａｒｔｙＣｏｎｎｅｃｔｏｒなどのＡＰＩを使用して、そのようなコネクタを設定することができ、そしてＳＰＳステージの結果の、第三者システムと互換性があるフォーマットへの適切な変換を、ｃｒｅａｔｅＴｈｉｒｄＰａｒｔｙＣｏｎｎｅｃｔｏｒの起動の結果としてインスタンス化された一つ以上のコネクタモジュールによって実行することができる。
矢印３５２に示すように、ＳＰＳは、ＳＭＳ ＡＰＩ３０７を呼び出して、その機能の少なくともいくつかを実行することができる。描写した実施形態では、ＳＭＳ ＡＰＩ３０７は、例えば、（それぞれ、ストリームを作製及び削除するための）ｃｒｅａｔｅＳｔｒｅａｍ及びｄｅｌｅｔｅＳｔｒｅａｍ、並びに（所与のパーティションに関与するさまざまなタイプのノードのネットワークアドレスなどの、ストリームについてのメタデータを入手するための）ｇｅｔＳｔｒｅａｍＩｎｆｏを含むことができる。ｐｕｔＲｅｃｏｒｄインターフェースを使用してデータレコードを書き込み、一方で、ｇｅｔＩｔｅｒａｔｏｒ及びｇｅｔＮｅｘｔＲｅｃｏｒｄｓインターフェースを、それぞれ、非順次及び順次読み出しに使用することができる。いくつかの実施形態において、ｒｅｐａｒｔｉｔｉｏｎＳｔｒｅａｍインターフェースを使用して、指定されたストリームの動的再パーティショニングをリクエストすることができる。そのような実行を所望するクライアント３７０は、矢印３５４に示すように、ＳＭＳ ＡＰＩ３０７を直接に呼び出すことができる。前述のように、他の実施形態では、さまざまな他のＳＭＳ及び／またはＳＰＳ ＡＰＩも実装することができる。いくつかの実施形態において、図３にリストされたＡＰＩのいくつかは、実装しなくてもよい。
さまざまな実施形態において、ＡＰＩ以外のプログラマチックインターフェースもまたは代わりとしてＳＰＳまたはＳＭＳのいずれかに実装することができる。そのようなインターフェースは、グラフィカルユーザインターフェース、ウェブページまたはウェブサイト、コマンドラインインターフェースなどを含むことができる。場合によっては、ウェブベースのインターフェースまたはＧＵＩは、基礎的要素としてＡＰＩを使用することができる。例えば、ウェブベースの相互作用によって、ＳＭＳまたはＳＰＳの制御コンポーネントにおいて一つ以上のＡＰＩを起動することができる。図４は、少なくともいくつかの実施形態に従う、ストリーム処理ステージのグラフをＳＰＳクライアントが生成できるように実装することができる実施例のウェブベースのインターフェースを示す。示すように、インターフェースは、メッセージ領域４０２、グラフメニュー領域４０４及びグラフ設計領域４０３を有するウェブページ４００を備える。
ユーザには、メッセージ領域４０２においてストリーム処理グラフの構築についての汎用命令、並びにストリーム概念及びプリミティブについてより多く知るのに使用できるリンクが提供され得る。メニュー領域４０４において、多くのグラフィカルアイコンが、ストリーム処理グラフツールセットの一部として提供され得る。例えば、クライアントは、さまざまなＳＰＳ処理ステージの入力または出力として、永続的なストリーム４５１、一時的なストリーム４５２またはコネクタ４５３を第三者処理環境に示すことができる。ウェブベースのインターフェースを実装するためのＳＰＳ／ＳＭＳに関して、永続的なストリーム４５１は、そのデータレコードがディスク、不揮発性ＲＡＭまたはＳＳＤなどの永続ストレージデバイスに保存されるストリームとして画定することができ、そして一時的なストリーム４５２は、そのデータレコードを永続ストレージデバイスに保存する必要がないものとして画定することができる。一時的なストリームは、例えば、ベストエフォートのリカバリポリシを実施する異なるＳＰＳステージによる入力として消費されることが予期されるＳＰＳステージの出力から作製することができる。
二つのタイプの処理ステージが、実施例のＳＰＳグラフ構築ウェブページ４００においてサポートされる。この処理ステージは、チェックポイントベースのワーカーノードリカバリを使用するステージ４５５（例えば、各ワーカーノードが間隔を置いて進捗レコードをセーブし、特定のワーカーノードの障害の発生時に、取り換えノードが、どのデータレコードの処理を開始するかを決定するために、障害のあるノードの進捗レコードを参照する）と、ベストエフォートのリカバリを使用するステージ４５６（例えば、取り換えワーカーノードが進捗レコードを参照はするが、受信したときに新規のデータレコードの処理を簡単に開始する）とである。各ステージにおいて実行される処理動作についての詳細は、メッセージ領域４０２の命令に示すように、グラフ構築領域４０３における対応するアイコンをクリックすることによって入力することができる。ストリーム、コネクタ及び処理ステージについてのアイコンに加えて、メニュー領域４０４は、第三者または外部ストリーム処理システムを表すアイコンタイプ４５９、及びそのリソースが処理ステージにおいて使用される、プロバイダネットワークにおいて実施することができるストレージサービスのノードを表すアイコンタイプ４６０も含む。
図４に示す実施例のシナリオでは、クライアントは、グラフ設計領域４０３内に三つの処理ステージ４１２、４１５及び４１６を備えたグラフ４０５を構築した。処理ステージ４１２は、チェックポイントベースのリカバリを使用するように構成され、入力として永続的なストリーム４１１を使用する。ステージ４１２における出力または処理結果は、ステージ４１５の入力を形成する異なる永続的なストリーム４１３の形態、及びステージ４１６の入力を形成する異なる一時的なストリーム４１４の形態において、二つの宛先に送信される。ステージ４１５及び４１６は、共に、ワーカーノードにおいてベストエフォートのリカバリポリシを使用する。ステージ４１５の出力は、一時的なストリームの形態においてストレージサービスノード４１９に送信される。ステージ４１５の出力は、コネクタ４１７を通じて第三者処理システム４１８に送信される。「セーブグラフ」ボタン４２０を使用して、例えば、ＪＳＯＮ（ジャバスクリプトオブジェクトノーテーション）、ＸＭＬ（拡張マークアップ言語）またはＹＡＭＬなどの任意の適切なフォーマットにおいて、処理ステージグラフの表示をセーブすることができる。さまざまな実施形態において、図４に示すものに類似するツールを使用して、複雑な処理ワークフローを任意に構築することができる。そのようなツールを使用して作製されるワークフローを、その後アクティブにし、そのようなアクティブ化によって、ＳＭＳ ＡＰＩを起動することができる。例えば、図４のステージ４１２などの処理ステージについてのデータレコードを入手するために、ｇｅｔＩｔｅｒａｔｏｒ及び／またはｇｅｔＮｅｘｔＲｅｃｏｒｄｓインターフェースを、ストリーム４１１において呼び出すことができる。
図５は、少なくともいくつかの実施形態に従う、ＳＭＳに実装することができるプログラマチックレコード提示インターフェース及びレコード検索インターフェースの実施例を示す。描写した実施形態では、示したＤＲ１１０Ｋ及び１１０Ｑなどのデータレコードを、さまざまなタイプのプログラマチック取り込みインターフェース５１０を通じてＳＭＳに提示することができる。いくつかの実施形態において、ＤＲ１１０は、四つのタイプの要素を含むことができる。すなわち、（ストリーム「Ｓ１」についての）５０１Ａまたは（ストリーム「Ｓ２」についての）５０１Ｂなどのストリーム識別子、レコードのデータまたは主部の表示、オプショナルパーティションキー５０４（例えば、５０４Ａまたは５０４Ｂ）、並びにオプショナルシークエンシング嗜好インジケータ５０６（例えば、シークエンシング嗜好インジケータ５０６Ａ及び５０６Ｂ）を含む。データそれ自体が、いくつかのデータレコードにおいてインライン（例えば、ＤＲ１１０Ｋのインラインデータ５０２）で提供され得、その一方で、他のデータレコードにおいて、ネットワークアクセス可能ロケーション（または、ネットワーク転送を必要としないローカルデバイスにおけるアドレス）をＳＭＳに示すポインタまたはアドレス５０３が提供され得る。いくつかの実施形態において、所与のストリームが、インライン及び照会用両方の（アドレスベースの）データレコード提示をサポートすることができる。他の実施形態では、所与のストリームに、すべてのデータをインラインでまたは照会用として供給するデータプロデューサが必要となり得る。いくつかの実施では、データレコード提示は、レコードに使用されるパーティション識別子を含むことができる。
描写した実施形態では、入力データレコード１１０を、パーティショニングポリシに基づいて、それぞれの取り込み及び／または保存ノードに導くことができる。同様に、レコード検索もパーティションベースであってもよい。例えば、一つ以上の検索ノードを、所与のパーティションのレコードに導かれる読み出しリクエストに応答するように用意できる。いくつかのストリームにおいて、明示的なパーティションキーを各データレコード書き込みリクエストに提供するために、データプロデューサが必要となり得る。他のストリームにおいて、ＳＭＳは、明示的に供給されたパーティションキー以外のメタデータまたは属性に依存するパーティショニングスキームに従い、データレコードを分配することができる。例えば、提示されたデータプロデューサに関連する識別情報をパーティションキーとして使用する、提示されたデータプロデューサのＩＰアドレスの一部もしくはすべてを使用する、または提示されたデータの一部を使用することができる。いくつかの実施では、例えば、パーティションキーにハッシュ関数を適用して、１２８ビット整数などの特定のサイズの整数を入手することができる。そのサイズの正の整数の全範囲（例えば、０〜２＾１２８−１）を、それぞれのパーティションをその各々が表すＮ個の隣接するサブ範囲に分配することができる。それ故に、そのような実施例では、データレコードのために決定または供給された任意の所与のパーティションキーを、対応する１２８ビット整数にハッシュして、そしてその整数が属する１２８ビット整数の隣接するサブ範囲が、データレコードが属するパーティションを表すことができる。パーティショニングポリシ及びその使用についてのさらなる詳細を、図１５に関して後述する。
特定のパーティションのデータレコードの取り込みまたは受け入れ、データレコードの保存、及び特定のパーティションにおける読み出しリクエストに対する応答に関与するノードのセットは、図５のパーティションにおいて、集合的にＩＳＲ（取り込み、保存及び検索）ノードと称される。表記Ｓｊ−Ｐｋが、ストリームＳｉのｋ番目のパーティションを表すのに使用される。示した実施形態では、ＩＳＲノード５２０Ａが、パーティションＳ１−Ｐｌのレコードの取り込み、保存及び検索のために構成され、ＩＳＲノード５２０Ｂが、パーティションＳ１−Ｐ２のレコードのために設定され、ＩＳＲノード５２０Ｃが、パーティションＳ１−Ｐ３のレコードのために設定され、ＩＳＲノード５２０Ｋが、パーティションＳ２−Ｐｌのレコードのために設定され、そしてＩＳＲノード５２０Ｌが、パーティションＳ２−Ｐ２のレコードのために設定される。いくつかの実施形態において、取り込みサブシステム、保存サブシステムまたは検索サブシステムの所与のノードを、二つ以上のパーティションのデータレコード（または、二つ以上のストリームの二つ以上のパーティション）を処理するように構成できる。いくつかの実施形態において、所与のストリームの単一のパーティションのレコードは、二つ以上のノードによって取り込む、保存するまたは検索することができる。所与のパーティションＳｊ−Ｐｋのために用意された取り込みノードの数は、少なくともいくつかの場合では、異なるパーティションＳｊ−Ｐｌのために用意された取り込みノードの数と異なってもよく、そしてＳｊ−Ｐｋのために用意された保存ノードの数、及び／またはＳｊ−Ｐｋのために用意された検索ノードの数とも異なってもよい。取り込み及び／または検索に関して、ＳＭＳ制御ノードは、いくつかの実施形態においてＡＰＩ（例えば、ｇｅｔＳｔｒｅａｍＩｎｆｏ）を実装し、これによりクライアントは、どのノードをどのパーティションに関与させるかを決定することができる。データレコードとパーティションとの間のマッピング、及びパーティションと構成されたＩＳＲノード（または、制御ノード）との間のマッピングは、動的再パーティショニングに関する議論において後述するように、経時的に変更することができる。
いくつかの実施形態において、所与のパーティションからのストリームデータレコードの検索または読み出しのために、いくつかの異なるプログラマチックインターフェース５８０を実装することができる。図５に示すように、非順次アクセスのために、（指定されたシーケンス番号を持つデータレコードにおいてまたはそれに続き、イテレータまたは読み出しカーソルをインスタンス化するための）ｇｅｔＩｔｅｒａｔｏｒなどの検索インターフェース、または（指定されたシーケンス番号を持つデータレコードを読み出すための）ｇｅｔＲｅｃｏｒｄなどのいくつかの検索インターフェース５８１を実装することができる。順次検索のための、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓなどの他の検索インターフェース５８２（シーケンス番号を増加するために、イテレータの現在位置からＮ個のレコードを読み出すことをリクエストするインターフェース）を実装することができる。回転円盤ベースのストレージシステムでは、前述のように、順次の入出力は、多くの場合において、ランダムの入出力よりも遥かに効率的であり得る。なぜならば、平均して入出力ごとに必要なディスクヘッドシークの数を、通常、ランダムの入出力よりも順次の入出力において遥かに小さくできるからである。多くの実施形態において、所与のパーティションのデータレコードは、シーケンス番号順に書き込まれ、その結果、（例えば、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓまたは類似のインターフェースを使用した）シーケンス番号順に基づく順次読み出しリクエストが、ランダム読み出しリクエストよりも遥かに効率的となり得る。したがって、少なくともいくつかの実施形態では、順次の検索インターフェースと非順次の検索インターフェースとには、異なる請求率が設定され得る。例えば、クライアントは、非順次読み出しではより多く課金され得る。
取り込みサブシステム
図６は、少なくともいくつかの実施形態に従う、ＳＭＳの取り込みサブシステム２０４の実施例の要素を示す。描写した実施形態では、取り込み動作は、フロントエンドとバックエンド機能とに論理的に分配される。フロントエンド機能は、データプロデューサ１２０（例えば、１２０Ａ、１２０Ｂまたは１２０Ｃ）との相互作用を伴い、バックエンド機能は、ＳＭＳ保存サブシステムとの相互作用を伴う。そのようなフロントエンドとバックエンドとの分割は、保存サブシステムのセキュリティの向上、及びパーティショニングポリシの詳細をデータプロデューサに提供する必要の回避などのいくつかの利点を有することができる。ＳＭＳクライアントライブラリ６０２が、さまざまなデータプロデューサ１２０においてインストールのために提供され得、データプロデューサが、ライブラリ６０２に含まれるプログラマチックインターフェースを呼び出して取り込みのためのデータを提示することができる。例えば、一実施形態において、データプロデューサ１２０は、プロバイダネットワークの何百または何千もの物理及び／または仮想サーバにおいてインスタンス化されたロギングまたはモニタリングエージェントを備えることができる。そのようなエージェントは、それぞれのサーバにおいてさまざまなログメッセージ及び／またはメトリクスを収集し、収集したメッセージまたはメトリクスを、ＳＭＳの一つ以上の取り込み制御ノード６６０によってインスタンス化されたフロントエンド負荷分散器６０４のエンドポイントに周期的に提示することができる。いくつかの実施形態において、データプロデューサがストリームデータを提示することができる一つ以上の仮想ＩＰアドレス（ＶＩＰ）を、負荷分散器において確立することができる。一つの実施において、データがデータプロデューサ１２０によって送信されるいくつかの同等に構成された負荷分散器の中から特定の負荷分散器を選択するために、ラウンドロビンＤＮＳ（ドメイン名システム）技術をＶＩＰにおいて使用することができる。
描写した実施形態では、受信したデータレコードを、いくつかのフロントエンドノード６０６（例えば、６０６Ａ、６０６Ｂまたは６０６Ｃ）のいずれかに導くことができる。少なくともいくつかの実施形態では、負荷分散器６０４は、データレコードにおいて使用されるパーティショニングポリシ６５０を認識せず、したがって、パーティションベースの負荷バランシングではなく、ラウンドロビン負荷バランシング（または、何らかの他の汎用負荷バランシングアルゴリズム）を使用して所与のデータレコードに対してフロントエンドノード６０６を選択することができる。フロントエンドノード６０６は、さまざまなストリームのためのパーティショニングポリシ６５０を認識でき、取り込み制御ノード６６０と相互作用して、所与のパーティションのデータレコードにおいて構成された具体的なバックエンド取り込みノード６０８（例えば、６０８Ａ、６０８Ｂまたは６０８Ｃ）のアイデンティティを入手することができる。それ故に、描写した実施形態では、フロントエンドノード６０４は、それぞれのデータレコードが属するパーティションに基づいて、各々、データレコードを複数のバックエンドノード６０６に伝送することができる。前述したように、データレコードが属するパーティションは、データプロデューサによって供給されるパーティションキー、データプロデューサのアイデンティティもしくはアドレスなどの一つ以上の他の属性、またはデータのコンテンツなどのさまざまなファクタの任意の組み合わせに基づいて決定することができる。
バックエンドノード６０６は、各々、一つ以上のストリームの一つ以上のパーティションに属するデータレコードを受信し、データレコードを保存サブシステムの一つ以上のノードに伝送することができる。バックエンドノードは、ＨＴＴＰ（ハイパーテキスト転送プロトコル）「ＰＵＴ」ウェブサービスＡＰＩによってデータが提示されるいくつかの実施形態において「ＰＵＴサーバ」と称され得る。所与のバックエンドノードは、そのデータレコードがクエリを提示することによって制御ノード６６０に伝送される保存サブシステムのノードのセットを決定することができる（言い換えると、異なるサブシステムについての制御機能が、ノードの個々のセットによって処理される実施形態では、対応するクエリを保存サブシステムの制御ノードに提示することができる）。
少なくともいくつかの実施形態では、少なくとも１回取り込みポリシまたはベストエフォート取り込みポリシなどの多くの異なる取り込み応答ポリシ６５２をサポートすることができる。少なくとも１回ポリシでは、データプロデューサ１２０は、提示されたデータレコードごとに肯定応答を必要とし得、（最初の提示の応答が受信されない場合には）応答が最終的に受信されるまで同じデータレコードを繰り返し提示することができる。ベストエフォート取り込みポリシでは、提示された少なくともいくつかのデータレコードについての肯定応答を必要としない（ただし、取り込みサブシステムは、時折の応答を依然として提供する、またはデータプロデューサからの応答を求める明示的なリクエストに応答することができる）。取り込みサブシステム２０４が応答をデータプロデューサに提供する必要があるいくつかの実施形態では、所与のデータレコードに関与するバックエンド取り込みノード６０８は、応答を生成する前に、（例えば、ストリームに関して確立された持続性ポリシに従い）必要な数のデータレコードのレプリカが保存サブシステムにおいて成功裏に作製されるまで待機することができる。さまざまな実施形態において、受信した各データレコードについて、そのレコードの同じパーティションまたはストリームの他のレコードとの相対的な取り込まれた順序などを表すシーケンス番号を取り込みサブシステムによって生成することができる。そのようなシーケンス番号は、応答または応答の一部としてデータプロデューサに戻すことができる。シーケンス番号についてのさらなる詳細は、図１３ａ及び図１３ｂを参照して後述する。いくつかの実施では、応答及び／またはシーケンス番号を、フロントエンドノード６０６を経由してデータプロデューサに返送することができる。少なくとも一つの実施では、少なくとも１回ポリシは、取り込みサブシステムそれ自体のフロントエンドとバックエンドノードとの間に実装することができる。例えば、所与のフロントエンドノード６０６は、バックエンドノードが応答を提供するまでデータレコードを適切なバックエンドノード６０８に繰り返し提示することができる。
取り込み制御ノード６６０は、数ある機能の中でも、フロントエンド及びバックエンドノードのインスタンス化、ノードの調子及び作業負荷レベルの監視、必要に応じて、フェイルオーバーの調整、そしてストリームの動的再パーティショニングから生じた取り込み関連構成動作において、どのノードが所与のパーティションまたはポリシ関連クエリに関与するかについてのクエリに対する応答の提供に関与することができる。いくつかの実施形態において、一つ以上のストリームの所与のセットのために用意される取り込み制御ノードの数は、経時的に変更することができる。例えば、一つ以上のマスタ制御ノードが、必要に応じて、制御ノードプールの再構成に関与することができる。図９及び図１０を参照してさらなる詳細は後述するように、取り込みフロントエンドまたはバックエンドノードにおいて冗長グループが設定されるいくつかの実施形態では、制御ノード６６０が、フェイルオーバーについてのトリガ条件を検出するために、そしてフェイルオーバーが必要なときに取り換えを選択するために、どのノードがプライマリ及び非プライマリであるかの追跡の役割を果たし得る。図６に示す多層取り込みサブシステムアーキテクチャはいくつかの実施形態では実装しなくてもよい、例えば、いくつかのシナリオでは、取り込みノードの単一セットのみを構成すればよいことに留意されたい。
保存サブシステム
図７は、少なくともいくつかの実施形態に従う、ＳＭＳの保存サブシステムの実施例の要素を示す。示すように、取り込みノード６０８（例えば、フロントエンド及びバックエンド取り込みの責務がノードの種々のセットによって処理される実施形態では、バックエンド取り込みノード）が、ストリームの一つ以上のパーティションのデータレコードを、それらのパーティションのために構成されたそれぞれの保存ノード７０２に伝送することができる。例えば、パーティションＳ１−Ｐｌのデータレコード１１０Ａが保存ノード７０２Ａに送信され、パーティションＳ２−Ｐ３のデータレコード１１０Ｂが保存ノード７０２Ｂ及び７０２Ｃに送信され、パーティションＳ３−Ｐ７のデータレコード１１０Ｃが保存ノード７０２Ｄに送信され、そしてパーティションＳ４−Ｐ５のデータレコード１１０Ｄが初期に保存ノード７０２Ｅに送信される。保存制御ノード７８０が、種々のストリームのデータレコードに適用される持続性ポリシ７５０の実行、保存ノードの構成及び必要に応じて再構成、保存ノード状態の監視、フェイルオーバーの管理、保存構成クエリまたは保存ポリシクエリに対する応答、並びに描写した実施形態におけるさまざまな他の管理上のタスクの役割を果たし得る。
種々の実施形態において、持続性ポリシ７５０は、さまざまな様式で互いと異なってもよい。例えば、ストリームＳｊに適用される持続性ポリシＰ１は、ストリームＳｋに適用されるポリシＰ２とは異なってもよい。すなわち、（ａ）保存される各データレコードのレプリカの数、（ｂ）レプリカが保存されるストレージデバイスまたはシステムのタイプ（例えば、レプリカが、揮発性メモリ、不揮発性キャッシュ、回転円盤ベースのストレージ、半導体ドライブ（ＳＳＤ）、さまざまな種類のストレージアプライアンス、プロバイダネットワークによって実施されるストレージサービスのノードにおける、データベース管理システム内のさまざまな種類のＲＡＩＤ（安価なディスクの冗長アレイ）などに保存されるか否か）、（ｃ）レプリカの地理的配分（例えば、ストリームデータが、種々のデータセンタにおけるレプリカの設置に伴う大規模な障害または特定のタイプの災害に対して回復力があるか否か）、（ｄ）書き込み応答プロトコル（例えば、Ｎ個のレプリカが保存される場合に、応答を取り込みノードに提供すべき前に成功裏に書き込む必要があるコピーのＮ個の数）、及び／または（ｅ）データレコードの複数のレプリカが保存される場合に、レプリカを並行してまたは連続的に作製すべきか否か、において異なってもよい。複数のレプリカを保存する場合において、データレコード１１０Ｄの場合では、所与の保存ノードは、データレコードを別の保存ノードに伝送することができる（例えば、保存ノード７０２Ｅは、データレコード１１０Ｄをさらなる複製のために保存ノード７０２Ｆに送信し、保存ノード７０２Ｆは、それを保存ノード７０２Ｇに送信する）。複数のレプリカ持続性ポリシを使用する他の場合において、データレコード１１０Ｂに二つのインメモリレプリカが保存される場合では、取り込みノードは、複数の複製を並行して起動することができる。少なくともいくつかの実施形態では、クライアントが選択した持続性ポリシは、ストリームデータレコードのために使用される保存場所のタイプを指定しない。代わりに、ＳＭＳは、例えば、費用、性能、データソースとの近接性、永続性要件などのさまざまな基準に基づいて、適切なタイプの保存技術及び／または位置を選択することができる。一実施形態において、クライアントまたはＳＭＳのいずれかは、所与のストリームの異なるパーティションまたは種々のストリームにおいて異なる保存技術または保存場所タイプを使用することを決定できる。
図７に示す実施例では、ストリームＳ１（または、少なくともストリームＳ１のパーティションＳ１−Ｐｌ）に適用される持続性ポリシは、シングルレプリカインメモリポリシであり、一方で、ストリームＳ２においては、ツーパラレルレプリカインメモリポリシが適用される。それ故に、データレコード１１０Ａのインメモリレプリカ７０４Ａが、保存ノード７０２Ａにおいて作製され、一方で、データレコード１１０Ｂに対応する二つのインメモリレプリカ７０５Ａ及び７０５Ｂが、保存ノード７０２Ｂ及び７０２Ｃにおいて並行して作製される。ストリームＳ３のデータレコード１１０Ｃにおいて、シングルオンディスクレプリカ７０６Ａが作製される。ストリームＳ４において、シケンシャルスリーレプリカオンディスクポリシが適用可能であり、その結果として、それぞれのオンディスクレプリカ７０７Ａ、７０７Ｂ及び７０７Ｃが、保存ノード７０２Ｅ、７０２Ｆ及び７０２Ｇにおいて連続的に作製される。種々の実施形態において、さまざまな他のタイプの持続性ポリシをデータストリームに適用することができる。検索サブシステムのノードが、データコンシューマによるさまざまなタイプの検索ＡＰＩの起動に応答して、適切な保存ノードからデータレコードを入手することができる。
検索サブシステム及び処理ステージ
図８は、少なくともいくつかの実施形態に従う、ＳＭＳの検索サブシステムの実施例の要素、及び検索サブシステムとＳＰＳとの相互作用の実施例を示す。示すように、検索サブシステム２０６は、検索ノード８０２Ａ、８０２Ｂ及び８０２Ｃなどの複数の検索ノード８０２並びに検索制御ノード８８０の集合を備えることができる。検索ノード８０２の各々は、後述するようなＳＰＳのワーカーノード８４０などのさまざまなクライアントまたはデータコンシューマ１３０からのストリームデータ検索リクエストに応答するように構成できる。種々の実施形態において、前述の非順次及び順次検索インターフェースなどの、様々なプログラマチック検索インターフェース８０２を、検索ノードによって実装することができる。いくつかの実施形態では、ＨＴＴＰ ＧＥＴリクエストなどのウェブサービスＡＰＩをデータレコード検索に使用し、それ故に、検索ノード８０２はＧＥＴサーバと称され得る。描写した実施形態では、所与の検索ノード８０２は、例えば、検索制御ノード８８０によって、保存ノード７０２Ａ及び７０２Ｂなどの適切な保存サブシステムのノードのセット７０２から一つ以上のストリームパーティションのデータレコードを入手するように構成できる。
描写した実施形態では、検索ノード８０２は、一つ以上の保存ノード７０２と相互作用し、一つ以上のＳＰＳワーカーノード８４０から受信した検索リクエストにも応答することができる。例えば、パーティションＳ４−Ｐ５のデータレコード（例えば、データレコード１１０Ｋ）及びパーティションＳ５−Ｐ８のデータレコード（例えば、データレコード１１０Ｌ）は、検索ノード８０２Ａによって保存ノード７０２Ａから読み出され、それぞれ、ワーカーノード８４０Ａ及び８４０Ｋに提供される。１１０Ｍなどの、パーティションＳ６−Ｐ７のデータレコードは、検索ノード８０２Ｂによって保存ノード７０２Ａから読み出され、ワーカーノード８４０Ｋに提供される。パーティションＳ４−Ｐ７のデータレコードは、検索ノード８０２Ｃによって保存ノード７０２Ｂから読み出され、ワーカーノード８４０Ｂに、そして他のデータコンシューマ１３０（例えば、ＳＰＳを通じてＳＭＳと相互作用する代わりに、ＳＭＳ検索ＡＰＩを直接に呼び出すデータコンシューマ）にも提供される。
少なくともいくつかの実施形態では、検索ノード８０２のいくつかまたはすべては、それぞれ、キャッシュ８０４（例えば、検索ノード８０２Ａにおけるキャッシュ８０４Ａ、検索ノード８０２Ｂにおけるキャッシュ８０４Ｂ、及び検索ノード８０２Ｃにおけるキャッシュ８０４Ｃ）を実装し、これらは、さまざまなパーティションのデータレコードを、将来の検索リクエストを予期して一時的に保持することができる。検索制御ノード８８０は、例えば、キャッシングポリシ（例えば、どの程度大きなキャッシュを所与のパーティションに構成すべきか、どの程度長いデータレコードをキャッシュすべきか）、保存ノード選択ポリシ（例えば、データレコードの複数のレプリカを保存するシナリオでは、どの特定の保存ノードを、所与のデータレコードを最初に入手するように接触させるべきか）などを含む多くの検索ポリシ８８２の実施の役割を果たし得る。さらに、検索制御ノードは、検索ノード８０２のインスタンス化及び監視、どの検索ノードがどのパーティションに関与しているかのクエリに対する応答、再パーティショニング動作の起動またはそれに対する応答などの役割を果たし得る。
示す実施例では、ＳＰＳ２９０は、二つの処理ステージ、２１５Ａ及び２１５Ｂを備える。ＳＰＳ制御ノード８８５が、さまざまな処理ステージ２１５におけるワーカーノード８０４のインスタンス化に関与することができる。例えば、ワーカーノード８４０Ａをインスタンス化してパーティションＳ４−Ｐ５のレコードを処理し、ワーカーノード８４０Ｂをインスタンス化してパーティションＳ４−Ｐ７のレコードを処理し、そしてワーカーノード８４０Ｋをインスタンス化してパーティションＳ５−Ｐ８及びＳ６−Ｐ７のレコードを処理する。ＳＰＳ制御ノード８８５は、ＳＰＳクライアントが処理ワークフローを設計することができる（例えば、図３及び図４に示す）プログラマチックインターフェースを実装できる。それぞれのパーティションにおける処理の進捗程度を示す進捗レコードをワーカーノードが保存するときまたは保存するか否か、進捗レコードに使用されるストレージデバイスのタイプなどを表すさまざまなチェックポイントポリシ８５０を、種々の処理ステージまたはワークフローに実装することができる。フェイルオーバー／リカバリポリシ８５２が、所与の処理ステージにおいてベストエフォートのリカバリまたはチェックポイントベースのリカバリが使用されるか否かにかかわらずワーカーノードを異なるノードと取り換えるべきかを導くトリガ条件または閾値を示すことができる。少なくともいくつかの実施形態では、ＳＰＳ制御ノード８８５は、例えば、所与のストリームのデータレコードをそこから入手する検索ノードの特定、特定の処理ワークフローに必要となり得る新規の一時的または永続的なストリームの構築などのために、さまざまなタイプのＳＭＳ制御ノードと相互作用することができる。少なくとも一つの実施形態では、クライアントは、例えば、ＳＭＳ制御インターフェースを活用する代わりに、ＳＰＳ制御ノードと相互作用してストリームをインスタンス化し、これにより一部のクライアントは、より高レベルのＳＰＳインターフェースのみの呼び出しを所望することができる。制御ノードの個々のセットを、ＳＭＳ取り込み、保存及び検索サブシステム、並びにＳＰＳステージに関して図６、図７及び図８に示すが、少なくともいくつかの実施形態において、サブシステム及び／またはＳＰＳのいくつかに所与の制御ノードを使用できることに留意されたい。
ノード冗長グループ
少なくともいくつかの実施形態では、ノードの冗長グループを、ＳＭＳの一つ以上のサブシステムのために構成することができる。つまり、例えば、ストリームパーティションＳｊ−Ｐｋについてのデータレコードを検索するための一つの検索ノードを構成する代わりに、そのような検索のために、一つのノードが所与の時点において「プライマリな」またはアクティブな役割を与えられ、一方で、他の一つ以上のノードが「非プライマリな」ノードとして用意される二つ以上のノードを構築することができる。進行中のプライマリノードは、クライアントまたは他のサブシステムのノードのいずれかから受信したリクエストなどの作業リクエストの応答に関与することができる。非プライマリな一つ以上のノードは、フェイルオーバーがトリガされるまで、例えば、障害、プライマリとの接続性の損失または他のトリガ条件に起因して、選択された非プライマリが先のプライマリの責務を引き継ぐことを制御ノードによって通知され得る時点まで、休止状態のままであることができる。それ故に、プライマリの役割は、フェイルオーバー期間には、進行中の責務のあるプライマリノードにおいて無効にされ、進行中の非プライマリノードに付与することができる。いくつかの実施形態において、非プライマリノードは、フェイルオーバーを発生させる、例えば、明示的な通知を必要としないことを決定したときには、それ自体がプライマリとして引き継ぐことができる。さまざまな実施形態において、ノードのそのような冗長グループを、ＳＭＳにおける取り込み、保存、検索及び／または制御機能を行うように設定でき、少なくともいくつかの実施形態では、ＳＰＳにおけるワーカーノードにも類似のアプローチをとることができる。いくつかの実施形態において、所与の機能を行う少なくとも一つのプライマリノード及び少なくとも一つの非プライマリノードを備えるそのようなグループは、「冗長グループ」または「複製グループ」と称され得る。保存ノードの冗長グループを、保存されるデータレコードの物理的コピーの数とは無関係に実装できることに留意されたい。例えば、データレコードに保存されるレプリカの数を、持続性ポリシによって決定し、その一方で、対応するパーティションのために構成される保存ノードの数を、冗長グループポリシに基づいて決定することができる。
図９は、少なくともいくつかの実施形態に従う、ＳＭＳまたはＳＰＳのノードに応じて設定することができる冗長グループの実施例を示す。描写した実施形態では、所与のストリームパーティションＳｊ−Ｐｋにおいて、それぞれの冗長グループ（ＲＧ）９０５、９１５、９２５及び９３５が、取り込みノード、保存ノード、検索ノード及び制御ノードに関して設定される。示した実施形態では、制御ノードに関する共通のＲＧ９３５が実装される。ただし、いくつかの実施形態では、取り込み制御ノード、保存制御ノードまたは検索制御ノードに個々のＲＧを実装することができる。各ＲＧは、プライマリノード（例えば、プライマリ取り込みノード９１０Ａ、プライマリ保存ノード９２０Ａ、プライマリ検索ノード９３０Ａ及びプライマリ制御ノード９４０Ａ）、及び少なくとも一つの非プライマリノード（例えば、非プライマリ取り込みノード９１０Ｂ、非プライマリ保存ノード９２０Ｂ、非プライマリ検索ノード９２０Ｃ及び非プライマリ検索ノード９２０Ｄ）を備える。プライマリの役割は、それぞれのフェイルオーバーポリシ（取り込みノードについての）９１２、（保存ノードについての）９２２、（検索ノードについての）９３２及び（制御ノードについての）９４２に従い、無効にして進行中の非プライマリに付与することができる。フェイルオーバーポリシは、例えば、プライマリの状態の変化、プライマリまたは非プライマリの調子状態の監視の有無及び方法、所与の冗長グループにおいて構成された非プライマリの数などに通じるトリガ条件を定義することができる。少なくともいくつかの実施形態では、複数のパーティションに単一のＲＧを構築することができる。例えば、ＲＧ９０５は、パーティションＳｊ−Ｐｋ並びにＳｐ−Ｐｑのレコードの取り込み処理に関与することができる。いくつかの実施では、一つのパーティションにおいてプライマリとして用意されたノードを、同時に、別のパーティションにおける非プライマリとして用意することができる。一実施形態において、複数のノードを、同時に、所与のＲＧ内のプライマリノードとして用意することができる。例えば、プライマリに障害が起きた場合に非プライマリとしてそれぞれが用意される二つのプライマリノード間に、所与のパーティションの取り込み関連の作業負荷を分配することができる。所与のＲＧにおいてインスタンス化されるノードの数は、対応する機能に所望されるアベイラビリティまたは回復力レベル（例えば、グループが耐えられると意図される多くの並行または重複する障害の程度）に応じて変えることができる。いくつかの実施形態において、ＳＭＳノードの使用に追加的にまたは代替的に、冗長グループを、ＳＰＳ処理ステージのワーカーノードに設定することができる。図１０に示すように、所与のＲＧの一部は、時々、地理的に、例えば、いくつかのデータセンタにわたって分配されることがある。いくつかの実施形態において、選択された制御ノードは、例えば、ハートビートメカニズムまたは他の調子監視技術を使用して、フェイルオーバートリガ条件を検出するように構成できる。そしてそのような制御ノードは、障害のあるプライマリと取り換えるための適切な非プライマリノードを選択し、選択された取り換えノードに通知してアクティブにすることなどによって、フェイルオーバーを調整することができる。
プロバイダネットワークを複数の地理的地域において組織化するいくつかの実施形態では、各地域が、一つ以上のアベイラビリティコンテナを含むことができ、この地域は本明細書において「アベイラビリティゾーン」とも称され得る。言い換えると、アベイラビリティコンテナは、所与のアベイラビリティコンテナにおけるリソースが、他のアベイラビリティコンテナにおける障害から隔離されるような様式で（例えば、電源関連機器、冷却機器、物理セキュリティコンポーネントなどの独立したインフラストラクチャコンポーネントを有し）設計された一つ以上の異なるロケーションまたはデータセンタを備えることができる。一つのアベイラビリティコンテナにおける障害が任意の他のアベイラビリティコンテナにおける障害を生じるようには予期されない。それ故に、リソースインスタンスまたは制御サーバの利用可能なプロファイルは、異なるアベイラビリティコンテナにおけるリソースインスタンスまたは制御サーバの利用可能なプロファイルとは無関係であると意図される。複数のアプリケーションインスタンスをそれぞれのアベイラビリティコンテナにおいて立ち上げる、または（いくつかのＳＭＳ及びＳＰＳが存在する場合には）所与の冗長グループのノードを複数のアベイラビリティコンテナにわたって分配することによって、さまざまなタイプのアプリケーションを単一ロケーションにおける障害から保護することができる。同時に、いくつかの実施では、安価かつ低遅延のネットワークの接続性を、同じ地理的地域内に存在するリソース（例えば、ＳＭＳ及びＳＰＳノードに使用されるホストまたはコンピュートインスタンス）間に提供し、そして同じアベイラビリティコンテナのリソース間のネットワーク伝送をさらにより速くすることができる。一部のクライアントは、それらのアプリケーションのさまざまなコンポーネントを実行する場合の厳密な所望の制御度を維持するために、ストリーム管理またはストリーム処理リソースが、例えば、地域レベル、アベイラビリティコンテナレベルまたはデータセンタレベルのいずれかにおいてリザーブ及び／またはインスタンス化されるロケーションの指定を所望することができる。他のクライアントは、リソースが、例えば、性能、ハイアベイラビリティなどについてのクライアント要求を満たす限り、それらのリソースがリザーブまたはインスタンス化される正確なロケーションにあまり関心がなくてもよい。いくつかの実施形態において、一つのアベイラビリティコンテナ（または、データセンタ）に設置される制御ノードは、他のアベイラビリティコンテナ（または、他のデータセンタ）における他のＳＭＳまたはＳＰＳノードを遠隔から構成することができる。つまり、特定のアベイラビリティコンテナまたはデータセンタは、ＳＭＳ／ＳＰＳノードを管理するためのローカル制御ノードを有する必要がない。
図１０は、少なくともいくつかの実施形態に従う、所与の冗長グループのノードを複数のデータセンタ間に分配することができるプロバイダネットワーク環境を示す。描写した実施形態では、プロバイダネットワーク１００２は、三つのアベイラビリティコンテナ１００３Ａ、１００３Ｂ及び１００３Ｃを備える。各アベイラビリティコンテナは、一つ以上のデータセンタの一部またはすべてを含む。例えば、アベイラビリティコンテナ１００３Ａは、データセンタ１００５Ａ及び１００５Ｂを備える。アベイラビリティコンテナ１００３Ｂは、データセンタ１００５Ｃを含み、アベイラビリティコンテナ１００３Ｃは、データセンタ１００５Ｄを含む。ＳＭＳ及び／またはＳＰＳノードの多くの異なる冗長グループ１０１２を示す。データセンタ１００５Ａ内に設置されたＲＧ１０１２Ａの場合のように、単一のデータセンタ内に一部のＲＧ１０１２を完全に実装することができる。ＲＧ１０１２Ｂなどの他のＲＧは、アベイラビリティコンテナ１００３Ａのデータセンタ１００５Ａ及び１００５Ｂにわたり、所与のアベイラビリティコンテナ内の複数のデータセンタのリソースを使用することができる。なおも他のＲＧは、異なるアベイラビリティコンテナにわたって広がるリソースを使用するよう実装することができる。例えば、ＲＧ１０１２Ｃは、アベイラビリティコンテナ１００３Ａ及び１００３Ｂそれぞれのデータセンタ１００５Ｂ及び１００５Ｃに設置されたリソースを使用し、ＲＧ１０１２Ｄは、アベイラビリティコンテナ１００３Ａ、１００３Ｂ及び１００３Ｃそれぞれにおけるデータセンタ１００５Ｂ、１００５Ｃ及び１００５Ｄにおけるリソースを活用する。一つの実施例の配置では、ＲＧ１０１２が一つのプライマリ及び二つの非プライマリノードを備える場合に、三つのノードの各々を、異なるアベイラビリティコンテナに設置することができる。それ故に、二つの異なるアベイラビリティコンテナに同時に大規模な障害事象が発生した場合でさえも、少なくとも一つのノードが機能性を高い可能性で保持することを保証することができる。
描写した実施形態では、それぞれＳＭＳ及びＳＰＳに関連するコンソールサービス１０７８及び１０７６が、プロバイダネットワーク１００２においてストリーム関連設定を構成するための、使いやすいウェブベースのインターフェースを提供することができる。その少なくともいくつかをＳＭＳ及び／またはＳＰＳによって使用することができる多くの追加のサービスを、一つ以上のデータセンタにわたって、または一つ以上のアベイラビリティコンテナにわたって広がるリソースを使用してプロバイダネットワーク１００２に実装することができる。例えば、さまざまな異なる性能レベルのコンピュートインスタンスとしてパッケージ化された選択された量の計算能力をクライアントが活用できる仮想コンピューティングサービス１０７２を実装することができる。そのようなコンピュートインスタンスを使用して、ＳＭＳ及び／またはＳＰＳノードを実装することができる。例えば、ブロックデバイスボリュームインターフェースまたはウェブサービスインターフェースのいずれかを経由してクライアントが所望のデータの永続性レベルを持つデータオブジェクトを保存及びそれにアクセスできる一つ以上のストレージサービス１０７０を実装することができる。いくつかの実施形態において、ストレージオブジェクトをサービス１０７２のコンピュートインスタンスに取り付けるまたはそれからそのオブジェクトにアクセスすることができ、それを使用して、ＳＭＳ保存サブシステムにおいてさまざまなストリーム持続性ポリシを実施することができる。一実施形態において、高性能キー値データベース管理サービス１０７４またはリレーショナルデータベースサービスなどの一つ以上のデータベースサービスをプロバイダネットワーク１００２に実装することができる。そのようなデータベースサービスを使用して、ＳＭＮＳ保存サブシステムによってストリームデータレコードを保存し、かつ／または制御サブシステム、取り込みサブシステム、保存サブシステム、検索サブシステムもしくは処理ステージのメタデータを保存することができる。
ストリームセキュリティオプション
少なくともいくつかの実施形態では、ＳＭＳ及び／またはＳＰＳのユーザには、データストリームについての多くのセキュリティ関連オプションが提供され得る。これによりクライアントは、取り込み、保存、検索、処理及び／または制御などのさまざまな機能別カテゴリに使用されるリソース（例えば、仮想または物理マシン）のセキュリティプロファイルを選択することができる。そのようなオプションは、例えば、さまざまなノードに使用されるリソースの物理的な位置のタイプについての選択（例えば、プロバイダネットワーク機能またはプロバイダネットワーク機能とは異なるセキュリティ特性を有し得るクライアント所有の設備を使用するか否か）、ストリームデータの暗号化についての選択、及び／またはストリーム処理インフラのさまざまな部分におけるネットワーク分離の選択を含むことができる。一部のクライアントは、価値が高い登録商標権を持つビジネスロジックまたはアルゴリズムへのアクセスを得て、例えば、クライアント所有の設備内のコンピューティングデバイスを使用してストリーム処理ワーカーノードを実装することを所望し得る侵入者またはアタッカーの可能性について憂慮することがある。ＳＭＳ及び／またはＳＰＳノードのセットを実施するのに使用されるリソースのタイプは、それらのノードに関して、本明細書において「配置宛先タイプ」と称され得る。図１１は、少なくともいくつかの実施形態に従う、ＳＭＳまたはＳＰＳのノードに応じて選択することができる複数の配置宛先タイプを示す。
描写した実施形態では、配置宛先は、一部のタイプのＳＭＳ／ＳＰＳ機能別カテゴリ（例えば、取り込み、保存、検索、制御または処理）のために、プロバイダネットワーク１１０２内に、及び他のタイプのＳＭＳ／ＳＰＳ機能別カテゴリのために、プロバイダネットワーク１１０２の外側に選択することができる。プロバイダネットワーク１１０２内において、コンピュートインスタンス、ストレージインスタンスまたはデータベースインスタンスなどの一部のリソースを、マルチテナントインスタンスホスト１１０３を使用して実装することができる。そのようなマルチテナントインスタンスホストは、一つ以上のクライアントについてのＳＭＳまたはＳＰＳノードの各々においてインスタンス化され、配置宛先タイプの第一のカテゴリ「Ａ」を形成することができる。物理リソースを他のクライアントと共用する必要性を回避するために、一部のクライアントは、そのクライアントのＳＭＳ／ＳＰＳノードを、単一のクライアントに限定されたインスタンスホストを使用して実装することをリクエストすることができる。そのようなシングルテナントインスタンスホストは、配置カテゴリタイプ「Ｂ」を形成することができる。いくつかの理由のために、一部のクライアントの観点からすれば、シングルテナントインスタンスホストが好ましいことがある。マルチテナントインスタンスホストは、シングルテナントインスタンスホストとは異なり、他のクライアントに属するコンピュートインスタンスを含み得るので、マルチテナントインスタンスホストにおける別のクライアントのインスタンスからのセキュリティ攻撃の可能性がより高くなり得る。さらに、マルチテナントホストにおいて実行されるあるクライアントのコンピュートインスタンスＣＩ１が、作業負荷を急増し、ホストの計算サイクルまたは他のリソースの大部分を消費し、それ故に、異なるコンピュートインスタンスＣＩ２を実行する別のクライアントのアプリケーションの性能に影響を及ぼす可能性がある「ノイジーネイバー」現象も、シングルテナントインスタンスホストを使用するときには回避することができる。
描写した実施形態では、ＩＶＮ１１０６Ａ及び１１０６Ｂなどの隔離された仮想ネットワーク（ＩＶＮ）１１０６が、配置宛先タイプの別のカテゴリ「Ｃ」を表すことができる。いくつかの実施形態において、ＩＶＮ１１０６は、プライベートネットワークの論理等価として、プロバイダネットワーククライアントのリクエストにおいて作製され、プロバイダネットワークリソースを使用するが、クライアントによって主として制御されるネットワーク構成を持つよう作製することができる。例えば、クライアントは、ＩＶＮの外側において既に使用され得るＩＰアドレスを重複する可能性について憂慮する必要なく、ＩＶＮ１１０６内で使用するＩＰアドレスを決定することができる。描写した実施形態では、一つ以上のＩＶＮにおけるさまざまなタイプのＳＭＳ及びＳＰＳノードの実装は、クライアントのストリームデータの管理及び／または処理に、割増レベルのネットワークセキュリティを追加することができる。場合によっては、所与のクライアントは、ＳＭＳ／ＳＰＳノードの一つの機能別カテゴリをＩＶＮ１１０６に、異なる機能別カテゴリを異なるＩＶＮに配置することを所望できる。さまざまな実施形態において、所与のＩＶＮ１１０６は、シングルテナントインスタンスホスト、マルチテナントインスタンスホストのいずれか、または両方のタイプのインスタンスホストを備えることができる。図１１には示さないが、いくつかの実施形態において、プロバイダネットワークのリソースを使用して別のセットの配置宛先タイプの選択（または、セキュリティプロファイルの選択）を、少なくともいくつかのクライアントに利用可能にすることができる。ストリーム関連動作においてプロバイダネットワークの仮想化されたコンピューティングサービスからクライアントがコンピュートインスタンスを取得及び使用することができる実施形態では、コンピュートインスタンスを、二つのモードのうちの一つにおいて使用することができる。一つのモードにおいて、クライアントは、ＳＰＳワーカーノードとして（または、取り込み、保存または検索ノードにおいて）構成され、ＳＭＳまたはＳＰＳにプログラムを実行させかつノードを管理させる、コンピュートインスタンスにおいて実行するための一つ以上の実行可能プログラムをＳＰＳまたはＳＭＳに提供することができる。この第一のモードは、ストリームについての動作においてコンピュートインスタンスを使用する「ストリームサービス管理」モードと称され得る。他のモードにおいて、クライアントは、ＳＰＳまたはＳＭＳからのより少ないサポートにおいて、実行可能プログラムを実行し、コンピュートインスタンスを管理することを所望できる。この第二のモードは、ストリームについての動作においてコンピュートインスタンスを使用する「クライアント管理」モードと称され得る。それ故に、これらの二つのモードの動作は、クライアントが選択可能な配置宛先タイプまたはセキュリティプロファイルに関する追加の選択を示すことができる。クライアントは、例えば、実行可能プログラムが、クライアントの組織からの主題専門家によって最もよく実行できる（シングルステッピングを含む）デバッギングを必要とする可能性が高い場合には、クライアント管理モードを選ぶことができる。一方で、デバッギングを恐らく必要としないより成熟したコードに関しては、ストリームサービス管理モードが妥当な選択であり得る。いくつかの実施形態において、これらの二つのモードに異なる価格決定ポリシを適用することができる。
図１１に示す実施形態において、プロバイダネットワーク外部の設備において多くの配置オプションをサポートすることができる。例えば、ＳＭＳライブラリ１１７１及び／またはＳＰＳライブラリ１１７２がインストールされたホスト１１６０を、プロバイダネットワークとの接続性の様式が異なる二つのタイプのクライアント設備（例えば、クライアント所有のデータセンタまたは設備）１１１０Ａまたは１１１０Ｂ内において、ストリーム管理または処理のために使用することができる。クライアント設備１１１０Ａは、少なくともいくつかの共有インターネットリンク１１５１を通じて、プロバイダネットワーク１１０２にリンクされる（すなわち、他の事業体のネットワークトラフィックも、クライアント設備１１１０Ａとプロバイダネットワーク１１０２との間のリンクの一部を流れることができる）。対照的に、一部のクライアント設備（例えば、１１１０Ｂ）は、（「直接結合」リンクと称され得ることもある）特殊な非共用の専用物理リンク１１０６によってプロバイダネットワークにリンクすることができる。これらの二つの異なるタイプのクライアント設備は、図１１に使用される専門用語において、それぞれ、配置宛先オプション「Ｄ」及び「Ｅ」を備える。いくつかの実施形態において、ＳＭＳ及び／またはＳＰＳの一部も、第三者設備（例えば、ＳＭＳ／ＳＰＳのクライアントによって所有または管理されないが使用されるデータセンタ）に実装することができる。そのような第三者設備は、配置宛先タイプ「Ｆ」として用意することができる。クライアント及び／または第三者設備の少なくともいくつかにおいて、ＳＭＳ及び／またはＳＰＳライブラリを、プロバイダネットワークから入手し、ＳＭＳ／ＳＰＳノードのために使用されるホストにインストールする必要が生じ得る。少なくとも一つの実施形態では、すべての異なる機能別カテゴリのノードを、適切なライブラリの援助を受けて、プロバイダネットワークの外部に実装することができる。種々の実施形態において、種々の配置宛先タイプは、例えば、実装されるネットワーク分離特徴、サポートされる侵入検出機能性、実装される物理的セキュリティポリシ、サポートされた暗号化レベルなどのさまざまなセキュリティ関連の態様において互いに異なってもよい。それ故に、さまざまな宛先タイプの各々は、一つ以上の様式において他の配置宛先のセキュリティプロファイルとは異なってもよいそれぞれのセキュリティプロファイルを有するものとみなされ得る。いくつかの実施形態において、ＳＭＳ及び／またはＳＰＳのクライアントは、例えば、図１２ａ及び図１２ｂに示すように、リクエストを一つ以上のＳＭＳまたはＳＰＳの制御ノードに送信することによって、異なるサブシステムまたはノードセットについてのそれぞれの配置宛先タイプをプログラムで選択することができる。いくつかの実施形態において、及び特定のタイプのストリームアプリケーションに関して、クライアントが、セキュリティの理由のみならず、性能及び／または機能性の理由にもよって、配置宛先タイプの制御を所望できることに留意されたい。例えば、前述のノイジーネイバー現象は、専用のクライアント設備のリソースまたはシングルテナントインスタンスホストを使用することによって回避することができる。いくつかの実施形態において、そのようなコンポーネントを使用して達成可能な機能的性能または性能レベルが、プロバイダネットワークにおいて容易にレプリカできない、またはプロバイダネットワークにおいて簡単にサポートされない場合には、クライアントは、ＳＰＳステージまたはＳＭＳノードに関して使用することを所望する専用のまたは登録商標権を持つハードウェア及び／またはソフトウェアを有することができる。クライアントは、外部データセンタにおいて、例えば、プロバイダネットワークリソース単独を使用して実行できるものよりも遥かに高い速度においてＳＰＳ処理を実行できるスーパーコンピュータレベルの処理性能を持つコンピュータサーバへのアクセスを有することができる。さまざまなノードについての配置宛先をクライアントが選択できることによって、そのような専用デバイスまたはソフトウェアを使用することができる。
図１２ａ及び図１２ｂは、それぞれ、少なくともいくつかの実施形態に従う、ＳＰＳクライアント及びＳＭＳクライアントによって提示することができるセキュリティオプションリクエストの実施例を示す。図１２ａは、識別子を持つ一つ以上の処理ステージ１２１０、ステージの制御ノードにおいてリクエストされた配置宛先タイプ（ＰＤＴ）（要素１２１２）、及びワーカーノードにおいてリクエストされたＰＤＴ（要素１２１４）についてクライアントが示すＳＰＳセキュリティオプションリクエスト１２００を示す。少なくとも一つの実施形態では、クライアントは、例えば、さまざまなネットワークリンクを通じて伝送する、またはさまざまな制御もしくは管理上の相互作用を暗号化する前に、指定されたアルゴリズムまたはプロトコルを使用してデータレコードを暗号化することをリクエストすることによって、ストリームデータレコードまたはストリーム処理結果についての暗号化設定を構成するためのリクエストを提示することもできる。例えば、図１２ａでは、ステージについての暗号化設定は、ステージ処理動作の結果に適用される暗号化技術、及び／またはステージの制御ノードとステージのワーカーノードとの間の通信に使用される暗号化を示すことができる。
同様に、図１２ｂにおいて、クライアントのＳＭＳセキュリティオプションリクエスト１２５０は、指定された識別子１２５２を持つ一つ以上のストリームについてのクライアントのセキュリティ嗜好を表す多くの要素を備える。取り込みノード、保存ノード及び検索ノードについての配置宛先タイプの嗜好が、それぞれ、要素１２５４、１２５８及び１２６２において表され得る。取り込み制御ノード、保存制御ノード及び検索制御ノードについてのＰＤＴ嗜好が、それぞれ、要素１２５６、１２６０及び１２６４によって表され得る。データレコードについての暗号化の嗜好、例えば、ノードのあるカテゴリから別のカテゴリに伝送されるときのデータレコードについての暗号化の実施の有無及び方法は、要素１２６６によって表され得る。図１２ａ及び図１２ｂに示すようなセキュリティオプションリクエストを使用して、クライアントは、（例えば、プロバイダネットワーク内部のまたはプロバイダネットワーク外部の）ロケーション、並びにストリーム管理及び処理環境の種々の部分についてのさまざまな他のセキュリティプロファイルコンポーネントを選ぶことができる。
少なくともいくつかの実施形態では、セキュリティ以外の理由ために、ノード配置宛先の選択を提供できることに留意されたい。例えば、クライアントは、性能の理由のために（例えば、主としてセキュリティの理由以外の前述した「ノイジーネイバー」問題を回避するために）シングルテナントホストにおいて実装された一部のタイプのＳＭＳまたはＳＰＳノードを有することを所望できる。少なくともいくつかの実施形態では、ストリームの寿命期間に配置の選択を変更することができる。例えば、クライアントは、初期に、ＳＭＳノードをマルチテナントインスタンスホストにおいてインスタンス化できるが、後で、ノードの少なくともいくつかのサブセットをシングルテナントインスタンスホストに移動させることを所望することができる。少なくともいくつかの実施形態では、種々の価格決定ポリシを種々のセキュリティ関連オプションに適用することができる。例えば、ＩＶＮ外部のマルチテナントインスタンスホストにおいてよりもＩＶＮにおいて特定の機能別カテゴリのＳＭＳノードを実装することにはより費用がかかり得る、またはマルチテナントインスタンスホストにおいておよりもシングルテナントインスタンスホストにおいてＳＭＳノードを実装することにはより費用がかかり得る。
ストリームレコードの順次保存及び検索
多くのタイプのストリームアプリケーションにおいて、データレコードは、複数のデータプロデューサ１２０から非常に高速でＳＭＳにおいて受信することができ、そしてデータコンシューマは、通常、レコードが生成された順序で保存されたデータレコードにアクセスすることを所望できる。特に、前述のような、ストリームデータレコードのためのストレージデバイスとして回転磁気ディスクが使用される環境では、（読み出し及び書き込み両方のための）順次の入出力アクセスパターンは、ランダムの入出力アクセスパターンよりも大幅に優れた性能優位性を有することができる。いくつかの実施形態において、ストリーム特有のまたはパーティション特有のシーケンス番号を、ＳＭＳによって受信されるときにデータレコードに割り当てることができる。そしてシーケンス番号に基づく順次検索動作をサポートすることができる。図１３ａは、少なくともいくつかの実施形態に従う、ストリームデータプロデューサとＳＭＳの取り込みサブシステムとの間の実施例の相互作用を示す。ストリームデータプロデューサは、データレコード１１０を取り込みサブシステムに提示することができる。描写した実施形態では、取り込みサブシステムは、提示されたレコードについて選択されたシーケンス番号１０２を使用して応答することができる。少なくともいくつかの実施形態では、取り込みノードは、保存サブシステムからシーケンス番号の一部を入手することができる。例えば、そのような実施形態では、受信したデータレコードの保存に続いて、適用可能な持続性ポリシに従いシーケンス番号１０２を決定することができる。そして保存サブシステムは、データレコードについて特有の番号順インジケータを生成し、取り込みノードによってデータレコードに割り当てられたより大きなシーケンス番号に含有させるために、そのインジケータを提供することができる。
さまざまな実施形態において、データレコードについての安定した一貫性のある順序を提供し、データコンシューマによるレコード全体を通じた反復可能な繰り返しを可能にするために、シーケンス番号を実装することができる。少なくともいくつかの実施において、特定のパーティションのデータレコードに割り当てられたシーケンス番号は、連続している必要はないが、経時的に単調に増加させることができる。さまざまな実施形態において、シーケンス番号は、以下の意味論の少なくともいくつかのサブセットにおいて割り当てることができる。（ａ）シーケンス番号は、ストリーム内において独自のものである、すなわち、所与のストリームの同じデータレコードに、同じシーケンス番号が割り当てられることはない、（ｂ）シーケンス番号は、ストリームのデータレコード内のインデックスとしての機能を果たし、所与のストリームパーティション内のデータレコードにわたって繰り返して使用することができる、（ｃ）任意の所与のデータプロデューサにおいて、データプロデューサがデータレコードに成功裏に提示した順序が、データレコードに割り当てられるシーケンス番号に反映される、そして（ｄ）所与のパーティションキー値を持つデータレコードについてのシーケンス番号は、動的再パーティショニング動作にわたる単調に増大する意味論を保持する、例えば、再パーティショニング後にパーティションキー値Ｋ１を持つデータレコードに割り当てられたシーケンス番号は、その各々が、動的再パーティショニングの前にそのパーティションキー値Ｋ１を持つデータレコードに割り当てられたシーケンス番号のいずれよりも大きくなり得る。（動的再パーティショニングのさらなる詳細は、図１６に関して後述する。）
いくつかの実施形態において、データプロデューサは、少なくともいくつかのデータレコードに対して選択されたシーケンス番号１０２の選択に影響を与えることを所望できる。例えば、データプロデューサ１２０は、ストリームの割り当てられたシーケンス番号内の境界線またはセパレータの境界を定めることを所望できる。これによりそのストリームのデータコンシューマは、ストリームの特定のサブセットをターゲットにした読み出しリクエストを提示することがより容易になる。いくつかの実施では、データプロデューサ１２０は、レコードと共に最小シーケンス番号の表示を提示することができる。そしてＳＭＳは、リクエストされた最小値に従う、そして前述のシーケンス番号の意味論にも従うシーケンス番号を選択することができる。
図１３ｂは、少なくともいくつかの実施形態に従う、ＳＭＳにおいて取り込まれたデータレコードに応じて生成することができるシーケンス番号の実施例の要素を示す。描写した実施形態では、シーケンス番号は、四つの要素を備えることができる。すなわち、ｎ１ビットＳＭＳバージョン番号１３０２、ｎ２ビットタイムスタンプまたはエポック値１３０４、ｎ３ビットサブシーケンス番号１３０６、及びｎ４ビットパーティション番号１３０８を備える。いくつかの実施では、１２８ビットシーケンス番号を使用することができる。例えば、ｎ１、ｎ２、ｎ３及びｎ４は、それぞれ、４、４４、６４及び１６ビットであってもよい。バージョン番号１３０２を簡単に使用して、ＳＭＳソフトウェアバージョンロールアウトに伴う混乱を回避することができる。これにより例えば、シーケンス番号を生成するのにＳＭＳソフトウェアのどのバージョンが使用されたかを容易に見分けることができる。少なくともいくつかの実施において、バージョン番号１３０２は、頻繁に変更することは予期されない。タイムスタンプ値１３０４は、例えば、取り込みサブシステムのノードによって、ローカルクロックソースまたはグローバルアクセス可能なクロックソース（例えば、ｇｅｔＣｕｒｒｅｎｔＥｐｏｃｈまたはｇｅｔＣｕｒｒｅｎｔＴｉｍｅ ＡＰＩを実装するプロバイダネットワークの状態管理システム）から入手することができる。少なくともいくつかの実施において、既知の時点からのオフセット（例えば、Ｕｎｉｘ（商標）ベースのオペレーティングシステムにおけるさまざまな時間関連システムコールを起動することによって入手することができる、１９７０年１月１日のＡＭ００：００：００ＵＴＣから経過した秒数）を、タイムスタンプ値１３０４に使用することができる。いくつかの実施形態において、保存サブシステムによって、特定のパーティションのデータレコードがストレージデバイスに書き込まれる順序を表すことができるサブシーケンス番号１０３６を生成することができる。それ故に、幾多のデータレコードが所与の秒内に受信され、そしてタイムスタンプ値１３０４がおおよそ秒毎の間隔においてしか変更されない実施では、サブシーケンス番号１３０６は、同じ秒内に偶然到着し、したがって、同じタイムスタンプ値が割り当てられたデータレコードについてのレコード到着（または、保存）順序のインジケータとしての機能を果たすことができる。いくつかの実施形態において、パーティション番号１３０８は、所与のストリーム内のパーティションを独自に特定することができる。シーケンス番号タイムスタンプが、対応するデータレコードが取り込まれた（少なくともおおよその）時刻を示す少なくともいくつかの実施では、シーケンス番号を、特定のタイプの時間ベースの検索リクエストについてのインデックスメカニズムとして使用することができる。例えば、クライアントは、特定の日または指定された時間範囲内に生成または取り込まれたストリームレコードを検索することを所望でき、そしてシーケンス番号を、データレコードの適切なセットを検索するための暗示的な二次インデックスのキーとして使用することができる。それ故に、少なくともいくつかの実施形態では、順序付けられた保存及び検索についてのタイムスタンプを含むシーケンス番号の使用によって、保存されたデータレコードのセットに時間的インデックスを提供するという追加の利益を有することができる。
所与のパーティションのデータレコードは、通常、多くの場合に大きな順次書き込み動作を使用して、シーケンス番号順に（例えば、ディスクに）書き込むことができる。いくつかの実施形態において、前述のように、イテレータベースのプログラマチックインターフェースを実装し、これによりデータコンシューマは、データレコードをシーケンス番号順に読み出すことができる。図１４は、少なくともいくつかの実施形態に従う、ＳＭＳにおいて順序付けられたストレージ及びストリームデータレコードの検索の実施例を示す。パーティションＳｊ−Ｐｋ（ストリームＳｊのｋ番目のパーティション）の六つのデータレコード１１０Ａ〜１１０Ｆが、シーケンス番号順に保存されて示される。少なくともいくつかの実施形態では、示したように、シーケンス番号は連続していなくてもよい。なぜならば、例えば、前述のタイムスタンプ部１３０４またはサブシーケンス番号１３０６に値が割り当てられる様式が、必ずしもそれらの要素において連続的な値をもたらさなくてもよいからである。
図１４に示す実施例では、データコンシューマは、イテレータを作製し、開始シーケンス番号「８６５」を指定することをリクエストした。ＳＭＳは、リクエストに応答して、リクエストされた開始シーケンス番号以上の最も近いシーケンス番号を持つデータレコードに位置付けられたＩｔｅｒａｔｏｒ１を初期化した。この場合は、隣のより小さいシーケンス（データレコード１１０Ｂに割り当てられた８６０）が、コンシューマのリクエストにおける開始シーケンス番号よりも小さいので、シーケンス番号８７０を持つデータレコード１１０Ｃが、イテレータの開始位置として選択された。ｇｅｔＩｔｅｒａｔｏｒインターフェースが、パーティション内のリクエストされた位置にカーソルを設定するために、リクエストの論理等価を考慮し、そして次に、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓインターフェースを使用して、例えば、シーケンス番号順にストリームに沿ってカーソルを移動させてカーソル位置から開始してデータレコードを読み出すことができる。示した実施例では、データコンシューマは、Ｉｔｅｒａｔｏｒ１に設定されたパラメータ「イテレータ」、及び（データレコードの最大数に戻すように）３に設定された「ｍａｘＮｕｍＲｅｃｏｒｄｓ」を持つｇｅｔＮｅｘｔＲｅｃｏｒｄｓインターフェースを呼び出した。それ故に、ＳＭＳ検索サブシステムは、データレコード１１０Ｃ、１１０Ｄ及び１１０Ｅをその順序でデータコンシューマに戻す。イテレータＩｔｅｒａｔｏｒ１は、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓの呼び出しが完了した後に新規の位置、例えば、データレコード１１０Ｆに移動し、同じイテレータについての次のｇｅｔＮｅｘｔＲｅｃｏｒｄ起動によって、データレコードを１１０Ｆから開始して戻すことができる。いくつかの実施形態において、ｇｅｔＩｔｅｒａｔｏｒの呼び出しの意味論は異なってもよい。例えば、指定されたシーケンスされた番号以上の最も近いシーケンス番号を持つデータレコードにイテレータを位置付ける代わりに、いくつかの実施形態において、イテレータを、リクエストされたシーケンス番号以下の最も大きいシーケンス番号を持つ最も近いデータレコードに位置付けてもよい。別の実施形態では、クライアントは、ｇｅｔＩｔｅｒａｔｏｒの呼び出しにおいて既存のシーケンス番号を指定する必要が生じ得る。例えば、リクエストされたシーケンス番号を持つレコードがストリーム内に存在しない場合には、エラーを戻すことができる。
パーティションマッピング
前述のように、さまざまな実施形態において、所与のストリームのレコードの取り込み、保存、検索及び処理に関連する作業負荷を、さまざまなパーティション及び再パーティショニングポリシに従い、いくつかのノード間に再分割及び分配することができる。図１５は、少なくともいくつかの実施形態に従う、ＳＭＳ及びＳＰＳノードに応じて作製できるストリームパーティションマッピング１５０１及び対応する構造決定の実施例を示す。例えば、ｃｒｅａｔｅＳｔｒｅａｍ ＡＰＩのクライアントの起動に応答して特定のデータストリームが作製または初期化されると、ストリームについてのパーティショニングポリシをアクティブにすることができ、これを使用して、ストリームのどの任意の所与のデータレコードのパーティションを一部分とみなすかを決定することができる。所与のデータレコードについての動作を実行可能な特定の取り込みサブシステム２０４、保存サブシステム２０６、検索サブシステム２０８、及び任意の関連するＳＰＳステージ２１５のノードは、レコードのパーティションに基づいて選択することができる。一実施形態において、所与のデータレコードに使用される制御ノードの少なくともサブセットも、同様に、パーティションに基づいて選択することができる。少なくともいくつかの実施形態では、データストリームの動的再パーティショニングを、例えば、ポリシに示されるトリガ条件または明示的なリクエストに応答して、パーティショニングポリシの一部としてサポートすることができる。
さまざまな実施形態において、所与のデータレコードに対して選択されるパーティションは、直接的（例えば、書き込みまたはプットリクエストのパラメータとして）、または間接的（例えば、ＳＭＳがデータプロデューサクライアントの識別子もしくは名前、データプロデューサのＩＰアドレス、またはデータレコードの実際のコンテンツの一部などのメタデータをパーティションキーとして使用できる）のいずれかにおいて、データプロデューサによってその値が供給され得る、レコードについてのパーティショニングキーに応じて決めることができる。図１５に示す実施形態において、一つ以上のマッピング機能１５０６を、データレコードパーティションキーまたは属性１５０２に適用し、データレコードパーティション識別子１５１０を決定することができる。一つの実施において、例えば、所与のパーティション識別子１５１０は、１２８ビット整数の空間にわたる隣接範囲を表すことができる。これによりストリームのすべてのパーティションについての範囲の結合が、１２８ビット整数が担い得るすべての起こり得る値を包含することができる。そのような実施例のシナリオでは、一つの単純なマッピング機能１５０６が、データレコードのパーティションキー値（複数可）または選択された属性値（複数可）から１２８ビットハッシュ値を生成することができる。そしてハッシュ値がたまたま位置する特定の隣接範囲に基づいて、パーティション識別子を決定することができる。いくつかの実施では、隣接範囲は、少なくとも初期にはサイズが等しくてもよく、他の実施では、異なるパーティションは、サイズが互いに異なってもよい隣接範囲に対応し得る。一つの実施において、再パーティショニングは、範囲境界線の調節もすることができる。他のパーティショニング機能１０６を種々の実施において使用することができる。
（さらなる詳細を後述するように）データストリームが動的再パーティショニングを受ける場合には、特定のキーを持つレコードがマッピングされるパーティションを変更することがある。それ故に、少なくともいくつかの実施形態では、ＳＭＳ及び／またはＳＰＳ制御ノードは、ストリームの寿命期間にストリームに適用されるいくつかの異なるマッピングを追跡する必要が生じ得る。いくつかの実施形態において、タイムスタンプ有効範囲１５１１またはシーケンス番号有効範囲などのメタデータを、パーティションマッピングごとに制御ノードに保存することができる。例えば、タイムスタンプ有効範囲１５１１は、特定のマッピングＭ１がストリームの作製時間から時刻Ｔ１まで適用され、異なるマッピングＭ２がＴ１からＴ２まで適用されることなどを表すことができる。ストリーム向けの読み出しリクエストに応答すると、検索ノードは、最初に、（例えば、読み出しリクエストに示されるシーケンス番号に応じて）どのマッピングを使用するかを決定し、次に、そのマッピングを使用して適切な保存ノードを特定する必要が生じ得る。
少なくともいくつかの実施形態では、ＳＭＳ及びＳＰＳ制御ノードは、いくつかの異なる粒度におけるリソースに対するパーティションのマッピングに関与することができる。例えば、図１５の実施例の実施１５９９に示すように、一つの実施において、（ワーカー）ノードの取り込み、保存、検索または処理の各々は、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）またはコンピュートインスタンスなどのサーバ仮想マシン内の実行のそれぞれのプロセスまたはそれぞれのスレッドとして実施することができる。そして各ＪＶＭまたはコンピュートインスタンスは、特定の物理ホストにおいてインスタンス化することができる。いくつかの実施形態において、複数のＪＶＭが単一のコンピュートインスタンス内において起動され、リソースマッピング決定の別の層を追加することができる。それ故に、所与のパーティションにおいて、一つ以上の制御ノードは、どの特定のリソースを、取り込みノード１５１５、保存ノード１５２０、検索ノード１５２５または処理ステージワーカーノード１５３０（例えば、それぞれ、ステージＰＳ１またはＰＳ２についてのノード１５３０Ａまたは１５３０Ｂ）として使用するかを選択することができる。制御ノードは、サーバ（例えば、取り込みサーバ１５３５、保存サーバ１５４０、検索サーバ１５４５または処理サーバ１５５０）へのそれらのノードのマッピング、及びサーバとホスト（例えば、取り込みホスト１５５５、保存ホスト１５６０、検索ホスト１５６５またはＳＰＳホスト１５７０Ａ／１５７０Ｂ）との間のマッピングも決定することができる。いくつかの実施では、パーティションマッピングは、例証されるさまざまなリソースの粒度（例えば、ノード、サーバ及びホストの粒度）の各々における識別情報（例えば、リソース識別子）、並びに一つ以上の機能１５０６への入力として使用されるデータレコード属性、及び機能１５０６それ自体の表示を備えることが考慮され得る。制御サーバは、パーティションマッピングの表示をメタデータストアに保存し、いくつかの実施形態では、さまざまなＡＰＩ（例えば、ｇｅｔＰａｒｔｉｔｉｏｎＩｎｆｏ ＡＰＩ）または他のプログラマチックインターフェースを公開し、マッピング情報を、データプロデューサ、データコンシューマまたはＳＭＳサブシステムもしくはＳＰＳのノードに提供することができる。
いくつかの実施形態において、パーティションへのデータレコードのマッピング、及びパーティションからリソースへのマッピングは、さまざまなファクタによってさらに複雑になり得る。例えば、（ａ）いくつかの実施形態において、所与のノード、サーバまたはホストが、複数のパーティションに関与して用意され得る、または（ｂ）障害または他のトリガが、所与のパーティションまたはパーティションのセットに割り当てられた新規のノード、サーバまたはホストをもたらし得る。さらに、前述した及び後述するように、所与のストリームについてのパーティションマッピングは、経時的に動的に変更し得、一方で、ストリームレコードは、ＳＭＳ及び／またはＳＰＳノードによって引き続き処理される。その結果、いくつかの実施形態において、その各々が異なる期間に対応する、マッピングメタデータのいくつかのバージョンを、少なくとも一時的に所与のストリームのために保持することができる。
動的ストリームの再パーティション
図１６は、少なくともいくつかの実施形態に従う、動的ストリームの再パーティションの実施例を示す。図１６に示すタイムラインの時刻Ｔ１において、ストリームＳ１が作製または初期化される。ストリームＳ１についてのパーティションマッピングＰＭ１が作製され、時間間隔Ｔ１〜Ｔ２の間、その実施が保持される。Ｔ１とＴ２との間にＳＭＳによって受信された三つのデータレコードが、実施例として示される。データレコード１１０Ａ（ＤＲ１１０Ａ）が、クライアント供給のパーティションキー値「Ａｌｉｃｅ」を含んで提示され、ＤＲ１１０Ｂが、クライアント供給のパーティションキー値「Ｂｉｌｌ」を含んで提示され、そしてＤＲ１１０Ｃが、クライアント供給のパーティションキー値「Ｃｈａｒｌｉｅ」を含んで提示される。初期のマッピングＰＭ１において、すべての三つのデータレコード１１０Ａ、１１０Ｂ及び１１０Ｃが、パーティション識別子「Ｐ１」を含んで同じパーティションにマッピングされる−Ｐｌデータレコードにおいて、単一ノードＩ１が取り込みを行うように構成され、単一ノードＳ１が保存を行うように構成され、単一ノードＲ１が検索を行うように構成され、そして単一ワーカーノードＷ１がＳＰＳ処理を行うように構成される。マッピングＰＭ１の有効範囲についての開始タイムスタンプが、Ｔ１に設定される。
図１６の実施例のタイムラインの時刻Ｔ２において、ストリームＳ１が動的に再パーティションされる。描写した実施形態では、再パーティショニングが起こるときにかかわらず、つまり、ＳＭＳもＳＰＳもオフラインになる必要がなく、データレコードは、到着し続け、ＳＭＳ及びＳＰＳによって処理される。再パーティショニングは、多くのファクタのいずれかの結果として起動することができる。例えば、取り込み、保存、検索もしくは処理ノードにおける過負荷条件の検出、さまざまなサブシステムの種々のホストにおける作業負荷レベル間のスキューもしくはアンバランスの検出、またはデータコンシューマもしくはデータプロデューサクライアントからのリクエストに応答して起動することができる。描写した実施形態では、新規のマッピングＰＭ２が、ＰＭ２について示す有効範囲開始タイムスタンプ設定に示すように、時刻Ｔ２において（または、Ｔ２の直後に）実施される。少なくともいくつかの実施において、データレコード属性の異なるセットを、再パーティショニングの前に使用されたデータレコードのパーティショニングに使用することができる。場合によっては、追加のパーティショニング属性が、（例えば、ＳＭＳのリクエストにおいて）データプロデューサによって提示され得、一方で他の場合において、追加の属性を、ＳＭＳ取り込みノードによって生成することができる。そのような追加の属性は、「添加された」属性と称され得、そして再パーティショニングのために追加の属性を使用する技術は、「添加」と称され得る。一つの実施例の実施において、過負荷の取り込みサーバは、再パーティショニングのためのデータプロデューサ（例えば、データプロデューサによって実行されるＳＭＳクライアントライブラリコード）を表し得、ランダムに選択された小さい整数が、以前に使用されたパーティションキーに追加として提供される。その後、オリジナルのパーティションキーと添加された追加の整数との組み合わせを使用して、取り込みの作業負荷を取り込みノードの異なるセット間に分配することができる。いくつかの実施形態において、検索ノード及び／またはデータコンシューマに、再パーティショニングに使用される追加の属性について通知する必要性が生じ得る。少なくともいくつかの実施において、そのような追加の属性は、再パーティショニングに使用しなくてもよい。
図１６に示す実施形態では、新規のパーティションマッピングが、Ｔ２前に同じキーに対して選択されたパーティションと相対的な、Ｔ２後に受信されたデータレコードの少なくともいくつかに対して選択された異なるパーティションをもたらす。ＤＲ１１０Ｐが、パーティションキー値「Ａｌｉｃｅ」を含んでＴ２後に提示され、ＤＲ１１０Ｑが、パーティションキー値「Ｂｉｌｌ」を含んでＴ２後に提示され、そしてＤＲ１１０Ｒが、パーティションキー値「Ｃｈａｒｌｉｅ」を含んでＴ２後に提示される。示す実施例のシナリオでは、ＰＭ２マッピングを使用して、ＤＲ１１０Ｐが、パーティション「Ｐ４」の一部分として用意され、ＤＲ１１０Ｑが、パーティション「Ｐ５」の一部分として用意され、さらに、ＤＲ１１０Ｒが、パーティション「Ｐ６」の一部分として用意される。描写した実施形態では、Ｔ２後に受信されたものとして示される実施例のデータレコードのいずれも、以前に使用されたパーティション「Ｐ１」の一部分として用意されない。代わりに、再パーティショニング後に、完全に新規なパーティションを使用することができる。いくつかの実施形態において、少なくともいくつかの以前に使用されたパーティションの使用を、再パーティショニング後に継続することができる。新規のパーティションＰ４、Ｐ５及びＰ６の各々において、種々のノードを、取り込み、保存、検索及び／または処理のために用意することができる。例えば、ノードＩ４、Ｓ４、Ｒ４及びＷ４を、パーティションＰ４のために構成し、ノードＩ５、Ｓ５、Ｒ５及びＰ５を、パーティションＰ５のために構成し、そしてノードＩ６、Ｓ６、Ｒ６及びＰ６を、パーティションＰ６のために構成することができる。いくつかの実施形態において、同じ保存ノードを、再パーティショニング前に特定のパーティションキーまたは属性を持つレコードに使用したように、再パーティショニング後にそのようなレコードに使用することができるが、再パーティショニング後に、そのノード内の異なる保存場所（例えば、異なるディスク、異なるディスクパーティションまたは異なるＳＳＤ）を使用してもよい。
Ｔ２における動的再パーティショニング後の少なくともいくらかの期間中、再パーティショニング前にＳＭＳ取り込み及び／または保存サブシステムによって処理されたデータレコードのための検索リクエストの検索を継続することができる。少なくともいくつかの場合において、データレコードが取り込まれた時点に実施されたＰＭ１マッピングに基づいて、リクエストされたデータレコードを検索する必要が生じ得る。それ故に、図１６に示すように、データ検索の目的のために、ＰＭ１及びＰＭ２の両方の使用を、Ｔ２後にいくらかの時間継続することができる。少なくともいくつかの実施において、データレコードは、最終的に、古くなったときにストリームから削除することができ、そしてより古いパーティションマッピングも、例えば、すべての対応するデータレコードそれ自体が削除されたときに、最終的に廃棄することができる。いくつかの実施形態において、ストリームレコードは、（削除する代わりに（または、その前に）、例えば、クライアント選択のアーカイバルポリシに基づいて）保存場所またはデバイスの異なるセットにアーカイブすることができる。これによりＳＭＳによって使用されるパーティションマッピングを、依然として、アーカイバル後にレコードを検索するために使用することができる。そのような実施形態では、ＰＭ１及びＰＭ２などのパーティションマッピングを、アーカイバルストレージに導かれる検索リクエストをサポートするのに必要である限り、保持することができる。いくつかのアーカイバルの実施では、保持されるストリームパーティションマッピングを必要としない種々の検索アプローチを使用することができる（例えば、アーカイブされたデータレコードに新規のインデックスを作製することができる）。いくつかの実施形態において、再パーティショニング前に使用されたが、再パーティショニング後に書き込みがもはや導かれないＰ２などのパーティションは、再パーティショニング後のある時点において、読み出しのために「閉じられる」ことがある。例えば、検索リクエストに応答して、「パーティションの終了に至る」エラーメッセージの均等物が提供され得る。
いくつかの実施では、所与のデータストリームを、幾多の（例えば、何百または何千の）パーティションに分配することができる。ストリームＳ１が１０００のパーティション、すなわち−Ｐｌ、Ｐ２〜Ｐ１０００に初期に分配される実施例の事例が考慮される。一つのパーティションに対応する過負荷条件、すなわち、Ｐ７が検出される場合には、データレコードの初期のマッピングをＰ７に変更するが、他のパーティションのマッピングを変更する必要がないことに価値があり得る。一つのアプローチにおいて、再パーティショニング動作によって二つの新規のパーティションＰ１００１及びＰ１００２を作製することができる。その元々の（すなわち、オリジナルマッピングに基づいた）属性がＰ７における構成員になり得るであろう、再パーティショニング後に受信されたレコードは、再パーティショニング後にＰ１００１またはＰ１００２のいずれかにマッピングされ、それ故に、Ｐ７の作業負荷を二つのパーティション間に分配することができる−Ｐｌ〜Ｐ６及びＰ８〜Ｐ１０００などの残りのパーティションは、変更しなくてもよい。少なくともいくつかの実施形態では、パーティションの小さなサブセットしかそのような再パーティショニングによる影響を受けないので、パーティション入力の有向非巡回グラフなどの組み合わせのデータ構造（または、パーティション入力のツリー）を生成して保存することができる。各入力は、パーティショニング機能の出力範囲及び有効時間範囲（入力のパーティショニング情報が有効であるとみなされている間の期間）を表すことができる。前述の実施例では、Ｐ７を伴う再パーティショニングが時刻Ｔ２に実行され、その一方で、時刻Ｔ１にストリームＳ１（及びその初期のマッピング）が作製されたと仮定される。そのようなシナリオでは、Ｐ７の入力のための有効な期間は、「Ｔ１〜Ｔ２」であり−Ｐｌ００１及びＰ１００２のための有効な期間は、「Ｔ２以降」であり、そして残りのパーティションのための有効な期間は、「Ｔ１以降」であろう。少なくともいくつかの実施において、そのような組み合わせのデータ構造の使用によって、パーティションマッピングメタデータに使用されるメモリまたは保存の量の実質的な減少をもたらすことができる。前述の実施例において、二つの新規のパーティションへのパーティションＰ７の分割を論じた。少なくともいくつかの実施において、再パーティショニング中にパーティションを統合することもできる。例えば、受信した検索リクエストが比較的少ない、または提示されたレコードが比較的少ない二つの隣接するパーティションを、単一のパーティションに統合することができる。任意の所与の時点において、データレコードが属するパーティションを、パーティショニング機能及び有効時間範囲情報を使用して、それが明白なものであると決定することができる。長期にわたり、より多くの分割及び／または統合を実行するのに伴い組み合わせのデータ構造を進化させることができるが、パーティショニングメタデータに必要な空間全体は、（当然ながら、分割が起こる頻度及び分割による影響を受ける平均的なパーティションの数にもよるが）著しく増大しなくてもよい。対照的に、異なる実施では、再パーティショニングが起こる度に、ストリームについての変化していないメタデータの全体セットをレプリカして、再パーティショニングによる影響を受けるパーティションのための入力と組み合わせることができる。パーティションマッピングメタデータに必要なストレージ及びメモリは、特に、前述のように、再パーティショニング後の少なくともいくらかの時間、より古いマッピングを保持する必要性が生じ得る場合には、後の実施において遥かに速い速度において増大することができる。
タイムスタンプ値（例えば、図１３ｂに示すタイムスタンプ値１３０４）を含むシーケンス番号を使用する少なくともいくつかの実施形態では、特殊なタイプのシーケンス番号の遷移を、動的再パーティショニングのために実施することができる。図１３ｂに示すものに類似するタイムスタンプベースのシーケンス番号スキームを、シーケンス番号への含有のための新規のタイムスタンプ値が毎秒生成されるものとして、ストリームＳ１に使用することが実施例として仮定される。動的再パーティショニングがサポートされる少なくともいくつかの実施において、動的再パーティショニング後に割り当てられたシーケンス番号のすべてが、動的再パーティショニング前に使用されたものとは異なる（再パーティション事象に対応する選択された初期タイムスタンプ値から開始された）タイムスタンプ値のセットを使用することができる。例えば、動的再パーティショニングがコミットされる（すなわち、効力を生じる）時に使用されるタイムスタンプ値がＴｋである場合には、Ｔｋ＋１以降にタイムスタンプ値を使用するために、コミット後に発行される任意の新規のシーケンス番号が必要となり得る。シーケンス番号値が、図１３ｂにおいて使用されるスキームにおける上位ビットの少なくともいくつかにおけるタイムスタンプ値をエンコードするので、記述するようなタイムスタンプ境界線に再パーティション事象が対応することが保証され、これにより検索リクエストに応答して使用されるマッピングの特定に伴う簿記を単純化することができる。それ故に、そのような実施では、特定のシーケンス番号を指定する検索リクエストが受信されると、そのシーケンス番号からタイムスタンプ値が抽出され、再パーティショニング後にマッピングを使用すべきか、または再パーティショニング前にマッピングを使用すべきかを容易に決定することができる。抽出されたタイムスタンプ値が再パーティションのために選択された初期のタイムスタンプ未満である場合には、再パーティショニング前にマッピングを使用し、抽出されたタイムスタンプ値が再パーティションのために選択された初期のタイムスタンプ以上である場合には、再パーティショニング後にマッピングを使用することができる。
ストリーム管理及び処理方法
図１７は、少なくともいくつかの実施形態に従う、ストリームレコード取り込み及びストリームレコード検索のための、プログラマチックインターフェースのそれぞれのセットをサポートするように実行できる動作の態様を示すフロー図である。要素１７０１に示すように、データストリームを作製または初期化するためのリクエストを、例えば、ＳＭＳクライアントまたはデータプロデューサクライアントから受信することができる。ストリームに使用される初期のパーティションマッピングを決定することができる（要素１７０４）。例えば、特定のデータレコードが属するパーティションを特定するのに使用される機能（複数可）、及びその機能（複数可）に使用される入力パラメータを、パーティショニングポリシに基づいて特定することができる。さまざまな実施形態において、前述のように、ＳＭＳの制御コンポーネントは、ストリーム作製リクエストの受信及び応答に関与することができる。ストリーム作製及び初期化（並びに、他の制御プレーン動作）が実施される様式は、実施形態ごとに異なってもよい。一実施形態において、例えば、制御サーバの冗長グループが構築され、そしてその冗長グループのプライマリ制御サーバが、新規のストリームについての適切なメタデータ（例えば、初期のパーティションマッピング、取り込み、保存及び検索のノードの初期のセットなど）を生成して永続的保存場所に保存することによって、ストリーム作製リクエストに応答することができる。ストリームについてのその後のクエリ（例えば、所与のパーティションに関与するバックエンドノードに関するフロントエンド取り込みノードからのリクエスト）に対する応答を、保存されたメタデータを使用してプライマリ制御サーバによって生成することができる。ＳＭＳ制御プレーンの機能性の別の実施では、ストリーム構成メタデータを、取り込み、保存または検索サブシステムの少なくともいくつかのノードによって直接にアクセス可能なデータベースに保存することができる。ストリームが作製及び初期化された後、レコードの提示、保存及び検索などのデータプレーン動作を開始し、通常、制御コンポーネントとの追加の相互作用を必要とせずに対応するサブシステムのそれぞれのコンポーネントによってその動作を処理することができる。
いくつかの実施形態において、明示的なパーティションキーを書き込みリクエストに提示するのにデータプロデューサが必要となり得、他の実施形態では、データプロデューサのアイデンティティ、データレコードがそこから受信されるＩＰアドレス、またはデータレコードのコンテンツそれ自体からなどの、書き込みリクエストに関連するメタデータに基づいて、パーティショニング機能に使用される入力を決定することができる。少なくとも一つの実施において、クライアントは、選択的に、パーティション識別子をデータレコード提示に供給することができ、そのような実施では追加のパーティショニング機能を必要としない。
ストリームについての取り込み、保存及び検索機能のためのノードの初期のセットの決定または構成には、多くの異なるファクタを考慮に入れることができる（要素１７０７）。例えば、（ストリームが分配されるパーティションの数、及びパーティションの相対的な予期されるサイズを決定し得る）パーティションマッピングそれ自体、そのような情報を利用可能である場合に予期される取り込み速度及び／もしくは検索速度についての情報、ストリームデータレコードについての永続性もしくは持続性要件、並びに／または（図９及び図１０に示すものに類似する冗長グループの設定をもたらし得る）さまざまなサブシステムについてのハイアベイラビリティ要件が、異なるサブシステムのノードの数及び配置に影響を与え得る。さらに、クライアントが、（図１１、図１２ａ及び図１２ｂに示すような）ノードのさまざまなカテゴリについての配置宛先タイプの嗜好を示すことができる実施形態では、そのような嗜好も、ＳＭＳ及び／またはＳＰＳノードに使用されるリソースを決定する役割を果たし得る。少なくともいくつかの実施形態では、取り込み、保存及び／または検索機能を実行する能力があるノードのそれぞれのプールを事前に設定することができ、制御コンポーネントは、そのようなプールの選択された一部を、作製された各々の新規のストリームに割り当てることができる。他の実施形態では、少なくとも場合によっては、ストリームが作製または初期化されたときに、新規の取り込み、保存または検索ノードをインスタンス化する必要が生じ得る。
描写した実施形態では、取り込みノードにおいて、レコードを、データレコード提示のために実装されたプログラマチックインターフェースのセットのいずれかを通じて受信することができる（要素１７１０）。このインターフェースは例えば、（提示リクエストにデータが含まれる）インライン提示インターフェース、及び（例えば、ウェブサービスリクエストまたは他のインターフェースを使用して、ＳＭＳ取り込みノードまたはＳＭＳ保存ノードによってそこからデータを検索することができるアドレスが提示リクエストに提供される）照会用提示インターフェースを含む。種々の実施形態において、レコードを提示する様式ごとに、多くの異なるタイプのプログラマチックインターフェースのいずれかを提供することができる。例えば、それぞれのアプリケーションプログラミングインターフェース（ＡＰＩ）が、インライン提示対照会用提示のためにサポートされ得、ウェブページもしくはウェブサイトが構築され得、グラフィカルユーザインターフェースが実装され得、またはコマンドラインツールが展開され得る。少なくともいくつかの実施形態では、ＳＭＳは、例えば、レコードを取り込みまたは保存する順序を表すシーケンス番号を、各々の取り込まれたレコードに割り当てることができる。シーケンス番号は、データコンシューマが検索リクエストのために使用することができる。検索サブシステムのノードにおいて、レコード検索リクエストを、実装されたプログラマチック検索インターフェースのセットのいずれかを通じて受信することができ、そしてそれに応答して、リクエストされたデータレコードのコンテンツを提供することができる（要素１７１３）。非順次アクセスにおいては、インターフェースは、例えば、（ｇｅｔＩｔｅｒａｔｏｒの起動において示されるシーケンス番号に基づいたパーティション内の選択された位置において、イテレータをインスタンス化することをリクエストする）ｇｅｔＩｔｅｒａｔｏｒ、または（指定されたシーケンス番号を持つデータレコードを入手するための）ｇｅｔＲｅｃｏｒｄＷｉｔｈＳｅｑｕｅｎｃｅＮｕｍｂｅｒを含むことができる。順次アクセスにおいては、（イテレータの現在位置または指定されたシーケンス番号から開始される順序で多くのレコードをリクエストする）ｇｅｔＮｅｘｔＲｅｃｏｒｄｓなどのインターフェースを実装することができる。少なくともいくつかの実施形態において、種々の検索インターフェースは、それらに関連する種々の請求率を有することができる。例えば、順次検索のためのレコードあたりの請求率を、非順次検索のためのレコードあたりの請求率未満に設定することができる。いくつかの実施形態において、種々の提示インターフェースも、種々の請求率を有することができる。例えば、照会用提示のレコードあたりの費用を、インライン提示のそれよりも高くすることができる。
経時的に、制御ノードまたは専門の請求サーバが、ストリーム管理サービスのさまざまなサブシステムにおいて実装された種々のプログラマチックインターフェースについての使用メトリクスを収集することができる（要素１７１６）。メトリクスは、例えば、種々のプログラマチックインターフェースの起動回数、（１回の起動によって複数のレコードを検索するように使用できるｇｅｔＮｅｘｔＲｅｃｏｒｄｓなどの少なくともいくつかのインターフェースの起動回数とは異なり得る）取り込みまたは検索されたレコードの総数、取り込みまたは検索されたデータの総量などを含むことができる。ストリームを所有するクライアント、またはストリームからのデータを生産及び／もしくは消費するクライアントへの請求額は、選択的に、使用メトリクス及びプログラマチックインターフェースに関連するそれぞれの請求率に少なくともある程度基づいて生成することができる（要素１７１９）。少なくともいくつかの実施形態では、請求活動は、ストリーム取り込みまたは検索動作と非同期であってもよい。例えば、請求書は、月単位で収集されたメトリクスに基づいて、毎月の請求期間の終わりに生成してもよい。
図１８ａは、少なくともいくつかの実施形態に従う、ストリーム処理（ＳＰＳ）ステージを構成するように実行できる動作の態様を示すフロー図である。要素１８０１に示すように、ストリームデータレコードのための多くの処理ステージをクライアントが構成できるプログラマチックインターフェースを実装することができる。特定のステージを構成するために、例えば、クライアントは、ステージにおいてパーティションされたストリームデータレコードに実行される処理動作（複数可）、処理動作の出力のための分配ポリシ、並びに処理されるデータをそこから入手する入力ストリームのアイデンティティなどの他のパラメータを示すことができる。いくつかの実施形態において、ＳＰＳステージにおける処理動作は、冪等である必要があり得る。他の実施形態では、少なくともいくつかのステージにおいて非冪等動作もサポートすることができる。いくつかの実施形態において、所与のステージにおいて実行される処理が非冪等である場合には、クライアントは、依然として、動作をいくつかの永続性の外部位置に周期的にフラッシュするためのワーカーノードを構成する、レコード検索シーケンスに関するフラッシュ動作を実行したときをレコードする、及びリカバリ中にフラッシュ動作をリプレイするための取り換えワーカーノードを後に構成することによって、リカバリ関連の冪等性の利益を得ることができる。少なくともいくつかの実施形態では、クライアントは、有向非巡回グラフ（ＤＡＧ）、またはいくつかの異なる状態においてストリームデータを並行して動作する処理ステージの他のグラフを構成することができる。いくつかのステージの結果が、他のステージにおいて入力ストリームとして使用される。いくつかの実施形態において、永続的なストリームではなく一つ以上の一時的なストリームを、異なるステージ間に作製することができる。例えば、あるステージから出力されたデータレコードを異なるステージへの入力として送り込む前に、必ずしも永続ストレージデバイスに保存しなくてもよい。
いくつかの実施形態において、チェックポイントベースのリカバリポリシまたはベストエフォートのリカバリポリシなどを含む多くの異なるリカバリポリシのいずれかを、ＳＰＳステージに実装することができる。一実施形態において、クライアントは、種々のＳＰＳステージについてのリカバリポリシを選択するためのプログラマチックインターフェースを使用することができる。チェックポイントベースのリカバリを使用するステージにおいて、ストリームパーティションにおいて到達した進捗の程度を示す進捗レコードまたはチェックポイントを保存するワーカーノードを、間隔を置いて構成できる（例えば、最近に処理されたレコードのシーケンス番号を、進行のインジケータとして保存することができる）。図１９に関して後述するように、進捗レコードは、後に、障害後のリカバリ動作期間に使用することができる。ベストエフォートのリカバリポリシでは、進捗レコードを保存する必要がなく、障害に応答して構成された取り換えワーカーノードが、新規のデータレコードを受信したときにそれを簡単に処理することができる。いくつかの実施形態において、所与のＳＰＳステージグラフまたはワークフロー内において、異なるリカバリポリシを異なるステージに適用することができる。
ＳＰＳ制御サーバは、例えば、要素１８０１において示されたプログラマチックインターフェースのうちの一つを通じて、出力分配記述子ＤＤｅｓｃ１に従い分配される処理結果とともに、パーティショニングポリシＰＰｏｌ１に従いストリームＳ１の特定のステージＰＳ１において実行される冪等動作Ｏｐ１の表示を受信することができる（要素１８０４）。ステージＰＳ１及びノードに必要な仮想または物理リソースのために構成されるワーカーノードの数は、例えば、Ｐｐｏｌ１、冪等動作Ｏｐ１の複雑性、及びワーカーノードのために使用されるリソースの実行能力などのさまざまなファクタに基づいて決定することができる（要素１８０７）。
次に、ワーカーノードを、例えば、選択された仮想または物理マシンリソースにおけるプロセスまたはスレッドとしてインスタンス化及び構成することができる（要素１８１０）。一つの単純な実施において、例えば、一つのワーカーノードを、初期に、Ｓ１のパーティションごとに割り当てることができる。所与のワーカーノードは、（ａ）Ｓ１の検索ノードの適切なサブセットからデータレコードを受信し、（ｂ）受信したデータレコードにＯｐ１を実行し、（ｃ）選択的に、ＰＳ１についてのリカバリポリシに基づいて、パーティションレコードのどのセットが処理されたかを示す進捗レコードまたはチェックポイントを保存し、（ｄ）ＤＤｅｓｃ１によって示された宛先に（例えば、永続的なもしくは一時的なストリームの中間の入力として、または他の処理ステージもしくはストレージシステムに直接に）出力を伝送するように構成できる。少なくともいくつかの実施形態において、ＳＰＳ処理が、継続的にほかの場所に伝送する必要がある任意の出力を必ずしも生成しなくてもよいことに留意されたい。例えば、いくつかのＳＰＳアプリケーションは、データレコードの一時的なリポジトリとしての機能を簡単に果たし、かつ／またはデータレコードをユーザが視認できるクエリインターフェースを実装することができる。そのようなアプリケーションは、例えば、受信したクエリに応答するが、分配記述子には従わない出力を生成するようにその出力を管理することができる。ロギング関連のＳＰＳアプリケーションは、例えば、クライアントがデバッギングまたは解析目的のためにロギングデータを視認することができる、大規模な分散システムから収集された直近日のログレコードを保存することができる。それ故に、いくつかの実施形態において、出力分配記述子は、ＳＰＳの少なくともいくつかのステージ、少なくともいくつかのストリーム、または少なくともいくつかのパーティションに特有である必要はない。次に、ワーカーノードは、それぞれの構成設定の通りのデータレコードの検索及び処理を起動することができる（要素１８１３）。少なくともいくつかの実施形態では、ＳＰＳ制御ノードは、（例えば、ハートビートプロトコルなどの反応性チェックを使用して）ワーカーノードの調子状態、並びにワーカーノードに使用されるリソースのリソース使用レベルなどのさまざまな他のメトリクスを監視することができる（要素１８１６）。ワーカーノードから収集した情報を使用して、ワーカーノードを取り換えるべきか、後述するようなリカバリポリシを実施すべきかなどのフェイルオーバーが必要であるか否かを決定することができる。
いくつかの実施形態において、インストール可能なＳＰＳクライアントライブラリを、クライアント所有の設備、及び／またはクライアント選択のプロバイダネットワークのリソースにＳＰＳワーカーノードを実装することを所望するクライアントに提供することができる。クライアントライブラリによって、ＳＰＳクライアントは、例えば、調子監視機能、自動作業負荷監視及びバランシング、セキュリティ管理、動的再パーティショニングなどの、ＳＰＳ管理サービスのさまざまな制御プレーン特徴の使用を所望する範囲を選択することもできる。図１８ｂは、少なくともいくつかの実施形態に従う、ストリーム処理ワーカーノードの構成のためのクライアントライブラリのコンポーネントの起動に応答して実行できる動作の態様を示すフロー図である。要素１８５１に示すように、ＳＰＳクライアントライブラリを、（例えば、図１８ａに示す種類の動作を実行するように構成可能なマルチテナントＳＰＳ管理サービスのウェブサイトからのダウンロードを通じて）提供することができる。ライブラリは、多くの実行可能コンポーネント、及び／またはクライアントアプリケーションにリンクすることができるコンポーネントを含むことができる。いくつかのライブラリコンポーネントによって、クライアントは、一つ以上のＳＰＳステージのストリーム処理動作を実行できるさまざまなワーカーノードの所望の特質を、選択、ＳＰＳ管理サービスを用いて記録、または指定することができる。例えば、あるクライアントは、ワーカーノードのために、プロバイダネットワークの仮想コンピューティングサービスにおいて実施されるコンピュートインスタンスの自身のセットを使用することを所望し、一方で、別のクライアントは、ストリームレコードの処理のために、クライアントが所有するデータセンタに設置されたコンピューティングデバイス（例えば、プロバイダネットワークによってサポートされない専用デバイス）の使用を所望できる。クライアントは、ワーカーノードを必要に応じてオンラインで特有の設備に届ける、または所望に応じて、仮想コンピューティングサービスのコンピュートインスタンスを使用することができる。ワーカーノードのそのようなオンデマンドのインスタンス化に追加的にまたは代替的に、いくつかの実施形態では、クライアントは、必要に応じて配置することができる、潜在的に再使用可能なワーカーノードのプールを事前設定することができる。いくつかの実施では、その後の制御プレーン動作をＳＰＳ管理サービスによって処理することができるように、クライアントは、ライブラリコンポーネントを実行してまたは呼び出して、指定されたステージのワーカーノードとしてクライアントによってインスタンス化された特定のプロセスまたはスレッドを、ＳＰＳ管理サービスを用いて記録することができる。一実施形態において、クライアントは、ワーカーノードのためのＳＰＳ管理サービスによって処理される種々のレベルの制御プレーン責務の中からそれを選択することもできる。例えば、あるクライアントは、ワーカーノードの調子を監視するために自身のカスタムモジュールの使用を所望し得、別のクライアントは、ワーカーノードの調子を監視し、障害が検出された場合に適切なアクションをとるためにＳＰＳ管理サービスの活用を所望できる。
ＳＰＳ管理サービスは、特定のＳＰＳステージＰＳ１のワーカーノード及び／または制御プレーン動作を構成するためにクライアントライブラリの使用を特定のクライアントが所望することの表示を受信することができる（要素１８５４）。（ＰＳ１それ自体は、ライブラリに含まれるプログラマチックインターフェース、または図４に示すウェブベースのインターフェースに類似するＳＰＳ管理サービスによって公開されるプログラマチックインターフェースを使用して指定することができる。）クライアントは、そのデータがＰＳ１による入力として使用するために検索されるストリームも示すことができる。選択的に、少なくともいくつかの実施形態では、クライアントは、ＰＳ１についての制御プレーン設定、例えば、そのクライアントが、ノードについてのサービスの調子監視機能を使用することを所望するか否か、またはカスタム調子監視ツールを使用することをいとわないか否かを示すことができる（要素１８５７）。クライアントによって示される嗜好に応じて、クライアントが使用するために構成される一つ以上のＳＭＳのノード及び／またはＳＰＳを決定することができる（要素１８６０）。ネットワークの接続性を、クライアントのワーカーノードとＳＭＳ／ＳＰＳノードとの間に確立することができ、かつ／または所望に応じて、データレコードを流し、結果を処理することができる他の構成動作を実行することができる。検索リクエストを受信したときにＳＰ１ワーカーノードにデータレコードを提供でき、そして必要に応じて、（もしクライアントによってリクエストされた場合には）所望の制御プレーン動作を実行することができる。少なくともいくつかの実施形態において、クライアントが、ＳＭＳ管理サービスのさまざまなサブシステムの制御プレーンの機能性の使用を所望する範囲を制御できる類似のアプローチもまたは代わりとして実施できることに留意されたい。
図１９は、少なくともいくつかの実施形態に従う、ストリーム処理のための一つ以上のリカバリポリシを実施するように実行できる動作の態様を示すフロー図である。要素１９０１に示すように、ＳＰＳ制御ノードは、ワーカーノードが無反応もしくは不調となった可能性がある、進行中のノードの作業負荷レベルがフェイルオーバーについての閾値に到達した可能性がある、ワーカーノードにおいて検出されたエラーの数が閾値を超えた可能性がある、またはワーカーノードの何らかの他の予期されない状態が特定された可能性があるなどの、特定のワーカーノードを取り換えるためのトリガ基準が満たされたことを確定することができる。取り換えワーカーノードを特定またはインスタンス化することができる（要素１９０４）。いくつかの実施形態において、そこから取り換えとして選択できる、例えば、またはそこから新規のスレッドもしくはプロセスを立ち上げることができる、利用可能なワーカースレッドのプールを設定することができる。
（要素１９０７において決定されたように）特定のワーカーノードがアクティブであるＳＰＳステージにおいてベストエフォートのリカバリポリシを使用する場合には、取り換えワーカーノードは、それらが利用可能になったときに追加のデータレコードの処理を簡単に開始することができ（要素１９１６）、例えば、取り換えられたワーカーノードの進行のレコードを分析する必要は全くない。チェックポイントベースのリカバリポリシが使用される場合には、取り換えられたワーカーノードによって保存された進捗レコードに、取り換えワーカーノードがアクセスできる位置の表示（例えば、ストレージデバイスアドレスまたはＵＲＬ）を提供することができる（要素１９１０）。取り換えワーカーノードは、取り換えられたノードによって保存された最近の進捗レコードを検索し、その進捗レコードを使用して、取り換えワーカーノードがステージの冪等動作を実行すべきデータレコードのセットを決定することができる（要素１９１３）。そのようなチェックポイントベースのリカバリポリシでは、最後の進捗レコードと取り換えワーカーノードがインスタンス化された時刻との間の期間、並びに取り換えられたワーカーノードが、進捗レコードが保存された後に追加のレコードを処理した速度に応じて、二つ以上のいくつかのデータレコードを処理することができる。少なくともいくつかの実施形態では、実行される動作が冪等である場合には、そのような繰り返しの動作は悪影響を全く受けないことがある。少なくともいくつかの実施形態では、取り換えワーカーノードが、以前に保存された進捗レコードに基づいて繰り返しのリカバリ動作を実行した後に、取り換えワーカースレッドが、リカバリが完了したことを示す自身の進捗レコードを保存し、そして正常なワーカースレッド動作を、新規に受信したデータレコードに開始することができる（要素１９１６）。
図２０は、少なくともいくつかの実施形態に従う、データストリームのための複数のセキュリティオプションを実施するように実行できる動作の態様を示すフロー図である。要素２００１に示すように、例えば、種々の機能別カテゴリのノード（例えば、取り込み、保存、検索、処理または制御ノード）についての配置宛先タイプオプションを含む、データストリーム管理及び処理についての様々なセキュリティオプションからクライアントが選択できる一つ以上のプログラマチックインターフェースを実装することができる。配置宛先タイプは、セキュリティプロファイルのさまざまな態様において互いに異なってもよい。いくつかの実施形態において、ＳＭＳまたはＳＰＳノードに使用されるリソースの物理的な位置は、宛先タイプごとに異なってもよい。例えば、ノードのためにプロバイダネットワークデータセンタに設置されたインスタンスホストなどのリソース、クライアント所有の設備におけるリソース、または第三者リソースを使用することができる。少なくともいくつかの実施形態では、ネットワーク分離レベルまたは他のネットワーキング特性は、宛先タイプごとに異なってもよい。例えば、いくつかのＳＭＳまたはＳＰＳノードを、隔離された仮想ネットワーク内において、または専用の孤立した物理リンクによってプロバイダネットワークに接続されたクライアント所有の設備においてインスタンス化することができる。一実施形態において、クライアントは、これも利用可能なマルチテナントインスタンスホストを使用する代わりに、特定のタイプのＳＭＳまたはＳＰＳノードがプロバイダネットワークのシングルテナントインスタンスホストにおいて確立されたことを示すことができる。少なくともいくつかの実施形態では、さまざまなタイプの暗号化オプションも、セキュリティ関連のプログラマチックインターフェースによって選択することができる。
ストリームＳ１に関する一つ以上の機能別カテゴリのノードについてのクライアントのセキュリティプロファイルの選択または嗜好を、セキュリティ関連のプログラマチックインターフェースを通じて受信することができる。例えば、クライアントは、機能別カテゴリＦＣ１のノードについてあるセキュリティプロファイルを選択し（例えば、クライアントは、クライアント所有の設備にＳＰＳワーカーノードを実装することを所望できる）、そして異なる機能別カテゴリＦＣ２のノードについて異なるセキュリティプロファイルを選択する（例えば、クライアントは、プロバイダネットワークデータセンタにＳＭＳ取り込みノードまたは保存ノードを実装することをいとわないことがある）ことができる（要素２００４）。場合によっては、クライアントは、すべての異なる機能別カテゴリのノードに、同じセキュリティプロファイルを設定することを決定できる。いくつかの実施形態においてＳＭＳ及び／またはＳＰＳは、さまざまな機能別カテゴリについてデフォルト配置宛先タイプを規定することができる。例えば、クライアントが他のものを示さない限り、すべての機能別カテゴリのノードを、プロバイダネットワークの隔離された仮想ネットワーク内に設定することができる。
次に、セキュリティプロファイル及び／または位置についてのクライアントの嗜好に基づいて（または、クライアントが嗜好を提供しないときには機能別カテゴリについてのデフォルト設定に基づいて）、種々の機能別カテゴリのノードを構成することができる（要素２００７）。構成は、例えば、適切な物理ホストまたはマシンの選択、種々の機能別カテゴリのノードについての適切なコンピュートインスタンス、仮想マシン、プロセス及び／またはスレッドについてのインスタンス化、並びにノード間の適切なネットワーク接続の構築を含むことができる。いくつかの実施形態において、構成の一部としてプロバイダネットワーク外部のホストにおけるインストールのために、種々のストリーム管理及び処理機能についての実行可能なライブラリコンポーネントを提供することができる。
少なくともいくつかの実施形態に従い、例えば、クライアントが示した暗号化の嗜好に従い、またはデフォルト暗号化設定に基づいて、ノードの一つ以上のカテゴリにおいて暗号化モジュールをアクティブにすることができる（要素２０１０）。次に、さまざまな機能別カテゴリのノードをアクティブにすることによって、所望に応じて、クライアントによってストリームデータの取り込み、保存、検索及び／または処理を行うことができる（要素２０１３）。
図２１は、少なくともいくつかの実施形態に従う、データストリームのためのパーティショニングポリシを実施するように実行できる動作の態様を示すフロー図である。要素２１０１に示すように、データストリームについてのパーティショニングポリシを決定することができる。ポリシは、例えば、データプロデューサによって供給されたキーまたは提示されたデータレコードのさまざまな属性並びにデータストリームを再パーティショニングするための一つ以上のトリガ基準に基づいた、パーティションへのデータレコードの初期のマッピングを含むことができる。いくつかの実施形態において、例えば、一つ以上のパーティションキーにハッシュ関数を適用し、１２８ビット整数のハッシュ値を生じさせることができる。可能性がある１２８ビット整数の範囲は、ストリームのＮ個のパーティションのうちの一つにその各々が相当するＮ個の隣接するサブ範囲に分割することができる。いくつかの実施形態において、サブ範囲のパーティションの数及び／または相対的サイズは、ストリームごとに異なってもよい。少なくともいくつかの実施形態では、クライアントは、自身のストリームを構成するために、所望のパーティションの数、または使用されるパーティショニング機能の所望の特性などの、使用するパーティショニングスキームについての入力を提供することができる。少なくとも一つの実施形態では、クライアントは、提示されたデータレコードのいくつかのサブセットまたはすべてについてのパーティション識別子またはパーティション名を提供することができる。
ストリームのデータレコードを受信すると、供給されたキー及び／または他の属性に基づいてそれぞれのパーティションを決定し、特定されたパーティションについての取り込み、保存及び検索ノードの適切なセットを選択することができる（要素２１０４）。少なくともいくつかの実施形態では、例えば、所与のパーティションのレコードが受信されたシーケンスを示す、データレコードについてのそれぞれのシーケンス番号を生成することができる（要素２１０７）。いくつかの実施では、シーケンス番号は、タイムスタンプ値（例えば、１９７０年１月１日の００：００：００ＵＴＣなどの既知のエポックから経過した秒数）、保存サブシステムから入手したサブシーケンス値、ＳＭＳソフトウェアのバージョン番号、及び／またはパーティション識別子などの多くの要素を含むことができる。いくつかの実施形態において、例えば、提示されたデータレコードの成功裏の取り込みを通知するために、データプロデューサにシーケンス番号を提供することができる。いくつかの実施形態において、シーケンス番号は、ストリームまたはパーティションのデータレコードを取り込み順序で検索するためにもデータコンシューマによって使用することができる。
少なくともいくつかの実施形態では、パーティショニングポリシに基づいて、データレコードが導かれた保存ノードに、そのデータレコードをシーケンス番号順に保存することができる（要素２１１０）。回転磁気ディスクストレージデバイスが使用される実施形態では、通常、受信したデータレコードをディスクにセーブするのに順次書き込みを使用することによって、ディスクの探し出しに要する待ち時間を回避することができる。少なくともいくつかの実施において、例えば、ディスクの探し出しの見込みをさらに減少するために、レコードをディスクに保存する前に、不揮発性バッファを書き込みキャッシュとして使用することができる。シーケンス番号によって順序付けられた複数のデータレコードを読み出す（例えば、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓまたは類似のインターフェースを起動する）ためのリクエストに応答して、後に、ストレージデバイスからの順次読み出しを使用してデータレコードを読み出すことができる（要素２１１３）。
図２２は、少なくともいくつかの実施形態に従う、データストリームの動的再パーティショニングを実施するように実行できる動作の態様を示すフロー図である。要素２２０１に示すように、（例えば、ＳＭＳまたはＳＰＳの制御コンポーネントにおいて）ストリームを動的に再パーティションすることを決定できる。取り込み、保存、検索、処理または制御ノードの一つ以上における過負荷の検出、種々のノードの作業負荷レベルにおけるアンバランスの検出、またはクライアント（例えば、データプロデューサまたはデータコンシューマ）から受信できる再パーティショニングリクエストなどの多くの異なるトリガ条件によって、ストリームを再パーティションすることを決定できる。いくつかの実施では、クライアントの再パーティショニングリクエストは、生成される変更されたマッピングのさまざまなパラメータなどの、リクエストされた再パーティショニングの具体的な詳細（例えば、追加または削除するパーティションの数、どの具体的なパーティションを結合または分割すべきかなど）を含むことができる。一つの実施において、クライアントの再パーティショニングリクエストは、クライアントが解決を所望する問題のある状態（例えば、負荷アンバランス）を示すことができ、そしてＳＭＳまたはＳＰＳは、適切な再パーティショニング動作における問題のある状態の記述の翻訳に関与することができる。場合によっては、再パーティショニングをリクエストする、または問題のある状態を記述する代わりに、クライアントは、再パーティショニングに使用するトリガ基準を指定することができる。いくつかの実施形態において、データストリームのデータ永続性要件に対する変更を決定することによって再パーティショニングをトリガし、例えば、ストリームレコードについてのストレージデバイスの異なるセットまたは異なる保存技術を選択することができる。場合によっては、データストリームの使用パターン（例えば、データレコードが生産または消費される速度）の変更を検出することによっても再パーティショニングを起こすことができ、これはまた、変更された使用パターンに、より適切な異なる保存技術またはストレージデバイスの異なるセットを使用することもできる。例えば、再パーティションの決定は、所与のパーティションまたはストリーム全体について予期される読み出し及び書き込みの速度についての決定に基づき得、ＳＳＤが、回転磁気ディスクよりも適切な保存技術であり得る。一実施形態において、スケジュールされたまたは差し迫ったソフトウェア及び／またはハードウェアバージョン変更によって、再パーティショニングをトリガすることができる。場合によっては、クライアントが、保存についての異なるパーティショニングアプローチ、または異なるアプローチを使用するときにより有効に満足し得る予算制約を示すときには、価格または請求額を考慮して再パーティショニングをトリガすることができる。少なくともいくつかの実施形態では、性能目標の変更によっても、再パーティショニングをトリガすることができる。図２２に描写する実施形態では、再パーティショニング後に割り当てられたシーケンス番号に使用される初期タイムスタンプ値（例えば、１９７０年１月１日の００：００：００ＵＴＣからの秒数の補正値、通常、いくつかのオペレーティングシステムにおけるシステムコールによって利用可能なエポック値）を選択することができる（要素２２０４）。いくつかの実施では、プロバイダネットワークに実装されたグローバル状態マネージャが、ｇｅｔＥｐｏｃｈＶａｌｕｅ ＡＰＩをサポートし、これにより例えば、ＳＭＳ及び／またはＳＰＳのさまざまなコンポーネントは、シーケンス番号生成に使用される一貫性のあるタイムスタンプ値を入手できる。他の実施では、他の時間ソースを使用することができる。例えば、ＳＭＳまたはＳＰＳ制御ノードを、一貫して順序付けられたタイムスタンプ値を他のコンポーネントに提供するように用意する、またはローカルシステムコールの起動を使用することができる。いくつかの実施形態において、タイムスタンプ値は、必ずしも、任意の特定のホストにおける掛け時計の時間に対応しなくてもよい。例えば、単調に増大する整数カウンタ値を簡単に使用してもよい。
再パーティショニングの決定時に使用されるマッピングとは異なる、ストリームについての、変更されたパーティションマッピングを生成することができる（要素２２０７）。少なくともいくつかの実施形態では、変更されたマッピングにおいて、特定のパーティションキーを持つデータレコードを、再パーティショニング前にマッピングされた同じキーを持つデータレコードとは異なるパーティションにマッピングすることができる。再パーティショニングについてのトリガ条件及び／または観測された作業負荷メトリクスに応じて、いくつかのパーティション（通常、頻繁に使用されるパーティション）を分割し、その一方で、他の（通常、あまり使用されない）パーティションを統合することができる。いくつかの実施形態において、再パーティショニング前ではなく再パーティショニング後に、異なるパーティショニング機能を使用することができる。例えば、異なるハッシュ関数、またはハッシュ関数結果のパーティションへの再分割についての異なるアプローチを使用することができる。例えば、パーティションが１２８ビット整数の隣接範囲に対応するいくつかの実施では、１２８ビット整数空間を、再パーティショニング後に、サブ範囲の異なるセットに分配することができる。少なくともいくつかの実施形態では、取り込み、保存、検索、処理または制御ノードの新規のセットを、新規に作製されたパーティションに割り当てることができる。いくつかの実施では、空間効率のよい組み合わせのデータ構造を使用して、初期のマッピング及び変更されたマッピングの両方を示すことができる（要素２２０８）。例えば、各入力がパーティショニング機能出力範囲（例えば、所与のパーティションに対応するパーティショニングハッシュ関数の結果の範囲）、及び有効時間範囲の表示を含むことによって、変更されたパーティションに対応するレコードのみを再パーティショニングの結果として修正する必要がある有向非巡回グラフまたはツリー構造を保存することができる。再パーティショニング中に変更されないパーティションの入力については、データ構造を変更しなくてもよい。新規のノードは、変更されたパーティションマッピングを実施するように構成できる（要素２２１０）。少なくともいくつかの実施形態では、先のマッピングに基づいて保存されたデータレコードについての検索リクエストの受信を少なくともいくらかの時間継続できるので、以前のノード及び以前のマッピングをいくらかの時間保持することができる。特定のシーケンス番号またはタイムスタンプを指定する読み出しリクエストが受信される（要素２２１３）と、新規のパーティションマッピングまたは以前のパーティションマッピングを使用して、読み出しリクエストが満たされたか否かについての決定を（例えば、制御ノードまたは検索ノードにおいて）為すことができる。次に、選択されたマッピングを使用して、リクエストされたデータをそこから入手する適切な保存ノードを特定することができる。
図２３は、少なくともいくつかの実施形態に従う、データストリームレコードのための少なくとも１回レコード取り込みポリシを実施するように実行できる動作の態様を示すフロー図である。要素２３０１に示すように、いくつかの取り込みポリシオプションの中から、データストリームについてのレコード取り込みポリシをクライアントが選択できる一つ以上のプログラマチックインターフェースを実装することができる。このオプションは、例えば、（ａ）肯定応答が受信されるまで１回以上レコード提示者がレコードを提示することに従う少なくとも１回ポリシ、または（ｂ）少なくともいくつかのレコード提示に対して応答が提供されないことに従うベストエフォート取り込みポリシを含む。一部のデータ生産クライアントは、他のアプローチのように、レコードのごく一部分の損失の可能性について憂慮しなくてもよく、したがって、ベストエフォート取り込みアプローチを選ぶことができる。いくつかの実施では、ベストエフォート取り込みのために構成されたストリームでさえも、ＳＭＳは、それでもなお、いくつかのデータレコードのサブセットについての応答を提供し、さらには、ベストエフォートポリシがあらゆるデータレコードについての応答を必要としない場合でさえも、すべてのデータレコードについての応答の提供を試みることができる。
指定されたストリームにおいて使用される特定の取り込みポリシを示すリクエストを、プログラマチックインターフェースの一つを通じて受信することができる（要素２３０４）。取り込みノードは、ストリームに実施されるパーティショニングポリシに従いインスタンス化することができる（要素２３０７）。同じデータレコードの一つ以上の提示が取り込みノードにおいて受信される（要素２３１０）と、実施される取り込みポリシに応じて種々のアクションをとることができる。（要素２３１３において決定されるような）少なくとも１回取り込みポリシが使用される場合には、一つ以上の提示の各々についての応答がデータプロデューサに送信され得るが、データレコードは、保存サブシステムに１回のみセーブすればよい（２３１６）。（ストリームにおいて実施される持続性ポリシに従い、場合によっては所与のレコードのＮ個のレプリカを保存できるが、所与のデータレコードがＭ回提示された場合には、レプリカは、提示のうちの一つについてのみ生成すればよい、すなわち、レコードレプリカが保存される総数が、Ｎ×Ｍ個ではなく、それでもなおＮ個であることに留意されたい。）（これも要素２３１３において検出されるような）ベストエフォート取り込みポリシが実施される場合には、ここでもなお、データレコードは、ストレージデバイスに１回セーブされ得るが、応答をデータプロデューサに送信する必要はない（要素２３１９）。少なくともいくつかの実施形態では、クライアントの請求額は、選択的に、選択された取り込みポリシに少なくともある程度基づいて決定することができる（要素２３２２）。前述したように、いくつかの実施形態において、少なくとも１回取り込みポリシの二つのバージョンをサポートすることができる。図２３に示すものに類似する一つのバージョンでは、ＳＭＳは、データレコードの重複排除に関与することができる（すなわち、データが、二つ以上の提示のセットのうちの一つのみに応答してＳＭＳ保存サブシステムに保存されることが保証される）。少なくとも１回取り込みの異なるバージョンでは、ＳＭＳによるデータレコードの重複を許可することができる。後者のアプローチは、データレコード重複の否定的な結果が少ないもしくは全くないストリームアプリケーション、及び／または自身で重複削除を実行するストリームアプリケーションに有用であり得る。
図２４は、少なくともいくつかの実施形態に従う、データストリームのための複数の持続性ポリシを実施するように実行できる動作の態様を示すフロー図である。要素２４０１に示すように、複数の持続性ポリシの中から、ストリームデータレコードについての持続性ポリシをクライアントが選択できる一つ以上のプログラマチックインターフェースを実装することができる。持続性ポリシは、さまざまな事項のいずれかに関して互いに異なってもよい。例えば、（ａ）セーブされるレプリカの数は異なってもよい（例えば、Ｎ個のレプリカポリシ、２つのレプリカポリシまたは１つのレプリカポリシをサポートすることができる）、（ｂ）使用される保存場所またはデバイスタイプ（例えば、回転磁気ディスク、ＳＳＤ、ＲＡＭ、またはデータベースサービスもしくはマルチテナントストレージサービス）は、異なってもよい、かつ／または（ｃ）ポリシは、大規模な障害に対する予期される回復力の範囲内において異なってもよい（例えば、マルチデータセンタポリシ、または単一データセンタポリシをサポートすることができる）。指定されたストリームについての特定の持続性ポリシのクライアントの選択を示すリクエストを受信することができる（要素２４０４）。いくつかの実施形態において、クライアントによって選択された持続性ポリシに応じて、所与のストリームのそれぞれのパーティションのために種々の保存場所タイプまたはデバイスタイプを使用することができる。一実施形態において、クライアントではなくＳＭＳが、ストリームレベルまたはパーティションレベルのいずれかに応じて、保存場所タイプまたはデバイスタイプを選択することができる。いくつかの実施形態では、クライアントは、いくつかの実施形態において持続性ポリシを選択するときに、データ永続性目標及び／または性能目標（例えば、所望の読み出しまたは書き込みのスループットまたは待ち時間）を示すことができる。そしてこれらの目標を、適切なストレージデバイスタイプまたは位置を選択するために、ＳＭＳによって使用することができる。例えば、低遅延が所望される場合には、一つ以上のパーティションまたはストリームのデータレコードを保存するために、回転磁気ディスクの代わりにＳＳＤを使用することができる。
取り込みノードのセットを、データプロデューサから選択されたストリームのデータレコードを受信するように決定または構成し、保存ノードのセットを、選択された持続性ポリシを実施するように構成できる（要素２４０７）。データレコードが取り込みノードにおいて受信される（要素２４１０）と、データレコードの一つ以上のコピーを、選択された持続性ポリシに基づいて、データレコードが属するパーティションに関与する保存ノードによって、選択されたストレージデバイスに保存することができる（要素２４１３）。少なくともいくつかの実施において、選択的に（かつ／または非同期に）、クライアントによって選択された具体的な持続性ポリシに基づいて請求額を決定することができる（要素２４１６）。
ストリーム処理のための分散的作業負荷管理
いくつかの実施形態において、ＳＰＳの制御プレーンの機能性のかなりの部分またはすべては、例えば、データベーステーブルなどの共有データ構造を通じてさまざまな制御動作（例えば、ワーカーノードへのパーティションの割り当て、動的再パーティショニングに対する応答、調子の監視及び／または負荷バランシング）を調整する、所与のＳＰＳステージ内のワーカーノードによって、分散的様式において実施することができる。所与のワーカーノードＷ１が、共有データ構造内の入力を検査して、例えば、ステージの入力ストリームのどのパーティションが、（もしそうであれば）現在処理されていないかを決定することができる。そのようなパーティションＰ１が発見された場合には、Ｗ１は、共有データ構造内の入力を更新して、Ｗ１がステージの処理動作をＰ１のレコードに実行することを示すことができる。他のワーカーノードは−Ｐｌレコードを処理するためにＷ１が割り当てられたことを知り、したがって、それら自身に異なるパーティションを割り当てることができる。ワーカーノードは、周期的にまたは時々、入力ストリームに有効な進行中のパーティションマップを決定するためのクエリをＳＭＳ制御プレーンに提示し、必要に応じて、（例えば、再パーティショニングの結果として）マップ変更を示すために共有データ構造を更新することができる。後述するように、さまざまな実施形態において、共有データ構造を通じて負荷バランシング及び他の動作も調整することができる。いくつかのそのような分散的な実施では、ＳＰＳのための専用の制御ノードを必要としないので、ＳＰＳワークフローを実施するのに必要な諸経費を減少することができる。そのような分散的なＳＰＳ制御プレーンの実装は、例えば、顧客に割り当てられたプロバイダネットワーク内の、またはプロバイダネットワーク外部に位置するコンピュートインスタンスにおいてさまざまな態様のストリーム処理を実施するためにＳＰＳクライアントライブラリを活用する予算意識の高い顧客に特に好評であり得る。分散的なＳＰＳ制御プレーン技術は、例えば、ＳＭＳ及びＳＰＳに使用されるすべてのリソースがプロバイダネットワーク内に構成されるときに、クライアントライブラリを使用しない実施形態にも使用することができる。ワーカーノードが少なくともいくつかの処理ステージについてのＳＰＳ制御プレーン機能のいくつかまたはすべてを実施するＳＰＳは、本明細書において「分散的制御ＳＰＳ」と称され得る。
図２５は、少なくともいくつかの実施形態に従う、処理ステージのワーカーノードがデータベーステーブルを使用して作業負荷を調整するストリーム処理システムの実施例を示す。分散的制御ＳＰＳ２５９０内において、ワーカーノードのそれぞれのセットをその各々が有する二つのステージ２１５Ａ及び２１５Ｂが画定される。ステージ２１５Ａは、ワーカーノード２５４０Ａ及び２５４０Ｂを備えており、ステージ４１５Ｂは、ワーカーノード２５４０Ｋ及び２５４０Ｌを備えている。各ステージ２１５Ａ及び２１５Ｂにおいて、ステージ２１５ＡのためのＰＡテーブル２５５０Ａ及びステージ２１５ＢのためのＰＡテーブル２５５０Ｂなどの対応するパーティション割当（ＰＡ）テーブル２５５０が、データベースサービス２５２０において作製される。いくつかの実施形態において、所与のステージのためのＰＡテーブル２５５０は、例えば、クライアントライブラリコンポーネントまたは機能の起動に応答して、ステージ初期化中に作製することができる。各ＰＡテーブル２５５０には、ステージの入力ストリームが割り当てられていないパーティション（すなわち、ワーカーノードが現在全く割り当てられていないパーティション）を表す入力または行の初期セットを投入することができる。ＰＡテーブル入力の実施例の列または属性を、図２６に示し、後述する。ステージにおいて立ち上げられたワーカーノード２５４０（例えば、コンピュートインスタンスまたは他のサーバにおいて立ち上げられたプロセスもしくはスレッド）には、ステージのＰＡテーブルへの読み出し／書き込みアクセスが付与され得る。ワーカーノードからＰＡテーブルに導かれる読み出し及び書き込みは、図２５において、それぞれ、ワーカーノード２５４０Ａ、２５４０Ｂ、２５４０Ｋ及び２５４０Ｌに対応する矢印２５６４Ａ、２５６４Ｂ、２５６４Ｋ及び２５６４Ｌによって表される。
所与のワーカーノード２５４０は、ＰＡテーブルにおける入力を調査することによってステージの処理動作を実行するための特定のパーティションを選択するように構成できる。一つの実施において、ワーカーノード２５４０Ａは、割り当てられていないパーティションＰｋの入力を見つけるまで、ＰＡテーブルにおける入力２５５０Ａを走査し、そして入力を更新する、例えば、ワーカーノードの識別子を入力の列のうちの一つに挿入することによって、パーティションＰｋをそれ自身に割り当てることを試みることができる。そのような挿入は、ワーカーノードによってパーティションをロッキングすることに類似するとみなされ得る。使用されるデータベースサービスのタイプに応じて、（例えば、ほぼ同じペースで、割り当てられていないパーティションをたまたま特定する二つ以上のワーカーノードによって）ＰＡテーブル入力に可能性として並行して書き込むことを管理する異なるアプローチを使用することができる。
一実施形態において、プロバイダネットワークの非リレーショナルマルチテナントデータベースサービスを使用することができる。これは、リレーショナルデータベーストランザクション意味論を必ずしもサポートせず、強い一貫性の及び条件付き書き込み動作をサポートする。条件付き書き込み動作は、ワーカーノードによって更新される場合に使用することができる。ＰＡテーブルにおけるパーティションに割り当てられた特定のワーカーノードの識別子を示すのに列「ワーカーノードＩＤ」が使用される実施例を考慮すると、パーティションにワーカーノードが全く割り当てられない列の値は、「ゼロ」に設定される。そのようなシナリオでは、識別子ＷＩＤ１を持つワーカーノードは、以下の論理等価をリクエストすることができる。「パーティションＰｋについての入力においてワーカーノードＩＤがゼロである場合には、その結果、その入力についてのワーカーノードＩＤをＷＩＤ１に設定する」。そのような条件付き書き込みリクエストが成功した場合には、識別子ＷＩＤ１を持つワーカーノードは、そこにパーティションＰｋが割り当てられたことを推測することができる。次に、ワーカーノードは、例えば、矢印２５５４（例えば、それぞれ、ワーカーノード２５４０Ａ、２５４０Ｂ、２５４０Ｋ及び２５４０Ｌに対応する矢印２５５４Ａ、２５５４Ｂ、２５５４Ｋ及び２５５４Ｌ）に示すように、ＳＭＳ検索サブシステム２０６のレコード検索インターフェースを使用して、パーティションＰｋのデータレコードの検索を開始し、検索されたレコードに処理動作を実行することができる。条件付き書き込みが失敗した場合には、ワーカーノードは、別の割り当てられていないパーティションについての探索を再開することができる。他の実施形態では、トランザクションをサポートするデータベースサービス（例えば、リレーショナルデータベース）を使用し、そしてトランザクション機能性を使用して、条件付き書き込み動作と同等のものを実施することができる。例えば、パーティションをワーカーノードに割り当てるための複数の並行（または、ほぼ並行）の試みのうちの一つのみが成功し、そのような並行の試みに関与したワーカーノードが、それらの成功または失敗を確実に通知されることが保証される。いくつかの実施形態において、条件付き書き込みもトランザクションサポートにも依存しない同期技術を使用することができる。いくつかの実施では、データベースサービスを使用せず、代わりに、ＰＡテーブルに類似する永続的データ構造における入力を更新するための排他的アクセスを取得するために、ワーカーノードによってロッキングサービスを使用することができる。
他のワーカーノード２５４０は、ＰＡテーブルにおける入力を分析し、どのパーティションが割り当てられていないかを決定し、一つ以上のパーティションをそれ自身に割り当てることに最終的に成功することができる。このようにして、ステージの一つ以上の入力ストリームのパーティションについての処理作業負荷を、最終的に、ステージのワーカーノードによってそれら自身の中で分配することができる。
任意の所与のストリームの初期のパーティションマッピングは、例えば、前述の動的再パーティショニング動作の結果として経時的に変更することができる。それ故に、図２５に描写する実施形態では、ワーカーノード２５４０の一つ以上が、時々（または、後述するようなトリガ条件に応答して）、進行中のパーティションメタデータを入手するためのリクエストを、ステージの入力ストリーム（複数可）のＳＭＳ制御サブシステム２１０に提示することができる。いくつかの実施では、そのようなリクエストは、矢印２５４４Ａ、２５４４Ｂ、２５４４Ｋ及び２５４４Ｌによって示されるｇｅｔＳｔｒｅａｍＩｎｆｏ ＡＰＩの起動などのＳＭＳ制御プレーンＡＰＩの起動を含むことができる。ＳＭＳ制御サブシステムは、例えば、ストリームのパーティションの最新リスト、及び／またはパーティションの有効な期間などの他の詳細に応答することができる。ＳＭＳ制御サブシステム２１０によって提供されるパーティション情報がＰＡテーブルにおける入力に一致しない場合には、例えば、ワーカーノードによって、一つ以上のパーティションについての入力を挿入または削除することによってＰＡテーブルを変更することができる。少なくともいくつかの実施形態では、ＳＭＳ制御サブシステムへのそのようなリクエスト２５５４は、通常、矢印２５５４Ａのラベル「低頻度」に示すように、レコード検索リクエスト２５５４（及び／または、データベース読み出しまたは書き込み動作２５６４）よりも遥かに頻度が少なくなり得る。例えば、パーティションが一旦割り当てられると、ワーカーノードは、通常、パーティションデータが完全に消費されるまで（例えば、ストリームの所有者がストリームを閉じる場合、または動的再パーティショニングの結果としてパーティションが閉じられる場合）、または何らかの他の可能性が低い状況に直面するまで（例えば、後述するように、別のワーカーノードが、検出された負荷アンバランスの故に、パーティションの転送をリクエストする場合）、そのパーティションのデータレコードの検索及び処理を維持することができる。それ故に、さまざまな実施形態においてｇｅｔＳｔｒｅａｍＩｎｆｏまたは類似のＡＰＩの起動に関連する諸経費は、通常、（ステージの入力ストリームに何百または何千ものパーティションが画定される場合のように）任意の所与の起動に応答してかなりの量の情報が提供される場合でさえも、極めて小さくすることができる。
それ故に、図２５に描写する実施形態では、分散的制御ＳＰＳ環境のキー作業負荷管理動作のいくつかは、次の通りに要約することができる。すなわち、（ａ）ストリーム処理ステージの第一のワーカーノードによるデータベーステーブルへのアクセスに少なくともある程度基づいて、そのステージに関して特徴づけられた処理動作のセットを実施するための、ストリーム処理ステージの入力データストリームの特定のパーティションを選択し、（ｂ）テーブルに保存される特定の入力に、第一のワーカーノードへの特定のパーティションの割り当てのインジケータを書き込み、（ｃ）第一のワーカーノードによって、マルチテナントストリーム管理サービスに実装されたプログラマチックレコード検索インターフェースを使用して、特定のパーティションのレコードを検索し、（ｄ）第一のワーカーノードによって、処理動作のセットを特定のパーティションのレコードに実施し、（ｅ）第二のワーカーノードによって、特定のデータベーステーブルにおける特定の入力に少なくともある程度基づいて、処理動作のセットを特定のパーティションに実行するのに割り当てられる第一のワーカーノードを決定し、（ｆ）第二のワーカーノードによって、処理動作のセットを実行するための異なるパーティションを選択する。ワーカーノードが、そこに割り当てられたパーティションにレコードがそれ以上保持されないことを決定した場合及び時に、ワーカーノードは、ＳＭＳ制御サブシステムから入力ストリームにおけるメタデータをリクエストし、メタデータが不一致を示す場合には、ＰＡテーブルを更新することができる。
図２６は、少なくともいくつかの実施形態に従う、作業負荷調整に使用されるパーティション割当テーブル２５５０に保存できる実施例の入力を示す。示すように、テーブル２５５０は、四つの列、すなわち、パーティション識別子列２６１４、割り当てられたワーカーノード識別子列２６１８、ワーカーノード調子インジケータ列２６２０、及び作業負荷レベルインジケータ列２６２２を備えることができる。他の実施では、他の列のセットを実装することができる。例えば、いくつかの実施形態では、パーティション作製時間またはパーティショニング機能出力値範囲を表す列を使用することができる、または作業負荷レベルインジケータ列を使用しなくてもよい。
いくつかの実施形態において、ＳＭＳ制御サブシステムによって（例えば、パーティション入力ツリー、グラフまたは他の前述の組み合わせのデータ構造の一部として）維持されるパーティションリスト２６５０が、少なくともある時点において、ＰＡテーブル２５５０に含まれるよりも多くのパーティションを含み得ることに留意されたい。描写した実施例では、パーティションリスト２６５０は、パーティションＰ１、Ｐ２、Ｐ３、Ｐ４及びＰ５を含み、そのうちＰ１及びＰ４が再パーティショニングの結果として閉じられた状態において示され、一方で、Ｐ２、Ｐ３及びＰ５がアクティブ（すなわち、現在、そのデータレコードが検索及び処理されているパーティション）として示される。描写した実施形態では、ＰＡテーブル２６５０は、アクティブパーティションについての入力を含み、閉じられたパーティションについての入力は含まない（例えば、再パーティショニングが実行された後のｇｅｔＳｔｒｅａｍＩｎｆｏ起動に対する応答を入手したときにワーカーノードによって削除され得る）。少なくともいくつかの実施では、ストリームの現在開かれているパーティションのすべてが、必ずしも所与の時点においてＰＡテーブルにおけるそれぞれの入力を有さなくてもよい。代わりに、例えば、現在割り当てられているまたは処理されているそれらのパーティションのサブセットのみを示してもよい。
図２６に示す実施例のシナリオでは、パーティションＰ１及びＰ２は、それぞれ、識別子Ｗ７及びＷ３を持つワーカーノードに割り当てられ、一方で、Ｐ５は、現在、割り当てられていない。種々の実施において、調子インジケータ列２６２０は、異なるタイプの値を保存することができる。いくつかの実施では、ワーカーノードは、ワーカーノードがアクティブであり、検索及び処理動作を継続できることを示すために、割り当てられたパーティションのＰＡ入力における調子インジケータ列のコンテンツの更新に周期的に（例えば、Ｎ秒ごとに１回、またはヒューリスティックのいくつかのセットに基づくスケジュールに従い）関与することができる。図２６において、ワーカーノードがその入力について調子インジケータ列を更新した最近の時刻（「最終変更時刻」）の表示を保存することができる。例えば、ワーカーＷ７は、２０１３年１２月１日の０２時２４分５４秒５３に入力が変更されたものとして示される。いくつかの実施形態において、他のワーカーノードは、最終変更時刻の値を使用して、割り当てられたワーカーノードの調子がよいか否かを決定することができる。例えば、ステージについてのフェイルオーバーポリシに規定されているように、Ｘ秒または分が経過した場合には、割り当てられたワーカーノードは、不調またはアクセスできないと考えられ得、パーティションを再び割り当てることができる。他の実施では、カウンタを調子インジケータとして使用することができる（例えば、カウンタ値がＹ秒の間に変化しなかった場合には、割り当てられたワーカーノードがフェイルオーバーを行う候補と判断することができる）、または割り当てられたワーカーノードが入力を最後に読み出したときを示す「最終読み出し時刻」の値を使用することができる。
少なくともいくつかの実施形態では、例えば、ある程度最近の期間（例えば、最終変更時刻前の５分間）に処理されたレコードの数、ＣＰＵ使用レベル、メモリ使用量、ストレージ使用量などの、ワーカーノードの最近の性能関連メトリクスなどの作業負荷レベルインジケータ値２６２２を、例えば、割り当てられたワーカーノードによって入力に保存することができる。いくつかの実施形態において、そのような作業負荷レベルインジケータ値は、図２９に関して後述するように、負荷アンバランスが存在するか否か、及び検出されたアンバランスに応答してアクションをとるか否かを決定するために、ワーカーノードによって使用することができる。例えば、ワーカーノードＷｋは、その作業負荷レベルが平均作業負荷レベルを上回ることを決定し、そしてそのパーティションの一つに割り当てないことができる、または動的再パーティショニングをリクエストすることができる。代替的に、ワーカーノードＷｋは、その作業負荷が他のワーカーノードまたはパーティションのそれと比較して過度に低いことを決定し、追加のパーティションをそれ自身に割り当てることができる。それ故に、描写した実施形態では、図２６に示すＰＡテーブルの列を使用して、ワーカーノードは、通常、集中制御ＳＰＳの実装における専用のＳＰＳ制御ノードによって実行できる同じタイプの制御プレーン機能のいくつかを実行することができる。
図２７は、少なくともいくつかの実施形態に従う、そこにおいて処理動作を実行するためのパーティションを選択するための、ストリーム処理ステージのワーカーノードによって実行できる動作の態様を示す。要素２７０１に示すように、ＰＡテーブルＰＡＴ１は、分散的制御ＳＰＳ処理ステージＳＰ１におけるデータベースサービスにおいて初期化することができる。テーブルは、例えば、クライアント設備におけるホスト、またはプロバイダネットワークデータセンタにおけるコンピュートインスタンスなどからＳＰＳクライアントライブラリコンポーネントが呼び出されたときに作製することができる。クライアントライブラリは、さまざまな目的のために使用することができる。例えば、ＳＰＳステージにおいて実施される特定の処理動作のための、ＪＡＲ（Ｊａｖａ（商標）アーカイブ）ファイルなどの実行可能コンポーネントを提供するため、ワーカーノードの特定に使用できるラベル（例えば、プログラム名、プロセス名またはコンピュートインスタンス名）を示すため、ステージについての入力として使用されるストリームを示すため、（もしあれば）ステージの出力宛先を示すためなどに使用することができる。いくつかの実施形態において、ＰＡＴ１は、初期に、ステージの入力ストリーム（複数可）において規定されたパーティションの少なくともサブセット（Ｐ１、Ｐ２〜）についての入力または行を満たすことができる。いくつかの実施では、テーブルは、初期には空欄であってもよく、一つ以上のワーカーノードが、例えば、ＳＭＳ制御サブシステムからのパーティションメタデータの入手の結果として、割り当てられていないパーティションについてのテーブルの行を満たしてもよい。ワーカーノードの初期セット（Ｗ１、Ｗ２〜）は、例えば、プロバイダネットワーク内のさまざまなコンピュートインスタンス、またはクライアント所有のコンピューティングデバイスにおいて立ち上げることができる（要素２７０４）。描写した実施形態では、ワーカーノードには、ＰＡＴ１への読み出し及び書き込みアクセスが付与され得る。
ワーカーノードがオンライン化されると、それらの各々は、割り当てられていないパーティションの発見を試みるために、ＰＡＴ１にアクセスすることができる。例えば、ワーカーノードＷ１は、ＰＡＴ１を分析して、パーティションＰ１が割り当てられていないことを発見することができる（要素２７０７）。次に、Ｗ１は−ＰｌがＷ１に割り当てられたことを示すために、使用されるデータベースサービスのタイプに応じて、例えば、条件付き書き込みリクエストまたはトランザクションの更新リクエストを使用して、ＰＡＴ１におけるＰ１の入力を更新することができる（要素２７１０）。Ｗ１は、テーブルを更新すると、ＳＭＳ検索サブシステムインターフェースを使用して−Ｐｌのデータレコードの検索を起動し（要素２７１３）、検索されたレコードにステージの処理動作ＰＳ１を実行することができる。
それと同時に、ある時点において、異なるワーカーノードＷ２が、割り当てられていないパーティションを発見するために、自身の試みにおいてＰＡＴ１にアクセスすることができる（要素２７１６）。Ｗ２は、Ｗ１のより先の更新に基づいて−Ｐｌは既に割り当てられているが、異なるパーティションＰ２が割り当てられていないことを決定することができる。いくつかの実施形態において、Ｐ２の現在割り当てられているワーカーノードが不調または非アクティブであることの（例えば、Ｐ２の入力における調子インジケータ列に基づく）Ｗ２による決定によっても、Ｗ２はＰ２を選択することができる。それ故に、少なくともいくつかの実施形態では、進行中のワーカーノードの割り当てられていない状態または不健全な状態の決定のいずれかを使用して、再割り当て（または、初期の割り当て）のための所与のパーティションを選択することができる。次に、Ｗ２は、Ｐ２をそれ自身に割り当てるためのＰＡＴ１の更新を試みることができる（要素２７１９）。更新が成功した場合には、Ｗ２は、ＳＭＳ検索インターフェースを使用してＰ２レコードの検索を開始し（要素２７２２）、ステージについての規定された適切な処理動作を実行することができる。
前述のように、分散的制御ＳＰＳにおけるワーカーノードは、ＳＭＳからパーティションマッピング情報を入手し（通常、頻度は低い）、必要に応じて、そのような情報を使用してＰＡテーブルを更新することができる。図２８は、少なくともいくつかの実施形態に従う、ストリーム管理サービス制御サブシステムから入手した情報に基づいてパーティション割当テーブルを更新するための、ストリーム処理ステージのワーカーノードによって実行できる動作の態様を示す。要素２８０１に示すように、ワーカーノードの初期化中、またはそこに割り当てられたパーティションの一つの閉鎖などのさまざまなトリガ条件に応答して、ワーカーノードＷ１は、最後のもしくは進行中のパーティションリスト、またはアクティブパーティションリストを入手するためのリクエストを、ＳＭＳ制御サブシステムに提示することができる。いくつかの実施では、ｇｅｔＳｔｒｅａｍＩｎｆｏまたは類似のＡＰＩを、この目的のために呼び出すことができる。いくつかの実施形態では、他のトリガ条件を使用することができる。例えば、ワーカーノードは、ランダムな時間後にまたは作業負荷レベルの予期されない低下もしくは増加に応答して新たなパーティションリストを入手するように、その各々を構成できる。描写した実施形態では、ＳＭＳによって戻されるパーティションリストを、パーティションについてのＰＡテーブルにおける入力と比較することができる（要素２８０７）。不一致が発見された場合（例えば、新たに入手したパーティションリスト内に、ＰＡテーブルにはないいくつかのパーティションが存在する場合、またはＳＭＳのリストにはない、ＰＡテーブルにおける入力が存在する場合）には、ワーカーノードは、不一致を解決するために、ＰＡテーブルに入力を挿入または入力を削除することができる（要素２８１０）。（いくつかの実施では、削除を目的とされる入力が、現在、割り当てられたワーカーノードを有する場合には、追加の調整が必要となり得る、例えば、直接にまたはＰＡテーブルそれ自身によって、割り当てられたワーカーノードに通知することができる。）
不一致の修正後、または不一致が検出されなかった場合には、ワーカーノードＷ１は、ステージの処理動作を実行すべきパーティションのセットを選択し（要素２８１３）、それに従いＰＡテーブルを更新することができる。場合によっては、検索されるパーティションリストに導かれたトリガ条件に応じて、Ｗ１は、そこに割り当てられた一つ以上のパーティションを既に有することができ、その割り当てを変更またはＰＡテーブルを更新する必要がない。次に、Ｗ１は、ＳＭＳ制御サブシステムとの相互作用、またはＰＡテーブルにおける入力の数の変更を行う必要なく、その割り当てられた一つ以上のパーティションのデータレコードを検索し、レコードを処理するように進行することができる（要素２８１６）。最終的に、トリガ条件が検出されたとき（例えば、検索リクエストに対してパーティションが閉じられていることを表す「パーティションの終了に至る」応答と同等のものが受信されたとき）に、Ｗ１は、新たなパーティション情報を求めるリクエストをＳＭＳ制御サブシステムに再び送信し、要素２８０１以降の動作を繰り返すことができる。
図２９は、少なくともいくつかの実施形態に従う、ストリーム処理ステージのワーカーノードによって実行できる負荷バランシング動作の態様を示す。要素２９０１に示すように、ワーカーノードＷ１は、高いリソース使用レベルの検出などの様々なトリガ条件のいずれかの検出時にまたは設定可能なスケジュールに基づいて、そのステージにおいて負荷バランシング解析を実行することを決定できる。Ｗ１は、ＰＡテーブルにおける入力を分析し（要素２９０４）、ステージについてのさまざまな作業負荷メトリクスを決定することができる。そのようなメトリクスは、ワーカーノードに割り当てられるパーティションの平均数、（作業負荷レベルインジケータがテーブルにセーブされる実施形態では）ワーカーノードまたは異なるパーティションの平均作業負荷レベル、ワーカーノードあたりの作業負荷の範囲または分配などを含むことができる
次に、Ｗ１は、（例えば、Ｗ１に割り当てられたパーティションの数、及び／またはパーティションあたりの作業負荷レベルインジケータに基づいた）自身の作業負荷と、メトリクスのいくつかまたはすべてとを比較することができる。通常、三つのタイプの結論、すなわち、Ｗ１が過負荷である、Ｗ１の負荷が不十分である、またはＷ１の作業負荷が過度に高くも過度に低くもない、のいずれかを導き出すことができる。「過度に高い」または「過度に低い」作業負荷レベルは、いくつかの実施形態では、ステージを構成するためにクライアントによって選択されたポリシによって、または他の実施形態では、ヒューリスティックのいくつかのデフォルト設定を使用して規定することができる。Ｗ１が、その作業負荷が過度に低い、例えば、いくつかの最小負荷閾値Ｔ１未満であることを決定した場合には（要素２９０７）、より忙しいまたはより高負荷のワーカーノードＷｋを特定することができる（要素２９１０）。次に、Ｗ１は、例えば、ＰＡテーブルにおけるＰｍ入力の変更を試みる、（Ｗｋのために生成される通知を生じることができる）そのような変更をリクエストする、またはＷｋに直接にリクエストすることによって、Ｗｋからそれ自身に一つ以上のパーティションＰｍを転送する処理を起動することができる（要素２９１３）。
Ｗ１が、その作業負荷が過度に高い、例えば、最大閾値Ｔ２超であることを決定した場合には（要素２９１６）、手放すための（すなわち、他のワーカーノードに割り当てるために放出するための）、その割り当てられたパーティションＰｎの一つ以上を特定することができる（要素２９１９）。次に、Ｗ１は、例えば、Ｐｎについての入力の割り当て列からその識別子を取り除くことによって、適切なＰＡテーブルにおける入力を変更することができる（要素２９２２）。Ｗ１の作業負荷が過度に高くも過度に低くもない場合、またはＷ１が、その作業負荷を増大もしくは減少するための前述の種類のアクションをとった後に、Ｗ１は、そこに割り当てられたパーティションのレコードの処理を再開することができる（要素２９２５）。別の負荷バランシング解析をトリガする条件が満たされるとき及び場合に、要素２９０１以降に対応する動作を繰り返すことができる。図２９に示した動作において、Ｗ１が、自身の作業負荷に関するアンバランスを検出したときのみに作業負荷の変更を起動するものとして示されることに留意されたい。他の実施形態では、Ｗ１は、それ自身ではなく他のワーカーノード間でアンバランスを検出した場合、例えば、Ｗ２がＷ３よりも遥かに低い作業負荷レベルを有することを決定した場合には、再バランシングアクションを起動することができる。いくつかの実施では、Ｗ１は、作業負荷アンバランスを検出した場合及び検出したときに、（例えば、図３に示すなどのｒｅｐａｒｔｉｔｉｏｎＳｔｒｅａｍ ＳＭＳ ＡＰＩ、またはその均等物を起動することによって）動的再パーティショニングをリクエストまたは起動することができる。いくつかの実施形態において、図２９に示す種類の動作は、例えば、ステージがいくらかの時間既に動作している後に、新規のノードがステージに追加されたときに、新規に構成されたワーカーノードによって実行することができる。この新規のノードは、高負荷の既存のノードからのパーティションの再割り当てをリクエストすることによって、自身の存在を既存のノードに間接的に通知することができる。いくつかの実施形態において、ＳＰＳワーカーノードのための、前述のものに類似する分散的制御技術もまたは代わりとして、一つ以上のＳＭＳサブシステムにおいて使用することができる。例えば、取り込み、保存または検索サブシステムのノードは、ＰＡテーブルに類似する共有データ構造を使用して自身の作業負荷を調整することができる
さまざまな実施形態において、図１７〜図２４及び図２７〜図２９のフロー図に示す以外の動作を使用して、前述のストリーム管理サービス及び／またはストリーム処理機能性を実施できることに留意されたい。いくつかの実施形態において、示す動作のいくつかは、実施しなくてもよく、異なる順序で実施してもよく、連続的ではなく並行して実施してもよい。さまざまな実施形態において、プログラマチックインターフェースをサポートするためのＳＭＳ及びＳＰＳ機能の各々に関して、インターフェースを実装するための一つ以上の技術の任意の組み合わせを使用できることにも留意されたい。この技術は、ウェブページ、ウェブサイト、ウェブサービスＡＰＩ、他のＡＰＩ、コマンドラインツール、グラフィカルユーザインターフェース、モバイルアプリケーション（ａｐｐ）、タブレットアプリケーションなどの使用を含む。
使用事例
ストリームデータレコードの収集、保存、検索及び段階的な処理のための、スケーラブルパーティショニングベースの、動的に構成可能な管理されたマルチテナントサービスを構築する前述の技術は、多くのシナリオにおいて有用であり得る。例えば、大規模プロバイダネットワークは、何万ものクライアントのための、多くの異なるマルチテナントまたはシングルテナントサービスのサービスインスタンスを実施する何千ものインスタンスホストを同時に備えることができる。さまざまなインスタンス及びホストにインストールされた監視及び／または請求エージェントは、正確な請求レコードを生産する、プロバイダネットワークのデータセンタについての効果的なプロビジョニング計画を決定する、ネットワーク攻撃を検出することなどができる、保存及び解析する必要が生じ得る何千ものメトリクスレコードを迅速に生成することができる。監視レコードは、スケーラブル取り込み及び保存のための入力ストリームをＳＭＳに形成し、記述するＳＰＳ技術を、収集したメトリクスの解析のために実施することができる。同様に、幾多のログソースから多数のログレコード（例えば、分配アプリケーションのノードからのアプリケーションログ、またはデータセンタにおけるホストもしくはコンピュートインスタンスからのシステムログ）を収集及び解析するためのアプリケーションも、ＳＭＳ及びＳＰＳ機能性を活用することができる。少なくともいくつかの環境において、ＳＰＳ処理動作は、リアルタイムＥＴＬ（抽出、変換、ロード）処理動作（すなわち、オフラインで変換する代わりに、宛先にロードするために受信したデータレコードをリアルタイムで変換する動作）またはデータウェアハウスに挿入するためのデータレコードの変換を含むことができる。データをデータウェアハウスにリアルタイムでロードするためにＳＭＳとＳＰＳとの組み合わせを使用することによって、通常、データを解析するためにウェアハウスに挿入し得る前に、一つ以上のデータソースからのデータをクリーンにする及び監督するのに必須の遅延を回避することができる。
多くの異なる「ビッグデータ」アプリケーションも、ＳＭＳ及びＳＰＳ技術を使用して作製することができる。例えば、さまざまな形態のソーシャルメディア相互作用におけるトレンドの解析を、ストリームを使用して能率的に実行することができる。携帯電話またはタブレットコンピュータから収集した、ユーザの位置情報などのデータは、ストリームレコードとして管理することができる。例えば、監視カメラの集合から収集した音声または映像情報は、スケーラブルな様式において収集及び処理できるストリーミングデータセットの別のカテゴリを表し、これは、さまざまな種類の攻撃を防ぐことを支援する可能性がある。例えば、気象衛星、海洋ベースのセンサ、森林ベースのセンサ、天体望遠鏡から収集された、ますます増加するデータセットの解析が必要な科学的アプリケーションも、本明細書に記述するストリーム管理及び処理性能から利益を得ることができる。適応性のあるポリシベースの構成オプション及び価格決定オプションは、異なるタイプのユーザが、自身の具体的な予算及びデータ永続性または有用性要件に合うように、ストリーミングの機能性をカスタマイズすることを支援できる。
本開示の実施形態は、以下の条項を考慮して記述することができる。
〔１〕
指定されたデータストリームに関連する特定の処理ステージに対応する、マルチテナントストリーム処理サービスのクライアントが、（ａ）パーティショニングポリシに従い、指定されたデータストリームのデータレコードに実行される処理動作、及び（ｂ）処理動作の結果についての出力分配記述子を示すことができる一つ以上のプログラマチックインターフェースを実装し、
一つ以上のプログラマチックインターフェースを通じて特定のクライアントから、特定の処理ステージにおいて特定のデータストリームのデータレコードに実行される特定の処理動作の表示、及び特定の処理動作の結果についての特定の出力分配記述子を受信し、
パーティショニングポリシに少なくともある程度基づいて、かつ処理ステージのためのワーカーノードとして配置されたリソースの推定の実行能力に少なくともある程度基づいて、指定されたデータストリームのためのワーカーノードの初期の数を決定し、
（ａ）特定のデータストリームの一つ以上のパーティションのデータレコードを受信し、（ｂ）受信したデータレコードに特定の処理動作を実行し、（ｃ）ワーカーノードにおいて処理された一つ以上のパーティションの一部分を示す進捗レコードを保存し、（ｄ）特定の処理動作の結果を、特定の出力分配記述子に従い一つ以上の宛先に転送するための、初期の数のワーカーノードのうちから特定のワーカーノードを構成し、
特定のワーカーノードの調子状態を監視し、かつ
特定のワーカーノードが望ましくない状態にあるという決定に応答して、特定のワーカーノードと取り換えるための取り換えワーカーノードであって、特定のワーカーノードによって保存された進捗レコードにアクセスして、特定の処理動作が取り換えワーカーノードによって実行される、一つ以上のパーティションの少なくとも一つのデータレコードを特定する取り換えワーカーノードを構成するように構成された一つ以上のコンピューティングデバイスを備えた、システム。
〔２〕
特定の処理動作の結果が、異なるデータストリームのデータレコードとして、異なるパーティショニングポリシに従い、異なるデータストリームのために構成された以上の取り込みノードに分配されることを、特定の出力分配記述子が示す、条項１に記載のシステム。
〔３〕
一つ以上のコンピューティングデバイスが、さらに、
特定のデータストリームのデータレコードが入力として提供される別の処理ステージの表示を、特定のクライアントから受信し、ここで、異なる処理動作が他の処理ステージにおいて実行され、
他の処理ステージのためのワーカーノードの追加のセットを構成するように構成された、条項１に記載のシステム。
〔４〕
一つ以上のコンピューティングデバイスが、さらに、
別の処理ステージについての別の処理動作を実行するように構成された異なるワーカーノードが望ましくない状態にあるという決定に応答して、進捗レコードにアクセスせずに、他の処理動作を一つ以上のその後に受信したデータレコードに実行するための異なる取り換えワーカーノードを構成するように構成された、条項１に記載のシステム。
〔５〕
一つ以上のコンピューティングデバイスが、さらに、
処理ステージの異なるワーカーノードにおける作業負荷レベルがトリガ基準を満たすことの決定に応答して、（ａ）ストリームの追加のデータレコードが処理され続けている間に実行される特定のデータストリームの動的再パーティショニング、（ｂ）異なるワーカーノードにおいて以前に処理された少なくとも一つのパーティションへの代替ワーカーノードの割り当て、（ｃ）処理ステージのために構成されたワーカーノードの数の変更、または（ｄ）あるサーバから別のサーバへのワーカーノードの転送の一つ以上を含むステージ再構成動作を実施するように構成された、条項１に記載のシステム。
〔６〕
特定のクライアントからのマルチテナントストリーム処理サービスにおいて、指定された処理ステージにおいて特定のデータストリームのデータレコードに実行される特定の動作の表示、及び特定の動作の結果についての特定の出力分配記述子を受信することと、
特定の動作に少なくともある程度基づいて、指定された処理ステージのために構成されたワーカーノードの初期の数を決定することと、
（ａ）特定のデータストリームの一つ以上のパーティションの受信したデータレコードに特定の動作を実行し、（ｂ）ワーカーノードにおいて処理された一つ以上のパーティションの一部分を示す進捗レコードを保存し、（ｃ）特定の動作の結果を、特定の出力分配記述子に従い一つ以上の宛先に転送するように、初期の数のワーカーノードのうちから特定のワーカーノードを構成することと、及び
特定のワーカーノードが不健全な状態にあるという決定に応答して、特定のワーカーノードと取り換えるための取り換えワーカーノードであって、特定のワーカーノードによって保存された進捗レコードにアクセスして、特定の動作が取り換えワーカーノードによって実行される、一つ以上のパーティションの少なくとも一つのデータレコードを特定する取り換えワーカーノードを選択することと、を一つ以上のコンピューティングデバイスによって実行することを含む、方法。
〔７〕
パラメータとして、リクエストされたデータレコードのパーティション内のシーケンス番号の表示を含む特定のプログラマチックデータレコード検索インターフェースを含む、マルチテナントストリーム管理サービスによって実装された一つ以上のプログラマチックデータレコード検索インターフェースを起動して、一つ以上のパーティションのデータレコードを受信することを、一つ以上のコンピューティングデバイスによって実行することをさらに含む、条項６に記載の方法。
〔８〕
一つ以上のデータストリームのデータレコードについての処理ステージの有向非巡回グラフを、ストリーム処理サービスのクライアントが指定できる一つ以上のプログラマチックインターフェースを実装することを、一つ以上のコンピューティングデバイスによって実行することをさらに含む、条項６に記載の方法。
〔９〕
特定のデータストリームのデータレコードの保存に関与するマルチテナントストリーム管理サービスから、特定のデータストリームに使用されるパーティショニングポリシの表示を入手することと、及び
パーティショニングポリシに少なくともある程度基づいて、ワーカーノードの初期の数を決定することと、を一つ以上のコンピューティングデバイスによって実行することをさらに含む、条項６に記載の方法。
〔１０〕
特定の動作の結果が、異なるデータストリームのデータレコードとして、異なるパーティショニングポリシに従い、異なるデータストリームのために構成された以上の取り込みノードに分配されることを、特定の出力分配記述子が示す、条項６に記載の方法。
〔１１〕
別の処理ステージについての別の動作を実行するように構成された異なるワーカーノードが望ましくない状態にあるという決定に応答して、進捗レコードにアクセスせずに、他の動作を一つ以上のその後に受信したデータレコードに実行するための異なる取り換えワーカーノードを構成することを、一つ以上のコンピューティングデバイスによって実行することをさらに含む、条項６に記載の方法。
〔１２〕
処理ステージの異なるワーカーノードにおける作業負荷レベルがトリガ基準を満たすことの決定に応答して、（ａ）特定のデータストリームの動的再パーティショニング、（ｂ）異なるワーカーノードにおいて以前に処理された少なくとも一つのパーティションへの代替ワーカーノードの割り当て、（ｃ）処理ステージのために構成されたワーカーノードの数の変更、または（ｄ）あるサーバから別のサーバへのワーカーノードの転送の一つ以上を実施することを、一つ以上のコンピューティングデバイスによって実行することをさらに含む、条項６に記載の方法。
〔１３〕
特定の動作の結果が、別のストリーム処理システムと互換性がある入力フォーマットに従いフォーマットされ、一つ以上の宛先のうちの特定の宛先が、他のストリーム処理システムの入力ノードを含む、条項６に記載の方法。
〔１４〕
特定のワーカーノードが、特定のワーカーノードにおいて処理された複数のデータレコードに対応する累積されたアプリケーション状態情報を表す入力を永続的なデータリポジトリに保存し、進捗レコードにおける入力の表示を含むように構成された、条項６に記載の方法。
〔１５〕
動作が、ログレコード解析動作、リソース監視メトリクス解析、請求額計算、センサデータ解析、ソーシャルメディア相互作用解析、リアルタイムＥＴＬ（抽出、変換、ロード）処理動作、またはデータウェアハウスに挿入する前のデータレコードの変換の一つを含む、条項６に記載の方法。
〔１６〕
クライアントライブラリコンポーネントの起動によってストリーム処理構成リクエストに応答して、マルチテナントストリーム処理サービスにおいて、異なる処理ステージのためのワーカーノードとして指定されたリソースを記録することを、一つ以上のコンピューティングデバイスによって実行することをさらに含む、条項６に記載の方法。
〔１７〕
クライアントライブラリコンポーネントの起動によってストリーム処理構成リクエストに応答して、マルチテナントストリーム処理サービスにおいて、異なる処理ステージにおいて実施される制御プレーン機能の一つ以上のカテゴリを決定することを、一つ以上のコンピューティングデバイスによって実行することをさらに含む、条項６に記載の方法。
〔１８〕
動作が冪等動作である、条項６に記載の方法。
〔１９〕
マルチテナントストリーム処理サービスにおいて、特定のクライアントから、異なる処理ステージにおいて異なるデータストリームのデータレコードに実行される特定の非冪等動作の表示を受信することと、及び
受信したデータレコードに非冪等動作を実行するための、異なる処理ステージの第一のワーカーノードを構成することと、を一つ以上のコンピューティングデバイスによって実行することをさらに含む、条項６に記載の方法。
〔２０〕
（ａ）フラッシュ動作を実行して非冪等動作の結果を一つ以上の宛先に保存し、かつ（ｂ）フラッシュ動作のタイミングの表示を永続的保存場所にセーブするように、異なる処理ステージの第一のワーカーノードを構成することと、及び
フラッシュ動作のタイミングの表示を使用して、第一のワーカーノードの障害後のリカバリ期間に、フラッシュ動作をリプレイするように取り換えワーカーノードを構成することと、を一つ以上のコンピューティングデバイスによって実行することをさらに含む、条項１９に記載の方法。
〔２１〕
一つ以上のプロセッサにおいて実行されるときにマルチテナントストリーム処理サービスの制御ノードを実施するプログラム命令を保存する非一時的コンピュータアクセス可能ストレージ媒体であって、制御ノードが、
プログラマチックインターフェースを通じて特定のクライアントから、特定のデータストリームのデータレコードに実行される特定の動作の表示を受信し、
特定のデータストリームに関連するパーティショニングポリシに少なくともある程度基づいて、処理ステージにおける指定されたデータストリームのためのワーカーノードの初期の数を決定し、
特定のデータストリームの一つ以上のパーティションの受信したデータレコードに特定の動作を実行するための、初期の数のワーカーノードのうちから特定のワーカーノードを構成し、かつ
特定のワーカーノードが不健全な状態にあるという決定に応答して、特定のワーカーノードと取り換えるための取り換えワーカーノードを構成するように動作する、非一時的コンピュータアクセス可能ストレージ媒体。
〔２２〕
制御ノードが、異なるデータストリームの異なるパーティションのデータレコードを処理するための複数のワーカーノードを備える冗長グループを構成するように動作し、複数のワーカーノードのうちの少なくとも一つのワーカーノードが、異なるパーティションのデータレコードを受信するためのプライマリノードとして用意され、そして複数のワーカーノードのうちの少なくとも別のワーカーノードが、トリガ事象に応答してプライマリノードの責務を引き受けるスタンドバイノードとして構成される、条項２１に記載の非一時的コンピュータアクセス可能ストレージ媒体。
〔２３〕
制御ノードが、処理ステージの異なるワーカーノードにおける作業負荷レベルがトリガ基準を満たすことの決定に応答して、（ａ）特定のデータストリームの動的再パーティショニング、（ｂ）異なるワーカーノードにおいて以前に処理された少なくとも一つのパーティションへの代替ワーカーノードの割り当て、（ｃ）処理ステージのために構成されたワーカーノードの数の変更、または（ｄ）あるサーバから別のサーバへのワーカーノードの転送の一つ以上を実行するように動作する、条項２１に記載の非一時的コンピュータアクセス可能ストレージ媒体。
〔２４〕
特定の動作の結果が、永続ストレージデバイスを必要としない保存のための一時的データストリームのデータレコードとして、異なるパーティショニングポリシに従い、一時的データストリームのために構成された以上の取り込みノードに分配されることを、特定の出力分配記述子が示す、条項２１に記載の非一時的コンピュータアクセス可能ストレージ媒体。
〔２５〕
一つ以上のデータストリームのデータレコードについての処理ステージの有向非巡回グラフを、ストリーム処理サービスのクライアントが指定できる一つ以上のプログラマチックインターフェースを実装するように制御ノードが動作する、条項２１に記載の非一時的コンピュータアクセス可能ストレージ媒体。
実例となるコンピュータシステム
少なくともいくつかの実施形態では、ＳＭＳサブシステム（例えば、取り込み、保存、検索及び制御サブシステム）のコンポーネントを実装する技術を含む、本明細書に記述する技術の一つ以上の一部またはすべてを実施するサーバ、並びにＳＰＳワーカー及び制御ノードは、一つ以上のコンピュータアクセス可能媒体、またはそれにアクセスするように構成された汎用コンピュータシステムを含むことができる。図３０は、そのような汎用コンピューティングデバイス９０００を示す。示す実施形態において、コンピューティングデバイス９０００は、入出力（Ｉ／Ｏ）インターフェース９０３０を通じてシステムメモリ９０２０に連結された一つ以上のプロセッサ９０１０を含む。コンピューティングデバイス９０００は、さらに、Ｉ／Ｏインターフェース９０３０に連結されたネットワークインターフェース９０４０を含む。
さまざまな実施形態において、コンピューティングデバイス９０００は、一つのプロセッサ９０１０を含むユニプロセッサシステムであってもよいし、いくつか（例えば、二つ、四つ、八つまたは別の適切な数）のプロセッサ９０１０を含むマルチプロセッサシステムであってもよい。プロセッサ９０１０は、命令を実行する能力がある任意の適切なプロセッサであってもよい。例えば、さまざまな実施形態において、プロセッサ９０１０は、×８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣまたはＭＩＰＳ ＩＳＡもしくは任意の他の適切なＩＳＡなどの、様々な命令セットアーキテクチャ（ＩＳＡ）のいずれかを実装する汎用または組み込みプロセッサであってもよい。マルチプロセッサシステムにおいて、プロセッサ９０１０の各々は、通例、必ずしも同じＩＳＡを実装しなくてもよい。いくつかの実施では、従来のプロセッサの代わりにまたはそれに加えて、グラフィック処理ユニット（ＧＰＵ）を使用してもよい。
システムメモリ９０２０は、プロセッサ（複数可）９０１０によってアクセス可能な命令及びデータを保存するように構成できる。さまざまな実施形態において、システムメモリ９０２０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、シンクロナスダイナミックＲＡＭ（ＳＤＲＡＭ）、非揮発性もしくはフラッシュタイプのメモリ、または任意の他のタイプのメモリなどの任意の適切なメモリ技術を使用して実施することができる。示す実施形態では、前述の方法、技術及びデータなどの一つ以上の所望の機能を実施するプログラム命令及びデータを、コード９０２５及びデータ９０２６としてシステムメモリ９０２０内に保存されるものとして示す。
一実施形態において、Ｉ／Ｏインターフェース９０３０は、プロセッサ９０１０、システムメモリ９０２０、並びにデータオブジェクトパーティションの物理レプリカを保存するのに使用されるさまざまなタイプの持続性及び／または揮発性ストレージデバイスなどの、ネットワークインターフェース９０４０または他の周辺インターフェースを含む、デバイスにおける任意の周辺デバイス間のＩ／Ｏトラフィックを調整するように構成できる。いくつかの実施形態において、Ｉ／Ｏインターフェース９０３０は、あるコンポーネント（例えば、システムメモリ９０２０）からのデータ信号を、別のコンポーネント（例えば、プロセッサ９０１０）による使用に適したフォーマットに変換するための任意の必須のプロトコル、タイミングまたは他のデータ変換を実行することができる。いくつかの実施形態において、Ｉ／Ｏインターフェース９０３０は、例えば、周辺コンポーネント相互接続（ＰＣＩ）バス標準またはユニバーサルシリアルバス（ＵＳＢ）標準の変形などのさまざまなタイプの周辺バスを通じて取り付けられる、デバイスのためのサポートを含むことができる。いくつかの実施形態において、Ｉ／Ｏインターフェース９０３０の機能は、例えば、ノースブリッジ及びサウスブリッジなどの二つ以上の別個のコンポーネントに分割することができる。また、いくつかの実施形態において、システムメモリ９０２０とのインターフェースなどのＩ／Ｏインターフェース９０３０の機能性のいくつかまたはすべては、プロセッサ９０１０に直接に組み込むことができる。
ネットワークインターフェース９０４０は、コンピューティングデバイス９０００と、例えば、図１〜図２９に示すような他のコンピュータシステムまたはデバイスなどの、一つ以上のネットワーク９０５０に取り付けられた他のデバイス９０６０との間でデータを交換できるように構成できる。さまざまな実施形態において、ネットワークインターフェース９０４０は、例えば、イーサネット（登録商標）ネットワークのタイプなどの任意の適切な有線または無線の一般のデータネットワークを通じて通信をサポートすることができる。さらに、ネットワークインターフェース９０４０は、アナログボイスネットワークもしくはデジタルファイバ通信ネットワークなどの遠距離通信もしくは電話通信ネットワーク、Ｆｉｂｒｅ Ｃｈａｎｎｅｌ ＳＡＮなどのストレージエリアネットワーク 、または任意の他の適切なタイプのネットワーク及び／もしくはプロトコルを通じて通信をサポートすることができる。
いくつかの実施形態において、システムメモリ９０２０は、対応する方法及び装置の実施形態を実施するための図１〜図２９に関する前述のようなプログラム命令及びデータを保存するように構成されたコンピュータアクセス可能媒体の一実施形態であってもよい。しかしながら、他の実施形態では、プログラム命令及び／またはデータは、異なるタイプのコンピュータアクセス可能媒体において受信、送信または保存することができる。一般的に言えば、コンピュータアクセス可能媒体は、例えば、磁気または光学媒体、例えば、Ｉ／Ｏインターフェース９０３０を通じてコンピューティングデバイス９０００に連結されたディスクまたはＤＶＤ／ＣＤなどの非一時的ストレージ媒体または記憶媒体を含むことができる。非一時的コンピュータアクセス可能ストレージ媒体は、コンピューティングデバイス９０００のいくつかの実施形態においてシステムメモリ９０２０または別のタイプのメモリとして含ませることができる、例えば、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどの任意の揮発性または不揮発性媒体も含むことができる。さらに、コンピュータアクセス可能媒体は、例えば、ネットワークインターフェース９０４０を通じて実装できる、ネットワーク及び／または無線リンクなどの通信媒体を通じて搬送される、電気、電磁もしくはデジタル信号などの伝送媒体または信号を含むことができる。さまざまな実施形態において、図３０に示すなどの複数のコンピューティングデバイスの一部またはすべてを使用して、記述した機能性を実施することができる。様々な種々のデバイス及びサーバにおいて実行されるソフトウェアコンポーネントを、機能性を提供するように協同させることができる。いくつかの実施形態において、記述した機能性の一部を、汎用コンピュータシステムを使用して実施するのに追加的にまたは代替的に、ストレージデバイス、ネットワークデバイスまたは専用のコンピュータシステムを使用して実施することができる。本明細書に使用される「コンピューティングデバイス」という用語は、少なくともすべてのこれらのタイプのデバイスを指し、かつこれらのタイプのデバイスに限定されない。
結論
さまざまな実施形態は、さらに、先の記述に従い実装された命令及び／またはデータを、コンピュータアクセス可能媒体において受信、送信または保存することを含むことができる。一般的に言えば、コンピュータアクセス可能媒体は、例えば、磁気または光学媒体、例えば、ディスクまたはＤＶＤ／ＣＤ−ＲＯＭ、例えば、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどの揮発性または不揮発性媒体などのストレージ媒体または記憶媒体、並びにネットワーク及び／または無線リンクなどの通信媒体を通じて搬送される、電気、電磁またはデジタル信号などの伝送媒体または信号を含むことができる。
図面に示し、本明細書に記述するさまざまな方法は、方法の例示の実施形態を示す。方法は、ソフトウェア、ハードウェアまたはそれらの組み合わせにおいて実施することができる。方法の順序は変更でき、さまざまな要素を、追加、再順序付け、結合、削除、変更することなどができる。
本開示の利益を有する当業者に明らかであるようなさまざまな修正及び変更を為すことができる。すべてのそのような修正及び変更を含み、それ故に、前の記述が、限定的な意味ではなく実例としてみなされることが意図される。

Claims (15)

  1. 特定のクライアントからのマルチテナントストリーム処理サービスにおいて、指定された処理ステージにおいて特定のデータストリームのデータレコードに実行される特定の動作の表示、及び前記特定の動作の結果についての特定の出力分配記述子を受信することと、
    前記特定の動作に少なくともある程度基づいて、前記指定された処理ステージのために構成されたワーカーノードの初期の数を決定することと、
    （ａ）前記特定のデータストリームの一つ以上のパーティションの受信したデータレコードに前記特定の動作を実行し、（ｂ）前記ワーカーノードにおいて処理された前記一つ以上のパーティションの一部分を示す進捗レコードを保存し、（ｃ）前記特定の動作の結果を、前記特定の出力分配記述子に従い一つ以上の宛先に転送するように、前記初期の数のワーカーノードのうちから特定のワーカーノードを構成することと、及び
    前記特定のワーカーノードが不健全な状態にあるという決定に応答して、前記特定のワーカーノードと取り換えるための取り換えワーカーノードであって、前記特定のワーカーノードによって保存された進捗レコードにアクセスして、前記特定の動作が前記取り換えワーカーノードによって実行される、前記一つ以上のパーティションの少なくとも一つのデータレコードを特定する前記取り換えワーカーノードを選択することと、を一つ以上のコンピューティングデバイスによって実行することを含む、方法。
  2. パラメータとして、リクエストされたデータレコードのパーティション内のシーケンス番号の表示を含む特定のプログラマチックデータレコード検索インターフェースを含む、マルチテナントストリーム管理サービスによって実装された一つ以上のプログラマチックデータレコード検索インターフェースを起動して、前記一つ以上のパーティションのデータレコードを受信することを、前記一つ以上のコンピューティングデバイスによって実行することをさらに含む、請求項１に記載の方法。
  3. 一つ以上のデータストリームのデータレコードについての処理ステージの有向非巡回グラフを、前記ストリーム処理サービスのクライアントが指定できる一つ以上のプログラマチックインターフェースを実装することを、前記一つ以上のコンピューティングデバイスによって実行することをさらに含む、請求項１に記載の方法。
  4. 前記特定のデータストリームの前記データレコードの保存に関与するマルチテナントストリーム管理サービスから、前記特定のデータストリームに使用されるパーティショニングポリシの表示を入手することと、及び
    前記パーティショニングポリシに少なくともある程度基づいて、前記ワーカーノードの初期の数を決定することと、を前記一つ以上のコンピューティングデバイスによって実行することをさらに含む、請求項１に記載の方法。
  5. 前記特定の動作の結果が、異なるデータストリームのデータレコードとして、異なるパーティショニングポリシに従い、前記異なるデータストリームのために構成された以上の取り込みノードに分配されることを、前記特定の出力分配記述子が示す、請求項１に記載の方法。
  6. 前記処理ステージの異なるワーカーノードにおける作業負荷レベルがトリガ基準を満たすことの決定に応答して、（ａ）前記特定のデータストリームの動的再パーティショニング、（ｂ）前記異なるワーカーノードにおいて以前に処理された少なくとも一つのパーティションへの代替ワーカーノードの割り当て、（ｃ）前記処理ステージのために構成されたワーカーノードの数の変更、または（ｄ）あるサーバから別のサーバへのワーカーノードの転送の一つ以上を実施することを、前記一つ以上のコンピューティングデバイスによって実行することをさらに含む、請求項１に記載の方法。
  7. 前記特定のワーカーノードが、前記特定のワーカーノードにおいて処理された複数のデータレコードに対応する累積されたアプリケーション状態情報を表す入力を永続的なデータリポジトリに保存し、進捗レコードにおける前記入力の表示を含むように構成された、請求項１に記載の方法。
  8. クライアントライブラリコンポーネントの起動によってストリーム処理構成リクエストに応答して、前記マルチテナントストリーム処理サービスにおいて、異なる処理ステージのためのワーカーノードとして指定されたリソースを記録することを、前記一つ以上のコンピューティングデバイスによって実行することをさらに含む、請求項１に記載の方法。
  9. 前記マルチテナントストリーム処理サービスにおいて、前記特定のクライアントから、異なる処理ステージにおいて異なるデータストリームのデータレコードに実行される特定の非冪等動作の表示を受信することと、及び
    前記受信したデータレコードに非冪等動作を実行するための、前記異なる処理ステージの第一のワーカーノードを構成することと、を前記一つ以上のコンピューティングデバイスによって実行することをさらに含む、請求項１に記載の方法。
  10. （ａ）フラッシュ動作を実行して前記非冪等動作の結果を一つ以上の宛先に保存し、かつ（ｂ）フラッシュ動作のタイミングの表示を永続的保存場所にセーブするように、前記異なる処理ステージの前記第一のワーカーノードを構成することと、及び
    前記フラッシュ動作のタイミングの前記表示を使用して、前記第一のワーカーノードの障害後のリカバリ期間に、前記フラッシュ動作をリプレイするように取り換えワーカーノードを構成することと、を前記一つ以上のコンピューティングデバイスによって実行することをさらに含む、請求項９に記載の方法。
  11. 一つ以上のプロセッサ及び一つ以上のメモリを含むシステムであって、前記一つ以上のメモリが、前記一つ以上のプロセッサにおいて実行されたときにマルチテナントストリーム処理サービスの制御ノードを実施するプログラム命令を含み、前記制御ノードが、
    プログラマチックインターフェースを通じて特定のクライアントから、特定のデータストリームのデータレコードに実行される特定の動作の表示を受信し、
    前記特定のデータストリームに関連するパーティショニングポリシに少なくともある程度基づいて、処理ステージにおける前記指定されたデータストリームのためのワーカーノードの初期の数を決定し、
    前記特定のデータストリームの一つ以上のパーティションの受信したデータレコードに前記特定の動作を実行するための、前記初期の数のワーカーノードのうちから特定のワーカーノードを構成し、かつ
    前記特定のワーカーノードが不健全な状態にあるという決定に応答して、前記特定のワーカーノードと取り換えるための取り換えワーカーノードを構成するように動作する、前記システム。
  12. 前記制御ノードが、異なるデータストリームの異なるパーティションのデータレコードを処理するための複数のワーカーノードを備える冗長グループを構成するように動作し、前記複数のワーカーノードのうちの少なくとも一つのワーカーノードが、前記異なるパーティションの前記データレコードを受信するためのプライマリノードとして用意され、そして前記複数のワーカーノードのうちの少なくとも別のワーカーノードが、トリガ事象に応答してプライマリノードの責務を引き受けるスタンドバイノードとして構成される、請求項１１に記載のシステム。
  13. 前記制御ノードが、前記処理ステージの異なるワーカーノードにおける作業負荷レベルがトリガ基準を満たすことの決定に応答して、（ａ）前記特定のデータストリームの動的再パーティショニング、（ｂ）前記異なるワーカーノードにおいて以前に処理された少なくとも一つのパーティションへの代替ワーカーノードの割り当て、（ｃ）前記処理ステージのために構成されたワーカーノードの数の変更、または（ｄ）あるサーバから別のサーバへのワーカーノードの転送の一つ以上を実行するように動作する、請求項１１に記載のシステム。
  14. 前記特定の動作の結果が、永続ストレージデバイスを必要としない保存のための一時的データストリームのデータレコードとして、異なるパーティショニングポリシに従い、前記一時的データストリームのために構成された以上の取り込みノードに分配されることを、前記特定の出力分配記述子が示す、請求項１１に記載のシステム。
  15. 前記一つ以上のデータストリームのデータレコードについての処理ステージの有向非巡回グラフを、ストリーム処理サービスのクライアントが指定できる一つ以上のプログラマチックインターフェースを実装するように前記制御ノードが動作する、請求項１１に記載のシステム。
JP2016529942A 2013-11-11 2014-11-11 パーティションベースのデータストリーム処理フレームワーク Active JP6450756B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/077,167 2013-11-11
US14/077,167 US10635644B2 (en) 2013-11-11 2013-11-11 Partition-based data stream processing framework
PCT/US2014/065057 WO2015070236A1 (en) 2013-11-11 2014-11-11 Partition-based data stream processing framework

Publications (2)

Publication Number Publication Date
JP2016536690A true JP2016536690A (ja) 2016-11-24
JP6450756B2 JP6450756B2 (ja) 2019-01-09

Family

ID=53042247

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016529942A Active JP6450756B2 (ja) 2013-11-11 2014-11-11 パーティションベースのデータストリーム処理フレームワーク

Country Status (6)

Country Link
US (1) US10635644B2 (ja)
EP (1) EP3069228B1 (ja)
JP (1) JP6450756B2 (ja)
AU (1) AU2014346366B2 (ja)
CA (1) CA2930101C (ja)
WO (1) WO2015070236A1 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190088188A (ko) * 2018-01-18 2019-07-26 주식회사 알티스트 파티셔닝을 적용하여 프로세스를 모니터링하는 컴퓨팅 시스템
KR102096737B1 (ko) * 2019-03-28 2020-04-02 한국과학기술원 저밀도 패리티 검사 부호를 활용한 고장 방지 능력을 갖춘 분산 기계 학습 방법 및 그 장치
JP2020521238A (ja) * 2017-05-15 2020-07-16 アルテリックス インコーポレイテッド キャッシュ最適化及び効率的な処理のためのデータ集約の方法
KR102188132B1 (ko) * 2020-05-27 2020-12-07 비코어(주) 데이터 적재 및 처리 시스템 및 그 방법
KR20210058401A (ko) * 2019-11-14 2021-05-24 대구대학교 산학협력단 클라우드 컴퓨팅 환경에서의 컨테이너 배치 장치 및 방법
EP3940535A1 (en) 2020-07-17 2022-01-19 Fujitsu Limited Information processing method and information processing program
JP7461354B2 (ja) 2018-08-23 2024-04-03 アルカス インコーポレイテッド ネットワークルーティング環境における独立データストア

Families Citing this family (175)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10191922B2 (en) 1998-11-24 2019-01-29 Oracle International Corporation Determining live migration speed based on workload and performance characteristics
US9239763B2 (en) * 2012-09-28 2016-01-19 Oracle International Corporation Container database
US8332365B2 (en) 2009-03-31 2012-12-11 Amazon Technologies, Inc. Cloning and recovery of data volumes
US10635674B2 (en) 2012-09-28 2020-04-28 Oracle International Corporation Migrating a pluggable database between database server instances with minimal impact to performance
US10922331B2 (en) 2012-09-28 2021-02-16 Oracle International Corporation Cloning a pluggable database in read-write mode
US10496640B2 (en) 2012-12-19 2019-12-03 Salesforce.Com, Inc. Querying a not only structured query language (NoSQL) database using structured query language (SQL) commands
US9720989B2 (en) 2013-11-11 2017-08-01 Amazon Technologies, Inc. Dynamic partitioning techniques for data streams
US20150142844A1 (en) 2013-11-15 2015-05-21 Salesforce.Com, Inc. Scalable objects for use in an on-demand services environment
US9882949B1 (en) * 2014-06-20 2018-01-30 Amazon Technologies, Inc. Dynamic detection of data correlations based on realtime data
US9229997B1 (en) 2014-06-20 2016-01-05 Amazon Technologies, Inc. Embeddable cloud analytics
US11868372B1 (en) 2014-06-20 2024-01-09 Amazon Technologies, Inc. Automated hierarchy detection for cloud-based analytics
JP6428012B2 (ja) * 2014-07-16 2018-11-28 富士通株式会社 分散処理プログラム、分散処理管理装置及び分散処理方法
US9300712B2 (en) * 2014-08-01 2016-03-29 Pivotal Software, Inc. Stream processing with context data affinity
CN106575427B (zh) * 2014-08-12 2020-12-08 艾高特有限责任公司 基于零知识环境的社交网络引擎
GB2529475A (en) * 2014-08-22 2016-02-24 Ibm Tenant allocation in multi-tenant software applications technical field
US20160071027A1 (en) 2014-09-08 2016-03-10 Pivotal Software, Inc. Compute intensive stream processing with concept drift detection
US9678773B1 (en) 2014-09-30 2017-06-13 Amazon Technologies, Inc. Low latency computational capacity provisioning
US10048974B1 (en) 2014-09-30 2018-08-14 Amazon Technologies, Inc. Message-based computation request scheduling
US9146764B1 (en) 2014-09-30 2015-09-29 Amazon Technologies, Inc. Processing event messages for user requests to execute program code
US9600312B2 (en) 2014-09-30 2017-03-21 Amazon Technologies, Inc. Threading as a service
US9830193B1 (en) 2014-09-30 2017-11-28 Amazon Technologies, Inc. Automatic management of low latency computational capacity
US9323556B2 (en) 2014-09-30 2016-04-26 Amazon Technologies, Inc. Programmatic event detection and message generation for requests to execute program code
CN104317556B (zh) * 2014-10-22 2018-03-16 华为技术有限公司 一种流式应用升级方法、主控节点及流计算系统
US9537788B2 (en) 2014-12-05 2017-01-03 Amazon Technologies, Inc. Automatic determination of resource sizing
US9588790B1 (en) 2015-02-04 2017-03-07 Amazon Technologies, Inc. Stateful virtual compute system
US9733967B2 (en) 2015-02-04 2017-08-15 Amazon Technologies, Inc. Security protocols for low latency execution of program code
US9930103B2 (en) 2015-04-08 2018-03-27 Amazon Technologies, Inc. Endpoint management system providing an application programming interface proxy service
US9785476B2 (en) 2015-04-08 2017-10-10 Amazon Technologies, Inc. Endpoint management system and virtual compute system
CN106549990A (zh) * 2015-09-18 2017-03-29 阿里巴巴集团控股有限公司 一种分布式数据的处理方法和系统
US11327937B1 (en) * 2015-09-18 2022-05-10 Amazon Technologies, Inc. Determining indexing progress for a table in a distributed data store
US10140313B2 (en) 2015-09-27 2018-11-27 International Business Machines Corporation Parallel processing of large data files on distributed file systems with dynamic workload balancing
US9871731B2 (en) * 2015-09-30 2018-01-16 Microsoft Technology Licensing, Llc Data plane manipulation in a load balancer
US10423625B2 (en) * 2015-10-08 2019-09-24 Samsung Sds America, Inc. Exactly-once semantics for streaming analytics in non-idempotent output operations
US9910713B2 (en) 2015-12-21 2018-03-06 Amazon Technologies, Inc. Code execution request routing
US10067801B1 (en) 2015-12-21 2018-09-04 Amazon Technologies, Inc. Acquisition and maintenance of compute capacity
WO2017107118A1 (en) * 2015-12-24 2017-06-29 Intel Corporation Facilitating efficient communication and data processing across clusters of computing machines in heterogeneous computing environment
US11232085B2 (en) * 2016-01-07 2022-01-25 Amazon Technologies, Inc. Outlier detection for streaming data
US10122788B2 (en) * 2016-03-29 2018-11-06 Amazon Technologies, Inc. Managed function execution for processing data streams in real time
WO2017172440A1 (en) 2016-03-30 2017-10-05 Amazon Technologies, Inc. Processing pre-existing data sets at an on-demand code execution environment
US11132213B1 (en) 2016-03-30 2021-09-28 Amazon Technologies, Inc. Dependency-based process of pre-existing data sets at an on demand code execution environment
US10891145B2 (en) 2016-03-30 2021-01-12 Amazon Technologies, Inc. Processing pre-existing data sets at an on demand code execution environment
CN107292186B (zh) * 2016-03-31 2021-01-12 阿里巴巴集团控股有限公司 一种基于随机森林的模型训练方法和装置
US11221890B2 (en) * 2016-06-22 2022-01-11 Verizon Media Inc. Systems and methods for dynamic partitioning in distributed environments
US11442792B2 (en) * 2016-06-22 2022-09-13 Yahoo Assets Llc Systems and methods for dynamic partitioning in distributed environments
US10102040B2 (en) 2016-06-29 2018-10-16 Amazon Technologies, Inc Adjusting variable limit on concurrent code executions
US10248523B1 (en) * 2016-08-05 2019-04-02 Veritas Technologies Llc Systems and methods for provisioning distributed datasets
US10884787B1 (en) 2016-09-23 2021-01-05 Amazon Technologies, Inc. Execution guarantees in an on-demand network code execution system
US10917324B2 (en) * 2016-09-28 2021-02-09 Amazon Technologies, Inc. Network health data aggregation service
US9858151B1 (en) * 2016-10-03 2018-01-02 International Business Machines Corporation Replaying processing of a restarted application
US10108345B2 (en) 2016-11-02 2018-10-23 Samsung Electronics Co., Ltd. Victim stream selection algorithms in the multi-stream scheme
US10439917B2 (en) * 2016-11-15 2019-10-08 At&T Intellectual Property I, L.P. Recovering a replica in an operator in a data streaming processing system
US10409648B1 (en) * 2017-03-01 2019-09-10 Amazon Technologies, Inc. Splitting processing responsibility for separately stored data partitions
US10761743B1 (en) 2017-07-17 2020-09-01 EMC IP Holding Company LLC Establishing data reliability groups within a geographically distributed data storage environment
US10817388B1 (en) 2017-07-21 2020-10-27 EMC IP Holding Company LLC Recovery of tree data in a geographically distributed environment
US10581945B2 (en) 2017-08-28 2020-03-03 Banjo, Inc. Detecting an event from signal data
US11025693B2 (en) 2017-08-28 2021-06-01 Banjo, Inc. Event detection from signal data removing private information
US10313413B2 (en) * 2017-08-28 2019-06-04 Banjo, Inc. Detecting events from ingested communication signals
US10902000B2 (en) 2017-09-29 2021-01-26 Oracle International Corporation Heartbeat propagation in a distributed stream processing system
US10452444B1 (en) * 2017-10-19 2019-10-22 Pure Storage, Inc. Storage system with compute resources and shared storage resources
US10880040B1 (en) 2017-10-23 2020-12-29 EMC IP Holding Company LLC Scale-out distributed erasure coding
US11269731B1 (en) 2017-11-22 2022-03-08 Amazon Technologies, Inc. Continuous data protection
EP3718021A4 (en) 2017-11-27 2021-08-18 Snowflake Inc. BATCH DATA ACQUISITION IN DATABASE SYSTEMS
US10382554B1 (en) 2018-01-04 2019-08-13 Emc Corporation Handling deletes with distributed erasure coding
US10812544B2 (en) * 2018-01-26 2020-10-20 Salesforce.Com, Inc. Transfer of data streaming services to provide continuous data flow
US11126608B2 (en) * 2018-01-31 2021-09-21 Salesforce.Com, Inc. Techniques and architectures for partition mapping in a multi-node computing environment
US10733085B1 (en) 2018-02-05 2020-08-04 Amazon Technologies, Inc. Detecting impedance mismatches due to cross-service calls
US10831898B1 (en) 2018-02-05 2020-11-10 Amazon Technologies, Inc. Detecting privilege escalations in code including cross-service calls
US10585724B2 (en) 2018-04-13 2020-03-10 Banjo, Inc. Notifying entities of relevant events
US10261846B1 (en) 2018-02-09 2019-04-16 Banjo, Inc. Storing and verifying the integrity of event related data
US10725752B1 (en) 2018-02-13 2020-07-28 Amazon Technologies, Inc. Dependency handling in an on-demand network code execution system
US10776091B1 (en) 2018-02-26 2020-09-15 Amazon Technologies, Inc. Logging endpoint in an on-demand code execution system
US10817374B2 (en) 2018-04-12 2020-10-27 EMC IP Holding Company LLC Meta chunks
US10579297B2 (en) 2018-04-27 2020-03-03 EMC IP Holding Company LLC Scaling-in for geographically diverse storage
US10936196B2 (en) 2018-06-15 2021-03-02 EMC IP Holding Company LLC Data convolution for geographically diverse storage
US11023130B2 (en) 2018-06-15 2021-06-01 EMC IP Holding Company LLC Deleting data in a geographically diverse storage construct
FR3082973B1 (fr) * 2018-06-22 2020-06-05 Bull Sas Procede de gestion de panne dans un reseau de noeuds base sur une strategie locale
FR3082974B1 (fr) * 2018-06-22 2020-06-05 Bull Sas Procede de gestion de panne dans un reseau de nœuds base sur une strategie globale
US10853115B2 (en) 2018-06-25 2020-12-01 Amazon Technologies, Inc. Execution of auxiliary functions in an on-demand network code execution system
US10649749B1 (en) 2018-06-26 2020-05-12 Amazon Technologies, Inc. Cross-environment application of tracing information for improved code execution
US11146569B1 (en) 2018-06-28 2021-10-12 Amazon Technologies, Inc. Escalation-resistant secure network services using request-scoped authentication information
US10949237B2 (en) 2018-06-29 2021-03-16 Amazon Technologies, Inc. Operating system customization in an on-demand network code execution system
US10768830B1 (en) 2018-07-16 2020-09-08 Amazon Technologies, Inc. Streaming data service with isolated read channels
US10956246B1 (en) 2018-07-16 2021-03-23 Amazon Technologies, Inc. Isolated read channel management interfaces at streaming data service
US10855754B1 (en) 2018-07-16 2020-12-01 Amazon Technologies, Inc. Isolated read channel categories at streaming data service
US10798140B1 (en) 2018-07-16 2020-10-06 Amazon Technologies, Inc. Stream data record reads using push-mode persistent connections
US11075984B1 (en) 2018-07-16 2021-07-27 Amazon Technologies, Inc. Workload management at streaming data service supporting persistent connections for reads
US11070600B1 (en) 2018-07-16 2021-07-20 Amazon Technologies, Inc. Optimization techniques to support lagging readers at streaming data service
US11099870B1 (en) 2018-07-25 2021-08-24 Amazon Technologies, Inc. Reducing execution times in an on-demand network code execution system using saved machine states
US11243953B2 (en) 2018-09-27 2022-02-08 Amazon Technologies, Inc. Mapreduce implementation in an on-demand network code execution system and stream data processing system
US11099917B2 (en) 2018-09-27 2021-08-24 Amazon Technologies, Inc. Efficient state maintenance for execution environments in an on-demand code execution system
US10606709B1 (en) * 2018-10-26 2020-03-31 EMC IP Holding Company LLC Method and system for intelligently load balancing database backup operations in information technology environments
US11436203B2 (en) * 2018-11-02 2022-09-06 EMC IP Holding Company LLC Scaling out geographically diverse storage
US11943093B1 (en) 2018-11-20 2024-03-26 Amazon Technologies, Inc. Network connection recovery after virtual machine transition in an on-demand network code execution system
US11934409B2 (en) 2018-11-23 2024-03-19 Amazon Technologies, Inc. Continuous functions in a time-series database
US10901635B2 (en) 2018-12-04 2021-01-26 EMC IP Holding Company LLC Mapped redundant array of independent nodes for data storage with high performance using logical columns of the nodes with different widths and different positioning patterns
US10884812B2 (en) 2018-12-13 2021-01-05 Amazon Technologies, Inc. Performance-based hardware emulation in an on-demand network code execution system
US10931777B2 (en) 2018-12-20 2021-02-23 EMC IP Holding Company LLC Network efficient geographically diverse data storage system employing degraded chunks
US11119683B2 (en) 2018-12-20 2021-09-14 EMC IP Holding Company LLC Logical compaction of a degraded chunk in a geographically diverse data storage system
US10892782B2 (en) 2018-12-21 2021-01-12 EMC IP Holding Company LLC Flexible system and method for combining erasure-coded protection sets
US11023331B2 (en) 2019-01-04 2021-06-01 EMC IP Holding Company LLC Fast recovery of data in a geographically distributed storage environment
US11941028B2 (en) * 2019-01-10 2024-03-26 Box, Inc. Efficient process for creating range-partitioned indexes ensuring uniform document distribution
US11544387B2 (en) * 2019-01-16 2023-01-03 International Business Machines Corporation Hash protection within an object storage library
US10942827B2 (en) 2019-01-22 2021-03-09 EMC IP Holding Company LLC Replication of data in a geographically distributed storage environment
US10936239B2 (en) 2019-01-29 2021-03-02 EMC IP Holding Company LLC Cluster contraction of a mapped redundant array of independent nodes
US10942825B2 (en) 2019-01-29 2021-03-09 EMC IP Holding Company LLC Mitigating real node failure in a mapped redundant array of independent nodes
US10846003B2 (en) 2019-01-29 2020-11-24 EMC IP Holding Company LLC Doubly mapped redundant array of independent nodes for data storage
US10866766B2 (en) 2019-01-29 2020-12-15 EMC IP Holding Company LLC Affinity sensitive data convolution for data storage systems
US11409725B1 (en) * 2019-02-04 2022-08-09 Amazon Technologies, Inc. Multi-tenant partitioning in a time-series database
US11010188B1 (en) 2019-02-05 2021-05-18 Amazon Technologies, Inc. Simulated data object storage using on-demand computation of data objects
US11861386B1 (en) 2019-03-22 2024-01-02 Amazon Technologies, Inc. Application gateways in an on-demand network code execution system
US10944826B2 (en) 2019-04-03 2021-03-09 EMC IP Holding Company LLC Selective instantiation of a storage service for a mapped redundant array of independent nodes
US11029865B2 (en) 2019-04-03 2021-06-08 EMC IP Holding Company LLC Affinity sensitive storage of data corresponding to a mapped redundant array of independent nodes
US11113146B2 (en) 2019-04-30 2021-09-07 EMC IP Holding Company LLC Chunk segment recovery via hierarchical erasure coding in a geographically diverse data storage system
US11119686B2 (en) 2019-04-30 2021-09-14 EMC IP Holding Company LLC Preservation of data during scaling of a geographically diverse data storage system
US11121727B2 (en) 2019-04-30 2021-09-14 EMC IP Holding Company LLC Adaptive data storing for data storage systems employing erasure coding
US11748004B2 (en) 2019-05-03 2023-09-05 EMC IP Holding Company LLC Data replication using active and passive data storage modes
US11119809B1 (en) 2019-06-20 2021-09-14 Amazon Technologies, Inc. Virtualization-based transaction handling in an on-demand network code execution system
US11115404B2 (en) 2019-06-28 2021-09-07 Amazon Technologies, Inc. Facilitating service connections in serverless code executions
US11190609B2 (en) 2019-06-28 2021-11-30 Amazon Technologies, Inc. Connection pooling for scalable network services
US11159528B2 (en) 2019-06-28 2021-10-26 Amazon Technologies, Inc. Authentication to network-services using hosted authentication information
US10938882B2 (en) * 2019-07-09 2021-03-02 Servicenow, Inc. Preprocessing and storage of cloud service usage reports
US11209996B2 (en) 2019-07-15 2021-12-28 EMC IP Holding Company LLC Mapped cluster stretching for increasing workload in a data storage system
CN110569206A (zh) * 2019-07-16 2019-12-13 广州市中海达测绘仪器有限公司 一种支持多传感器的驱动框架、方法、电子设备及存储介质
US11449399B2 (en) 2019-07-30 2022-09-20 EMC IP Holding Company LLC Mitigating real node failure of a doubly mapped redundant array of independent nodes
US11023145B2 (en) 2019-07-30 2021-06-01 EMC IP Holding Company LLC Hybrid mapped clusters for data storage
WO2021029862A1 (en) * 2019-08-12 2021-02-18 Nokia Technologies Oy Ran coordination for high reliability in tsn networks
WO2021041915A1 (en) * 2019-08-28 2021-03-04 Sparta Systems, Inc. Method, apparatus, and computer readable medium for generating an audit trail of an electronic data record
US11228322B2 (en) 2019-09-13 2022-01-18 EMC IP Holding Company LLC Rebalancing in a geographically diverse storage system employing erasure coding
GB201913348D0 (en) * 2019-09-16 2019-10-30 Palantir Technologies Inc Data deletion system and method
US11216487B1 (en) 2019-09-23 2022-01-04 Amazon Technologies, Inc. Schema-based spatial partitioning in a time-series database
US11449248B2 (en) 2019-09-26 2022-09-20 EMC IP Holding Company LLC Mapped redundant array of independent data storage regions
US11106477B2 (en) 2019-09-27 2021-08-31 Amazon Technologies, Inc. Execution of owner-specified code during input/output path to object storage service
US11360948B2 (en) 2019-09-27 2022-06-14 Amazon Technologies, Inc. Inserting owner-specified data processing pipelines into input/output path of object storage service
US11550944B2 (en) 2019-09-27 2023-01-10 Amazon Technologies, Inc. Code execution environment customization system for object storage service
US10996961B2 (en) 2019-09-27 2021-05-04 Amazon Technologies, Inc. On-demand indexing of data in input path of object storage service
US11023416B2 (en) 2019-09-27 2021-06-01 Amazon Technologies, Inc. Data access control system for object storage service based on owner-defined code
US10908927B1 (en) 2019-09-27 2021-02-02 Amazon Technologies, Inc. On-demand execution of object filter code in output path of object storage service
US11023311B2 (en) 2019-09-27 2021-06-01 Amazon Technologies, Inc. On-demand code execution in input path of data uploaded to storage service in multiple data portions
US11386230B2 (en) 2019-09-27 2022-07-12 Amazon Technologies, Inc. On-demand code obfuscation of data in input path of object storage service
US11416628B2 (en) 2019-09-27 2022-08-16 Amazon Technologies, Inc. User-specific data manipulation system for object storage service based on user-submitted code
US11656892B1 (en) 2019-09-27 2023-05-23 Amazon Technologies, Inc. Sequential execution of user-submitted code and native functions
US11250007B1 (en) 2019-09-27 2022-02-15 Amazon Technologies, Inc. On-demand execution of object combination code in output path of object storage service
US11055112B2 (en) 2019-09-27 2021-07-06 Amazon Technologies, Inc. Inserting executions of owner-specified code into input/output path of object storage service
US11263220B2 (en) 2019-09-27 2022-03-01 Amazon Technologies, Inc. On-demand execution of object transformation code in output path of object storage service
US11394761B1 (en) 2019-09-27 2022-07-19 Amazon Technologies, Inc. Execution of user-submitted code on a stream of data
US11288139B2 (en) 2019-10-31 2022-03-29 EMC IP Holding Company LLC Two-step recovery employing erasure coding in a geographically diverse data storage system
US11119690B2 (en) 2019-10-31 2021-09-14 EMC IP Holding Company LLC Consolidation of protection sets in a geographically diverse data storage environment
US11435910B2 (en) 2019-10-31 2022-09-06 EMC IP Holding Company LLC Heterogeneous mapped redundant array of independent nodes for data storage
US11435957B2 (en) 2019-11-27 2022-09-06 EMC IP Holding Company LLC Selective instantiation of a storage service for a doubly mapped redundant array of independent nodes
US10942795B1 (en) 2019-11-27 2021-03-09 Amazon Technologies, Inc. Serverless call distribution to utilize reserved capacity without inhibiting scaling
US11119826B2 (en) 2019-11-27 2021-09-14 Amazon Technologies, Inc. Serverless call distribution to implement spillover while avoiding cold starts
US11526500B2 (en) * 2019-12-12 2022-12-13 Sap Se System and method for initiating bulk inserts in a distributed database
US11144220B2 (en) 2019-12-24 2021-10-12 EMC IP Holding Company LLC Affinity sensitive storage of data corresponding to a doubly mapped redundant array of independent nodes
CN113127380A (zh) * 2019-12-31 2021-07-16 华为技术有限公司 部署实例的方法、实例管理节点、计算节点和计算设备
US11231860B2 (en) 2020-01-17 2022-01-25 EMC IP Holding Company LLC Doubly mapped redundant array of independent nodes for data storage with high performance
US11714682B1 (en) 2020-03-03 2023-08-01 Amazon Technologies, Inc. Reclaiming computing resources in an on-demand code execution system
US11188391B1 (en) 2020-03-11 2021-11-30 Amazon Technologies, Inc. Allocating resources to on-demand code executions under scarcity conditions
US11507308B2 (en) 2020-03-30 2022-11-22 EMC IP Holding Company LLC Disk access event control for mapped nodes supported by a real cluster storage system
US11775640B1 (en) 2020-03-30 2023-10-03 Amazon Technologies, Inc. Resource utilization-based malicious task detection in an on-demand code execution system
US11288229B2 (en) 2020-05-29 2022-03-29 EMC IP Holding Company LLC Verifiable intra-cluster migration for a chunk storage system
JP2021192189A (ja) * 2020-06-05 2021-12-16 富士通株式会社 パイプライン分割位置決定方法及びパイプライン分割位置決定プログラム
US11640402B2 (en) 2020-07-22 2023-05-02 International Business Machines Corporation Load balancing in streams parallel regions
US11693983B2 (en) 2020-10-28 2023-07-04 EMC IP Holding Company LLC Data protection via commutative erasure coding in a geographically diverse data storage system
US11341006B1 (en) * 2020-10-30 2022-05-24 International Business Machines Corporation Dynamic replacement of degrading processing elements in streaming applications
US11593270B1 (en) 2020-11-25 2023-02-28 Amazon Technologies, Inc. Fast distributed caching using erasure coded object parts
US11550713B1 (en) 2020-11-25 2023-01-10 Amazon Technologies, Inc. Garbage collection in distributed systems using life cycled storage roots
US11847141B2 (en) 2021-01-19 2023-12-19 EMC IP Holding Company LLC Mapped redundant array of independent nodes employing mapped reliability groups for data storage
US11625174B2 (en) 2021-01-20 2023-04-11 EMC IP Holding Company LLC Parity allocation for a virtual redundant array of independent disks
US11416312B1 (en) 2021-02-12 2022-08-16 Microsoft Technology Licensing, Llc Near-real-time data processing with partition files
US11354191B1 (en) 2021-05-28 2022-06-07 EMC IP Holding Company LLC Erasure coding in a large geographically diverse data storage system
US11449234B1 (en) 2021-05-28 2022-09-20 EMC IP Holding Company LLC Efficient data access operations via a mapping layer instance for a doubly mapped redundant array of independent nodes
US11388210B1 (en) 2021-06-30 2022-07-12 Amazon Technologies, Inc. Streaming analytics using a serverless compute system
CN113673822B (zh) * 2021-07-15 2023-08-11 微梦创科网络科技（中国）有限公司 一种弹性调度方法及系统
CN113656369A (zh) * 2021-08-13 2021-11-16 辽宁华盾安全技术有限责任公司 一种大数据场景下的日志分布式流式采集及计算方法
US11941029B2 (en) 2022-02-03 2024-03-26 Bank Of America Corporation Automatic extension of database partitions

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005250839A (ja) * 2004-03-04 2005-09-15 Nomura Research Institute Ltd 耐障害性システム
US20130073724A1 (en) * 2011-09-16 2013-03-21 Rutgers, The State University Of New Jersey Autonomic Workflow Management in Dynamically Federated, Hybrid Cloud Infrastructures
US8572091B1 (en) * 2011-06-27 2013-10-29 Amazon Technologies, Inc. System and method for partitioning and indexing table data using a composite primary key

Family Cites Families (73)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5692177A (en) * 1994-10-26 1997-11-25 Microsoft Corporation Method and system for data set storage by iteratively searching for perfect hashing functions
US5813009A (en) 1995-07-28 1998-09-22 Univirtual Corp. Computer based records management system method
US5864677A (en) * 1996-07-01 1999-01-26 Sun Microsystems, Inc. System for preserving sequential ordering and supporting nonidempotent commands in a ring network with busy nodes
US6249879B1 (en) * 1997-11-11 2001-06-19 Compaq Computer Corp. Root filesystem failover in a single system image environment
US7386586B1 (en) 1998-12-22 2008-06-10 Computer Associates Think, Inc. System for scheduling and monitoring computer processes
US6272598B1 (en) 1999-03-22 2001-08-07 Hewlett-Packard Company Web cache performance by applying different replacement policies to the web cache
US6505216B1 (en) * 1999-10-01 2003-01-07 Emc Corporation Methods and apparatus for backing-up and restoring files using multiple trails
US8055894B2 (en) 1999-11-09 2011-11-08 Google Inc. Process and streaming server for encrypting a data stream with bandwidth based variation
US6584581B1 (en) * 1999-12-06 2003-06-24 Ab Initio Software Corporation Continuous flow checkpointing data processing
JP2002010234A (ja) 2000-06-19 2002-01-11 Sony Corp コンテンツ配信システム及び方法、情報提供装置、情報端末、記録媒体
US7418470B2 (en) * 2000-06-26 2008-08-26 Massively Parallel Technologies, Inc. Parallel processing systems and method
US7047309B2 (en) * 2000-08-23 2006-05-16 International Business Machines Corporation Load balancing and dynamic control of multiple data streams in a network
US7266823B2 (en) * 2002-02-21 2007-09-04 International Business Machines Corporation Apparatus and method of dynamically repartitioning a computer system in response to partition workloads
EP1359722A1 (en) 2002-03-27 2003-11-05 BRITISH TELECOMMUNICATIONS public limited company Data streaming system and method
JP4062441B2 (ja) 2003-07-18 2008-03-19 日本電気株式会社 並列処理システム及び並列処理プログラム
US8234517B2 (en) * 2003-08-01 2012-07-31 Oracle International Corporation Parallel recovery by non-failed nodes
JP4601969B2 (ja) 2004-01-27 2010-12-22 株式会社日立製作所 ファイル入出力制御装置
WO2005109212A2 (en) * 2004-04-30 2005-11-17 Commvault Systems, Inc. Hierarchical systems providing unified of storage information
US8024733B2 (en) * 2004-05-13 2011-09-20 International Business Machines Corporation Component model for batch computing in a distributed object environment
TWI370979B (en) 2004-05-14 2012-08-21 Ibm Grid computing system, information processing unit, job execution request generation unit, control method, program, and recording medium
US7814056B2 (en) 2004-05-21 2010-10-12 Computer Associates Think, Inc. Method and apparatus for data backup using data blocks
US8255422B2 (en) * 2004-05-28 2012-08-28 Microsoft Corporation Highly reliable and scalable architecture for data centers
US7861246B2 (en) * 2004-06-17 2010-12-28 Platform Computing Corporation Job-centric scheduling in a grid environment
US7814492B1 (en) * 2005-04-08 2010-10-12 Apple Inc. System for managing resources partitions having resource and partition definitions, and assigning a named job to an associated partition queue
TW200717246A (en) 2005-06-24 2007-05-01 Koninkl Philips Electronics Nv Self-synchronizing data streaming between address-based producer and consumer circuits
KR100715674B1 (ko) * 2005-09-15 2007-05-09 한국전자통신연구원 부하 분산 방법 및 장치, 그리고 이를 이용한 소프트웨어스트리밍 시스템
US7606844B2 (en) * 2005-12-19 2009-10-20 Commvault Systems, Inc. System and method for performing replication copy storage operations
US7716180B2 (en) 2005-12-29 2010-05-11 Amazon Technologies, Inc. Distributed storage system with web services client interface
US7921077B2 (en) * 2006-06-29 2011-04-05 Netapp, Inc. System and method for managing data deduplication of storage systems utilizing persistent consistency point images
US8095745B1 (en) 2006-08-07 2012-01-10 Marvell International Ltd. Non-sequential transfer of data from a memory
US7716186B2 (en) 2007-01-22 2010-05-11 International Business Machines Corporation Method and system for transparent backup to a hierarchical storage system
WO2009061903A2 (en) 2007-11-10 2009-05-14 Landmark Graphics Corporation Systems and methods for workflow automation, adaptation and integration
JP4800289B2 (ja) 2007-11-30 2011-10-26 富士通セミコンダクター株式会社 電源制御装置及びその電源制御装置を有するシステムｌｓｉ
US8190960B1 (en) * 2007-12-13 2012-05-29 Force10 Networks, Inc. Guaranteed inter-process communication
US8126048B2 (en) 2008-03-18 2012-02-28 Seiko Epson Corporation Recording streaming delta-encoded data
US8488661B2 (en) 2008-06-13 2013-07-16 Verizon Patent And Licensing Inc. Systems and methods for data streaming
US8255739B1 (en) 2008-06-30 2012-08-28 American Megatrends, Inc. Achieving data consistency in a node failover with a degraded RAID array
US9996572B2 (en) 2008-10-24 2018-06-12 Microsoft Technology Licensing, Llc Partition management in a partitioned, scalable, and available structured storage
US8533478B2 (en) * 2008-10-24 2013-09-10 Hewlett-Packard Development Company, L. P. System for and method of writing and reading redundant data
JP5396848B2 (ja) 2008-12-16 2014-01-22 富士通株式会社 データ処理プログラム、サーバ装置およびデータ処理方法
US8161255B2 (en) 2009-01-06 2012-04-17 International Business Machines Corporation Optimized simultaneous storing of data into deduplicated and non-deduplicated storage pools
US20100257140A1 (en) 2009-03-31 2010-10-07 Philip John Davis Data archiving and retrieval system
US8560639B2 (en) 2009-04-24 2013-10-15 Microsoft Corporation Dynamic placement of replica data
US8495413B2 (en) 2009-12-15 2013-07-23 Unisys Corporation System and method for providing a computer standby node
US9501365B2 (en) 2009-12-28 2016-11-22 Netapp, Inc. Cloud-based disaster recovery of backup data and metadata
US8607242B2 (en) * 2010-09-02 2013-12-10 International Business Machines Corporation Selecting cloud service providers to perform data processing jobs based on a plan for a cloud pipeline including processing stages
US8719362B2 (en) 2010-09-09 2014-05-06 Riverbed Technology, Inc. Tiered storage interface
JP2012080417A (ja) 2010-10-04 2012-04-19 Pioneer Electronic Corp ストリーミング再生装置、ストリーミング再生方法、コンピュータプログラム及び記録媒体
US9110936B2 (en) 2010-12-28 2015-08-18 Microsoft Technology Licensing, Llc Using index partitioning and reconciliation for data deduplication
US9262504B2 (en) 2011-02-15 2016-02-16 At&T Intellectual Property I, L.P. Methods, systems, and products for maintaining data consistency in a stream warehouse
US20120233315A1 (en) * 2011-03-11 2012-09-13 Hoffman Jason A Systems and methods for sizing resources in a cloud-based environment
US8774213B2 (en) 2011-03-30 2014-07-08 Amazon Technologies, Inc. Frameworks and interfaces for offload device-based packet processing
US9628535B2 (en) 2011-04-15 2017-04-18 International Business Machines Corporation Data streaming infrastructure for remote execution in a constrained environment
US8745434B2 (en) 2011-05-16 2014-06-03 Microsoft Corporation Platform for continuous mobile-cloud services
US8751863B2 (en) 2011-05-23 2014-06-10 Microsoft Corporation Implementing failover processes between storage stamps
EP3313083B1 (en) 2011-06-08 2019-12-18 Koninklijke KPN N.V. Spatially-segmented content delivery
US9251481B2 (en) 2011-06-13 2016-02-02 Accenture Global Services Limited Distributed metering and monitoring system
US8463633B2 (en) 2011-07-27 2013-06-11 Xerox Corporation Methods and systems for deploying a service workflow in a hybrid cloud environment
US8489680B1 (en) 2011-08-18 2013-07-16 Google Inc. Transmission of input values using an unreliable communication link
JP5760898B2 (ja) 2011-09-26 2015-08-12 沖電気工業株式会社 配信システム、仮想マシン割当装置およびプログラム
JP5818394B2 (ja) 2011-11-10 2015-11-18 トレジャー データ, インク.Treasure Data, Inc. 大量データプラットフォームを操作するシステム及び方法
CA2889387C (en) 2011-11-22 2020-03-24 Solano Labs, Inc. System of distributed software quality improvement
US8886781B2 (en) * 2011-12-13 2014-11-11 Microsoft Corporation Load balancing in cluster storage systems
US8762378B2 (en) 2011-12-23 2014-06-24 Sap Ag Independent table nodes in parallelized database environments
US10860563B2 (en) * 2012-01-06 2020-12-08 Microsoft Technology Licensing, Llc Distributed database with modular blocks and associated log files
US9753999B2 (en) * 2012-01-06 2017-09-05 Citus Data Bilgi Islemieri Ticaret A.S. Distributed database with mappings between append-only files and repartitioned files
CN103281594A (zh) 2012-01-12 2013-09-04 特克特朗尼克公司 监控基于开放互联网的自适应视频流式传输
US8887056B2 (en) * 2012-08-07 2014-11-11 Advanced Micro Devices, Inc. System and method for configuring cloud computing systems
US8904231B2 (en) * 2012-08-08 2014-12-02 Netapp, Inc. Synchronous local and cross-site failover in clustered storage systems
EP3737047A1 (en) * 2012-09-21 2020-11-11 NYSE Group, Inc. High performance data streaming
US8943353B2 (en) * 2013-01-31 2015-01-27 Hewlett-Packard Development Company, L.P. Assigning nodes to jobs based on reliability factors
US9183016B2 (en) * 2013-02-27 2015-11-10 Vmware, Inc. Adaptive task scheduling of Hadoop in a virtualized environment
US9336288B2 (en) * 2013-06-03 2016-05-10 Bank Of America Corporation Workflow controller compatibility

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005250839A (ja) * 2004-03-04 2005-09-15 Nomura Research Institute Ltd 耐障害性システム
US8572091B1 (en) * 2011-06-27 2013-10-29 Amazon Technologies, Inc. System and method for partitioning and indexing table data using a composite primary key
US20130073724A1 (en) * 2011-09-16 2013-03-21 Rutgers, The State University Of New Jersey Autonomic Workflow Management in Dynamically Federated, Hybrid Cloud Infrastructures

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020521238A (ja) * 2017-05-15 2020-07-16 アルテリックス インコーポレイテッド キャッシュ最適化及び効率的な処理のためのデータ集約の方法
JP7038740B2 (ja) 2017-05-15 2022-03-18 アルテリックス インコーポレイテッド キャッシュ最適化及び効率的な処理のためのデータ集約の方法
KR20190088188A (ko) * 2018-01-18 2019-07-26 주식회사 알티스트 파티셔닝을 적용하여 프로세스를 모니터링하는 컴퓨팅 시스템
KR102043538B1 (ko) 2018-01-18 2019-11-11 주식회사 알티스트 파티셔닝을 적용하여 프로세스를 모니터링하는 컴퓨팅 시스템
JP7461354B2 (ja) 2018-08-23 2024-04-03 アルカス インコーポレイテッド ネットワークルーティング環境における独立データストア
KR102096737B1 (ko) * 2019-03-28 2020-04-02 한국과학기술원 저밀도 패리티 검사 부호를 활용한 고장 방지 능력을 갖춘 분산 기계 학습 방법 및 그 장치
KR20210058401A (ko) * 2019-11-14 2021-05-24 대구대학교 산학협력단 클라우드 컴퓨팅 환경에서의 컨테이너 배치 장치 및 방법
KR102426132B1 (ko) 2019-11-14 2022-07-26 대구대학교 산학협력단 클라우드 컴퓨팅 환경에서의 컨테이너 배치 장치 및 방법
KR102188132B1 (ko) * 2020-05-27 2020-12-07 비코어(주) 데이터 적재 및 처리 시스템 및 그 방법
US11797513B2 (en) 2020-05-27 2023-10-24 Bcore Data loading and processing system, and method therefor
EP3940535A1 (en) 2020-07-17 2022-01-19 Fujitsu Limited Information processing method and information processing program
US11599388B2 (en) 2020-07-17 2023-03-07 Fujitsu Limited Processing program to rearrange order of task in stream processing

Also Published As

Publication number Publication date
CA2930101A1 (en) 2015-05-14
JP6450756B2 (ja) 2019-01-09
AU2014346366B2 (en) 2017-09-14
EP3069228B1 (en) 2018-09-19
AU2014346366A1 (en) 2016-06-02
US10635644B2 (en) 2020-04-28
US20150134626A1 (en) 2015-05-14
WO2015070236A1 (en) 2015-05-14
CN105706047A (zh) 2016-06-22
EP3069228A1 (en) 2016-09-21
EP3069228A4 (en) 2017-06-14
CA2930101C (en) 2020-06-16

Similar Documents

Publication Publication Date Title
JP6450756B2 (ja) パーティションベースのデータストリーム処理フレームワーク
JP6510112B2 (ja) データストリーム取り込み及び永続性ポリシ
US10795905B2 (en) Data stream ingestion and persistence techniques
US10691716B2 (en) Dynamic partitioning techniques for data streams
EP3069274B1 (en) Managed service for acquisition, storage and consumption of large-scale data streams
EP3069495B1 (en) Client-configurable security options for data streams

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160511

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170510

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170606

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20170906

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171106

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20180501

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180829

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20180905

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20181113

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181210

R150 Certificate of patent or registration of utility model

Ref document number: 6450756

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250