JP6357243B2 - データストリーム取り込み及び永続性ポリシ - Google Patents

データストリーム取り込み及び永続性ポリシ Download PDF

Info

Publication number
JP6357243B2
JP6357243B2 JP2016553274A JP2016553274A JP6357243B2 JP 6357243 B2 JP6357243 B2 JP 6357243B2 JP 2016553274 A JP2016553274 A JP 2016553274A JP 2016553274 A JP2016553274 A JP 2016553274A JP 6357243 B2 JP6357243 B2 JP 6357243B2
Authority
JP
Japan
Prior art keywords
data
stream
partition
node
client
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.)
Active
Application number
JP2016553274A
Other languages
English (en)
Other versions
JP2017501515A (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
Priority claimed from US14/077,162 external-priority patent/US9858322B2/en
Priority claimed from US14/077,171 external-priority patent/US9720989B2/en
Application filed by アマゾン・テクノロジーズ・インコーポレーテッド filed Critical アマゾン・テクノロジーズ・インコーポレーテッド
Publication of JP2017501515A publication Critical patent/JP2017501515A/ja
Application granted granted Critical
Publication of JP6357243B2 publication Critical patent/JP6357243B2/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
    • 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

データ記憶の費用が年とともに下落するに従い、また、計算インフラストラクチャの様々な要素を相互接続する能力が改善するにつれ、多種多様のアプリケーションに対応可能なより多くのデータが、場合により収集され分析され得る。例えば、携帯電話は、位置、電話のユーザによって使用されるアプリケーション等を示すデータを生成することができ、少なくともそのいくつかは、カスタマイズされたクーポン、広告等をユーザに提示するために、収集され分析され得る。監視カメラによって収集されたデータの分析は、犯罪を防止し及び／または解決する上で有用であってよく、航空機のエンジン、自動車または複雑な機械装置内部の様々な位置に埋め込まれたセンサから収集されたデータは、予防保全、効率の向上及び費用の低減のような様々な目的に使用され得る。
ストリーミングデータ量の増加は、商品のハードウェアの使用増加に付随する（及び場合によっては可能になった）。商品のハードウェア用の仮想化技術の到来は、多くの種類のアプリケーション用の大規模な計算リソースを運用するに際し、様々な計算リソースが効率的に、かつ安全に多数の顧客によって共有されるのを可能にするという利点を提供してきた。例えば、仮想化技術は、単一の物理的計算機によりホスティングされる１つ以上の仮想マシンを各ユーザに提供することによって、単一の物理的計算機が多数のユーザ間で共有されることを可能にてよく、それぞれのこのような仮想マシンは、独自の論理計算システムとして動作するソフトウェアシミュレーションであり、自分が唯一の操作者であり、所与のハードウェアの計算リソースを管理しているという錯覚をユーザに提供する。一方、様々な仮想マシンの間にアプリケーションの単独及び安全も提供し得る。さらに、ある仮想化技術は、多数の異なる物理計算システムに及ぶ多数の仮想プロセッサを備える単一の仮想マシンのような、２つまたはそれ以上の物理リソースに及ぶ仮想リソースを提供することが可能である。計算プラットフォームに加えて、いくつかの大きな組織は、また、仮想技術を使用して構築された、様々な種類のストレージサービスを提供している。このようなストレージサービスを使用し、大量のデータが所望の耐久レベルで記憶され得る。
様々なプロバイダから比較的低コストで仮想化した計算リソース及び／またはストレージリソースを入手可能であるものの、しかしながら、大きく動的に変動するデータストリームを収集、記憶及び処理の管理及びオーケストレーションは、様々な理由で難易度の高い仕事である。より多くのリソースが大量のデータストリームを扱うために設定されたシステムに追加されるにつれ、例えば、システムの異なる部分間のワークロードにおける不均衡が生じ得る。この不均衡に対処がされないままの場合には、その他のリソースの利用が不十分になることに加え（及び、そのため損失）、このような不均衡は、いくつかのリソースで重大な性能障害に繋がり得る。このようなデータまたは結果がクライアントが制御しない設備に格納される場合には、クライアントはまた、ストリーミングデータまたはストリーミングデータの分析結果の安全性に関して、懸念し得る。分散システムのサイズが大きくなるにつれて、時折起こる接続故障及び／またはハードウェア破損のような、頻度の増加とともに自然に起こり得る破損は、費用のかかる破損からストリームデータの収集、記憶または分析を守るために、効果的に対処されなければならない場合もある。
少なくともいくつかの実施形態による、データストリームの構想の簡略化した概略を提供する。 少なくともいくつかの実施形態による、ストリーム処理ステージの収集を含む、ストリーム管理システム（ＳＭＳ）及びストリーム処理システム（ＳＰＳ）の様々なサブコンポーネントの間のデータの流れの概略を提供する。 少なくともいくつかの実施形態による、ＳＭＳ及びＳＰＳで実装され得るプログラムによるインタフェースのそれぞれのセットの例を示す。 少なくともいくつかの実施形態による、ＳＰＳクライアントがストリーム処理ステージのグラフ生成を可能にするために実装され得るウェブベースのインタフェースの例を示す。 少なくともいくつかの実施形態による、ＳＭＳで実装され得る、プログラミングによるレコードのサブミッションインタフェース及びレコード検索インタフェースの例を示す。 少なくともいくつかの実施形態による、ＳＭＳの取り込みサブシステムの実施例の要素を示す。 少なくともいくつかの実施形態による、ＳＭＳのストレージサブシステムの実施例の要素を示す。 少なくともいくつかの実施形態による、ＳＭＳの検索サブシステム及びＳＰＳでの検索サブシステムの相互作用の実施例の要素を示す。 少なくともいくつかの実施形態による、ＳＭＳまたはＳＰＳのノード用に設定され得る冗長グループの実施例を示す。 少なくともいくつかの実施形態による、所与の冗長グループのノードが複数のデータセンタに分散され得る、プロバイダのネットワーク環境を示す。 少なくともいくつかの実施形態による、ＳＭＳまたはＳＰＳのノード用に選択され得る複数の宛先の実施例を示す。 少なくともいくつかの実施形態による、ＳＰＳクライアント及びＳＭＳクライアントのそれぞれによって送信され得る、セキュリティオプションの要求の実施例を示す。 少なくともいくつかの実施形態による、ストリームデータ生成部とＳＭＳの取り込みノードとの間の相互作用の実施例を示す。 少なくともいくつかの実施形態による、ＳＭＳで取り込まれたデータレコードのために生成され得る、シーケンス番号の実施例の要素を示す。 少なくともいくつかの実施形態による、ＳＭＳでストリームデータレコードが並べられたストレージ及び検索の実施例を示す。 少なくともいくつかの実施形態による、ＳＭＳノード及びＳＰＳノードのために作製され得るストリームパーティションマッピング及び対応する構成決定の実施例を示す。 少なくともいくつかの実施形態による、動的ストリームの再分割の実施例を示す。 少なくともいくつかの実施形態による、ストリームレコードの取り込み及びストリームレコードの検索用のプログラムによるインタフェースのそれぞれのセットを支援するために実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、ストリーム処理ステージを構成するよう実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、ストリーム処理ワーカノードの構成のための、クライアントのライブラリコンポーネントの呼び出しに対応して実行され得る動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、ストリーム処理のために１つ以上のリカバリポリシを実装するために実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、データストリーム用の複数のセキュリティオプションを実装するために実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、データストリームのためにポリシの分割を実装するために実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、データストリームの動的再分割を実装するために実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、データストリームレコード用の少なくとも１回のレコードの取り込みポリシを実装するために実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、データストリーム用の複数の永続性ポリシを実装するために実行され得る、動作の態様を示すフローチャートである。 少なくともいくつかの実施形態による、処理ステージのワーカノードがデータベーステーブルを使用してワークロードを調節するストリーム処理システムの例を示す。 少なくともいくつかの実施形態による、ワークロードの調節に使用されるパーティションの割り当てテーブルに記憶され得る入力の実施例を示す。 少なくともいくつかの実施形態による、処理動作を実行するパーティションを選択するために、ストリーム処理ステージのワーカノードによって実行され得る動作の態様を示す。 少なくともいくつかの実施形態による、ストリーム管理サービス制御サブシステムから取得された情報に基づいて、パーティション割り当てテーブルをアップデートするために、ストリーム処理ステージのワーカノードによって実行され得る動作の態様を示す。 少なくともいくつかの実施形態による、ストリーム処理ステージのワーカノードによって実行され得る負荷分散動作の態様を示す。 少なくともいくつかの実施形態で使用され得る計算装置の実施例を示すブロック図である。
実施形態は、いくつかの実施形態及び説明図用に一例として本明細書で記載されているものの、当業者は、実施形態は実施形態または図面に限定されないことを理解するであろう。図面及び詳細な説明は、開示された特定の形式の実施形態に限定することを意図せず、反対に添付の特許請求の範囲により規定されるように趣旨及び範囲内にある全ての修正、等価物及び代替物を網羅しようとするものであると理解すべきである。本明細書で使用された見出しは、組織の目的のためのみであり、記述の範囲または特許請求の範囲を限定するために使用されることを意図したものではない。本願の全体を通じて使用されるとき、「してもよい」という語は、義務の意味（即ち必須を意味する）というよりはむしろ、許可の意味で使用されている（即ち、あることを行う可能性を有することを意味する）。同様に、「含む」、「含んでいる」は、含んでいることを意味するが、これらに限定されない。
何百または何千もの同時並行データ生成部及びデータコンシューマの取り扱いを目的とした、大規模データストリームの作成、記憶、検索及び処理を管理するための方法及び装置の様々な実施形態が記載されている。本発明で使用する場合、「データストリーム」という用語は、１つ以上のデータ生成部によって生成し、１つ以上のデータコンシューマによってアクセスされ得るデータレコードのシーケンスを意味し、各データレコードは、不変のバイト列であると仮定される。いくつかの実施形態では、ストリーム管理サービス（ＳＭＳ）は、ストリームデータレコードの送信、記憶及び検索と同様に、ストリームの作成、構成及び削除を可能にするために、プログラムによるインタフェース（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）、ウェブページ若しくはウェブサイト、グラフィカルユーザインターフェースまたはコマンドラインツール）を提供し得る。ＳＭＳ制御コンポーネントとの相互作用を含む、（ストリーム作成若しくは削除、または下記に記載の動的再分割操作の種類のような）いくつかの種類のストリーム操作は、本明細書では「制御プレーン」操作と呼ばれることもある。一方、典型的には、制御コンポーネントとの相互作用を必要としない（例えば、通常の操作条件下で）データレコードの送信、記憶及び検索のような操作は、本明細書では「データプレーン」操作と呼ばれることもある。ダイナミックプロビジョンされた計算、記憶及びネットワークリソースのセットは、例えば、さらに詳細に後述のように、ストリーム管理ワークロードが数々のサービスコンポーネントの中でスケーラブルな方法で分散されることが可能な様々なパーティションポリシに基づいて、このようないくつかの実施形態におけるサービスを実装するために使用され得る。頭字語のＳＭＳは、本明細書においてはストリーム管理サービスを意味するために使用され得る。また、ストリーム管理サービスを実装するために使用される、仮想及び／または物理リソースの収集を含む、ストリーム管理システムを意味するために使用され得る。
ＳＭＳの何人かの顧客は、様々な実施形態で、ＳＭＳプログラムによるインタフェースを直接起動するアプリケーションを開発し得る。少なくともいくつかの実施形態では、しかしながら、ＳＭＳインタフェースに加えて、より高いレベルの抽象化またはアプリケーションレベルの処理フレームワークは、顧客に提供されてよく、ＳＭＳによって直接支援される、より低いレベルのストリーム管理機能を使用するアプリケーションの開発を望まない、これらのクライアントに対するストリーム処理の様々な態様を簡略化し得る。このようなフレームワークは、それ自身のプログラムによるインタフェース（例えば、ＳＭＳインタフェースの上部に設置）を提供してよく、より低いレベルのストリーム管理操作よりも顧客がストリームレコードを使用して実装されるビジネスロジックにより集中し得る。より高いレベルのフレームワークは、いくつかの実施形態では、それ自身の制御プレーン及びデータプレーンコンポーネントを備えるストリーム処理サービス（ＳＰＳ）として実装されてよく、ストリーム処理のための自動リソースプロビジョニング、処理ノードの自動フェイルオーバ、任意のストリーム処理ワークフローグラフを構築する能力、一過性のストリームの支援、ワークロードの変化またはその他のトリガ条件に基づいた動的再分割等のような、高度な機能性を提供し得る。少なくともいくつかの実施形態では、ストリーム管理サービス、ストリーム処理サービスの何れか、または両方のサービスは、仮想環境においてマルチテナント管理ネットワークでアクセス可能なサービスであり得る。すなわち、（コンピュータサーバまたはホスト、記憶装置、ネットワーク装置等のような）様々な物理リソースは、少なくとも場合によっては、リソースがどのように共有されているのか正確に顧客に必ずしも気付かせる必要がなく、あるいは所与のリソースが共有されていることを全く気付かせることさえなく、このような実施形態における異なる顧客のストリーム間で共有される。管理されたマルチテナントストリーム管理及び／または処理中の管理サービスの制御コンポーネントは、動的に追加、削除し、または様々な適用可能なポリシに基づいた特定のストリームに使用されるノード若しくはリソースを再構成してよく、それらのいくつかはクライアントが選択可能であり得る。加えて、制御コンポーネントは、また、（例えば、少なくともいくつかのハードウェアまたはソフトウェアが双方のクライアントに共有される可能性があっても、１つのクライアントのストリームのアプリケーションは別のクライアントのデータにアクセスすることができないことを確実にするための）様々な種類のセキュリティプロトコルを、透過的に実装する役割をし、監査またはデバック等に使用され得る請求、ロギング情報の生成のためのリソース使用状況を監視する。管理されたマルチテナントサービス（単数または複数）のクライアントの見地から、サービス（単数または複数）によって実装される制御／管理者機能は、大規模のストリーミングアプリケーションを支援することに伴う複雑さの大部分を解消し得る。いくつかの場合では、このようなマルチテナントサービスの顧客は、少なくともいくつかの種類のストリーム関連の操作のためのリソースを共有したくない場合には、いくつかの物理リソースは、これらの種類の操作のためにシングルテナントのように少なくとも一時的に指定され得る（すなわち、単一の顧客またはクライアントに代わって実行される操作に限定する）ことを表すことが可能であり得る。
様々な実施形態では、いくつかの異なる手法がＳＭＳ及び／またはＳＰＳ制御プレーン及びデータプレーン操作を実装するためにとられ得る。例えば、制御プレーンの操作に関しては、いくつかの実装では、制御サーバまたはノードの冗長グループが設定され得る。冗長グループは複数の制御サーバを含んでよく、そのうちの１つのサーバは、様々なストリームに関して管理者の要求に応答する役割をするプライマリサーバとして示されている。一方、別のサーバは、現在のプライマリでの破損（または接続不良）のようなトリガ条件の場合、プライマリとして引き継ぐように示され得る。別の実装においては、ネットワークにアクセス可能なデータベースサービスで作成された１つ以上のテーブルは、様々なストリームに（パーティションマップのような）制御プレーンメタデータを格納するために使用され得る。また、様々な取り込み、記憶ノードや検索ノードは、データプレーン操作に必要なメタデータのサブセットの取得する必要に応じてテーブルにアクセス可能であり得る。異なる実施形態における、ＳＰＳ及びＳＭＳデータプレーン及び制御プレーンの機能性の様々な態様に関する詳細は、下記に提供されている。ストリーム管理サービスが実装される、いくつかの実施形態では、より高いレベルの基本要素を提供するストリーム処理サービスは必ずしも実装されない可能性があることに注意する。その他の実施形態では、高いレベルのストリーム処理サービスのプログラムによるインタフェースのみが顧客に公開され、使用されるより低レベルのストリーム管理インタフェースはクライアントには入手可能ではない。
いくつかの実施形態によると、ストリーム管理システムは、データレコードを取得または収集する役割を主にするレコード取り込みサブシステムと、適用可能な永続性または耐久性ポリシによるデータレコードコンテンツを保存する役割を主にするレコード記憶サブシステムと、及び格納されたレコードに向けられた読み出し要求に応答する役割を主にするレコード検索サブシステムと、を含む、複数の独立して構成可能なサブシステムを備え得る。制御サブシステムは、また、いくつかの実施形態において実装され、例えば、動的に判定することによって及び／または必要な数のノードを初期化することによって、サブシステムを、仮想または物理サーバのような選択されたリソースで取り込み、記憶及び取得するために、残りのサブシステムを構成する役割をする１つ以上の管理者または制御コンポーネントを備え得る。取り込み、記憶、検索及び制御サブシステムのそれぞれは、全体がサブシステムの「ノード」または「サーバ」と呼ばれ得る、複数のハードウェア及び／またはソフトウェアコンポーネントのそれぞれを使用して実装され得る。このように、ＳＭＳの様々なリソースが、取り込み、記憶、検索または制御という４つの機能カテゴリのうちの１つに論理的に属するとされ得る。いくつかの実装においては、制御コンポーネントのそれぞれのセットは、その他のサブシステムのそれぞれに構築され得る。例えば、独立取り込み制御サブシステム、記憶制御サブシステム及び／または検索制御サブシステムが実装され得る。それぞれのこのような制御サブシステムは、対応するサブシステムのその他のノードのために及び／またはクライアントまたはその他のサブシステムからの管理クエリに応答するために、使用されるリソースを識別する役割をし得る。いくつかの実装においては、様々な種類のＳＭＳ及び／またはＳＰＳの機能を可能にするノードプールは、予め設定されてよく、これらのプールの選択されたメンバは、必要に応じて新しいストリームまたは新しい処理ステージに割り当てられ得る。
ストリームパーティションポリシ及び関連するマッピングは、例えば、取り込み、記憶、検索及び／または制御ノードの異なるセットの間のデータレコードのサブセットに分散するために、少なくともいくつかの実施形態においては、実装され得る。例えば、レコード取り込み率及び／または検索率の予想のようなその他の要因と同様に、特定のデータストリームに選択されるパーティションポリシに基づいて、制御コンポーネントは、いくつのノード（例えばプロセスまたはスレッド）が取り込み、記憶及び検索のために最初に確率されるか（すなわち、ストリーム作成時間）、及びこれらのノードがどのように仮想及び／または物理マシンにマッピングされるべきかを判定し得る。時間の経過とともに、所与のストリームに関連するワークロードは、増加または減少してよく、これは（その他のトリガ条件のなかで）ストリームの再分割という結果をもたらし得る。このような再分割は、レコードのパーティション、使用されるパーティションキー、パーティションのすべての数、取り込みノードの数、記憶ノード若しくは検索ノード、または異なる物理リソース若しくは仮想リソースへのノードの配置を判定するために使用される機能のような、様々なパラメータへの変更を伴い得る。少なくともいくつかの実施形態では、さらに詳細に書きに記載された技術を使用して、再分割はデータレコードの流れを中断することなく動的に実装され得る。いくつかの実施形態では、異なるパーティションの手法及び再分割のトリガ基準は、例えば、クライアントが提供するパラメータまたはＳＭＳ制御ノードの発見に基づいて異なるデータストリームに使用され得る。いくつかの実施形態では、再分割の数及び／または頻度を制限することが可能であり得る。例えば、クライアントの好み、ストリームの予想耐用期間またはその他の要因である。
いくつかの異なるレコード取り込みポリシ及びインタフェースは、異なる実施形態において実装され得る。例えば、いくつかの実施形態では、クライアント（例えば、ＳＭＳの顧客に代わってＳＭＳのプログラムによるインタフェースを起動するよう構成された実行可能なコンポーネントまたはモジュール）は、インラインサブミッションインタフェースまたはバイリファレンスサブミッションインタフェースの何れにも利用し得る。その実施形態において、インラインサブミッションには、データレコードのコンテンツまたは本文がサブミッション要求の一部として含まれ得る。対照的に、バイリファレンスサブミッション要求においては、アドレス（記憶装置アドレス、データベースレコードアドレスまたはＵＲＬ（ユニフォームリソースロケータ））は、データレコードのコンテンツまたは本文が取得され得るところから提供され得る。いくつかの実装においては、ハイブリッドサブミッションインタフェースも、または代わりに支援され得る。データレコードの第１のＮバイトはインラインに含まれ得る。それに対し、残りのバイト（可能ならば）は、参照により提供される。このような場合には、短いレコード（その本文がＮバイトの長さ未満である）はサブミッション要求によって十分に指定され得るが、一方、それよりも長いレコードの部分は対応するアドレスから入手し得る。
取り込み中のレコードコンテンツを指定するための異なる選択肢に加え、いくつかの実施形態では、様々な応答または複製排除に関連する取り込みポリシもまた、実装され得る。例えば、いくつかのストリームアプリケーションには、クライアントはそれぞれ及び全てのデータレコードがＳＭＳによって確実に取り込まれることを確保したい場合がある。大規模に分散されるストリーム管理環境においては、データ生成部と取り込みノードとの間のパスに沿ってパケットは破損するか、様々な障害が時折起こり得、これはいくつかの送信されたデータを潜在的に失う結果となり得る。したがって、いくつかの実施形態では、レコード送信者は、同じレコードを、肯定応答が取り込みサブシステムから受信されるまで、１度以上送信し得ることにより、ＳＭＳは少なくとも１回の取り込みポリシを実装し得る。通常の操作環境下では、レコードは一度送信されてよく、送信者は受信する取り込みノードがレコードを取得し格納した後に応答を受信してよい。応答が損失されたか遅延した場合、またはレコード送信要求自体が損失された場合には、送信者は、最終的に応答が受信されるまで、同じデータレコードを１度以上再送信してよい。例えば、応答がすでに送信者によって受信されていた場合、レコードは再送信されないという予想に基づいて、取り込みノードは、送信が複製であるか否かにかかわらず、各送信に対し応答を生成し得る。しかしながら、取り込みノードは、少なくともいくつかの実施形態では、同一のデータレコードは複数回送信されたことを認識し、複製のデータの新しいコピーを不必要に記憶することを避ける役割をし得る。一実施形態では、少なくとも１回の取り込みポリシの少なくとも２つのバージョンは、（「少なくとも１回の取り込み、複製不可」と称され得る）、ＳＭＳがデータレコードを複製排除する役割をする（すなわち、２つまたはそれ以上の送信のセットの１つのみに対応して、データがＳＭＳ記憶サブシステムに格納されることを確実にする）１つのバージョン、及び、（「少なくとも１回、複製可」と称され得る）ＳＭＳによってデータレコードストレージの複製が許可される１つのバージョンを支援され得る。少なくとも１回の複製が許可された手法は、データレコードの複製の否定的な結果が少数であるか、全く無いストリームアプリケーション、及び／またはそれ自身の複製を排除を実行するストリームアプリケーションには有用であり得る。その他の取り込みポリシもまた、応答が送信されたデータレコード毎に必要とされないベストエフォートの取り込みポリシのように支援され得る。少数のデータレコードの損失は、ベストエフォートの取り込みポリシが少なくともいくつかの実施形態で有効である場合に受け入れ可能であり得る。クライアントは様々な実施形態における様々なストリームに使用を希望する取り込みポリシを選択し得る。
ストリームレコードの記憶に関しては、いくつかの代替的なポリシもまた、少なくともいくつかの実施形態で支援され得る。例えば、クライアントはＳＭＳによって支援されるいくつかのうちから永続性のポリシを選択可能であってよく、これは格納されるべき所与のデータレコードのコピーの数として、このようなレコードの記憶の態様を管理し、記憶技術の種類（例えば、揮発性または不揮発性ＲＡＭ、回転ディスクベースのストレージ、固体装置（ＳＳＤ）、ネットワーク接続記憶装置等）がコピー等に使用され得る。例えば、クライアントがディスクベースのストレージサーバへのＮ−レプリカ永続性ポリシを選択する場合、データレコードの送信は、レコードのＮコピーがＮの各ディスク装置に安全に書き込まれるまで完全であると考えられない可能性がある。ディスクベースの記憶装置が使用される少なくともいくつかの実施形態では、ＳＭＳ記憶サブシステムは、例えばディスクシークのパフォーマンスインパクトを避けるために、順次、ディスクに対して所与のパーティションの入ってくるデータレコードの書き込みを試み得る。シーケンス番号は、例えば、取り込み時間に基づいて並べられたレコード検索を可能にするタイムスタンプに基づいた技術を含む、様々な下記の技術を使用してデータレコードに生成（かつ記憶）され得る。少なくともいくつかの実施形態では、所与のパーティションのデータレコードは、例えば、ディスクに連続的に、及びその他のパーティションのデータレコードから分離して一緒に記憶され得る。いくつかの実装においては、（クライアント若しくはＳＭＳによって選択された）保持ポリシまたは（任意の所与のデータレコードの送信後の期間を表示し、その間、いくつかの複製が送信されたとしてもＳＭＳは、複製のないその所与のデータレコードが、ＳＭＳ記憶サブシステムに格納されることを確保する必要があり得る）複製排除時間窓ポリシによれば、少なくともいくつかのデータレコードは、異なる種類のストレージサービスに移され得る及び／またはＳＭＳからある期間の後に削除され得る。このような除去の操作は、本明細書においては、「トリミング」と称し得る。クライアントはいくつかの実施形態では、ストリームをトリミングする要求を送信し得る。例えば、ＳＭＳに指定のデータレコードはもはや必要されておらず、そのためトリミング要求を送信するクライアントの見地から、削除が可能であることを通知するか、または指定のデータレコードの削除を明示的に要求する。多数のクライアントが所与のストリームのデータレコードを使用する可能性がある場合では、ＳＭＳは、すべての関係コンシューマによってアクセスされる前に、所与のレコードが尚早に削除またはトリミングされないことを確実にする役割があってよい。いくつかの実装においては、所与のストリームのＮデータコンシューマがある場合には、ストリームの所与のレコードＲを削除する前に、ＳＭＳはすべてのＮデータコンシューマがＲを読み出しまたは尚早に処理したことを判定するまで待機し得る。例えば、コンシューマからの各トリミング要求に基づいて、または、ストリーム内でデータコンシューマがどのくらい進んでいるかというそれぞれの表示に基づいて、Ｒはすべてのコンシューマによって読み込まれたと、ＳＭＳは判定し得る。いくつかの実施形態では、データコンシューマの（テストに関連するアプリケーションのような）いくつかの種類は、アクセスされる前に、少なくとも一部の部分のデータレコードの削除を受け入れ得る。したがって、アプリケーションは、少なくともいくつかの実施形態においては、検索前にデータ削除の受容性に関してＳＭＳに通知可能であってよく、及びＳＭＳはその通知によって削除を予定し得る。いくつかの実施形態では、例えば、データ保持ポリシの一部として、保存用のポリシが実装されてよく、例えば、ストリームデータレコードがコピーされるべき記憶装置の種類を表示し、ポリシがこのようなコピーへの使用とを予定する。
少なくともいくつかの実施形態においては、複数のプログラムによるインタフェースもまた、レコード検索のために支援され得る。一実施形態では、イテレータベースの手法が使用されてよく、一プログラムによるインタフェース（例えば、ｇｅｔＩｔｅｒａｔｏｒ）はインスタンス化し、イテレータまたはカーソルを指定の理論オフセットに配置するために、ストリームのパーティション内で（例えば、シーケンス番号またはタイムスタンプに基づいて）使用され得る。次に（ｇｅｔＮｅｘｔＲｅｃｏｒｄのような）異なるプログラムによるインタフェースは、イテレータの現在位置から順次開始する指定の数のデータレコードを読み込むために使用され得る。イテレータのインスタンス化は、要するに、クライアントが恣意的または無作為の開始位置を、ストリームパーティション内でレコード検索するために特定することを可能にし得る。クライアントがこのような実施形態で無作為なアクセスパターンでデータレコードの読み出しを希望する場合には、クライアントは繰り返し新しいイテレータを生成しなくてはならない場合がある。回転ディスクベースの記憶システムにおいては、頻繁なランダムアクセスに必要とされるディスクシークは、Ｉ／Ｏ応答回数に著しく影響を与える場合がある。したがって、ストリームデータレコードを無作為に読み込むよりも順次に読み込むことをクライアントに促すために、少なくともいくつかの実施形態では、異なる（例えば高い）課金率が、シーケンシャルリードアクセスに適用されるよりも、ランダムリードアクセスに適用され得る。したがって、いくつかの実装においてはＸ＞Ｙの状態で、例えば、クライアントはｇｅｔＩｔｅｒａｔｏｒ通話毎にＸ通貨単位で、及び、レコード検索毎にｇｅｔＮｅｘｔＲｅｃｏｒｄを介しＹ通貨単位請求され得る。代替的なクライアントインタフェースが、（取り込みのような）その他の操作カテゴリに支援される場合、少なくともいくつかの実施形態では、課金率または代替物の価格もまた、異なり得る。クライアントがシーケンシャルリードよりもランダムリードにより課金され得るのと同様に、例えば、クライアントは、オンラインの送信要求よりもバイリファレンスの送信要求により課金され得る。データレコードのサイズ、時間の経過とともに書き込み対読み出し要求の分散、選択された永続性ポリシ等のような、その他の要因もまた様々な実施形態において課金に影響し得る。
いくつかの実施形態によると、ストリーム処理サービス（ＳＰＳ）は、クライアントが、多数の処理ステージを含む複雑な処理ワークフローを適宜、特定することを可能にし、所与のステージで実行される処理の出力が、ゼロまたはそれ以上のその他のステージ用に入力として使用され得る。パーティションポリシ（データレコードの取り込み、格納及び検索のためのＳＭＳに記載されるものに類似）は、いくつかの実施形態における様々なステージで複数のワーカノードのうち処理中のワークロードを分割するために使用され得る。このような一実施形態では、プログラムによるＳＰＳインタフェースは、クライアントが任意の所与のステージのために様々な構成設定を特定可能なように実装されてよく、例えば、ステージのために入力データソース（単数または複数）（例えば、ストリーム用のパーティションポリシと一緒に、データレコードが検索される１つ以上のストリーム）、ステージで実行される処理操作、及びステージからの出力または結果の分散のためディスクリプタまたは指定（例えば、出力が記憶位置に保存され、ネットワークの終点に送信され、または異なるストリームの形式で１つ以上のその他のステージに入力されるか否かを問わず）を含む。少なくともいくつかの実施形態では、ＳＰＳステージのために指定される処理操作は冪等であり得る。すなわち、所与の処理操作が同じ入力データで複数回実行される場合、操作の結果は、操作が１回のみ実行された場合に得られたであろう結果とは異ならない。さらに詳細に後述のように、破損からのリカバリ（例えば、ＳＰＳステージでのワーカノードの損失）は、処理操作が冪等の場合、簡略化され得る。いくつかの実施形態によると、非冪等の処理操作はいくつかのまたはすべてのＳＰＳステージで許可され得る。
入力ストリームパーティションポリシ及び次にＳＰＳプログラムによるインタフェースを介して受信される処理操作の性質のような構成情報に少なくとも部分的に基づいて、様々な実施形態では、処理ワークフローの様々なステージのために、どのくらいの数のワーカノードが最初に設定されるべきかをＳＰＳ制御サーバは判定し得る。ワーカノードに使用されるリソースの遂行能力（例えば、使用される仮想マシンまたは物理マシン）もまた、初期番号及びワーカノードの配置を決定する際に、考慮され得る。選択されたワーカノードの番号は、インスタンス化され得る（いくつかの実装では、実行可能なスレッドまたは実行可能なプロセスをそれぞれ備える）。各ワーカノードは、例えば、適切な入力ソースからデータレコードを（例えば、１つ以上のストリームパーティションの検索ノードから）取得し、データレコードで指定された処理操作を実行し、及び指定された宛先（単数または複数）に処理の結果を伝送するよう構成され得る。加えて、少なくともいくつかの実施形態では、パーティションレコードが連続して処理される仮定で、所与のワーカノードは、そのワーカノードで処理されてきたプログレスレコードまたはパーティションの一部を示すチェックポイントを格納するよう構成され得るにしたがい、チェックポイントのスキームが実装され得る。いくつかの実装において、例えば、ワーカノードは、プログレスレコードを永続性ストレージに定期的（例えば、Ｎ秒毎に１度、またはＲデータレコードに１度が処理されている）に及び／またはＳＰＳ制御サーバからチェックポイントの要求に対応して、書き込みしてよい。
いくつかの実施形態では、プログレスレコードはワーカノードの破損から迅速にリカバリするために使用され得る。例えば、ＳＰＳ制御サーバは、（ＣＰＵ利用、Ｉ／Ｏ装置利用またはネットワーク利用レベルのような）例えば、ハートビート機構の使用及び／またはリソース利用レベルの監視により、様々なワーカノードの健康状態を時間の経過とともに監視し得る。特定のワーカノードが好ましくないまたは健康ではない状態にあるとのＳＰＳ制御サーバによる判定に対応して（例えば、応答しないかオーバーロードの場合）、交換されたワーカノードは特定のワーカノードの役割を引き継ぐためにインスタンス化され得る。交換されたワーカノードは、交換されたワーカノードによって格納された最新のプログレスレコードにアクセスして、交換されたワーカノードが処理すべきデータレコードのセットを識別し得る。処理操作が冪等である実施形態では、いくつかの操作が繰り返されていても（例えば、最新のプログレスレコードが交換されたワーカのインスタンス化以前のある時に書き込まれたため）、処理全体の結果は破損及び交換の影響を受けないであろう。いくつかの実装においては、所与のストリームのサブセットまたはこのサブセットによって処理されたパーティションを表すプログレスレコードを格納することに加えて、ワーカノードもまた、蓄積されたアプリケーション状態の情報を格納するよう構成され得る。例えば、ストリーム処理ワークフローは、サービス使用メトリクスを表すストリーミングデータレコードの分析に基づいて特定のサービスのためクライアント課金額を決定する役割をする場合には、ワーカノードは、様々なクライアントに決定された累積の課金額を定期的に格納し得る。
少なくともいくつかの実施形態では、ＳＰＳ制御サーバは、また、様々なステージのための入力ストリームの動的再分割の要求のようなその他の動作を開始し、所与のステージで所与のパーティションに割り当てられたワーカノードの数の変更し、いくつかのステージにより高い性能のワーカノードの割り当てし、または異なる性能能力で１つの物理リソースから別の物理リソースへワーカノードの伝達することによって、ワークロードレベル若しくは検出されたワークロードの不均衡（例えば、１つのパーティションに対する取り込みレートがその他のものよりも不均衡に高くなっている場合）の変更のような、様々なその他のトリガに、応答するよう構成され得る。いくつかの実施形態では、例えば、ベストエフォートリカバリポリシは、チェックポイントベースのリカバリポリシよりもむしろ、所与のステージのために実装されるＳＰＳ制御サーバによる判定に対応して、上記に記載した種類のプログレスレコードは、少なくともいくつかのＳＰＳステージのワーカノードによって格納されない場合がある。このようなベストエフォートリカバリポリシのいくつかの実装においては、交換されたワーカノードは、プログレスレコードにアクセスする必要なく、受信された際に新しいデータレコードを単純に処理し得る。いくつかの実施形態では、クライアントがＳＰＳステージでベストエフォートリカバリポリシの実装を希望する場合には、ステージで実行されるストリーム処理操作は必ずしも冪等である必要はない。非冪等の処理操作がＳＰＳステージでストリームレコード上で実行されるいくつかの実施形態では、チェックポイントベースのリカバリは支援されなくてよく、ベストエフォートリカバリのような異なるリカバリスキームが使用され得る。少なくとも一実施形態においては、冪等ストリーム処理操作のみがＳＰＳステージ許容され得る。
いくつかのストリームのデータレコードは、秘密または機密情報を含み、またはＳＰＳステージで実行される処理操作は、競合相手による発見は問題となり得る著作権のあるアルゴリズムの使用を含み得る。そのため、クライアントは様々なカテゴリのストリーム管理及び処理操作のセキュリティについて、特に操作が、クライアント自身によって完全に制御されないプロバイダネットワークデータセンタに配置されるリソースを使用して実行される場合、関心があり得る。インターネット及び／またはその他のネットワークを介して分散されたクライアントのセットにアクセス可能な（様々な種類のクラウドベースのデータベース、電算処理またはストレージサービスのような）１つ以上のネットワークにアクセス可能なサービスを提供する会社または公的部門の組織のようなエンティティによって設定されるネットワークは、本明細書ではプロバイダネットワークと称され得る。いくつかの実施形態では、クライアントはデータストリームのために、複数のセキュリティに関連する選択肢のうちから選択可能であり得る。上記のように、組み合わされたＳＰＳ及びＳＭＳの構成は、ＳＭＳ及び／またはＳＰＳ用の制御ノード、ＳＭＳ取り込みノード、ＳＭＳ記憶ノード、ＳＭＳ検索ノード及びＳＰＳ処理若しくはワーカノードのような、異なる機能のカテゴリのいくつかに属するノードを備え得る。いくつかの実施形態では、クライアントが入手可能であるセキュリティに関連する選択肢は、様々な種類のノードの位置または配置のため選択肢を含み得る。例えば、一実施形態では、クライアントは、たとえストリームレコードが当初、プロバイダネットワークに配置されるリソースを使用して収集及び／または格納されても、ストリームワークフローの１つ以上の処理ステージのためのＳＰＳワーカノードは、クライアント所有の設備に配置された計算装置に実装されることを要求することが可能であり得る。このような配置要求に対応して、所与のストリームのための異なる機能カテゴリのノードは、異なるセキュリティ特性またはプロフィールとセットで各リソースでインスタンス化され得る。
リソースセットは、異なる実施形態において、例えば、物理位置、使用される物理セキュリティプロトコル（例えば、リソースへの物理アクセルを有するもの）、ネットワーク隔離レベル（例えば、リソースのネットワークアドレスが様々なエンティティに可視である範囲）、マルチテナント対シングルテナント等を含む、様々なセキュリティに関連する特性が互いに異なり得る。いくつかの実施形態では、クライアントのＩＶＮ内に含まれた様々な装置のネットワーク構成を実質的に制御する所与のクライアントとともに、クライアントは、プロバイダネットワーク内に隔離された仮想ネットワーク（ＩＶＮ）を確率し得る。特に、クライアントは、様々なサーバまたはＩＶＮ内のコンピュートインスタンスに割り当てられたネットワークアドレス（例えば、インターネットプロトコルまたはＩＰアドレス）にアクセスすることを制限し得る。このような実施形態においては、クライアントはＳＭＳノードまたはＳＰＳノードの一定のサブセットが特定のＩＶＮ内でインスタンス化されることを要求し得る。仮想インスタンスホスト（典型的にはマルチテナントホストとして構成され得る）のようなプロバイダネットワークリソースが、ＳＭＳノードまたはＳＰＳノードの様々なカテゴリに使用される実施形態では、クライアントは、いくつかのセットのノードは、クライアントのみに属するインスタンスの実装を制限されるインスタンスホスト上でインスタンス化されることを要求し得る（すなわち、いくつかのＳＭＳノードまたはＳＰＳノードはシングルテナントホストとして構成されたインスタンスホストに実装され得る）。
いくつかの実施形態では、別のセキュリティ関連の選択肢としては、クライアントは、特定のストリームのデータレコードは、例えば、ＳＭＳに取り込まれる前に、取り込みと記憶サブシステムとの間、記憶サブシステムと検索サブシステムとの間、検索サブシステムとＳＰＳワーカノードとの間、及び／またはワーカノードとＳＰＳ出力宛先との間のネットワークリンクから伝送される前に暗号化されることを要求し得る。クライアントはいくつかの実施形態にて使用される暗号化アルゴリズムを特定し得る。一実施形態では、ＴＬＳ（トランスポート層セキュリティ）またはＳＳＬ（セキュアソケット層）プロトコルのようなセキュアなネットワークプロトコルは、データレコードの伝送及び／またはＳＰＳ処理結果の伝送に使用され得る。
データストリームのコンセプト及び概略
図１は、少なくともいくつかの実施形態による、データストリームの構想の簡略化した概略を提供する。ここに示すように、ストリーム１００は、ＤＲ１１０Ａ、１１０Ｂ、１１０Ｃ、１１０Ｄ及び１１０Ｅのような複数のデータレコード（ＤＲ）１１０を備え得る。データ生成部１２０Ａ及びデータ生成部１２０Ｂのような１つ以上のデータ生成部１２０（データソースとも称され得る）ストリーム１００のデータレコードの内容を生成するために書き込み操作１５１を実行し得る。いくつかの異なる種類のデータ生成部は、例えば、携帯電話あるいはタブレットアプリケーション、センサアレイ、ソーシャルメディアプラットフォーム、ロギングアプリケーションあるいはシステムロギングコンポーネント、種々のモニタリングエージェント等のような、異なる実施形態においてデータのストリームを生成し得る。（データコンシューマ１３０Ａ及びデータコンシューマ１３０Ｂのような）１つ以上のデータコンシューマ１３０は、データ生成部１２０によって生成されたデータレコードの内容にアクセスするために読み出し操作１５２を実行し得る。いくつかの実施形態では、データコンシューマ１３０は、例えば、ストリーム処理ステージのワーカノードを備え得る。
少なくともいくつかの実施形態では、ＳＭＳに記憶される際の所与のデータレコード１１０はデータ部分１０１（例えば、それぞれＤＲ１１０Ａ，１１０Ｂ，１１０Ｃ，１１０Ｄ及び１１０Ｅのデータ部分１０１Ａ、１０１Ｂ、１０１Ｃ、１０１Ｄ及び１０１Ｅ）及びシーケンス番号ＳＮ１０２（例えば、それぞれＤＲ１１０Ａ，１１０Ｂ，１１０Ｃ，１１０Ｄ及び１１０ＥのＳＮ１０２Ａ、１０２Ｂ、１０２Ｃ、１０２Ｄ及び１０２Ｅ）を備え得る。シーケンス番号１０２は記載された実施形態において、ＤＲはストリーム管理システム（またはストリーム管理システムの特定のノード）で受信された順序であることを示し得る。データ部分１０１はいくつかの実装においては、変更不能な解釈されないバイト列を含み得る。すなわち、書き込み操作１５２が完了すると、書き込みの結果として生じたＤＲの内容は、ＳＭＳによって変更されなくてよく、一般にＳＭＳはデータの意味を認識しなくてよい。いくつかの実装においては、所与のストリーム１００の異なるデータレコードは、異なる量のデータを含み、それに対しその他の実施形態では、所与のストリームの全てのデータレコードは同じサイズであり得る。少なくともいくつかの実装においては、ＳＭＳのノード（例えば、取り込みサブシステムノード及び／または記憶サブシステム）は、ＳＮ１０２を生成する役割をし得る。さらに詳細に後述のように、データレコードのシーケンス番号は、必ずしも連続とは限らない。一実装においては、クライアントまたはデータ生成部１２０は、書き込み要求の一部として、対応するデータレコードに使用される最小のシーケンス番号の表示を提供し得る。いくつかの実施形態では、データ生成部１２０は、データレコードのデータの一部（またはアドレス）にポインタを含む書き込み要求を、例えば、（装置名及び装置内のオフセットのような）記憶装置のアドレスまたはデータ部分が取得され得る（ＵＲＬのような）ネットワークアドレスを提供することによって送信し得る。
様々な実施形態では、ストリーム管理サービスは、データ生成部１２０からデータを受信し、データを格納し、及びデータコンシューマ１３０を１つ以上のアクセスパターンにおいてデータをアクセス可能にする役割をし得る。少なくともいくつかの実施形態では、ストリーム１００は、データレコードを受信し、格納し、及び検索するワークロードを分散するためにパーティション化または「分割」され得る。このような実施形態においては、パーティションまたは分割は、データレコードの１つ以上の属性に基づいて入ってくるデータレコード１１０のために選択され、及びデータレコードを取り込みし、格納しまたは検索する特定のノードは、パーティションに基づいて識別され得る。いくつかの実装においては、データ生成部１２０は、パーティションの属性として機能し得る各書き込み操作を明示的なパーティションキーに提供し、及びこのようなキーはパーティション識別子にマッピングされ得る。その他の実施形態においては、ＳＭＳは、データ生成部１２０の識別、データ生成部のＩＰアドレスの要因に基づいて、または送信されたデータの内容に基づいて、パーティションＩＤを推測し得る。データストリームがパーティション化されるいくつかの実装においては、シーケンス番号はパーティション毎に割り当てられ得る。例えば、シーケンス番号は、特定のパーティションのデータレコードが受信される順序を示すが、２つの異なるパーティションにおけるデータレコードＤＲ１及びＤＲ２のシーケンス番号は、ＤＲ１及びＤＲ２が受信された関連する順序を必ずしも示さない可能性がある。その他の実装においては、データレコードＤＲ１に割り当てられたシーケンス番号ＳＮ１がデータレコードＤＲ２に割り当てられたシーケンス番号ＳＮ２よりも低い場合には、ＤＲ１及びＤＲ２がどちらのパーティションに属するかに関わらず、これは、ＤＲ１はＳＭＳによってＤＲ２よりも前に受信されたことを示すように、シーケンス番号はパーティション毎のベースよりもむしろストリーム幅に割り当てられ得る。
様々な実施形態では、ＳＭＳによって支援される検索または読み出しインタフェースは、データコンシューマ１３０がデータレコードに連続して及び／または無作為の順番でアクセスするのを可能にし得る。一実施形態では、イテレータベースの読み出しアプリケーションプログラミングインタフェース（ＡＰＩ）のセットは支援され得る。データコンシューマ１３０は、特定のシーケンス番号及び／またはパーティション識別子によって表されたイテレータの初期の位置とともに、データストリームのためにイテレータを取得するよう要求を送信し得る。イニシエータがインスタンス化された後、データコンシューマは、ストリーム内またはパーティション内の初期位置から始まるシーケンスの順序で、データレコードを読み込むために要求を送信し得る。データコンシューマが何らかの無作為の順序でデータレコードを読み込みたい場合には、このような実施形態では、新しいイテレータは各読み出しのためにインスタンス化しなければならない場合がある。少なくともいくつかの実装においては、所与のパーティションまたはストリームのデータレコードは、典型的にはディスクシークを避ける連続的な書き込み操作を使用して、シーケンス番号順でディスクベースのストレージに書き込まれ得る。シーケンシャル読み出し操作はまた、ディスクシークのオーバーヘッドを避け得る。したがって、いくつかの実施形態では、データコンシューマは無作為の読み出しよりもシーケンシャルな読み出しを実行することを価格で動機付けして奨励され得る。例えば、イテレータのインスタンス化のような、ランダムアクセス読み出し操作はシーケンシャルにアクセスする読み出し操作よりも高い関連する課金率を有し得る。
システム環境の例
図２は、少なくともいくつかの実施形態による、ストリーム処理ステージの収集を含む、ストリーム管理システム（ＳＭＳ）及びストリーム処理システム（ＳＰＳ）の様々なサブコンポーネントの間のデータの流れの概略を提供する。ここに示すように、ＳＭＳ２８０は取り込みサブシステム２０４、記憶サブシステム２０６，検索サブシステム２０８及びＳＭＳ制御サブシステム２１０を備え得る。後述のように、ＳＭＳサブシステムのそれぞれは、１つ以上のノードまたはコンポーネントを含んでよく、例えば、対応する実行可能なスレッドまたはプロバイダネットワーク（またはクライアント所有設備か第三者の設備）の様々なリソースでインスタンス化されるプロセスを使用して実装される。取り込みサブシステム２０４のノードは、ストリームに使用されるパーティションポリシに基づいて、（１２０Ａ、１２０Ｂ、及び１２０Ｃのような）データ生成部１２０から特定のデータストリームのデータレコードを取得するよう、（例えば、ＳＭＳ制御サブシステム２１０のノードによって）構成され、各取り込みノードは、記憶サブシステム２０６の対応するノードに受信されたデータレコードを渡し得る。記憶サブシステムのノードは、ストリームのために選択された永続性ポリシにより、様々な種類の記憶装置の何れかに、データレコードを保存し得る。検索サブシステム２０８のノードは、ＳＰＳ２９０のワーカノードのようなデータコンシューマからの読み出し要求に応答し得る。ＳＰＳ２９０のステージ２１５Ａ、ステージ２１５Ｂ、ステージ１２１５Ｃ及びステージ２１５Ｄのようなストリーム処理ステージ２１５は、ＳＰＳ制御サブシステム２２０の助けによって確立され得る。各ステージ２１５は、受信されたデータレコードで処理操作のセットを実行するＳＰＳ制御サブシステム２２０によって構成された１つ以上のワーカノードを含み得る。ここに示すように、（２１５Ａ及び２１５Ｂのような）いくつかのステージ２１５は、ＳＭＳ２８０から直接データレコードを取得し得る。一方、（２１５Ｃ及び２１５Ｄのような）その他は、その他のステージから入力を受信し得る。多数のＳＰＳステージ２１５は、いくつかの実施形態においては並行して操作し得る。例えば、異なる処理操作は、ステージ２１５Ａ及びステージ２１５Ｂで同じストリームから検索されたデータレコード上で同時に実行され得る。特定のストリーム用の、図２に示されたものと類似する、それぞれのサブシステム及び処理ステージは、また、その他のストリームもインスタンス化され得ることに注意する。
少なくともいくつかの実施形態においては、図２に示されているサブシステム及び処理ステージのノードのうち少なくともいくつかは、プロバイダネットワークリソースを使用して実装され得る。前述したように、インターネット及び／またはその他のネットワークを介して分散されたクライアントのセットにアクセス可能な（様々な種類のクラウドベースのデータベース、電算処理またはストレージサービスのような）１つ以上のネットワークにアクセス可能なサービスを提供する会社または公的部門の組織のようなエンティティによって設定されるネットワークは、本明細書ではプロバイダネットワークと称され得る。サービスのいくつかは、より高いレベルのサービスを構築するために使用され得る。例えば、算出、記憶またはデータベースサービスは、ストリーム管理サービスまたはストリーム処理サービスのためのビルディングブロックとして使用され得る。プロバイダネットワークの少なくともいくつかのコアサービスは、「インスタンス」と呼ばれるサービスユニットにおいてクライアントが使用するためにパッケージ化され得る。例えば、仮想計算サービスによってインスタンス化される仮想マシンは、「コンピュートインスタンス」を表し、及びストレージサービスによってインスタンス化されるブロックレベルのボリュームのような記憶装置は、「ストレージインスタンス」と呼ばれることもあり、またはデータベース管理サーバは「データベースインスタンス」と呼ばれることもある。プロバイダネットワークの様々なネットワークにアクセス可能なサービスの装置が実装される、サーバのような計算装置は、本明細書では、「インスタンスホスト」またはより簡単に「ホスト」と呼ばれ得る。いくつかの実施形態では、取り込みサブシステム２０４のノード、記憶サブシステム２０６、検索サブシステム２０８、ＳＭＳ制御システム２１０、処理ステージ２１５及び／またはＳＰＳ制御サブシステム２２０は、複数のインスタンスホスト上の様々なコンピュートインスタンスで実行するスレッドまたはプロセスを備え得る。及び／またはＳＰＳ制御サブシステム２２０は、複数のインスタンスホスト上の様々なコンピュートインスタンスで実行するスレッドまたはプロセスを備え得る。所与のインスタンスホストはいくつかのコンピュートインスタンス及び特定のインスタンスホストでコンピュートインスタンスでの収集は、１つ以上のクライアントの様々な異なるストリームのためにノードを実行するために使用され得る。ストレージインスタンスは、いくつかの実施形態では、様々なストリームのデータレコードを記憶するために使用されるか、ストリーム処理ステージの結果の宛先であり得る。図１５及び図１６を参照すると、以下に記載されるように、データレコードを依然、受信、記憶及び処理し続ける間、時間の経過とともに、例えば、ノードを追加または削除、ノードのマッピングをコンピュートインスタンスまたはインスタンスホストに変更または所与のストリームを再分割することによって、制御サブシステムは、様々なトリガ条件に対応してその他のサブシステムの人口を動的に修正し得る。
プロバイダネットワークリソースがストリームに関連した操作に使用される実施形態との関係においては、「クライアント」という用語は、所与の通信のソースまたは宛先として使用される場合、（多数のユーザまたは単一のユーザを有する組織、グループのような）エンティティに所有され、管理されまたは割り当てられる、計算装置、プロセス、ハードウェアモジュールまたはソフトウェアモジュールのいずれかを意味し得る。プロバイダネットワークの少なくとも１つのネットワークにアクセス可能なサービスにアクセスし、利用することが可能なあるサービスのクライアントは、別のサービスのリソースを使用して自身が実装され得る。例えば、ストリームデータコンシューマ（ストリーム管理サービスのクライアント）は、コンピュートインスタンス（仮想化された計算サービスによって提供されたり）を備え得る。
所与のプロバイダネットワークは、物理的及び／若しくは仮想化されたコンピュータサーバの収集、それぞれに１つ以上の記憶装置を備えるストレージサーバ及びネットワーク機器等のような、様々なリソースツールをホストする（異なる地理的領域にわたって分散され得る）多数のデータセンタを含んでよく、プロバイダによって提供されるインフラストラクチャ及びサービスを実装、構成及び分散する必要がある。いくつかの異なるハードウェア及び／またはソフトウェアコンポーネントは、そのいくつかはインスタンス化されるか、異なるデータセンタまたは異なる地理的領域で実行され得るが、様々な実施形態におけるサービスのそれぞれを実装するために一括して使用され得る。クライアントは、プロバイダネットワークの外部にあるクライアント所有またはクライアント管理の構内若しくはデータセンタに位置される装置及び／またはプロバイダネットワーク内装置から、プロバイダネットワークでリソース及びサービスと相互作用し得る。プロバイダネットワークは、本明細書で記載される多くのストリーム管理技術及びストリーム処理技術が実装される一例のコンテキストとしての役割をするが、これらの技術は、プロバイダネットワークよりもその他の種類の分散システムに、例えば、アプリケーションの単一ビジネスエンティティによって操作される大規模な分散環境に、適用され得ることに留意する。
プログラムによるインタフェースの例
上記のように、少なくともいくつかの実施形態では、ＳＰＳは、様々なストリームベースのアプリケーションに、所望のビジネスロジックを実装するために、ＳＰＳクライアントによってより容易に使用されることが可能な、より高いレベルの機能を構築するように、ＳＭＳプログラムによるインタフェースを利用し得る。ＳＰＳとＳＭＳの機能の違いを考えると、類似性が有用である。ＳＰＳの機能は、一般に、Ｃ＋＋のような、より高いレベルの言語におけるプログラミング言語の構築と比較され得る。それに対してＳＭＳの機能は一般に、プログラミング言語構築はコンパイラによって変換されるアセンブリ言語命令と比較され得る。アセンブリ言語命令を直接使用して同一の操作を実行することは可能であり得るが、より高いレベルの言語におけるプログラミングは、一般に、顧客またはユーザの多くのカテゴリにはより容易である。同様に、ＳＭＳによって供給された基本要素を使用して、様々なアプリケーションを実行することは可能であり得るが、ＳＰＳ特徴を使用して行うことはより容易であり得る。ＳＰＳ処理操作（データレコードで実行される冪等の処理操作のような）は、ストリームレコードのデータコンテンツ上で実行され得る。一方、ＳＭＳ操作は、レコードのコンテンツを通常考慮せずに、ＳＭＳ操作の取得、記憶及び検索を実行する。図３は、少なくともいくつかの実施形態による、ＳＭＳ及びＳＰＳで実装され得るプログラムによるインタフェースのそれぞれのセットの例を示す。いくつかの異なるアプリケーションプログラミングインタフェース（ＡＰＩ）は、ＳＭＳ及びＳＰＳの両方を例として指示する。示されているＡＰＩは、任意の所与の実装で支援される網羅的なリストであることを目的としていない。示されているＡＰＩのいくつかは、所与の実装で支援されなくてよい。
矢印３５０で示されているように、ＳＰＳクライアント３７５は、ＳＰＳプログラムによるインタフェース３０５を起動して処理ステージを構成し得る。様々な種類のＳＰＳプログラムによるインタフェース３０５は、異なる実施形態において実装され得る。例えば、ｃｒｅａｔｅＳｔｒｅａｍＰｒｏｃｅｓｓｉｎｇＳｔａｇｅＡＰＩは、クライアントが特定の入力ストリームのために新しい処理ステージ２１５の構成を要求を可能にし得る。ステージのワーカノードは、インタフェースの起動で特定される、一連の冪等操作を実行し、出力分散ディスクリプタまたはポリシによって表示された宛先に、結果を分散するよう、それぞれ構成される。ｃｒｅａｔｅＳｔｒｅａｍＰｒｏｃｅｓｓｉｎｇＳｔａｇｅ ＡＰＩまたはその等価物のいくつかのバージョンにおいては、クライアントは入力ストリームも同様に作成を要求し得る。一方、その他のバージョンでは、入力ストリームは、処理ステージが作成される前に作成されなければならない可能性がある。リカバリポリシはワーカノードに指定されてよく、例えば、チェックポイントベースのリカバリ技術が使用されるべきか否か、またはベストエフォートのリカバリ技術が好ましいか否かを示す。いくつかの実施形態では、ｉｎｉｔｉａｌｉｚｅＷｏｒｋｅｒＮｏｄｅ ＡＰＩは特定のステージでワーカノードの明示的なインスタンス化を要求するために支援され得る。チェックポイントベースのリカバリが実装される実施形態では、ｓａｖｅＣｈｅｃｋｐｏｉｎｔ ＡＰＩが、プログレスレコードがワーカノードによって生成されるようクライアントが要求することが可能になるよう支援され得る。
様々な種類のＳＰＳ出力管理ＡＰＩは、ｓｅｔＯｕｔｐｕｔＤｉｓｔｒｉｂｕｔｉｏｎ ＡＰＩのような、異なる実施形態において支援され得る。それによって、クライアントは、特定のステージで実行される処理操作の結果を使用して、１つ以上のストリームが作成されることを示してよく、及び、特定のパーティションポリシが新しく作成されたストリームに使用される。いくつかの処理ステージが再分割のために主に構成され得る。例えば、レコードの属性セットＡ１に基づいて、データレコードをＮ１パーティションにマップする１つのパーティション機能ＰＦ１は入力ストリームＳ１に使用され、及びＮ２パーティションに、（異なる属性セットＡ２または同一の属性セットＡ１の何れかを使用して）これらの同一のデータレコードをマップするために処理ステージは異なるパーティションの機能ＰＦ２を実装するように使用され得る。ｌｉｎｋＳｔａｇｅのような、いくつかのＳＰＳ ＡＰＩは、任意のグラフ（例えば、有向非巡回グラフ）を構成するために使用され得る。いくつかの実施形態では、第三者またはオープンソースのストリーム処理フレームワークまたはサービスへのコネクタが支援され得る。このような一実施形態においては、ＳＰＳステージは、第三者またはオープンソースシステムが存在することによる消費に、（例えば、ステージで実行される処理操作の結果を適切にフォーマットすることによって）データレコードを用意するために使用され得る。記載された実施形態において、ｃｒｅａｔｅＴｈｉｒｄＰａｒｔｙＣｏｎｎｅｃｔｏｒのようなＡＰＩは、このようなコネクタを設定するために使用されてよく、ＳＰＳステージの結果を適切に第三者システムと互換性があるフォーマットへの変換は、ｃｒｅａｔｅＴｈｉｒｄＰａｒｔｙＣｏｎｎｅｃｔｏｒの結果としてインスタンス化された、１つ以上のコネクタモジュールによって実行され得る。
ＳＰＳは矢印３５２で示すように、少なくとも機能のいくつかを実行するために、ＳＭＳ ＡＰＩ３０７を起動してよい。例えば、記載された実施形態では、ＳＭＳ ＡＰＩ３０７は、ｃｒｅａｔｅＳｔｒｅａｍ及びｄｅｌｅｔｅＳｔｒｅａｍ（それぞれストリームを作成し削除するために）と、（所与のパーティションの役割をする、様々な種類のノードのネットワークアドレスのように、ストリームのためにメタデータを取得するために）ｇｅｔＳｔｒｅａｍＩｎｆｏとを含み得る。ｐｕｔＲｅｃｏｒｄインタフェースは、データレコードを書き込むために使用され得る。一方、ｇｅｔＩｔｅｒａｔｏｒ及びｇｅｔＮｅｘｔＲｅｃｏｒｄｓインタフェースは、それぞれ、非シーケンシャルリードとシーケンシャルリードに使用され得る。ｒｅｐａｒｔｉｔｉｏｎＳｔｒｅａｍインタフェースは、いくつかの実施形態では、特定のストリームの動的再分割を要求するために使用され得る。このようにすることを希望するクライアント３７０は、矢印３５４によって示されるように、直接ＳＭＳ ＡＰＩ３０７を起動し得る。上記のように、様々なその他のＳＭＳ及び／またはＳＰＳ ＡＰＩは、また、その他の実施形態で実装されてよく、図３に列挙されたＡＰＩのいくつかは、いくつかの実施形態で実装されなくてよい。
種々の実施形態では、以外のＡＰＩプログラムによるインタフェースもまた、ＳＰＳまたはＳＭＳの代わりに、または何れかに実装され得る。このようなインタフェースはグラフィカルユーザインターフェース、ウェブページまたはウェブサイト、コマンドラインインタフェース等を含み得る。場合によっては、ウェブベースのインタフェースまたはＧＵＩは、ビルディングブロックとしてＡＰＩを使用し得る。例えば、ウェブベースの相互作用は、ＳＭＳまたはＳＰＳの制御コンポーネントで１つ以上のＡＰＩの起動がもたらされる可能性がある。図４は、少なくともいくつかの実施形態による、ＳＰＳクライアントがストリーム処理ステージのグラフ生成を可能にするために実装され得るウェブベースのインタフェースの実施例を示す。ここに示すように、インタフェースは、メッセージ領域４０２、グラフメニュー領域４０４及びグラフデザイン領域４０３を有するウェブページ４００を備える。
ユーザは、ストリームの概念及び基本要素についてより学習するために使用可能なリンクと同様に、メッセージ領域４０２のストリーム処理グラフの構築に関する一般的な命令を提供され得る。いくつかのグラフィカルアイコンは、メニュー領域４０４におけるストリーム処理グラフツールセットの一部として提供され得る。例えば、クライアントは、様々なＳＰＳ処理ステージの入力または出力、永続性ストリーム４５１、一過性のストリーム４５２、または第三者の処理環境へのコネクタ４５３として示すことが可能である。ウェブベースのインタフェースが実装されるＳＰＳ／ＳＭＳに関して、永続性ストリーム４５１は、ディスク、不揮発性ＲＡＭまたはＳＳＤのようなデータレコードが永続性記憶装置に格納されるストリームとして定義されてよく、一過性ストリーム４５２はデータレコードが永続性記憶装置に格納される必要がないものとして定義されてよい。一過性ストリームは、例えば、ベストエフォートリカバリポリシが実装される、異なるＳＰＳステージによって入力として消費されることが予想されるＳＰＳステージの出力から作成され得る。
２つの種類の処理ステージが例示的なＳＰＳグラフ構成ウェブページ４００において支援されている。チェックポイントベースのワーカノードリカバリが使用されるステージ４５５（例えば、各ワーカノードがインターバルでプログレスレコードを保存し、特定のワーカノードの破損の場合、交換されたノードが、どのデータレコードが処理を始めるべきか判断する、損失したノードのプログレスレコードを参照する）、及びベストエフォートリカバリが使用されるステージ４５６が使用される（例えば、交換されたワーカノードはプログレスレコードを参照せず、しかし受信されたときに新しいデータレコードを単に処理し始める）。各ステージで実行される処理操作に関する詳細は、メッセージ領域４０２における命令によって示されるように、グラフ構成領域４０３中の対応するアイコンをクリックすることによって、入力され得る。ストリーム、コネクタ及び処理ステージのアイコンに加え、メニュー領域４０４はまた、第三者または外部のストリーム処理システムを示すアイコンタイプ４５９を含む。アイコンタイプ４６０は、リソースが処理ステージに使用される、プロバイダネットワークで実装され得るストレージサービスのノードを示す。
図４に示されている例示的な場合においては、クライアントは、グラフデザイン領域４０３内に、３つの処理ステージ４１２、処理ステージ４１５及び処理ステージ４１６を備えるグラフ４０５を構築した。処理ステージ４１２は、チェックポイントベースのリカバリを使用するよう構成され、入力として永続性ストリーム４１１を使用する。ステージ４１２での処理の出力または結果は、ステージ４１５の入力を形成する、異なる永続性ストリーム４１３の形態で、及びステージ４１６の入力を形成する、一過性ストリーム４１４の形態で、２つの宛先に送信される。ステージ４１５及びステージ４１６の両方は、ベストエフォートリカバリポリシをワーカノードに使用する。ステージ４１５の出力は、一過性ストリームの形態でストレージサービスノード４１９に送信される。ステージ４１５の出力は、コネクタ４１７を介して第三者処理システム４１８に送信される。「グラフを保存」というボタン４２０は、例えば、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） ＯｂｊｅｃｔＮｏｔａｔｉｏｎ）、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）またはＹＡＭＬ任意の適切なフォーマットで処理ステージのグラフの表示を保存するために使用され得る。任意の複雑な処理ワークフローは、様々な実施形態で、図４に示されたものに類似するツールを使用して構築され得る。このようなツールを使用して作成されたワークフローは、次にアクティブ化され、このようなアクティブ化は、例えば、図４のステージ４１２のような処理ステージのためにデータレコードを取得するために、ＳＭＳ ＡＰＩの起動がもたらされる可能性があり、ｇｅｔＩｔｅｒａｔｏｒ及び／またはｇｅｔＮｅｘｔＲｅｃｏｒｄインタフェースは、ストリーム４１１上で起動され得る。
図５は、少なくともいくつかの実施形態による、ＳＭＳで実装され得る、プログラミングによるレコードの送信インタフェース及びレコード検索インタフェースの実施例を示す。図示された実施形態において、ＤＲ１１０Ｋ及び１１０Ｑのような、データレコードは、様々な種類のプログラムによる取り込みインタフェース５１０を介してＳＭＳに送信され得る。ＤＲ１１０は、いくつかの実施形態で、（ストリーム「Ｓ１」に）５０１Ａまたは（ストリーム「Ｓ２」に）５０１Ｂのようなストリーム識別子、データまたはレコード本体の表示、（５０４Ａまたは５０４Ｂのような）任意のパーティションキー５０４及び（順序付け設定表示５０６Ａ及び順序付け設定表示５０６Ｂのような）任意の順序付け設定表示５０６の、４つの種類の要素を備え得る。データ自体は、いくつかのレコード（例えば、ＤＲ１１０Ｋのインラインデータ５０２）においてインラインにて提供されてよい。一方、その他のデータレコードには、ポインタまたはアドレス５０３が提供されてよく、ＳＭＳ（またはネットワークの転送を必要としないローカルデバイスのアドレス）にネットワークにアクセス可能な位置を表示する。いくつかの実施形態では、所与のストリームは、インライン及びバイリファレンス（アドレスベース）データレコード送信の送信によって支援し得る。その他の実施形態では、所与のストリームは、すべてのデータをインラインで、またはすべてのデータを参照によって供給するためにデータ生成部を必要とし得る。いくつかの実装においては、データレコードの送信は、パーティション識別子がレコードに使用されることを含み得る。
図示された実施形態において、入力データレコード１１０は、パーティションポリシに基づいて、それぞれの取り込み及び／またはストレージノードに向けられ得る。同様に、レコードの検索もパーティションベースであり得る。例えば、１つ以上の検索ノードは所与のパーティションのレコードに向けられた要求の読み取りに対応して指示され得る。いくつかのストリームには、データ生成部は、明示的にパーティションキーに各データレコード書き込み要求を提供することを必要とし得る。その他のストリームには、ＳＭＳは、明示的に与えられたパーティションキー以外のメタデータまたは属性に依存するパーティションスキームによるデータレコードを分散することが可能であり得る。例えば、データ生成部への送信に関する識別情報は、パーティションキーとして使用され得る。またはデータ生成部のＩＰアドレスの一部若しくはすべての送信データが使用されるか、送信されるデータの一部が使用され得る。いくつかの実装においては、例えば、ハッシュ関数が、１２８ビット整数のような特定のサイズの整数値を取得するために、パーティションキーに適用され得る。そのサイズの正の整数の全範囲（例えば、０から２∧１２８−１）は、Ｎ連続副範囲に分けられてよく、対応するパーティションを表す各副範囲を備え得る。このため、このような実施例においては、データレコードのために決定され、または供給される任意の所与のパーティションキーは、１２８ビット整数値に対応してハッシュされ、整数値が属する１２８ビット整数値の連続副範囲は、データレコードが属するパーティションを表し得る。さらにパーティションポリシ及びその使用についての詳細は、図１５に関して下記に提供され得る。
特定のパーティションのデータレコードを取り込みまたは受信、データレコードの格納、及び特定のパーティションに対する読み込み要求に応答する役割をするノードのセットは、図５のパーティション用のＩＳＲ（取り込み、記憶及び検索）ノードと総称される。Ｓｊ−Ｐｋという表記は、ストリームＳｉのｋ番目のパーティションを表すために使用される。図示した実施形態では、ＩＳＲノード５２０Ａは、パーティションＳ１〜Ｐ１のレコードを取り込み、格納及び検索するように構成され、ＩＳＲノード５２０ＢはパーティションＳ１〜Ｐ２のレコードを設定し、ＩＳＲノード５２０Ｃは、パーティションＳ１〜Ｐ３のレコードを設定し、ＩＳＲノード５２０Ｋは、パーティションＳ２〜Ｐ１のレコードを設定し、及びＩＳＲノード５２０Ｌは、パーティションＳ２〜Ｐ２のレコードを設定する。いくつかの実施形態では、取り込みサブシステム、記憶サブシステムまたは検索サブシステムの所与のノードは、２つ以上のパーティション（または２つ以上のストリームの２つ以上のパーティション）のデータレコードを取り扱うよう構成され得る。いくつかの実施形態では、所与のストリームの単一パーティションのレコードは、２つ以上のノードによって取り込まれ、格納され、または検索され得る。所与のパーティションＳｊ〜Ｐｋ用に示された取り込みノードの数は、少なくともいくつかの場合において、異なるパーティションＳｊ〜Ｐｌ用に指定された取り込みノードの数と異なり得る。また、Ｓｊ〜Ｐｋ用に指定された記憶ノードの数及び／またはＳｊ〜Ｐｋ用に指定された検索ノードの数と異なり得る。取り込み及び／または検索に関して、ＳＭＳ制御ノードは、いくつかの実施形態において、どのノードがどのパーティションに対し役割をするかをクライアントが決定することが可能になるように、（ｇｅｔＳｔｒｅａｍＩｎｆｏのような）ＡＰＩを実装し得る。データレコードとパーティションとの間及びパーティションとＩＳＲノード（または制御ノード）との間の構成されたマッピングは、下記の動的再分割に関する記載したように、経時修正され得る。
いくつかの実施形態では、いくつかの異なるプログラムによるインタフェース５８０は、所与のパーティションからストリームデータレコードを検索または読み込みするために実装され得る。図５にて示すように、いくつかの検索インタフェース５８１は、（特定のシーケンス番号を備えたデータレコードで、または特定のシーケンス番号を備えたデータレコードの後に、イテレータをインスタンス化またはカーソルを読み込みするための）ｇｅｔＩｔｅｒａｔｏｒまたは（特定のシーケンス番号を備えたデータレコードを読み込むための）ｇｅｔＲｅｃｏｒｄのような、非シーケンシャルアクセスのために実装され得る。その他の検索インタフェース５８２は、ｇｅｔＮｅｘｔＲｅｃｏｒｄ（シーケンス番号の小さい順に、Ｎレコードがイテレータの現在位置から読み込まれることを要求するインタフェース）のようなシーケンシャル検索のために実装され得る。回転ディスクベースの記憶システムにおいては、前述のように、多くの場合、シーケンシャルＩ／Ｏは、ランダムＩ／Ｏよりもさらに、より効率的であり得る。平均Ｉ／Ｏ当たりに要求されるディスクヘッドシークの数は、典型的には、ランダムＩ／Ｏに対するよりも、シーケンシャルＩ／Ｏに対してはかなり低い可能性がある。多くの実施形態では、所与のパーティションのデータレコードは、シーケンス番号順に書き込まれ得る。シーケンス番号順に基づいて、その結果、シーケンシャル読み込み要求（例えば、ｇｅｔＮｅｘｔＲｅｃｏｒｄまたは類似のインタフェースを使用する）は、ランダムリードリクエストよりも著しくより効率的であり得る。したがって、少なくともいくつかの実施形態では、異なる課金はシーケンシャル対非シーケンシャル検索インタフェースに設定され得る。例えば、クライアントは非シーケンシャルリードに対し、より多く課金され得る。
取り込みサブシステム
図６は、少なくともいくつかの実施形態による、ＳＭＳの取り込みサブシステム２０４の要素の実施例を示す。図示された実施形態において、取り込み操作は、フロントエンド及びバックエンドの機能に論理的に分かれ、データ生成部１２０（例えば、１２０Ａ、１２０Ｂまたは１２０Ｃ）との相互作用を含むフロントエンドの機能及びＳＭＳ記憶サブシステムとの相互作用を含むバックエンド機能を備える。このようなフロントエンド／バックエンドの分割は、記憶サブシステムのセキュリティを向上し、データ生成部にパーティショニングポリシの詳細を提供する必要を避けるなどの、いくつかの利点を有し得る。ＳＭＳクライアントライブラリ６０２は、様々なデータ生成部１２０でインストールするために提供され得る。データ生成部は、ライブラリ６０２に含まれるプログラムによるインタフェースを起動して取り込みのためにデータを送信し得る。例えば、一実施形態では、データ生成部１２０は、何十万かのプロバイダネットワークの物理的及び／または仮想サーバをインスタンス化されたロギングエージェントまたはモニタリングエージェントを備え得る。このようなエージェントは、それぞれのサーバに様々なログメッセージ及び／または測定基準を収集し得る。また、定期的に、収集したメッセージまたは測定基準を、ＳＭＳの１つ以上の取り込み制御ノード６６０によってインスタンス化されたフロントエンド負荷分散装置６０４の終点に送信し得る。いくつかの実施形態では、１つ以上の仮想ＩＰアドレス（ＶＩＰ）は、負荷分散装置用に確立され、データ生成部はストリームデータを送信し得る。一実装においては、ラウンドロビンＤＮＳ（ドメイン名システム）技術は、データがデータ生成部１２０によって送信される、いくつかの同等に構成された負荷分散装置のうち、特定の負荷分散装置を選択するためにＶＩＰに使用され得る。
図示された実施形態において、受信されたデータレコードはいくつかのフロントエンドのノード６０６（例えば、６０６Ａ，６０６Ｂまたは６０６Ｃ）のいずれかに向けられ得る。少なくともいくつかの実施形態では、負荷分散装置６０４は、データレコードに使用するパーティショニングポリシ６５０を理解しなくてよい。したがって、フロントエンドノード６０６は、パーティションベースの負荷調整よりも、ラウンドロビン負荷分散（またはいくつかのその他の汎用負荷調整アルゴリズム）を使用して、所与のデータレコードに選択され得る。フロントエンドのノード６０６は、様々なストリーム用のパーティショニングポリシ６５０を理解し、取り込み制御ノード６６０と相互作用して、所与のパーティションのデータレコードに構成される、特定のバックエンド取り込みノード６０８（例えば、６０８Ａ，６０８Ｂまたは６０８Ｃ）の識別子を取得し得る。そのため、図示された実施形態においては、フロントエンドのノード６０４は、データレコードが属するそれぞれのパーティションに基づいて、複数のバックエンドノード６０６にデータレコードをそれぞれ伝送し得る。上記のように、データレコードが属するパーティションは、データ生成部によって供給されるパーティションキー、データ生成部の識別またはアドレスのような１つ以上のその他の属性、またはデータのコンテンツのような、様々な要因の任意の組み合わせに基づいて決定され得る。
バックエンドノード６０６は、１つ以上のストリームの１つ以上のパーティションに属するデータレコードをそれぞれ受信し、データレコードを記憶サブシステムの１つ以上のノードに伝送し得る。データがＨＴＴＰ（ハイパーテキストトランスファープロトコル）の「ＰＵＴ」ウェブサービスＡＰＩを介して送信される、いくつかの実施形態では、バックエンドノードは、「ＰＵＴサーバ」と称され得る。所与のバックエンドノードは、そのデータレコードが制御ノード６６０にクエリを送信することによって伝送される、記憶サブシステムノードのセットを決定し得る（順次、異なるサブシステムの制御機能が、ノードの分離したセットによって処理される実施形態において、対応するクエリを記憶サブシステムの制御ノードに送信し得る）。
少なくともいくつかの実施形態においては、少なくとも１回の取り込みポリシまたはベストエフォート取り込みポリシのような、いくつかの異なる取り込み応答ポリシ６５２が支援され得る。少なくとも１回のポリシでは、データ生成部１２０は、送信された各データレコードに肯定応答を要求し、（第１送信の応答が受信されない場合には）応答が最終的に受信されるまで、繰り返し同じデータレコードを送信し得る。ベストエフォート取り込みポリシにおいては、肯定応答は、送信された少なくともいくつかのデータレコードは必要とされなくてよい（しかしながら、取り込みサブシステムは依然として不定期に応答を提供し得る。またはデータ生成部からの応答の明示的な要求に応答し得る）。取り込みサブシステム２０４がデータ生成部に応答を提供するよう要求する、いくつかの実施形態では、所与のデータレコードの役割をするバックエンド取り込みノード６０８は、応答を生成する前に、要求された数のデータレコードの複製が、記憶サブシステムで正常に作成されるまで（例えば、ストリームに確立された永続性ポリシに従って）待機し得る。様々な実施形態では、シーケンス番号は、受信された各データレコードのために取り込みサブシステムによって生成され得る。例えば、類似のパーティションまたはストリームのその他のレコードに関連してそのレコードが取り込まれた順序を示す。またこのようなシーケンス番号はデータ生成部に応答として、または応答の一部として返され得る。シーケンス番号に関するさらなる詳細は、図１３ａ及び図１３ｂを参照して以下に提供され得る。いくつかの実装においては、応答及び／またはシーケンス番号は、フロントエンドのノード６０６を介してデータ生成部に戻って伝送され得る。少なくとも一実装においては、少なくとも１回のポリシが、取り込みサブシステム自体のフロントエンドノードとバックエンドノードの間で実装され得る。例えば、所与のフロントエンドのノード６０６は、バックエンドノードが応答を提供するまで、適切なバックエンドノード６０８にデータレコードを繰り返し送信し得る。
取り込み制御ノード６６０は、ストリームの動的再分割に起因する、取り込みに関連した構成操作に対し、その他の機能のうち、フロントエンドノードとバックエンドノードをインスタンス化し、ノードのヘルスとワークロードレベルを監視し、必要に応じてフェイルオーバを編成し、所与のパーティションの役割をするノードに関するクエリまたはポリシに関連したクエリへの応答を提供する役割があってよい。いくつかの実施形態では、１つ以上のストリームの所与のセットに指定された、取り込み制御ノードの数は、時間とともに変化され得る。例えば、１つ以上のマスター制御ノードは、必要に応じて制御ノードプールの再構成をする役割をし得る。冗長グループが取り込みフロントエンドノードまたはバックエンドノードに設定される、いくつかの実施形態では、図９及び図１０を参照して、さらに詳細に後述のように、制御ノード６６０は、どのノードがプライマリでどのノードが非プライマリであるか把握し、フェイルオーバに対するトリガ条件検出し、フェイルオーバが要求されたときに置換えを選択し得る。図６に示された、多層の取り込みサブシステム構造は、いくつかの実施形態で実装されない可能性があることに注意する。例えば、取り込みノードの単一セットのみがいくつかの場合において構成され得る。
記憶サブシステム
図７は、少なくともいくつかの実施形態による、ＳＭＳの記憶サブシステムの要素の実施例を示す。ここに示すように、取り込みノード６０８（例えば、フロントエンド及びバックエンド取り込みの役割は、異なるノードのセットによって処理される実施形態におけるバックエンド取り込みノード）は、これらのパーティション用に構成されたそれぞれの記憶ノード７０２に、ストリームの１つ以上のパーティションのデータレコードを伝送し得る。例えば、パーティションＳ１〜Ｐ１のデータレコード１１０Ａはストレージノード７０２Ａに送信され、パーティションＳ２〜Ｐ３のデータレコード１１０Ｂは、ストレージノード７０２Ｂ及びストレージノード７０２Ｃに送信され、パーティションＳ３〜Ｐ７のデータレコード１１０Ｃは、ストレージノード７０２Ｄに送信され、及びパーティションＳ４〜Ｐ５のデータレコード１１０Ｄは、ストレージノード７０２Ｅに初めに送信される。記憶制御ノード７８０は、異なるストリームのデータレコードに適用される永続性ポリシ７５０を実現し、必要に応じてストレージノードを構成及び再構成し、ストレージノードの状態を監視し、フェイルオーバを管理し、ストレージ構成クエリまたはストレージポリシクエリに応答し、及び図示された実施形態において様々なその他の管理タスクをする役割をし得る。
永続性ポリシ７５０は、異なる実施形態において、様々な方法で互いに異なり得る。例えば、ストリームＳｊに適用される永続性ポリシＰ１は、（ａ）格納される各データレコードのいくつかの複製（ｂ）複製が記憶される記憶装置またはシステムの種類（例えば、複製が揮発性メモリ、不揮発性キャッシュ、回転ディスクベースのストレージ、ソリッドステートドライブ（ＳＳＤ）、様々な種類のストレージアプライアンス、データベース管理システム中の様々な種類のＲＡＩＤ（安価なディスクの冗長アレイ）、プロバイダネットワークによって実装されるストレージサービスのノードなどに記憶されるべきか否か）（ｃ）複製の地理的分散（例えば、ストリームデータは、異なるデータセンタに複製を配置することによって、大規模な破損または特定の種類の事故に対し回復力があるか否か）（ｄ）書き込み応答プロトコル（例えば、Ｎ複製が格納される場合には、応答が取り込みノードに提供される前に、いくつのＮ複製が正常に書き込みする必要があるか）及び／または（ｅ）データレコードの多数の複製が格納される場合、複製は並行してまたは継続して作成されるか否かという点においてストリームＳｋに適用されるポリシＰ２、とは異なり得る。多数の複製が格納されるいくつかの場合には、データレコード１１０Ｄの場合のように、所与のストレージノードは、データレコードは別のストレージノードに送信し得る（例えば、ストレージノード７０２Ｅはさらにストレージノード７０２Ｆにデータレコード１１０Ｄをさらに複製するために送信し、ストレージノード７０２Ｆはストレージノード７０２Ｇを送信する）。多数の複製永続性ポリシが使用される、その他の場合においては、２つのメモリ内複製が格納されるデータレコード１１０Ｂの場合においては、取り込みノードは多数の複製を並行して開始し得る。少なくともいくつかの実施形態においては、クライアントの選択した永続性ポリシは、ストリームデータレコードに使用される記憶位置の種類を明示しなくてよい。むしろ、ＳＭＳは、記憶技術の適切な種類及び／または費用、性能、データレコードへの費用、性能、データソースへの近接、耐久性の条件等、様々な基準に基づいた位置を選択し得る。一実施形態では、クライアントまたはＳＭＳのどちらかは、所与のストリームの異なるパーティションまたは異なるストリーム用の、異なる記憶技術または記憶位置の種類を使用するために決定し得る。
図７に示された実施例においては、ストリームＳ１（または少なくともストリームＳ１のパーティションＳ１〜Ｐ１）に適用される永続性ポリシは、メモリ内ポリシの単一の複製である。一方、ストリームＳ２には、２つの並行複製メモリ内ポリシが適用される。したがって、データレコード１１０Ａのメモリ内複製７０４Ａは、ストレージノード７０２Ａで作成され、一方、データレコード１１０Ｂに対応する２つのメモリ内複製７０５Ａ及びメモリ内複製７０５Ｂは、ストレージノード７０２Ｂ及びストレージノード７０２Ｃで並行して作成される。ストリームＳ３のデータレコード１１０Ｃには、単一ディスク上の複製７０６Ａが作成される。ストリームＳ４には、シーケンシャルな３つの複製のディスク上ポリシが適用可能であり、その結果、それぞれのディスク上の複製７０７Ａ、複製７０７Ｂ及び複製７０７Ｃはシーケンシャルにストレージノード７０２Ｅ、ストレージノード７０２Ｆ及びストレージノード７０２Ｇで作成される。様々なその他の種類の永続性ポリシが、異なる実施形態でデータストリームに適用され得る。検索サブシステムのノードは、データコンシューマによる、様々な種類の検索ＡＰＩの起動に対応する適切なストレージノードから、データレコードを取得し得る。
検索サブシステム及び処理ステージ
図８は、少なくともいくつかの実施形態による、ＳＭＳの検索サブシステムの実施例の要素及びＳＰＳとの検索サブシステムの相互作用の実施例を示す。示されているように、検索サブシステム２０６は、検索制御ノード８８０の収集と同様に、検索ノード８０２Ａ、検索ノード８０２Ｂ及び検索ノード８０２Ｃのような、複数の検索ノード８０２を備え得る。検索ノード８０２のそれぞれは、後述のように、ＳＰＳのワーカノード８４０のような、様々なクライアントまたはデータコンシューマ１３０からのストリームデータの検索要求に応答するよう構成され得る。様々なプログラムによる検索インタフェース８０２は、前述した非シーケンシャル検索インタフェース及びシーケンシャル検索インタフェースによって、異なる実施形態において検索ノードによって実装され得る。いくつかの実施形態では、ＨＴＴＰ ＧＥＴ要求のようなウェブサービスＡＰＩは、データレコード検索に使用され、したがって、検索ノード８０２はＧＥＴサーバと称され得る。所与の検索ノード８０２は、記憶ノード７０２Ａ及び記憶ノード７０２Ｂのような、適切な記憶サブシステム７０２のセットから、記載された実施形態においては、例えば、検索制御ノード８８０によって、１つ以上のストリームパーティションのデータレコードを取得するよう構成され得る。
記載された実施形態において、検索ノード８０２は１つ以上の記憶ノード７０２と対話し、また、１つ以上のＳＰＳワーカノード８４０から受信された検索要求に応答し得る。例えば、パーティションＳ４〜Ｐ５のデータレコード（例えば、データレコード１１０Ｋ）及びパーティションＳ５からＰ８（例えば、データレコード１１０Ｌ）は、記憶ノード７０２Ａから、検索ノード８０２Ａによって読み込まれ、ワーカノード８４０Ａ及びワーカノード８４０Ｋにそれぞれ提供される。１１０Ｍのような、パーティションＳ６〜Ｐ７のデータレコードは、記憶ノード７０２Ａから検索ノード８０２Ｂによって読み込まれ、ワーカノード８４０Ｋに提供される。パーティションＳ４〜Ｐ７のデータレコードは、検索ノード８０２Ｃによって記憶ノード７０２Ｂから読み込まれ、ワーカノード８４０Ｂに提供され、また、その他のデータコンシューマ１３０（例えば、ＳＰＳを介してＳＭＳと対話する代わりに、直接ＳＭＳ検索ＡＰＩをデータコンシューマ起動する）に提供される。
少なくともいくつかの実施形態においては、検索ノード８０２のいくつか、またはすべては、様々なパーティションのデータレコードが将来の検索要求を予測して一時的に保持され得る、それぞれのキャッシュ８０４を実装し得る（検索ノード８０２Ａでのキャッシュ８０４Ａ、検索ノード８０２Ｂでのキャッシュ８０４Ｂ及び検索ノード８０２Ｃでのキャッシュ８０４Ｃ）。検索制御ノード８８０は、例えば、キャッシュポリシ（例えば、キャッシュが所与のパーティションを構成するためにどのくらいの大きさであるべきか、データレコードはどのくらいの長さをキャッシュすべきか）、記憶ノード選択ポリシ（例えば、どの特定の記憶ノードが、データレコードの多数の複製が格納される場合において、所与のデータレコードを取得するために最初に接触されるべきか）、などを含む、いくつかの検索ポリシ８８２を実装する役割をし得る。加えて、検索制御ノードは、検索ノード８０２をインスタンス化し監視する役割をし、どちらの検索ノードがどちらのパーティションの役割をし、再分割の操作等を開始して、応答するかに関するクエリに応答し得る。
図示された実施例では、ＳＰＳ２９０は２つの処理ステージ２１５Ａ及び処理ステージ２１５Ｂを備える。ＳＰＳ制御ノード８８５は、パーティションＳ４〜Ｐ５のレコードを処理するワーカノード８４０Ａ、パーティションＳ４〜Ｐ７のレコードを処理するワーカノード８４０Ｂ、パーティションＳ５〜Ｐ８及びパーティションＳ６〜Ｐ７のレコードを処理するワーカノード８４０Ｋのような、様々な処理ステージ２１５でワーカノード８０４をインスタンス化する役割をし得る。ＳＰＳ制御ノード８８５は、（図３及び図４に示されたような）プログラムによるインタフェースを実装し、ＳＰＳクライアントが処理ワークフローを設計するのを可能にする。様々なチェックポイントポリシ８５０が、異なる処理ステージまたはワークフローに実装されてよく、いつワーカノードがプログレスレコードを格納するべきかを表示し、どのくらいそれぞれのパーティション、プログレスレコード等に使用される記憶装置の種類などを処理しているのかを表示する。フェイルオーバ／リカバリポリシ８５２は、異なるノードでワーカノードを置き換えすることにつながる、トリガ条件または閾値を表示してよく、ベストエフォートリカバリが使用されるか、チェックポイントベースのリカバリが所与の処理ステージに使用されるかを表示し得る。少なくともいくつかの実施形態においては、ＳＰＳ制御ノード８８５は、例えば、所与のストリームのデータレコードが取得される検索ノードを識別し、特定の処理ワークフロー等に必要であり得る新しい一過性または永続性のストリームを確立するために、様々な種類のＳＭＳ制御ノードと相互作用してよい。少なくとも一実施形態においては、クライアントはＳＰＳ制御ノードと対話し、ストリームをインスタンス化し得る。例えば、ＳＭＳ制御インタフェースを利用する代わりに、あるクライアントはより高いレベルのＳＰＳインタフェースのみを起動したい可能性がある。ＳＭＳの取り込み、格納及び検索サブシステムのための制御ノードの分離したセットは図６、図７及び図８に示されているが、ＳＰＳステージには、少なくともいくつかの実施形態では、所与の制御ノードはいくつかのサブシステム及び／またはＳＰＳに使用され得ることに注意する。
ノード冗長グループ
少なくともいくつかの実施形態においては、ノードの冗長グループは、ＳＭＳの１つ以上のサブシステム用に構成され得る。すなわち、例えば、ストリームパーティションＳｊ〜Ｐｋ用のデータレコードを検索する１つの検索ノードを構成する代わりに、２つまたはそれ以上のノードが、このような検索のために確立されてよく、「プライマリ」と認められている１つのノードまたは所与の時点で動作中の役割をする一方、その他のノードは「非プライマリ」ノードとして設計されている。現在のプライマリノードは、例えば、クライアントまたはその他のサブシステムのノードの何れかから受信した要求の、ワーク要求に応答する役割をし得る。非プライマリノードまたはノードは、例えば、破損、プライマリへの接続不良、またはその他のトリガ条件のため、フェイルオーバがトリガされるまで休眠したままでよく、その場合には、選択された非プライマリは制御ノードによって通知され、従来のプライマリの役割に取って代わってもよい。したがって、プライマリの役割は、フェイルオーバの間、従来のプライマリノードから取り消され、現在の非プライマリノードを許可される。いくつかの実施形態では、非プライマリノードは、フェイルオーバが起こったと決定されたときに、プライマリとして取って代わり得る。例えば、明示的な通知が必要とされなくてよい。様々な実施形態では、このようなノードの冗長グループは、ＳＭＳの機能を取り込み、格納、検索及び／または制御するために設定されてよく、類似の手法もまた、少なくともいくつかの実施形態でＳＰＳのワーカノードに取られてよい。いくつかの実施形態では、所与の機能のための、少なくとも１つのプライマリノード及び少なくとも１つの非プライマリノードを備える、このようなグループは、「冗長グループ」または「複製グループ」と呼ばれ得る。ストレージノードの冗長グループは、格納されるデータレコードのいくつかの物理的複製を独立して実装され、例えば、格納されるべきいくつかの複製のデータレコードは、永続性ポリシによって決定されてよく、一方、対応するパーティションのために構成された、いくつかの記憶ノードは、冗長グループポリシに基づいて決定されることに注意する。
図９は、少なくともいくつかの実施形態による、ＳＭＳまたはＳＰＳのノード用に設定され得る冗長グループの実施例を示す。記載された実施形態において、所与のストリームパーティションＳｊ〜Ｐｋには、それぞれの冗長グループ（ＲＧ）９０５、冗長グループ９１５、冗長グループ９２５及び冗長グループ９３５が取り込みノード、記憶ノード、検索ノード及び制御ノードのために設定されている。取り込み制御ノード、記憶制御ノードまたは検索制御ノードのための分離したＲＧはいくつかの実施形態で実装されているが、制御ノードのための共通のＲＧ９３５は、図示された実施形態において実装されている。各ＲＧは、プライマリノード（例えば、プライマリ取り込みノード９１０Ａ、プライマリ記憶ノード９２０Ａ、プライマリ検索ノード９３０Ａ及びプライマリ制御ノード９４０Ａ）及び少なくとも１つの非プライマリノード（例えば、非プライマリ取り込みノード９１０Ｂ、非プライマリ記憶ノード９２０Ｂ，非プライマリ検索ノード９２０Ｃ及び非プライマリ検索ノード９２０Ｄ）を備える。プライマリの役割は、それぞれのフェイルオーバポリシ９１２（取り込みノード用）、フェイルオーバポリシ９２２（記憶ノード用）、フェイルオーバポリシ９３２（検索ノード用）及びフェイルオーバポリシ９４２（制御ノード用）にしたがい、取り消され、現在の非プライマリが許可される。例えば、フェイルオーバポリシは、プライマリステイタスにおける変更につながるトリガ条件管理してよく、プライマリまたは非プライマリのヘルスステータスが監視されているか否か、及びどのように監視されているか、所与の冗長グループ等に構成されるべき非プライマリの数を管理し得る。少なくともいくつかの実施形態においては、単一のＲＧは、多数のパーティション用に確立され得る。例えば、ＲＧ９０５は、パーティションＳｐ〜Ｐｑと同様に、パーティションＳｊ〜Ｐｋのレコードの取り込みを処理する役割があり得る。いくつかの実装においては、１つのパーティション用のプライマリとして設計されたノードは、同時に、別のパーティション用の非プライマリとして設計され得る。一実施形態では、多数のノードは、同時に、所与のＲＧ内のプライマリノードとして示され得る。例えば、所与のパーティションの取り込みに関連したワークロードは、２つのプライマリノードに分散されてよく、破損した場合に備え、どちらかがプライマリで非プライマリとして示される１つのノードを備える。所与のＲＧ内のインスタンス化されたノードの数は、対応する機能に望ましい入手可能性または回復レベルに依存し得る（例えば、そのグループ耐え得ることを予定しているのが、どのくらい多くの同時発生または重複する破損か）。いくつかの実施形態では、ＳＭＳノードへの使用またはＳＭＳノードへの使用の代わりに、冗長グループはＳＰＳ処理ステージのワーカノードのために設定され得る。図１０に示されるように、所与のＲＧのメンバは、例えば、いくつかのデータセンタにわたって地理的に時々、分散され得る。いくつかの実施形態では、選択された制御ノードは、例えば、ハートビート機構またはその他のヘルス監視技術を使用し、フェイルオーバトリガ条件を検出するよう構成され得る。また、このような制御ノードは、損失したプライマリの置換えとして、適切な非プライマリノードを選択し、選択された置換えのノード等を通知／起動することによってフェイルオーバを調整し得る。
いくつかの実施形態では、プロバイダネットワークは、複数の地理的領域に分けられ、各領域は１つ以上のアベイラビリティコンテナを含んでよく、本明細書では「アベイラビリティゾーン」とも呼ばれる。アベイラビリティコンテナは、順次、１つ以上の異なる位置またはデータセンタを備え、所与のアベイラビリティコンテナにおけるリソースが、その他のアベイラビリティコンテナにおける破損から絶縁されるような方法で設計され得る（例えば、電力関連装置、冷却装置、物理的安全構成要素等の、独立したインフラストラクチャコンポーネント）。一アベイラビリティコンテナにおける破損は、任意のその他のアベイラビリティコンテナにおける損失という結果にならない可能性がある。このため、リソースインスタンスのアベイラビリティプロフィールまたは制御サーバは、異なるアベイラビリティコンテナにおいて、リソースインスタンスのアベイラビリティプロフィールまたは制御コントロールサーバに依存しないことを意図している。様々な種類のアプリケーションは、それぞれのアベイラビリティコンテナにおける多数のアプリケーションインスタンスを起動すること、または、（いくつかのＳＭＳ及びＳＰＳの場合）多数のアベイラビリティコンテナにわたって、所与の冗長グループのノードを分散するによって、多数の単一の位置での破損から保護され得る。同時に、いくつかの実装においては、安価で短待ち時間のネットワークの接続は、類似の地理的領域内にあるリソース（ＳＭＳ及びＳＰＳノードに使用されるホストまたはコンピュートインスタンス）間で提供されてよく、類似のアベイラビリティコンテナのリソース間のネットワーク伝送がさらに速くなり得る。あるクライアントは、ストリーム管理リソースまたはストリーム処理リソースが予約及び／またはインスタンス化される位置を特定したいと思う可能性がある。例えば、アプリケーションが実行される様々な構成要素の所望の制御度合いを維持するアベイラビリティコンテナレベルまたはデータセンタレベルの何れかの領域レベルリソースが、例えば性能、ハイアベイラビリティ等のクライアントの要求に合致する限り、その他のクライアントは、リソースが予約またはインスタンス化される、実際の場所にあまり興味が無い可能性がある。いくつかの実施形態では、１つのアベイラビリティコンテナ（またはデータセンタ）に配置された制御ノードは、その他のアベイラビリティコンテナ（またはその他のデータセンタ）におけるその他のＳＭＳまたはＳＰＳノードを遠隔から構成することが可能であり得る。つまり、特定のアベイラビリティコンテナまたはデータセンタが、ＳＭＳ／ＳＰＳノードを管理するためにローカル制御ノードを有する必要はない。
図１０は、少なくともいくつかの実施形態による、所与の冗長グループのノードが複数のデータセンタに分散され得る、プロバイダのネットワーク環境を示す。図示された実施形態においては、プロバイダネットワーク１００２は、３つの可用性コンテナ１００３Ａ、可用性コンテナ１００３Ｂ及び可用性コンテナ１００３Ｃを備える。各可用性コンテナは、１つ以上のデータセンタの一部または全部を含む。例えば、可用性コンテナ１００３Ａはデータセンタ１００５Ａ及びデータセンタ１００５Ｂを備え、可用性コンテナ１００３Ｂはデータセンタ１００５Ｃを含み、及び可用性コンテナ１００３Ｃはデータセンタ１００５Ｄを含む。ＳＭＳ及び／またはＳＰＳノードのいくつかの異なる冗長グループ１０１２が示されている。データセンタ１００５Ａ内に配置されたＲＧ１０１２Ａの場合のように、いくつかのＲＧ１０１２は、単一のデータセンタ内に全体が実装され得る。その他のＲＧは、ＲＧ１０１２Ｂのように、所与の可用性コンテナ内で多数のデータセンタのリソースを使用してよく、可用性コンテナ１００３Ａのデータセンタ１００５Ａ及びデータセンタ１００５Ｂにわたる。しかしながら、その他のＲＧは、異なる可用性コンテナにわたって広がるリソースを使用して実装され得る。例えば、ＲＧ１０１２Ｃは、可用性コンテナ１００３Ａ及び可用性コンテナ１００３Ｂのデータセンタ１００５Ｂ及びデータセンタ１００５Ｃに配置されたリソースをそれぞれ使用し、ＲＧ１０１２Ｄは、可用性コンテナ１００３Ａ、可用性コンテナ１００３Ｂ及び可用性コンテナ１００３Ｃ中それぞれのデータセンタ１００５Ｂ、データセンタ１００５Ｃ及びデータセンタ１００５Ｄでリソースを利用する。一例示的な配置においては、ＲＧ１０１２が１つのプライマリノード及び２つの非プライマリノードを備え、３つのノードのそれぞれは、異なる可用性コンテナに配置され得る。そのため、少なくとも１つのノードは、大規模な破損イベントが２つの異なる可用性コンテナを同時に起こしても、機能的なままである可能性が高い。
図示された実施形態において、ＳＭＳ及びＳＰＳのそれぞれに関連する、コンソールサービス１０７８及びコンソールサービス１０７６は、使用が簡単なウェブベースのインタフェースを、プロバイダネットワーク１００２にストリームに関連する設定を構成するために提供し得る。いくつかのさらなるサービスは、その少なくともいくつかはＳＭＳ及び／またはＳＰＳによって使用され得るが、１つ以上のデータセンタにわたる、または１つ以上の可用性コンテナを横断するリソースを使用してプロバイダネットワーク１００２にて実装され得る。例えば、仮想計算サービス１０７２は、実装され得る。クライアントが様々な異なるケーパビリティレベルのコンピュートインスタンスとしてパッケージ化された計算能力の選択された量を利用することができ、このようなコンピュートインスタンスは、ＳＭＳ及び／またはＳＰＳノードを実装するために使用され得る。１つ以上のストレージサービス１０７０は、例えばブロックデバイスボリュームインタフェース、またはウェブサービスインタフェースの何れかを介して実装されてよく、クライアントが所望のデータ耐久性でデータオブジェクトを記憶しアクセスするのを可能にする。ストレージオブジェクトは、サービス１０７２のコンピュートインスタンスに取り付け可能であり得る。またはサービス１０７２のコンピュートインスタンスからアクセス可能であり得る。いくつかの実施形態では、ＳＭＳストレージサブシステムで様々なストリーム永続性ポリシに使用され得る。一実施形態では、ハイパフォーマンスキー値管理サービス１０７４のような、１つ以上のデータベースサービスまたはリレーショナルデータベースサービスは、プロバイダネットワーク１００２で実装され得る。このようなデータベースサービスは、ＳＭＮＳストレージサブシステムによってストリームデータレコードに及び／または制御サブシステム、取り込みサブシステム、記憶サブシステム、検索サブシステムまたは処理ステージのメタデータを格納するために使用され得る。
ストリームセキュリティオプション
少なくともいくつかの実施形態においては、ＳＭＳ及び／またはＳＰＳのユーザは、データストリームのためにいくつかのセキュリティに関連するオプションが提供されてよく、クライアントが、取り込み、記憶、検索、処理及び／または制御のような、様々な機能カテゴリに使用するためにリソースのセキュリティプロフィール（例えば、仮想または物理マシン）を選択することが可能になる。このようなオプションとしては、例えば、様々なノードに使用されるリソースの物理位置の種類に関する選択（例えば、プロバイダネットワーク設備が使用されるべきかどうか、またはクライアント所有の設備が使用されるべきかどうかであり、これはプロバイダネットワーク設備とは異なるセキュリティ特徴を有し得る）、ストリームデータの暗号化に関する選択、及び／またはストリーム処理インフラストラクチャの様々な部分においてネットワークを遮断する選択が挙げられる。あるクライアントは、貴重な独占しているビジネスロジックまたはアルゴリズムへのアクセスをする侵入者または攻撃者の可能性について懸念を持ち得る。例えば、クライアント所有のプロミス内の計算装置を使用してストリーム処理ワーカノードを実装し得る。ＳＭＳ及び／またはＳＰＳノードのセットを実装するために使用されるリソースの種類は、本明細書においては、これらのノードに対する「配置先種類」と称し得る。図１１は、少なくともいくつかの実施形態による、ＳＭＳまたはＳＰＳのノード用に選択され得る複数の配置先の種類を示す。
図示された実施形態において、配置先は、ＳＭＳ／ＳＰＳ機能カテゴリ用のプロバイダネットワーク１１０２（例えば、取り込み、記憶、検索、制御または処理）及びその他の種類のＳＭＳ／ＳＰＳの機能カテゴリ用の外部のプロバイダネットワーク１１０２内で選択され得る。プロバイダネットワーク１１０２内では、コンピュートインスタンス、ストレージインスタンスまたはデータベースインスタンスのような、いくつかのリソースは、マルチテナントのインスタンスホスト１１０３を使用して実装され得る。このようなマルチテナントのインスタンスホストは、１つ以上のクライアントに対するＳＭＳまたはＳＰＳノードのそれぞれがインスタンス化されてよく、配置先の種類の第１カテゴリ「Ａ」を形成し得る。その他のクライアントと物理リソースを共有しなければならないことを避けるために、あるクライアントはＳＭＳ／ＳＰＳノードを単一のクライアントに限定したインスタンスホストを使用して実装されることを要求し得る。このようなシングルテナントのインスタンスホストは、配置カテゴリの種類「Ｂ」を形成し得る。シングルテナントのインスタンスホストは、いくつかの理由のため、あるクライアントの観点から、望ましい場合がある。マルチテナントのインスタンスホストは、その他のクライアントに属するコンピュートインスタンスを含み得る。シングルテナントのインスタンスホストよりも、マルチテナントのインスタンスホストにおける別のクライアントのインスタンスからのセキュリティ攻撃の可能性がより高くなり得る。加えて、マルチテナントホストで動くあるクライアントのコンピュートインスタンスＣＩ１は、ワークロードでサージを経験し、ホストの計算サイクルまたはその他のリソースの大きな割合を消費し始め、そのため場合により異なるコンピュートインスタンスＣＩ２上で動く別のクライアントのアプリケーションの性能に衝撃を与える、「ノイジーネイバー」現象は、またシングルテナントのインスタンスホストが使用されるときに避けられ得る。
ＩＶＮ１１０６Ａ及びＩＶＮ１１０６Ｂのような、隔離された仮想ネットワーク（ＩＶＮ）１１０６は、図示された実施形態において、配置先種類の別のカテゴリ「Ｃ」を表し得る。いくつかの実施形態では、ＩＶＮ１１０６は、プライベートネットワークの論理等価として、プロバイダネットワークのクライアントの要求で作成されてよく、プロバイダネットワークのリソースを使用して構築するが、クライアントによって主に制御されるネットワーク構成である。例えば、クライアントは、ＩＶＮの外部ですでに使用され得るＩＰアドレスを複製する可能性について懸念することなしに、ＩＰアドレスを決定し、ＩＶＮ１１０６内で使用し得る。図示された実施形態において、１つ以上のＩＶＮにおいて、ＳＭＳ及びＳＰＳノードの様々な種類の実装は、クライアントのストリームデータの管理及び／または処理に対するネットワークセキュリティのレベルをさらに上げ得る。場合によっては、所与のクライアントは、１つのＩＶＮ１１０６におけるＳＭＳ／ＳＰＳノードの１つの機能的カテゴリ、及び異なるＩＶＮに異なる機能的カテゴリを配置したいと思う可能性がある。様々な実施形態では、所与のＩＶＮ１１０６は、シングルテナントのインスタンスホストかマルチテナントのインスタンスホストの何れか、またはインスタンスホストの両種類を備え得る。いくつかの実施形態では、プロバイダネットワークのリソースを使用する、配置先種類の選択の別のセット（またはセキュリティプロフィールの選択）は、図１１には図示されていないが、少なくともあるクライアントには入手可能であり得る。クライアントが、ストリーム関連の操作のために、プロバイダネットワークの仮想計算サービスからコンピュートインスタンスを取得し使用できる実施形態においては、コンピュートインスタンスは２つのモードのうち１つで使用され得る。１つのモードにおいては、クライアントは、ＳＰＳまたはＳＭＳに、実行可能なプログラムまたは、ＳＰＳワーカノードとして構成されたコンピュートインスタンスにて（若しくは取り込みノード、記憶ノードまたは検索ノードにて）動作されるプログラムを提供し、ＳＭＳあるいはＳＰＳにプログラムを動作させ、ノードを管理させ得る。この第１モードは、ストリーム操作にコンピュートインスタンスを使用する「ストリームサービスが管理する」モードとして呼ばれることもある。その他のモードにおいては、クライアントは、ＳＰＳまたはＳＭＳから支援がより少ない状態で、実行可能なプログラムを動かし、コンピュートインスタンスの管理をすることを希望する場合がある。この第２モードは、ストリーム操作にコンピュートインスタンスを使用する「クライアントが管理する」モードとして呼ばれることもある。よって、これら２つの操作モードは、クライアントが選択可能な配置先の種類またはセキュリティプロフィールに関する追加の選択肢を表し得る。例えば、クライアントは、実行可能なプログラムが、クライアントの組織から主題に関する専門家によって最適に実行されるデバッグ（シングルステッピングを含む）を必要とする可能性がある場合には、クライアントが管理するモードを選択し得る。一方、ストリームサービスが管理するモードは、デバッグを必要とする可能性のないより完成したコードには有効な選択肢であり得る。いくつかの実施形態では、異なる価格設定がこれら２つのモードに適用し得る。
いくつかの配置の選択肢が、図１１に示された実施形態におけるプロバイダネットワーク外部の設備で支援され得る。例えば、ＳＭＳライブラリ１１７１及び／またはＳＰＳライブラリ１１７２がインストールされるホスト１１６０は、クライアントの設備１１１０Ａまたは設備１１１０Ｂ内（例えば、クライアントが所有するデータセンタ若しくは構内）でストリーム管理またはストリーム処理に使用されてよく、２種類のクライアントの設備は、プロバイダネットワークへの接続方法において異なる。クライアントの設備１１１０Ａは、プロバイダネットワーク１１０２に少なくともいくつかの共有されるインターネットリンク１１５１を介してリンクされている（すなわち、その他のエンティティのネットワークトラフィックは、また、クライアントの設備１１１０Ａとプロバイダネットワーク１１０２との間のリンクのいくつかにわたって流れ得る）。対照的に、（１１１０Ｂのような）いくつかのクライアントの設備は、特別な共有されない専用の物理リンク１１０６（時に「直接接続リンク」と呼ばれ得る）を介してプロバイダネットワークにリンクされ得る。これら２つの異なる種類のクライアントの構内は、配置先の選択肢「Ｄ」及び「Ｅ」を備え、そのそれぞれが図１１にて用語が使用されている。いくつかの実施形態では、ＳＭＳ及び／またはＳＰＳの一部は、また、第三者の構内（例えば、ＳＭＳ及び／またはＳＰＳのクライアントによって使用されるが所有または管理されないデータセンタ）で実装可能であってよく、このような第三者の構内は、配置先「Ｆ」として示され得る。少なくともいくつかのクライアント及び／または第三者の構内においては、ＳＭＳ及び／またはＳＰＳライブラリは、プロバイダネットワークから取得され、ＳＭＳ及び／またはＳＰＳノードに使用されるホストにインストールされる必要があり得る。少なくとも一実施形態においては、すべての異なる機能カテゴリのノードは、適切なライブラリの支援でプロバイダネットワークの外部に実装され得る。
異なる実施形態においては、異なる配置先の種類は、ネットワーク隔離の特徴が実装され、侵入検知の機能が支援され、物理セキュリティポリシが実装され、暗号化レベルが支援されるなど、様々なセキュリティに関連する態様において、互いに異なり得る。したがって、様々な配置の種類のそれぞれは、対応するセキュリティプロフィールを有すると考えられてよく、これは１つ以上の方法で、その他の配置先のセキュリティプロフィールとは異なることがある。いくつかの実施形態では、ＳＭＳ及び／またはＳＰＳのクライアントは、異なるサブシステムまたはノードセットに対し、例えば、図１２ａ及び図１２ｂにて示されているように、ＳＭＳまたはＳＰＳの１つ以上の制御ノードに要求を送信することによって、それぞれの配置先の種類をプログラムで選択し得る。注意が必要なのは、いくつかの実施形態及びストリームアプリケーションの特定の種類においては、クライアントは配置先の種類を、単にセキュリティの理由からではなく、性能及び／または機能性の理由から制御したいと思う可能性があることである。例えば、前述のノイジーネイバー現象は、専用のクライアントの設備のリソースまたはシングルテナントのインスタンスホストを使用することにより回避され得る。いくつかの実施形態では、クライアントは、ＳＰＳステージまたはＳＭＳノードに使用を希望する専用または専有のハードウェア及び／またはソフトウェアを有し得る。このようなコンポーネントを使用して達成可能な機能上の能力または性能レベルは、プロバイダネットワークで容易に複製されることが不可能であり、または単にプロバイダネットワークで支援されない。クライアントは外部のデータセンタで、スーパーコンピュータレベルの処理能力を有するコンピュータサーバにアクセスし得る。例えば、プロバイダネットワークのリソースのみを使用するときに可能な処理よりも、かなり高い速度でＳＰＳ処理を実行することが可能であり得る。クライアントが様々なノードへの配置先を選択することを可能にすることで、このような専用装置または専用ソフトウェアが使用できる。
図１２ａ及び図１２ｂは、少なくともいくつかの実施形態による、ＳＰＳクライアント及びＳＭＳクライアントのそれぞれによって送信され得る、セキュリティオプションの要求の実施例を示す。図１２ａは、ＳＰＳセキュリティオプションの要求１２００を示し、識別子１２１０を備える１つ以上の処理ステージには、クライアントが、ステージ（要素１２１２）の制御ノードに要求される配置先の種類（ＰＤＴ）、及びワーカノード（要素１２１４）に要求されるＰＤＴを示す。少なくとも一実施形態においては、クライアントもまた、ストリームデータレコードまたはストリーム処理結果に対する暗号化設定を構成する要求を送信可能であり得る。例えば、様々なネットワークリンクにわたって伝送する前に、特定のアルゴリズムまたはプロトコルを使用して暗号化されるデータレコードを要求することにより、または様々な制御若しくは管理相互作用を暗号化することを要求することにより、例えば、図１２ａでは、ステージに対する暗号化設定は、ステージ処理操作の結果に適用される暗号化技術及び／またはステージの制御ノードとステージのワーカノードとの間の通信に使用される暗号を示し得る。
同様に、図１２ｂにおいては、クライアントのＳＭＳのセキュリティオプション要求１２５０は、特定の識別子１２５２を備える、１つ以上のストリームに対するクライアントのセキュリティの基本設定を示すいくつかの要素を備える。取り込みノード、記憶ノード及び検索ノードに対する配置先の種類の基本設定は、それぞれ要素１２５４、要素１２５８及び要素１２６２に示され得る。取り込み制御ノード、記憶制御ノード及び検索制御ノードに対するＰＤＴの基本設定は、それぞれ要素１２５６、要素１２６０及び要素１２６４に示され得る。例えば、データレコードがあるノードのカテゴリから別のカテゴリへと伝送されるときに、暗号がデータレコードに対して実行されるか否か、及び／またはどのように実行されるか、のようなデータレコードに対する暗号化の基本設定は、要素１２６６を介して示され得る。図１２ａ及び図１２ｂに示されるようなセキュリティオプションの要求を使用して、クライアントは位置（例えば、プロバイダネットワークの内部またはプロバイダネットワークの外部）及びストリーム管理及び処理環境の異なる部分に対する、様々なその他のセキュリティプロフィールコンポーネントを選択可能であり得る。
ノードの配置先の選択は、少なくともいくつかの実施形態では、セキュリティよりもその他の理由にあることに注意する。例えば、クライアントは、性能上の理由から（例えば、主にセキュリティ上の理由よりもむしろ、前述の「ノイジーネイバー」の問題を避けるため）、シングルテナントのホストで実装される、いくつかの種類のＳＭＳまたはＳＰＳノードを有することを要望し得る。配置の選択は、少なくともいくつかの実施形態では、ストリームの耐用年数の間に変更され得る。例えば、クライアントは最初にＳＭＳノードがマルチテナントのインスタンスホストでのインスタンス化を許可するが、後で、ノードのサブセットの少なくともいくつかをシングルテナントのインスタンスホストに移動することを要望する可能性がある。少なくともいくつかの実施形態では、異なる価格設定が異なるセキュリティ関連のオプションに適用され得る。例えば、ＩＶＮの外部のマルチテナントのインスタンスホストよりも、ＩＶＮでの特定の機能的カテゴリのＳＭＳノードを実装する方が、費用がかかる可能性がある。またはマルチテナントのインスタンスホストでするよりも、シングルテナントのインスタンスホストでＳＭＳノードを実装する方が、費用がかかる可能性がある。
ストリームレコードのシーケンシャル記憶及びシーケンシャル検索
多くの種類のストリームアプリケーションには、データレコードが複数のデータ生成部１２０から高速でＳＭＳで受信されてよく、データコンシューマは、典型的には、レコードが生成された順番に、記憶されたデータレコードにアクセスすることを希望し得る。特に、前述したように、回転磁気ディスクがストリームデータレコードに記憶装置として使用される環境においては、シーケンシャルＩ／Ｏアクセスパターン（読み出し及び書き込み）は、ランダムＩ／Ｏアクセスパターンに優る著しい性能面での利点を有し得る。いくつかの実施形態では、ストリーム固有またはパーティション固有のシーケンス番号は、ＳＭＳによって受信されたときに、データレコードを割り当てられ得る。シーケンス番号に基づいたシーケンシャル検索操作が支援され得る。図１３ａは、少なくともいくつかの実施形態による、ストリームデータ生成部とＳＭＳの取り込みサブシステムとの間の相互作用例を示す。ストリームデータ生成部は、データレコード１１０を取り込みサブシステムに送信してよく、図示された実施形態においては、取り込みサブシステムは、送信されたレコード用に選択されたシーケンス番号１０２に応答してよい。少なくともいくつかの実施形態においては、取り込みノードは記憶サブシステムからシーケンス番号の一部を取得し得る。例えば、シーケンス番号１０２は、このような実施形態における、適用可能な永続性ポリシによる、受信されたデータレコードが記憶された後で決定され得る。また、記憶サブシステムは、データレコードに対し、自身の数列インジケータを生成してよく、取り込みノードによってデータレコードに割り当てられる、より大きなシーケンス番号に含めるために、そのインジケータを提供してよい。
シーケンス番号は、様々な実施形態において、安定的で一貫性のあるデータレコードの順序を提供するため、また、データコンュシーマによってレコード上で繰り返し反復することを可能にするために、実装され得る。少なくともいくつかの実装においては連続である必要はないが、特定のパーティションのデータレコードに割り当てられたシーケンス番号は、時間とともに単調増加し得る。様々な実施形態では、シーケンス番号は以下のセマンティックスの少なくともいくつかのサブセットに割り当てられ得る。（ａ）シーケンス番号はストリーム内で固有である。すなわち、所与のストリームの２つのデータレコードは同一のシーケンス番号に割り当てられる可能性はない。（ｂ）シーケンス番号は、ストリームのデータレコードに索引付けとして機能し得る。また、所与のストリームパーティション内のデータレコード内を繰り返して使用され得る。（ｃ）任意の所与のデータ生成部には、データ生成部が正常にデータレコードを送信する順序は、データレコードに割り当てられたシーケンス番号に反映される。及び（ｄ）所与のパーティションキー値を有するデータレコードにシーケンス番号の付与は、動的再分割操作にわたって、セマンティックの単調増加を維持する。例えば、再分割後にパーティションキー値Ｋ１を有するデータレコードに割り当てられたシーケンス番号は、任意のシーケンス番号よりもそれぞれが大きくてよく、このシーケンス番号は、動的再分割の前にそのパーティションキー値Ｋ１を有するデータレコードに割り当てられている。（動的再分割は図１６を参照して下記にさらに詳細が記載されている。）
いくつかの実施形態では、データ生成部は少なくともいくつかのデータレコードに選択されたシーケンス番号１０２の選択に影響したい可能性がある。例えば、そのストリームのデータコンシューマにとって、ストリームの特定のサブセットを対象とする読み出し要求を送信することをより容易にするために、データ生成部１２０は、境界または割り当てられたストリームのシーケンス番号内のセパレータを画定したいかもしれない。いくつかの実装においては、データ生成部１２０は、最小のシーケンス番号の表示をレコードとともに送信してよく、また、ＳＭＳは、上述したシーケンス番号のセマンティックにも従う、要求最小によるシーケンス番号を選択してよい。
図１３ｂは、少なくともいくつかの実施形態による、ＳＭＳでの取り込まれたデータレコードのために生成され得るシーケンス番号の要素例を示す。図示された実施形態においては、シーケンス番号は４つの要素、ｎ１−ビットＳＭＳバージョン番号１３０２、ｎ２−ビットタイムスタンプまたはエポック値１３０４、ｎ３−ビットサブシーケンス番号１３０６及びｎ４−ビットパーティション番号１３０８、を含み得る。いくつかの実装においては、１２８ビットのシーケンス番号が使用されてよく、例えば、ｎ１、ｎ２、ｎ３及びｎ４は、それぞれ、４、４４、６４及び１６ビットであり得る。バージョン番号１３０２は、例えば、ＳＭＳソフトウェアのどのバージョンがシーケンス番号を生成するために使用されたのか区別を容易にするために、単にＳＭＳソフトウェアバージョンのロールアウトを、混乱を避けるために使用され得る。バージョン番号１３０２は、少なくともいくつかの態様において変更が頻繁に行われることを想定していない。タイムスタンプ値１３０４は、例えば、取り込みサブシステムノードによってローカルクロックソースまたはグローバルにアクセス可能なクロックソース（例えば、ｇｅｔＣｕｒｒｅｎｔＥｐｏｃｈまたはｇｅｔＣｕｒｒｅｎｔＴｉｍｅ ＡＰＩを実装するプロバイダネットワークの状態管理システム）から取得され得る。少なくともいくつかの実装においては、時間においてよく知られたポイントからのオフセットは、（例えば、１９７０年１月１日の協定世界時００：００：００から経過した秒数であり、Ｕｎｉｘ（登録商標）ベースのオペレーティングシステムで、様々な時間に関連したシステムコールによって得ることができる）タイムスタンプ値１３０４に使用され得る。いくつかの実施形態では、サブシーケンス番号１０３６は、記憶サブシステムによって生成されてよく、特定のパーティションのデータレコードが記憶装置に書き込まれる順を示してよい。このように、多数のデータレコードが所与の秒内に受信され、タイムスタンプ値１３０４が約１秒から２秒の間隔でのみ変更する実装においては、サブシーケンス番号１３０６は、たまたま同一の秒内に到着し、そのため同一のタイムスタンプ値の割り当てられるデータレコードに対し、レコードが到着（または記憶）する順のインジケータとしての役割をしてよい。いくつかの実施形態では、パーティション番号１３０８は、所与のストリーム内のパーティションを固有に識別し得る。対応するデータレコードが取り込まれるシーケンス番号のタイムスタンプが（少なくともほぼ）クロックタイムを示す少なくともいくつかの実装においては、シーケンス番号が特定の種類の時間ベースの検索要求のためのインデックス機構に使用され得る。例えば、クライアントは、特定の日または特定の時間範囲の間に生成され取り込まれたストリームレコードを検索することを希望し、シーケンス番号はデータレコードの適切なセットを検索する暗黙の二次インデックスのキーとして使用され得る。このように、少なくともいくつかの実施形態においては、並べられた記憶及び検索に対するタイムスタンプを含むシーケンス番号の使用は、時間的なインデックスを格納されたデータレコードのセットに提供する追加の利点を有し得る。
所与のパーティションのデータレコードは、典型的には、シーケンス番号順に（例えば、ディスクに）書き込まれ、しばしば大規模な連続的な書き込み操作を使用して書き込まれる。いくつかの実施形態では、前述したように、イテレータベースのプログラムによるインタフェースは、データコンシューマがシーケンス番号順にデータレコードを読み込むことができるように実装され得る。図１４は、少なくともいくつかの実施形態による、ＳＭＳでのストリームデータレコードを順番に並べられた記憶及び検索する実施例を示す。パーティションＳｊ〜Ｐｋ（ストリームＳｊのｋ番目のパーティション）の、６つのデータレコード１１０Ａ〜１１０Ｆがシーケンス番号順に格納されていることを示す。図示されているように、シーケンス番号は少なくともいくつかの実施形態において、連続していない場合がある。例えば、値がタイムスタンプ部１３０４に割り当てられる手法か、または上述したサブシーケンス番号１３０６は、それらの要素に対して必ずしも連続値になるとは限らないからである。
図１４に示された実施例においては、データコンシューマは、イテレータが作成するよう要求し、シーケンス番号「８６５」での開始を明示する。要求に対して、ＳＭＳは、イテレータ１を初期化し、要求された開始シーケンス番号よりも大きいか等しい、最も近いシーケンス番号でデータレコードに配置する。この場合、シーケンス番号８７０のデータレコード１１０Ｃは、イテレータの開始位置として選択されており、次のより低いシーケンス（データレコード１１０Ｂに割り当てられた８６０）は、コンシューマの要求における開始シーケンス番号よりも小さい。このｇｅｔＩｔｅｒａｔｏｒインタフェースは、パーティション内の要求された位置でカーソルを設定するための要求の論理等価として考えられ、ｇｅｔＮｅｘｔＲｅｃｏｒｄインタフェースは、次に、例えばシーケンス番号順にストリームに沿ってカーソルを移動するために、カーソルの位置から始まるデータレコードを読み出すために使用され得る。図示された実施例では、データコンシューマはｇｅｔＮｅｘｔＲｅｃｏｒｄインタフェースを“ｉｔｅｒａｔｏｒ”のセットをＩｔｅｒａｔｏｒ１に、“ｍａｘＮｕｍＲｅｃｏｒｄｓ”（データレコードを返す最大数）のセットを３にするパラメータで起動する。したがって、ＳＭＳ検索サブシステムは、データレコード１１０Ｃ，データレコード１１０Ｄ及びデータレコード１１０Ｅをその順でデータコンシューマに返す。イテレータのＩｔｅｒａｔｏｒ１は、例えば、データレコード１１０Ｆのような、新しい位置に移動され、ｇｅｔＮｅｘｔＲｅｃｏｒｄが完了を宣言した後、次に同一のイテレータに対するｇｅｔＮｅｘｔＲｅｃｏｒｄの起動は１１０Ｆで始まるデータレコードを返し得る。ｇｅｔＩｔｅｒａｔｏｒの宣言のセマンティックスはいくつかの実施形態において異なり得る。例えば、特定のシーケンス番号よりも大きいか等しい、最も近いシーケンス番号でデータレコードでイテレータを配置する。イテレータは、いくつかの実施形態で、要求されたシーケンス番号と等しいかまたは低い最も近いデータレコードに配置され得る。別の実施形態では、クライアントはｇｅｔＩｔｅｒａｔｏｒの呼び出しにおける現在のシーケンス番号を特定しなければならない可能性がある。例えば、要求されたシーケンス番号がストリーム中に存在しない場合、エラーが返され得る。
パーティションマッピング
前述したように、様々なパーティション及び再分割ポリシによる様々な実施形態においては、所与のストリームのレコードの取り込み、記憶、検索及び処理に関するワークロードは、細分化され、いくつかのノードに分散される。図１５は、少なくともいくつかの実施形態による、ＳＭＳノード及びＳＰＳノードのために作成され得るストリームパーティションマッピング１５０１及び対応する構成決定の実施例を示す。例えばクライアントによるｃｒｅａｔｅＳｔｒｅａｍ ＡＰＩの起動に対応して、特定のデータストリームが作成されるか初期化されるとき、パーティショニングポリシはストリームのために有効にされ、ストリームの任意の所与のデータレコードがメンバと考えられるか、パーティションを決定するために使用され得る。所与のデータレコードに対して操作を実行する、取り込みサブシステム２０４、記憶サブシステム２０６、検索サブシステム２０８及び任意の関連するＳＰＳステージ２１５の特定のノードは、レコードのパーティションを基準にして選択され得る。一実施形態では、所与のデータレコードに使用される少なくとも制御ノードのサブセットは、パーティションにも基づいて選択され得る。少なくともいくつかの実施形態においては、データレコードの動的再分割は、例えば、ポリシに示されたトリガ条件または明示的な要求に対応して、パーティションポリシの一部として支援され得る。
様々な実施形態では、所与のデータレコードに選択されたパーティションは、レコードに対しては、パーティションキーに依存し、その値はデータ生成部によって直接（例えば、パラメータの書き込みまたは要求として）または間接的（例えば、ＳＭＳは、データ生成部のクライアントの識別子若しくは名前、データ生成部のＩＰアドレス、またはパーティションキーとしてデータレコードの実際のコンテンツの一部のようなメタデータを使用し得る）の何れかで供給され得る。１つ以上のマッピングの機能１５０６は、図１５に示された実施形態のデータレコードのパーティション識別子１５１０を決定するために、データレコードのパーティションキーまたは属性１５０２に適用されてよい。一実装においては、例えば、所与のパーティション識別子１５１０は、１２８ビットの整数値のスペースの連続した範囲にわたって、表し得る。ストリームのすべてのパーティションに対する範囲のユニオンが、１２８ビットの整数値が仮定する、すべての可能な値をカバーし得る。このような例示的な場合においては、１つの単純なマッピング機能１５０６は、データレコードのパーティションキー値（単数または複数）から１２８ビットのハッシュ値を生成するか、データレコードの属性値を選択されてよく、パーティションの識別子は、ハッシュ値がある特定の隣接する範囲に基づいて決定され得る。いくつかの実装においては、隣接する範囲は、少なくとも最初はサイズが等しく、その他の実装では、異なるパーティションは、互いにサイズが異なり得る隣接する範囲に対応する。再分割は、また、１つの実装において範囲の境界を調整する結果となり得る。その他のパーティション機能１０６は、異なる実装で使用され得る。
データストリームが（さらに詳細に下記に記載されているように）動的再分割された場合、特定のキーを有するレコードがマップされるパーティションは変更し得る。したがって、少なくともいくつかの実施形態においては、ＳＭＳ及び／またはＳＰＳ制御ノードは、ストリームの耐用年数の間、ストリームに適用する、いくつかの異なるマッピングを把握する必要がある。いくつかの実施形態では、タイムスタンプの有効性の範囲１５１１のようなメタデータまたはシーケンス番号の有効性の範囲は、各パーティションマッピングに制御ノードによって格納され得る。タイムスタンプの有効性の範囲１５１１は、例えば、特定のマッピングＭ１は、ストリームの作成時間から時間Ｔ１までを適用し、異なるマッピングＭ２はＴ１からＴ２等に適用することを表し得る。ストリームに向けられた読み出し要求に応答して、検索ノードは、どのマッピングが（例えば読み出し要求に示されたシーケンス番号に基づいて）使用され、次にそのマッピングを適切な記憶ノードを識別するために使用する。
少なくともいくつかの実施形態では、ＳＭＳ制御ノード及びＳＰＳ制御ノードは、いくつかの異なる粒度でパーティションをリソースにマッピングする役割をし得る。例えば、図１５の例示的な実装１５９９に示されているように、１つの実装、各取り込み、記憶、検索または処理（ワーカ）ノードは、実装され得る。サーバ仮想マシン内でそれぞれの処理、または実行のそれぞれのスレッドとしてＪａｖａ（登録商標）仮想マシン（ＪＶＭ）またはコンピュートインスタンス、及び各ＪＶＭまたはコンピュートインスタンスは特定の物理ホストでインスタンス化され得る。いくつかの実施形態では、多数のＪＶＭは、単一のコンピュートインスタンス内で起動されてよく、リソースのマッピング決定の別の層を加える。したがって、所与のパーティションには、１つ以上の制御ノードが、どの特定のリソースが取り込みノード１５１５、記憶ノード１５２０、検索ノード１５２５または処理ステージワーカノード１５３０（例えば、ステージＰＳ１またはステージＰＳ２に対してそれぞれ、ノード１５３０Ａまたはノード１５３０Ｂ）として使用されるべきか、選択し得る。制御ノードは、また、それらのノードをサーバ（取り込みサーバ１５３５，ストレージサーバ１５４０，検索サーバ１５４５または処理サーバ１５５０のように）にマッピングすること、及びサーバとホスト（取り込みホスト１５５５、ストレージホスト１５６０、検索ホスト１５６５またはＳＰＳホスト１５７０Ａ／ホスト１５７０Ｂ）との間をマッピングすることを決定し得る。いくつかの実装においては、パーティションマッピングは、示されている様々なリソースの粒度（例えば、ノード、サーバ及びホスト粒度）のそれぞれに、識別情報（例えば、リソースの識別子）を含むと考えられ得る。機能１５０６自身と同様に、機能１５０６への入力として使用されるデータレコードの属性の表示が使用される。制御サーバは、メタデータ記憶にてパーティションマッピングの表示を記憶し得る。いくつかの実施形態では、（ｇｅｔＰａｒｔｉｔｉｏｎＩｎｆｏＡＰＩのような）様々なＡＰＩまたはその他のプログラムによるインタフェースを暴露して、データ生成部、データコンシューマまたはＳＭＳサブシステムのノードまたはＳＰＳにマッピングの情報を提供し得る。
データレコードをパーティションにマッピングすること、及びパーティションからリソースにマッピングすることは、（ａ）所与のノード、サーバまたはホストは、いくつかの実施形態において、多数のパーティションの役割をするよう設計され得る、または（ｂ）破損またはその他のトリガは、所与のパーティションまたはパーティションのセットに割り当てられた新しいノード、サーバまたはホストがもたらされる可能性があるというような、様々な要因からさらにいくつかの実施形態においては複雑になり得る。加えて、上記に示したように、また下記に記載するように、所与のストリームに対するパーティションマッピングは、ストリームレコードがＳＭＳノード及び／またはＳＰＳノードによって処理され続ける一方、時間の経過とともに動的に修正され得る。その結果、マッピングのメタデータのいくつかのバージョンは、いくつかの実施形態においては、少なくとも一時的に所与のストリームに保持されるため、それぞれは異なる時間にそれぞれ対応し得る。
動的ストリームの再分割
図１６は、少なくともいくつかの実施形態による、動的ストリームの再分割の実施例を示す。図１６に示された時系列の時間Ｔ１で、ストリームＳ１が作成されるか初期化される。パーティションマッピングＰＭ１は、ストリームＳ１のために作成され、時間間隔Ｔ１からＴ２の間に有効を維持する。Ｔ１とＴ２との間のＳＭＳによって受信された３つのデータレコードは、一例として示されている。データレコード１１０Ａ（ＤＲ１１０Ａ）は、クライアントが供給するパーティションキー値「Ａｌｉｃｅ」とともに送信され、ＤＲ１１０Ｂはクライアントが供給するパーティションキー値「Ｂｉｌｌ」とともに送信され、ＤＲ１１０Ｃは、クライアントが供給するパーティションキー値「Ｃｈａｒｌｉｅ」とともに送信される。初期のマッピングＰＭ１において、すべての３つのデータレコード１１０Ａ、データレコード１１０Ｂ及びデータレコード１１０Ｃは、パーティション識別子「Ｐ１」を備える同一のパーティションにマッピングされる。Ｐ１データレコードには、単一のノードＩ１が取り込みを処理するために構成され、単一のノードＳ１は、記憶装置を処理するために構成され、単一のノードＲ１は、検索を処理するために構成され、及び単一のワーカノードＷ１は、ＳＰＳ処理を行うために構成される。ＰＭ１をマッピングする有効な範囲の開始のタイムスタンプはＴ１に設定されている。
時間Ｔ２、ストリームＳ１は、図１６の例示的な時系列において動的に再分割される。図示された実施形態において、データレコードは継続して到着し、ＳＭＳ及びＳＰＳによって処理される。再分割がいつ起こるのかに関係なく、ＳＭＳまたはＳＰＳの何れもオフラインにする必要はない。例えば、取り込み、記憶、検索または処理ノードにおいてオーバーロード状態の検出に対応して、様々なサブシステムの異なるホストでのワークロードレベル間のずれ、または不均衡の検出に対応して、またはデータコンシューマ若しくはデータ生成部からの要求に対応して、再分割はいくつかの要因のいずれかの結果として開始され得る。図示された実施形態において、ＰＭ２に示された有効範囲の開始タイムスタンプの設定によって示されるように、新しいマッピングＰＭ２は、時間Ｔ２（またはＴ２の直後）で影響を及ぼす。少なくともいくつかの実装においては、データレコードの属性の異なるセットは、再分割の前に使用されたよりもデータレコードの分割に使用され得る。場合によっては、追加の分割の属性は、（例えば、ＳＭＳの要求で）データ生成部によって送信され得る。一方、その他の場合では、追加の属性はＳＭＳ取り込みノードによって生成され得る。このような追加の属性は「塩漬けされた」属性と称され得る。再分割に追加の属性を使用する技術は、「塩漬けする」と称され得る。一例示的な実装においては、オーバーロードした取り込みサーバは、データ生成部（例えば、データ生成部によって実行されるＳＭＳクライアントライブラリコード）に示してよく、再分割には、無作為に選択された小整数値が以前に使用されたパーティションキーに加えて提供される。元のパーティションキーと塩漬けされた追加の整数との組み合わせは、その後に、取り込みノードの異なるセットに取り込みワークロードを分散するために使用され得る。いくつかの実施形態では、検索ノード及び／またはデータコンシューマは、再分割に使用される追加の属性に関して通知される必要があり得る。このような追加の属性は、少なくともいくつかの実装において、再分割に使用されなくてよい。
図１６に示す実施形態では、Ｔ２前の同一のキーのために選択されたパーティションに対して、新しいパーティションマッピングは、Ｔ２の後に受信されたデータレコードの少なくともいくつかのために選択された、異なるパーティションの結果になる。ＤＲ１１０Ｐは、パーティションキー値「Ａｌｉｃｅ」でＴ２の後に送信され、ＤＲ１１０Ｑは、パーティションキー値「Ｂｉｌｌ」でＴ２の後に送信され、ＤＲ１１０Ｒは、パーティションキー値「Ｃｈａｒｌｉｅ」でＴ２の後に送信される。図示された場合においては、ＰＭ２のマッピングを使用して、ＤＲ１１０Ｐは、パーティション「Ｐ４」のメンバに指定され、ＤＲ１１０Ｑは、パーティション「Ｐ５」のメンバに指定され、一方、ＤＲ１１０Ｒは、パーティション「Ｐ６」のメンバに指定される。図示された実施形態において、Ｔ２の後の受信として示される、例示的なデータレコードの何れも、以前に使用されたパーティションの「Ｐ１」のメンバとして指定されない。その代わりに、完全に新しいパーティションが、再分割後に使用され得る。いくつかの実施形態では、少なくともいくつかの以前に使用されたパーティションが再分割後に使用され続けてよい。新しいパーティションのＰ４、Ｐ５及びＰ６のそれぞれには、異なるノードが取り込み、記憶、検索及び／または処理に指定され得る。例えば、ノードＩ４、ノードＳ４、ノードＲ４及びノードＷ４は、パーティションＰ４に構成されてよく、ノードＩ５、ノードＳ５、ノードＲ５及びノードＰ５は、パーティションＰ５に構成されてよく、ノードＩ６、ノードＳ６、ノードＲ６及びノードＰ６は、パーティションＰ６に構成されてよい。いくつかの実施形態では、同一の記憶ノードは、再分割前のこのようなレコードに使用されたように、再分割後の特定のパーティションキーまたは属性を備えるレコードに使用され得る。しかしながら、そのノード（例えば、異なるディスク、異なるディスクパーティションまたは異なるＳＳＤ）内の異なる記憶位置は、再分割後に使用され得る。
Ｔ２での動的再分割後、少なくともある時間、検索要求は、再分割の前にＳＭＳ取り込み及び／または記憶サブシステムによって処理された、データレコードのために、継続して検索されてよい。少なくともいくつかの場合においては、要求されたデータレコードは、データレコードが取り込まれた時に有効である、ＰＭ１マッピングに基づいて検索される必要があり得る。したがって、図１６に示されたように、データ検索の目的で、ＰＭ１及びＰＭ２の両方は、Ｔ２の後のある時点で継続して使用され得る。少なくともいくつかの実装においては、データレコードは、古くなるにつれて、ストリームから最終的に削除され、より古いパーティションマッピングは、また、最終的に破棄され得る。例えば、すべての対応するデータレコード自体が削除される。いくつかの実施形態では、削除される代わりに（または削除の前に）、ストリームレコードは、ＳＭＳによって使用されるパーティションマッピングは、アーカイブの後、レコードを検索することが依然として不可能なように、記憶位置または記憶装置の異なるセットに、（例えば、クライアントが選択したアーカイブポリシに基づいて）アーカイブされ得る。このような実施形態においては、アーカイブストレージに向けられた検索要求を支援する必要がある限り、ＰＭ１及びＰＭ２のようなパーティションマッピングは保持され得る。いくつかのアーカイブの実装においては、ストリームパーティションマッピングが保持される必要のない、異なる検索手法が使用され得る（例えば、新しいインデックスがアーカイブされたデータレコードのために作成され得る）。いくつかの実施形態では、再分割の前に使用されたが、再分割の後、書き込みがもはや指示されない、Ｐ２のようなパーティションは、再分割の後ある時点で読み込みのために「閉じられ」得る。例えば、「パーティションの最後に達しました」というエラーメッセージの等価は検索要求に対して提供され得る。
いくつかの実装においては、所与のデータストリームは、多数（例えば、何十万）のパーティションに分かれ得る。ストリームＳ１が初めに１０００のパーティションのＰ１，Ｐ２，・・・，Ｐ１０００に分かれる例示的な場合を考える。１つのパーティション、例えばＰ７に対応するオーバーロード状態が検出される場合、データレコードＰ７を初期のマッピングを変更することは価値があり得るが、その他のパーティションのマッピングは、変更される必要はない。１つの手法においては、２つの新しいパーティションＰ１００１及びＰ１００２が、再分割操作を介して作成され得る。その属性が元々、（すなわち、元のマッピングを基準として）Ｐ７におけるメンバの結果となる再分割後に受信されたレコードは、再分割後、つまり、２つのパーティションのうち、Ｐ７のワークロードを分配した後、Ｐ１００１またはＰ１００２のいずれかにマッピングされ得る。残余のパーティション、例えばＰ１〜Ｐ６及びＰ８〜Ｐ１０００は、修正される必要はなくてよい。小さなパーティションのサブセットのみがこのような再分割によって影響を受けるため、少なくともいくつかの実施形態では、パーティション入力（またはパーティション入力のツリー）の有向非巡回グラフのような組み合わされたデータ構造が、生成され、格納され得る。各入力は、パーティション機能の出力範囲と、有効な時間範囲（入力のパーティション情報が有効である時間）を示し得る。前述の例では、Ｐ７を含む再分割は、時間Ｔ２で実行された。一方、ストリームＳ１（及びその初期のマッピング）は時間Ｔ１で作られる。このような場合においては、Ｐ７に関する入力の有効な時間は「Ｔ１からＴ２」であり、Ｐ１００１及びＰ１００２の有効な時間は「Ｔ２以降」、及び残りのパーティションの有効な時間は、「Ｔ１以降」であろう。このような組み合わされたデータ構造の使用は、少なくともいくつかの実装における、パーティションマッピングのメタデータに使用される、メモリまたはストレージに実質的な減少につながり得る。上記の例では、パーティションＰ７を２つの新しいパーティションに分けることが記載されていた。少なくともいくつかの実装においては、パーティションはまた、再分割をする間にマージされ得る。例えば、比較的少ない検索要求が受信され、または比較的少ないレコードが送信された、２つの隣接したパーティションは、単一のパーティションにマージされ得る。任意の所与の時点では、データレコードが属するパーティションは、パーティションの機能及び有効な時間範囲の情報を使用して、明確に決定され得る。時間の経過とともに、組み合わされたデータ構造は、より多くの分割及び／またはマージが実行されながら発展し得るが、メタデータを分割するために必要な全空間は、急激に増加し得ない（分割の頻度、分割によって影響を受けるパーティションの平均数）。対照的に、異なる実施形態では、再分割が起こるたびに、ストリームのための変更されていないメタデータのセットの全体が、複製され、再分割の影響を受けたパーティションのための入力とセットで組み合わされ得る。パーティションマッピングのメタデータのためのストレージ及びメモリの要求は、後の実装においては、さらに速い速度で増加し得る。特に以前のマッピングが上記のように、再分割後の少なくともある時点で、保持される必要があり得る。
タイムスタンプ値（図１３ｂに示されたタイムスタンプ値１３０４のような）を含むシーケンス番号が使用される、少なくともいくつかの実施形態では、シーケンス番号の推移の特定の種類は、動的再分割のために実装され得る。図１３ｂに示されているのと同様に、タイムスタンプベースのシーケンス番号のスキームがストリームＳ１に使用される一例として考えると、新しいタイムスタンプ値が常にシーケンス番号で生成される動的再分割が支援される少なくともいくつかの実装においては、動的再分割後割り当てられたシーケンス番号は、（再分割に対応して、選択された初期のタイムスタンプ値から始まる）動的再分割前に使用されるものと異なるタイムスタンプ値のセットをすべて使用し得る。例えば、動的再分割がコミットする（すなわち、有効になる）時間で使用されるタイムスタンプ値がＴｋであった場合には、コミット後に発行される新しいシーケンス番号は、Ｔｋ＋１以降のタイムスタンプ値を使用する必要があり得る。シーケンス番号値が、図１３ｂに使用されるスキームにおける少なくともいくつかの上位ビットをタイムスタンプ値を符号化するため、記載されたように、タイムスタンプの境界に対応する再分割のイベントは、順次、検索要求に対応して使用されるマッピングの識別に関する記帳を簡素化し得ることを確実にする。したがって、このような実装においては、特定のシーケンス番号を特定する検索要求が受信されると、タイムスタンプ値がシーケンス番号から抽出されてよく、再分割後のマッピングが使用されるべきか、または再分割前のマッピングが使用されるべきかを容易に判断され得る。抽出されたタイムスタンプ値が、再分割のために選択された初期のタイムスタンプよりも低い場合には、再分割前のマッピングが使用されてよく、抽出されたタイムスタンプ値が再分割に選択された初期のタイムスタンプ値に等しいかまたは高い場合には、再分割後のマッピングが使用され得る。
ストリームの管理及び処理の方法
図１７は、少なくともいくつかの実施形態による、ストリームレコードの取り込み及びストリームレコードの検索用のプログラムによるインタフェースのそれぞれのセットを支援するために実行され得る、操作の態様を示すフローチャートである。要素１７０１に示されているように、例えば、ＳＭＳのクライアントまたはデータ生成部のクライアントから、データストリームを作成するか初期化する要求が受信され得る。ストリームに使用される初期のパーティションマッピングは、決定され得る（要素１７０４）。例えば、特定のデータレコードが属するパーティションを識別するのに使用される機能（単数または複数）、及び機能（単数または複数）に使用される入力パラメータは、パーティションポリシに基づいて識別され得る。前述のように、ＳＭＳの制御コンポーネントは、様々な実施形態で、ストリームの作成要求を受信し、応答する役割をし得る。ストリームの作成及び初期化が実行される方法（その他の制御プレーン操作と同様に）は、一実施形態から別の実施形態によって異なり得る。一実施形態では、例えば、制御サーバの冗長グループが確立されてよく、その冗長グループのプライマリ制御サーバは、（例えば、初期パーティションマッピング、取り込みノード、記憶ノード及び検索ノード等の初期のセット）新しいストリームのために、永続性記憶位置に、適切なメタデータを生成し格納することによって、ストリーム作成要求に応答してよい。ストリームに関する次のクエリに対する応答（例えば、所与のパーティションの役割をするバックエンドノードに関するフロントエンドの取り込みノードからの要求）は、格納されたメタデータを使用するプライマリ制御サーバによって生成され得る。ＳＭＳ制御プレーンの機能の別の実装では、ストリーム構成のメタデータは、取り込みサブシステム、記憶サブシステムまたは検索サブシステムの少なくともいくつかのノードによって直接アクセス可能なデータベースに格納され得る。ストリームが作成し初期化された後、典型的には制御コンポーネントと追加の相互作用をせずに、レコードの送信、記憶及び検索のようなデータプレーンが開始してよく、対応するサブシステムのそれぞれのコンポーネントによって処理されてよい。
いくつかの実施形態では、データ生成部は書き込み要求を有する明示的なパーティションキーを送信する必要はなくてよい。一方、その他の実施形態においては、パーティション機能に使用される入力は、データ生成部の識別、データレコードが受信されるＩＰアドレス、またはデータレコード自身のコンテンツからのような、書き込み要求に関連するメタデータに基づいて決定され得る。少なくとも一実装においては、クライアントは所望により、データレコードの送信におけるパーティションの識別子を供給し、追加のパーティション機能は、このような実装にいて必要とされなくてよい。
ストリームのための取り込み機能、記憶機能及び検索機能用のノードの初期セットを決定または構成するとき、いくつかの異なる要素が考慮に入れられ得る（要素１７０７）。例えば、（ストリームが分けられるパーティションの数及びパーティションの関連する予想サイズを決定し得る）パーティションマッピング自体、このような情報が入手可能な場合には予想される取り込み率及び／または検索率に関する情報、ストリームデータレコードのための耐久性／永続性の要件、及び／または（図９及び図１０に示されたものと類似の冗長グループの設定になり得る）様々なサブシステムのための高可用性の要件は、異なるサブシステムのノードの数と配置に影響し得る。加えて、クライアントが、（図１１、図１２ａ及び図１２ｂに示されるように）様々なカテゴリのノードに対して配置先種類の基本設定を示し得る実施形態においては、このような基本設定は、また、ＳＭＳ及び／またはＳＰＳノードに使用されるリソースを決定する上で役割をし得る。少なくともいくつかの実施形態においては、取り込み、記憶及び／または検索機能の実行が可能なノードのそれぞれのプールは、前もって設定され、制御コンポーネントは、作成される新しいストリームのそれぞれにこのようなプールの選択されたメンバを割り当て得る。その他の実施形態では、少なくともいくつかの場合においては、新しい取り込みノード、記憶ノードまたは検索ノードは、ストリームが作成または初期化されるときにインスタンス化される必要があり得る。
図示された実施形態における取り込みノードでは、レコードは、例えば、（データは送信要求に含まれている）インラインの送信インタフェースを含む、データレコードの送信（要素１７１０）のために実装されたプログラムによるインタフェースのセットのいずれかを介して受信され、参照によるバイリファレンス送信インタフェース（アドレスが送信要求に提供され、たとえば、ウェブサービス要求またはその他のインタフェースを使用してデータがＳＭＳ取り込みノードまたはＳＭＳ記憶ノードによって検索され得る。）いくつかの異なる種類のプログラムによるインタフェースのいずれかは、レコードを送信する方法のそれぞれに、異なる実施形態に提供され得る。例えば、それぞれのアプリケーションプログラミングインタフェース（ＡＰＩ）は、インライン対バイリファレンス送信のために支援され得る。ウェブページまたはウェブサイトは確立され、グラフィカルユーザインターフェースが実装され、またはコマンドラインツールが開発され得る。少なくともいくつかの実施形態においては、ＳＭＳは各取り込みレコードにシーケンス番号を割り当て得る。例えば、レコードが取り込みまたは格納される順に表示し、シーケンス番号はデータコンシューマによって検索要求に使用可能であり得る。検索サブシステムノードでは、レコード検索要求は、実装されたプログラムによる検索インタフェースの任意のセットを介して受信され、要求されたデータレコードのコンテンツは、応答（要素１７１３）に提供され得る。非シーケンシャルなアクセスには、例えばインタフェースは、（ｇｅｔＩｔｅｒａｔｏｒの起動で示されたシーケンス番号に基づいて、イテレータがパーティション内で選択された位置でインスタンス化されるように要求する）ｇｅｔＩｔｅｒａｔｏｒまたは（特定のシーケンス番号を備えたデータレコードを取得するための）ｇｅｔＲｅｃｏｒｄＷｉｔｈＳｅｑｕｅｎｃｅＮｕｍｂｅｒを含み得る。シーケンシャルなアクセスには、（イテレータの現在位置から始まる順、または特定のシーケンス番号から始まる順に、いくつかのレコードを要求する）ｇｅｔＮｅｘｔＲｅｃｏｒｄのようなインタフェースが実装され得る。少なくともいくつかの実施形態においては、異なる検索インタフェースは、それに関連する異なる課金率を有し得る。例えば、シーケンシャル検索のためのレコード課金毎の率は、非シーケンシャル検索に対するレコード毎の課金率より低く設定され得る。異なる送信インタフェースは、またいくつかの実施形態において、異なる課金率を有し得る。例えば、バイリファレンス送信は、インライン送信よりもレコード毎の費用がよりかかり得る。
時間の経過とともに、制御ノードまたは特定の課金サーバは、ストリーム管理サービス（要素１７１６）の様々なサブシステムで実装される異なるプログラムによるインタフェースに対する使用メトリクスを収集し得る。例えば、このメトリクスは、異なるプログラムによるインタフェースの起動カウントと、（単一起動で多数のレコードを検索するために使用され得るｇｅｔＮｅｘｔＲｅｃｏｒｄのような、少なくともいくつかのインタフェースのための起動カウントとは異なり得る）取り込まれるか検索されるレコードの総数と、取り込まれるか検索されるデータの総量等とを含み得る。ストリームを所有するクライアントまたはストリームからデータを生成及び／若しくは消費するクライアントに請求される課金額は、プログラムによるインタフェース（要素１７１９）に関連する、少なくとも部分的に使用メトリクス及びそれぞれの課金率に基づいて、所望により生成され得る。少なくともいくつかの実施形態においては、課金動作は、ストリーム取り込み／検索操作に関して非同期であり得る。例えば、請求書はその月の間に収集されたメトリクスに基づいて月毎の請求期間の最後に生成され得る。
図１８ａは、少なくともいくつかの実施形態による、ストリーム処理ステージ（ＳＰＳ）を構成するよう実行され得る、操作の態様を示すフローチャートである。要素１８０１に示されているように、プログラムによるインタフェースは、クライアントがストリームデータレコードのためにいくつかの処理ステージ構成可能にするよう実装され得る。例えば、特定のステージを構成するために、クライアントは、ステージで分割されたストリームデータレコード上で実行される処理操作（単数または複数）を示してよく、処理されるデータの入力ストリームの識別のような、その他のパラメータと同様に、処理操作の出力のための分散ポリシが取得され得る。いくつかの実施形態では、ＳＰＳステージでの処理操作は、冪等に必要であり得る。その他の実施形態では、非冪等の操作は、また、少なくともいくつかのステージで支援され得る。所与のステージで実行される処理が非冪等である場合、クライアントは依然として、いくつかの実施形態で、ワーカノードが定期的に、いくつかの永続性のある外部位置に操作の出力をフラッシュするように構成し、レコード検索シーケンスに関してフラッシュ操作がいつ実行されたか記録し、及び後に交換されたワーカノードが回復中にフラッシュ操作を再操作するよう構成することで、回復に関連した冪等の利益を取得することが可能である。少なくともいくつかの実施形態においては、並行してストリームデータ上で操作しているいくつかの異なる状態、及びその他のステージに入力ストリームとして使用されるいくつかのステージの結果を備える、クライアントは有向非巡回グラフ（ＤＡＧ）またはその他の処理ステージのグラフを構成することが可能であり得る。いくつかの実施形態では、永続性ストリームよりもむしろ、１つ以上の一過性は、異なるステージ間で作成され得る。例えば、１つのステージからのデータレコード出力は、異なるステージに入力として入れられる前に、必ずしも永続性記憶装置に格納されない。
例えば、チェックポイントベースの回復ポリシまたはベストエフォート回復ポリシを含む、いくつかの実施形態では、いくつかの異なる回復ポリシのいずれかは、ＳＰＳステージに実装され得る。一実施形態では、クライアントは異なるＳＰＳステージに対する回復ポリシを選択するために、プログラムによるインタフェースを使用し得る。チェックポイントベースの回復が使用されるステージでは、ワーカノードは、プログレスレコードまたは間隔毎のチェックポイントを格納するよう構成され、ストリームパーティション内でワーカノードがどのくらいまで達したのか示し得る（例えば、一番最近処理されたレコードのシーケンス番号がプログレスのインジケータとして格納され得る）。図１９を参照して以下に記載されたように、プログレスレコードは、破損後の復旧操作の間、後に使用され得る。ベストエフォートリカバリポリシにおいては、プログレスレコードは格納される必要がなく、破損に対応して構成される交換されたワーカノードは、受信されるときに新しいデータレコードを単に処理し得る。所与のＳＰＳステージグラフまたはワークフローの中では、いくつかの実施形態において異なる回復ポリシが異なるステージに適用され得る。
ＳＰＳ制御サーバは、例えば、要素１８０１において示されたプログラムによるインタフェースの１つを介して、パーティションポリシＰＰｏｌ１による、ストリームＳ１の特定のステージＰＳ１で実行される冪等操作Ｏｐ１の表示を受信してよく、処理の結果が出力分散ディスクリプタＤＤｅｓｃ１に従って分散される（要素１８０４）。状態ＰＳ１のために構成されるワーカノードの数及び、ノードに必要な仮想リソースまたは物理リソースは、例えば、Ｐｐｏｌ１冪等操作Ｏｐ１の複雑性及びワーカノードに使用されるリソースの遂行能力（要素１８０７）のような様々な要因に基づいて、決定され得る。
ワーカノードは、次にインスタンス化され、例えば、選択された仮想または物理マシンリソースで、プロセスまたはスレッドとして構成され得る（要素１８１０）。単純な一実装においては、例えば、１つのワーカノードは、Ｓ１の各パーティションに最初に割り当てられ得る。所与のワーカノードは、（ａ）Ｓ１の検索ノードの適切なサブセットからデータレコードを受信し、（ｂ）受信されたデータレコード上でＯｐ１を実行し、（ｃ）所望により、例えば、ＰＳ１のために回復ポリシに基づいて、パーティションレコードのセットが処理されたことを示すプログレスレコード／チェックポイントを格納し、及び（ｄ）ＤＤｅｓｃ１（例えば、中間永続性ストリームまたは一過性ストリームへの入力、またはその他の処理ステージまたは記憶システムへの直接入力）によって示された宛先に出力を伝送するよう構成され得る。少なくともいくつかの実施形態においては、ＳＰＳ処理は、継続的にどこかに伝送される必要がある任意の出力を必ずしも生成しなくてよいことに注意する。例えば、いくつかのＳＰＳアプリケーションは、単にデータレコードの一時的なリポジトリとして機能し、及び／またはユーザがデータレコードを見ることを可能にするクエリのインタフェースを実装し得る。このようなアプリケーションは、出力を管理し得る。例えば、出力は受信されたクエリに対応して生成され得るが、分散されたディスクリプタにより生成されない。ロギングに関連したＳＰＳアプリケーションは、大規模な分散システムから収集された最終日のログレコードを保持し、例えば、クライアントがデバッグまたは分析の目的でロギングデータを見ることを可能にする。したがって、いくつかの実施形態では、出力分散ディスクリプタは、ＳＰＳの少なくともいくつかのステージ、少なくともいくつかのストリーム、または少なくともいくつかのパーティションのために特定される必要はない。ワーカノードは、次に、それぞれの構成の設定（要素１８１３）通りに、検索を開始し、データレコードを処理し始め得る。少なくともいくつかの実施形態においては、ＳＰＳ制御ノードは、ワーカノード（要素１８１６）に使用されるリソースにおけるリソース利用レベルのような、様々なその他のメトリクスと同様に、（例えば、ハートビートプロトコルのように応答性チェックを使用して）ワーカノードのヘルスステータスを監視し得る。ワーカノードから収集される情報は、下記に記載するように、例えば、ワーカノードは置換えられ、回復ポリシが実装されるべき場合にフェイルオーバが必要か否かを決定するために使用され得る。
いくつかの実施形態では、実装可能なＳＰＳクライアントのライブラリは、クライアントが所有する構内でＳＰＳワーカノードを、及び／またはクライアントが選択するプロバイダネットワークのリソースを実装することを希望するクライアントに提供され得る。クライアントのライブラリはまた、ＳＰＳクライアントが、ヘルス監視機能、自動ワークロード監視及び分散、セキュリティ管理、動的再分割等のような、ＳＰＳ管理サービスの様々な制御プレーン特徴の使用を希望する程度を選択するのを可能にし得る。図１８ｂは、少なくともいくつかの実施形態による、ストリーム処理ワーカノードの構成のための、クライアントのライブラリコンポーネントの起動に対応して実行され得る操作の態様を示すフローチャートである。要素１８５１に示されるように、ＳＰＳクライアントのライブラリは、（例えば、図１８ａに図示したように、操作の種類を実行するよう構成されるマルチテナントのＳＰＳ管理サービスのウェブサイトからダウンロードを介して）提供され得る。ライブラリは、いくつかの実行可能なコンポーネント及び／またはクライアントのアプリケーションにリンク可能なコンポーネントを含み得る。いくつかのライブラリのコンポーネントは、クライアントが、選択、ＳＰＳ管理サービスを登録、または１つ以上のＳＰＳステージのストリーム処理操作が実行される、様々なワーカノードの所望の特性を明示することを可能にし得る。例えば、あるクライアントは、ワーカノードのためのプロバイダネットワークの仮想計算サービスで実装されるコンピュートインスタンスのセットを使用することを希望してよい。一方、別のクライアントは、ストリームレコードを処理するために、（プロバイダネットワークによって支援されない専用装置のような）クライアント自身のデータセンタに配置された計算装置を使用することを希望してよい。クライアントはワーカノードをクライアントの構内において必要に応じて、または所望により、仮想計算サービスのコンピュートインスタンスを使用してオンラインにし得る。このようなオンデマンドでのワーカノードのインスタンス化に加え、またはその代わりに、いくつかの実施形態では、クライアントは、必要な時に配置され得る、潜在的に再利用可能なワーカノードのプールを事前に構成し得る。いくつかの実装においては、ライブラリコンポーネントは、クライアントが、指定されるステージのワーカノードのようなクライアントによってインスタンス化される、ＳＰＳ管理サービス、特定のプロセスまたはスレッドでの登録を可能にするよう実行または起動されてよく、後の制御プレーン操作がＳＰＳ管理サービスによって処理され得る。一実施形態では、クライアントは、またワーカノードのためにＳＰＳ管理サービスによって処理される異なるレベルの制御プレーンの役割から選択することも可能であり得る。例えば、あるクライアントは、ワーカノードのヘルス状態を監視するためにクライアント自身のカスタムモジュールを使用することを希望し、一方、別のクライアントはワーカノードのヘルス状態を監視し、破損が検出された場合には適切な行動を取るためのＳＰＳ管理サービスを利用することを希望し得る。
ＳＰＳ管理サービスは、特定のクライアントは、特定のＳＰＳステージＰＳ１（要素１８５４）のワーカノード及び／または制御プレーン操作を構成するクライアントのライブラリを使用することを希望するという表示を受信し得る。（ＰＳ１自体は、ライブラリに含まれるプログラムによるインタフェースまたはＳＰＳ管理サービスによって露出されるプログラムによるインタフェースを使用して設計されてよく、これは図４に示されたウェブベースのインタフェースに類似している）クライアントはまた、データがＰＳ１による入力として使用するために検索されるストリームを示し得る。所望により、少なくともいくつかの実施形態においては、クライアントは、例えばクライアントがノードのために、サービスのヘルス状態の監視能力を使用することを希望するか、または独自のヘルス状態を監視するツール（要素１８５７）を使用することを希望するかに対するＰＳ１に制御プレーンを設定を示し得る。クライアントによって示された基本設定に応じて、クライアントの使用するために構成されるＳＭＳ及び／またはＳＰＳの１つ以上のノードは、決定され得る（要素１８６０）。ネットワークの接続性は、ＳＭＳ及び／またはＳＰＳのノードへのクライアントのワーカノード、並びに／またはその他の構成操作は、データレコードが流れ、かつ所望の結果を処理することを可能にするために実行され得る。データレコードは、検索要求を受信するとＳＰ１ワーカノードに提供され、所望の制御プレーン操作（クライアントによってそれが要求された場合）は必要に応じて実行され得る。少なくともいくつかの実施形態においては、クライアントが、ＳＭＳ管理サービスの様々なサブシステムの制御プレーンの機能性を使用することを希望する範囲の制御を可能にする類似の手法も、あるいはその代わりに実装され得ることに注意する。
図１９は、少なくともいくつかの実施形態による、ストリーム処理のために１つ以上のリカバリポリシを実装するために実行され得る、操作の態様を示すフローチャートである。要素１９０１に示されているように、ＳＰＳ制御ノードは、特定のワーカノードを置き換えるためのトリガ基準が合致したと決定し得る。例えば、ワーカノードは応答しなくなるか、ヘルス状態でなくなり、現在のノードのワークロードレベルは、フェイルオーバのため閾値に達し、ワーカノードで検出された、いくつかのエラーは、閾値を超え、またはワーカノードの何か別の予期しない状態が識別され得る。置換えられたワーカノードは識別されるかインスタンス化され得る（要素１９０４）。いくつかの実施形態では、入手可能なワーカスレッドのプールが設定され、置き換えとして選択されてよく、例えば、新しいスレッドまたはプロセスが開始され得る。
ベストエフォートリカバリポリシが、特定のワーカノードが動作しているＳＰＳステージで（要素１９０７にて決定される際に）使用される場合には、置き換えられたワーカノードは、入手可能になるときに（要素１９１６）、追加のデータレコードを単に処理し始めてよく、例えば、置換えられたワーカノードの進捗記録は確認されない。チェックポイントベースの回復ポリシが使用される場合、置換えられたワーカノードは、置換えられたワーカノードによって格納されたプログレスレコードにアクセスし得る位置の表示（例えば、記憶装置のアドレスまたはＵＲＬ）は、提供され得る（要素１９１０）。置換えられたワーカノードは、置換えられたノードによって格納された直近のプログレスレコードを検索し、置換えられたワーカノードが、ステージの冪等操作を実行（要素１９１３）すべきデータレコードのセットを決定するためにプログレスレコードを使用し得る。このようなチェックポイントベースの回復ポリシにおいては、最後のプログレスレコードと置換えられたワーカノードがインスタンス化される時間との間の持続時間に応じて、置換えられたワーカノードが、記憶されたプログレスレコード以降の、追加のレコードを処理した速度と同様に、いくつかの数のデータレコードが２回以上処理され得る。実行されるこの操作は冪等である場合には、このような反復操作は少なくともいくつかの実施形態では、良くない影響を有し得ない。置換えられたワーカノードが、以前に格納されたプログレスレコードに基づいて、反復の回復操作を実行した後、少なくともいくつかの実施形態では、置き換えのワーカスレッドは、そのプログレスレコードを格納してよく、回復が完了したことを示し、新しく受信されたデータレコード（要素１９１６）上の通常のワーカスレッド操作を開始してよい。
図２０は、少なくともいくつかの実施形態による、データストリーム用の複数のセキュリティオプションを実装するために実行され得る、操作の態様を示すフローチャートである。要素２００１に示されているように、クライアントがデータストリームの管理及び処理のために、例えば、異なる機能カテゴリ（例えば、取り込み、記憶、検索、処理または制御ノード）のノードのための配置先の種類の選択肢を含む、様々なセキュリティオプションから選択するのを可能にする、１つ以上のプログラムによるインタフェースが実装され得る。配置先の種類は、様々なセキュリティプロフィールに関連する態様において、互いに異なり得る。ＳＭＳまたはＳＰＳノードに使用されるリソースの物理位置は、いくつかの実施形態において、宛先の種類によって異なり得る。例えば、プロバイダネットワークデータセンタに配置されるインスタンスホストのようなリソースは、ノードに使用され得る。またはクライアントが所有する設備のリソースが使用され得る。または第三者のリソースが使用され得る。ネットワーク隔離レベルまたはその他のネットワークの特徴は、少なくともいくつかの実施形態において、宛先の種類によって異なり得る。例えば、いくつかのＳＭＳノードまたはＳＰＳノードは、隔離された仮想ネットワーク内、または、専用の隔離された物理リンクを介してプロバイダネットワークに接続されたクライアントが所有する設備でインスタンス化されてよい。一実施形態では、特定の種類のＳＭＳノードまたはＳＰＳノードは、入手することも可能なマルチテナントのインスタンスホストを使用する代わりに、プロバイダネットワークのシングルテナントのインスタンスホストに確立されることをクライアントは示し得る。少なくともいくつかの実施形態においては、様々な種類の暗号化の選択肢はまた、セキュリティに関連するプログラムによるインタフェースを介して選択され得る。
クライアントのセキュリティプロフィールの選択またはストリームＳ１のための１つ以上の機能カテゴリのノードに関する基本設定は、セキュリティに関連するプログラムによるインタフェースを介して受信され得る。例えば、クライアントは機能カテゴリＦＣ１（例えば、クライアントはクライアントが所有する構内でＳＰＳワーカノードを実装したいと希望し得る）のノードに１つのセキュリティプロフィール及び異なる機能カテゴリＦＣ２のノードに異なるセキュリティプロフィール（例えば、クライアントはプロバイダネットワークデータセンタでのＳＭＳ取り込みノードまたは記憶ノードの実装を希望し得る）（要素２００４）を選択し得る。場合によっては、クライアントは類似のセキュリティプロフィールですべての異なる機能カテゴリのノードを設定すると決定し得る。ＳＭＳ及び／またはＳＰＳは、いくつかの実施形態では、様々な機能カテゴリに対し、デフォルトの配置先種類を定義し得る。例えば、クライアントが支持しない限り、すべての機能カテゴリのノードはプロバイダネットワークの隔離された仮想ネットワーク内に設定され得る。
異なる機能カテゴリのノードは、次に、セキュリティプロフィール及び／または位置に対するクライアントの基本設定に基づいて（またはクライアントが基本設定を提供しない機能カテゴリのデフォルトの設定に基づいて）（要素２００７）構成され得る。構成は、例えば、適切な物理ホストまたは物理マシンを選択すること、適切なコンピュートインスタンス、仮想マシン、異なる機能カテゴリのノードのプロセス及び／またはスレッドをインスタンス化すること、ノード間の適切なネットワーク接続を確立すること、を含み得る。いくつかの実施形態では、異なるストリーム管理及び処理機能に対する実行可能なライブラリのコンポーネントは、構成の一部としてプロバイダネットワークの外部ホストにインストールするために提供され得る。
少なくともいくつかの実施形態による、暗号化モジュールは、例えば、クライアントによって示された暗号の基本設定によって、またはデフォルトの暗号化設定（要素２０１０）に基づいてノードの１つ以上のカテゴリで作動され得る。様々な機能カテゴリのノードは、次に、クライアントの希望で（要素２０１３）、ストリームデータが取り込まれ、格納され、検索され及び／または処理されるように作動されてよい。
図２１は、少なくともいくつかの実施形態による、データストリームのためのポリシを動的再分割を実装するために実行され得る、操作の態様を示すフローチャートである。要素２１０１にて示すように、パーティションポリシは、データストリームのために決定され得る。ポリシは、例えば、データストリームを再分割するための１つ以上のトリガ基準と同様に、データ生成部によって供給されるキーに基づいて、または送信されるデータレコードの様々な属性に基づいて、パーティションにデータレコードを初期にマッピングすることを含み得る。例えば、いくつかの実施形態では、ハッシュ関数がパーティションキーまたはキーに適用されてよく、１２８ビット整数のハッシュ値を生成する。可能な１２８ビット整数の範囲は、Ｎ連続副範囲に分かれてよく、それぞれはストリームのＮパーティションのひとつを表す。いくつかの実施形態では、パーティションの数及び／または副範囲の関連するサイズは、ストリームによって異なってよい。少なくともいくつかの実施形態においては、代理してストリームが構成されるクライアントは、パーティションスキームの使用、例えば、使用される所望のパーティションの数、所望のパーティション機能の特徴に関する、入力を提供し得る。少なくとも１つの実施形態においては、クライアントはパーティションの識別子または送信されるデータレコードのいくつか、またはすべての名前を提供し得る。
ストリームのデータレコードが受信されると、それぞれのパーティションは供給されたキー及び／またはその他の属性に基づいて決定され得る。また、取り込み、記憶及び検索ノードの適切なセットは、識別されるパーティション（要素２１０４）のために選択され得る。少なくともいくつかの実施形態においては、それぞれのシーケンス番号（要素２１０７）は、例えば、所与のパーティションのレコードが受信された順を示すデータレコードのために生成され得る。シーケンス番号は、タイムスタンプ値（例えば、よく知られた１９７０年１月１日の協定世界時００：００：００などからの経過秒数）、記憶サブシステム、ＳＭＳソフトウェアのバージョン番号及び／またはパーティション識別子から取得されるサブシーケンス値のようないくつかの実装においていくつかの要素を構成し得る。シーケンス番号はいくつかの実施形態では、データ生成部に、例えば、送信されたデータレコードの正常な取り込みへの応答に、提供され得る。いくつかの実施形態では、シーケンス番号はデータコンシューマによって、ストリームのデータレコードまたはパーティションを取り込み順に検索し、使用され得る。
データレコードは、パーティションポリシ（要素２１１０）に基づいて向けられた、ストレージノードで、少なくともいくつかの実施形態では、シーケンス番号順に格納され得る。回転磁気ディスクの記憶装置が使用される実施形態では、シーケンシャルライトが典型的には、受信されたデータレコードをディスクに保存するために使用され得る。それによってディスクシークレイテンシを避ける。少なくともいくつかの実装においては、不揮発性のバッファは、例えば、ディスクシークの確立をさらに減少させるために、レコードをディスクに記憶する前にライトキャッシュとして使用され得る。シーケンス番号によって並べられた多数のデータレコードの読み込みに対する要求（例えば、ｇｅｔＮｅｘｔＲｅｃｏｒｄまたは類似のインタフェースの起動）に対応して、データレコードは、記憶装置（要素２１１３）からシーケンシャルリードを使用して後に読み込まれ得る。
図２２は、少なくともいくつかの実施形態による、データストリームの動的再分割を実装するために実行され得る、操作の態様を示すフローチャートである。要素２２０１に示されるように、ストリームが、（例えば、ＳＭＳまたはＳＰＳの制御コンポーネントで）動的に再分割されるべきであると決定され得る。いくつかの異なるトリガ条件が、取り込み、記憶、検索、処理または制御ノードのうち１つ以上で、過負荷の検出のようなストリームを再分割する決定、または異なるノードのワークロードレベルにおける不均衡の検出、またはクライアント（例えば、データ生成部またはデータコンシューマ）から受信され得る再分割要求に誘導し得る。いくつかの実装において、クライアントの再分割要求は、生成される修正されたマッピングの様々なパラメータのような、要求された再分割の特定の詳細を含み得る（例えば、特定のパーティションが組み合わされ、または分割などされるべき、追加または削除された、パーティションの数）。一実装においては、クライアントによる再分割の要求は、クライアントが解決を希望する（負荷の不均衡のような）問題のある状態を示し得る。また、ＳＭＳまたはＳＰＳは、問題のある状態の記載を適切な再分割の操作に変換する役割があってよい。場合によっては、問題のある状態を再分割または記載することを要求する代わりに、クライアントは再分割に使用するためにトリガ基準を特定し得る。データストリームにおけるデータの耐久性要件の変更を決定するのは、再分割をトリガし得る。いくつかの実施形態では、例えば、ストリームレコードのために、異なるセットの記憶装置または異なる記憶技術を選択する結果になり得る。データストリームの使用状況の変化（例えば、データレコードが生成または消費される速度）の検出は、また、場合によっては、再分割をもたらし、また、変更された使用状況により適切な、異なる記憶技術または異なる記憶装置のセットを使用することになり得る。例えば、再分割の決定は、所与のパーティションまたはストリーム全体に予想される読み出し及び書き込みの速度には、ＳＳＤは回転磁気ディスクよりも、より適切な記憶技術であり得るという判断をもとになされ得る。予定された、または間近に迫ったソフトウェア及び／またはハードウェアのバージョン改訂は、一実施形態では、再分割をトリガし得る。場合によっては、課金または請求についての懸念は、再分割をトリガし得る。クライアントが予算の制約があることを示す場合には、異なるパーティション手法または異なる格納手段を使用してより効率的になり得る。変更された性能目標は、また少なくともいくつかの実施形態では、再分割をトリガし得る。図２２に示された実施形態においては、再分割後に割り当てられるシーケンス番号に使用される、初期のタイムスタンプ値は、（１９７０年１月１日の協定世界時００：００：００秒からのオフセットのように、エポック値は、典型的には、いくつかのオペレーティングシステムにおけるシステムコールを介して入手可能である）選択され得る（要素２２０４）。いくつかの実装においては、プロバイダネットワークで実装されるグローバル状態管理部は、ｇｅｔＥｐｏｃｈＶａｌｕｅ ＡＰＩを支援してよく、例えば、均一なタイムスタンプ値を取得するためにＳＭＳ及び／またはＳＰＳの様々なコンポーネントがシーケンス番号の生成のために使用されることを可能にする。その他の実装においては、その他の時間源が使用され得る。例えば、ＳＭＳまたはＳＰＳ制御ノードは、その他のコンポーネントに均一に並べられたタイムスタンプ値を提供するよう指定され得るか、またはローカルシステムコールの起動が使用され得る。いくつかの実施形態では、タイムスタンプ値は、任意の特定のホストで、必ずしも壁時計時刻に対応する必要がない。例えば、単調増加整数カウンタ値が単に使用され得る。
修正されたパーティションマッピングは、再分割の決定時に使用されるマッピングとは異なり、ストリームのために生成され得る（要素２２０７）少なくともいくつかの実施形態においては、変更されたマッピングは、特定のパーティションキーを有するデータレコードを、再分割前にマップされた同一のキーを有するデータレコードと異なるパーティションにマップし得る。いくつかのパーティション（典型的には、使用頻度が高いパーティション）が分割され得る。一方、その他の（典型的には、使用頻度が低い）パーティションが、再分割及び／または観察されたワークロードメトリクスのためのトリガ条件に応じて、組み合わされ得る。いくつかの実施形態では、異なるパーティション機能が、再分割の前よりも再分割後に使用され得る。例えば、異なるハッシュ関数、またはハッシュ関数による結果をパーティションに細分化するための異なる手法が使用され得る。いくつかの実装においては、例えば、１２８ビット整数、１２８ビット整数空間の連続的な範囲に対応するパーティションは、再分割後に副範囲の異なるセットに分けられ得る。少なくともいくつかの実施形態においては、取り込み、記憶、検索、処理または制御ノードの新しいセットは、新しく作成されたパーティションに割り当てられ得る。いくつかの実装においては、空間効率のよい組み合わされたデータ構造は、初期のマッピング及び修正されたマッピング（要素２２０８）の両方を表すために使用され得る。例えば、有向非巡回グラフまたはツリー構造は格納されてよく、各入力は、修正されたパーティションに対応するレコードのみが再分割の結果として変更が必要であるように、パーティション機能出力範囲（例えば、所与のパーティションに対応するパーティションのハッシュ関数の結果の範囲）の表示及び有効な時間範囲を含み得る。再分割の間に変更されないパーティションの入力は、データ構造中で修正される必要がない可能性がある。新しいノードは、修正されたパーティションマッピング（要素２２１０）を実装するよう構成され得る。少なくともいくつかの実施形態においては、以前のマッピングを基準にして格納されたデータレコードに対する検索要求が少なくともある時に継続して受信され得るため、従来のノード及び従来のマッピングは、ある時に保持され得る。特定のシーケンス番号またはタイムスタンプを明示する読み出し要求が受信されると（要素２２１３）、新しいパーティションマッピングか、または従来のパーティションマッピングを使用して読み出し要求を満たすかについての決定が（例えば、制御ノードまたは検索ノードで）され得る。選択されたマッピングは、次に、要求されたデータが取得される、適切な記憶ノードを識別するために使用され得る。
図２３は、少なくともいくつかの実施形態による、データストリームレコード用の少なくとも１回のレコードの取り込みポリシを実装するために実行され得る、操作の態様を示すフローチャートである。要素２３０１に示されるように、１つ以上のプログラムによるインタフェースは、クライアントが、データストリームのために、例えば、（ａ）肯定応答が受信されるまで、どちらのレコード送信者がレコードを１回以上送信したかによる、少なくとも１回のポリシまたは（ｂ）どちらの応答が少なくともいくつかのレコード送信に提供されないかによる、ベストエフォート取り込みポリシを含む、いくつかの取り込みポリシの選択肢から、レコード取り込みポリシを選択可能なように実装され得る。いくつかのデータを生成するクライアントは、その他の人と同じようには、レコードのほんの一部分の潜在的な損失については心配しない可能性がある。そのためベストエフォートの取り込み手法を選択し得る。いくつかの実装においては、ベストエフォートの取り込みのために構成されたストリームに対しても、ＳＭＳは、データレコードのいくつかのサブセットに対して応答を依然として提供し得る。または、ベストエフォートポリシはデータレコード毎に応答を必要とはしないものの、すべてのデータレコードに対する応答の提供を試みようとさえし得る。
要求は、特定のストリーム（要素２３０４）のために使用される特定の取り込みポリシを示す、プログラムによるインタフェースの１つを介して受信され得る。取り込みノードは、ストリームに影響するパーティションポリシによって、インスタンス化され得る（要素２３０７）。同一データレコードの１つ以上の送信が取り込みノードで受信されると（要素２３１０）、異なる動作が、有効な取り込みポリシに依存して行われ得る。少なくとも１回取り込みポリシが使用されると（要素２３１３において決定されるように）、応答は、１つ以上の送信のそれぞれのために、データ生成部に送信され得る。しかしながら、データレコードは記憶サブシステム（２３１６）にて１度のみ保存され得る。（ストリームのために有効な永続性ポリシによる、所与のレコードのＮ複製が場合によっては、格納され得る。しかしながら、所与のデータレコードがＭ回数送信されると、複製は送信のうち１つのみに対して生成され得る。すなわち、格納されたレコードの複製の全体数は、依然としてＮであり、ＮｘＭではないことに注意する）。ベストエフォート取り込みポリシが有効であった場合には、（要素２３１３においても検出されるように）データレコードは記憶装置にて依然として１度のみ保存され得る。しかしながら、応答はデータ生成部（要素２３１９）に送信される必要はない。少なくともいくつかの実施形態においては、クライアントの請求額は、所望により、少なくとも部分的に選択された取り込みポリシ（要素２３２２）に基づいて、決定され得る。前述したように、いくつかの実施形態では、少なくとも１回の取り込みポリシの２つのバージョンは、支援され得る。図２３に示されたものと同様に、１つのバージョンにおいて、ＳＭＳは、データレコードを複製を排除する機能があり得る（すなわち、２つまたはそれ以上の送信のセットの１つのみに対応して、データがＳＭＳ記憶サブシステムに格納されることを確実にする）。少なくとも１回の取り込みの異なるバージョンにおいては、ＳＭＳによるデータレコードの複製が許可され得る。後者の手法は、ストリームアプリケーションには有用であり得、データレコードの複製の否定的な結果が少数であるか、全く無い。及び／またはそれぞれの複製を排除を実行するストリームアプリケーションであり得る。
図２４は、少なくともいくつかの実施形態による、データストリーム用の複数の永続性ポリシを実装するために実行され得る、操作の態様を示すフローチャートである。要素２４０１に示されるように、クライアントが複数の永続性ポリシからストリームデータレコードのために永続性ポリシを選択可能にする、１つ以上のプログラムによるインタフェースが実装され得る。永続性ポリシは様々な面のいずれかにおいて、互いに異なり得る。例えば、（ａ）保存すべきいくつかの複製の数が異なり得る（例えば、Ｎ個の複製対２つの複製対単一の複製ポリシが支援され得る）（ｂ）使用されるストレージの位置／装置の種類が異なり得る（例えば、回転磁気ディスク対ＳＳＤ対ＲＡＭ対データベースサービスまたはマルチテナントストレージサービス）及び／または（ｃ）ポリシが大規模な破損に対する回復力の予想される範囲が異なり得る（例えば、マルチデータセンタ対シングルデータセンタポリシが支援され得る）。要求が、特定のストリーム（要素２４０４）のため、特定の永続性ポリシのクライアントの選択を示す受信され得る。いくつかの実施形態では、クライアントに選択された永続性ポリシは、所与のストリームのそれぞれのパーティションのための異なる記憶位置の種類または装置の種類の使用をする結果となり得る。一実施形態では、ストリームレベルまたはパーティションレベルの何れかで、クライアントよりもむしろＳＭＳが記憶位置の種類または装置の種類を選択し得る。いくつかの実施形態では、クライアントは、（所望の読み出し及び書き込みスループットまたは待ち時間のような）データの耐久性及び／または性能の目標を示し得る。いくつかの実施形態では、永続性ポリシを選択する際に、これらの目標は、適切な記憶装置の種類または位置を選択するために、ＳＭＳによって使用され得る。例えば、短待ち時間が所望される場合には、ＳＳＤは、１つ以上のパーティションまたはストリームのデータレコードを格納するために、回転磁気ディスクの代わりに、使用され得る。
１セットの取り込みノードは、データ生成部からの選択されたストリームのデータレコードを受信するよう決定または構成され得る。また、ストレージノードセットは、選択された永続性ポリシを実装するように構成され得る（要素２４０７）。データレコードが取り込みノードにおいて受信されるとき（要素２４１０）、１つ以上のデータレコードのコピーが、データレコードが属するパーティションの役割をするストレージノードによって選択された記憶装置で、選択された永続性ポリシに基づいて格納され得る（要素２４１３）。少なくともいくつかの実装においては、請求額は所望により（及び／または非同期的に）、クライアントによって選択された特定の永続性ポリシに基づいて、決定され得る（要素２４１６）。
ストリーム処理のための分散化したワークロード管理
いくつかの実施形態では、ＳＰＳの実質的な部分または制御プレーンの機能性のすべては、例えば、（ワーカノードへのパーティションの割り当て、動的パーティションへの応答、ヘルス監視及び／または負荷分散のような）様々な制御操作を調整する所与のＳＰＳステージ内のワーカノードによって、データベーステーブルのような、共有されたデータ構造を介して、分散化された方法で実装され得る。所与のワーカノードＷ１は、例えば、どのステージの入力ストリームのパーティションが（もしあれば）、現時点では処理されていない共有されたデータ構造内の入力であるか決定するために調べ得る。このようなパーティションＰ１が発見されるときには、Ｗ１は、Ｗ１がＰ１のレコード上でステージの処理操作を実行することを示すために、共有されたデータ構造中の入力をアップデートし得る。その他のワーカノードは、Ｗ１はＰ１レコードを処理するために割り当てられ、また、したがって、異なるパーティションをＰ１レコードに割り当て得ることを学習し得る。ワーカノードは定期的に、または場合により、ＳＭＳ制御プレーンにクエリを送信して、入力ストリームに有効な現在のパーティションマップを決定し、また、必要であれば（例えば、再分割の結果として）マップの変更を示す共有されたデータ構造をアップデートし得る。負荷分散及びその他の操作は、また、様々な実施形態において下記に記載されるように、共有されたデータ構造を介して調整され得る。いくつかのこのような分散化された実装においては、専用の制御ノードは、ＳＰＳに必要とされず、そのためＳＰＳワークフローを実装するのに必要なオーバーヘッドを低減する。このような分散化されたＳＰＳ制御プレーンの実装は、例えば、顧客またはプロバイダネットワーク外の位置に割り当てられるプロバイダネットワーク内のコンピュートインスタンスのような、ＳＰＳクライアントライブラリを利用してストリーム処理の様々な態様を実装する、特に予算に敏感な顧客には人気があり得る。分散されたＳＰＳ制御プレーン技術は、また、クライアントライブラリが使用されていない実施形態において使用され得る。例えば、ＳＭＳ及びＳＰＳに使用されるすべてのリソースがプロバイダネットワーク内に構成されている場合である。ワーカノードが、少なくともいくつかの処理ステージのための、いくつかのまたはすべてのＳＰＳ制御プレーン機能を実装するＳＰＳは、本明細書においては、「分散された制御ＳＰＳ」と称する。
図２５は、少なくともいくつかの実施形態による、処理ステージのワーカノードがデータベーステーブルを使用してワークロードを調節するストリーム処理システムの例を示す。分散された制御ＳＰＳ２５９０内では、２つのステージ２１５Ａ及びステージ２１５Ｂは、ワーカノードのそれぞれのセットで定義される。ステージ２１５Ａは、ワーカノード２５４０Ａ及びワーカノード２５４０Ｂを備え、一方、ステージ４１５Ｂは、ワーカノード２５４０Ｋ及びワーカノード２５４０Ｌを備える。ステージ２１５Ａ及びステージ２１５Ｂのそれぞれには、対応するパーティションの割り当て（ＰＡ）テーブル２５５０は、ステージ２１５ＡにはＰＡテーブル２５５０Ａ及びステージ２１５ＮにはＰＡテーブル２５５０Ｂのような、データベースサービス２５２０で作成される。いくつかの実施形態では、所与のステージに対するＰＡテーブル２５５０は、例えば、クライアントライブラリコンポーネントまたは機能の起動に対応して、ステージの初期化中に作成され得る。各ＰＡテーブル２５５０は、入力の初期セットで、またはステージの入力ストリームの未割り当てのパーティションを表す行が備えられ得る（すなわち、ワーカノードが現時点で割り当てられていないパーティション）。例示的なカラムまたはＰＡテーブル入力の属性は、図２６に示され、以下に記載されている。ステージのために開始されるワーカノード２５４０（例えば、コンピュートインスタンスまたはその他のサーバで開始されるプロセスまたはスレッド）は、ステージのＰＡテーブルに読み出し／書き込みアクセスを許可され得る。ワーカノードからＰＡテーブルに向けられる読み出し及び書き込みは、ワーカノード２５４０Ａ、２５４０Ｂ、２５４０Ｋ及び２５４０Ｌに対し、それぞれ２５６４Ａ、２５６４Ｂ、２５６４Ｋ及び２５６４Ｌの矢印で図２５において示されている。
所与のワーカノード２５４０は、ＰＡテーブル中の入力を調べることによって、ステージの処理操作を実行する特定のパーティションを選択するよう構成され得る。一実装においては、ワーカノード２５４０Ａは、未割り当てのパーティションＰｋの入力を見つけられるまでＰＡテーブル２５５０Ａにおける入力をスキャンし、入力をアップデートすることによって、例えば、ワーカノードの識別子を入力のカラムのうちの１つに挿入することによって、パーティションＰｋの割り当てを試み得る。このような挿入は、ワーカノードによってパーティションをロックすることに類似していると考えられ得る。使用されるデータベースのサービスの種類によって、同時にＰＡテーブルの入力への書き込みを潜在的に管理するための異なる手法（例えば、ほぼ同時に未割り当てのパーティションを期せずして識別する、２つまたはそれ以上のワーカノードによって）が、使用され得る。
一実施形態では、プロバイダネットワークの非リレーショナルマルチテナントデータベースサービスが使用されてよく、強い整合性及び条件付き書き込み操作を支援するリレーショナルデータベースのトランザクションセマンティクスを必ずしも支援せずに、条件付きの書き込み操作は、ワーカノードによるアップデートのような場合で使用され得る。ＰＡテーブル中のパーティションに割り当てられた特定のワーカノードの識別子を示すために、カラム「ワーカノードＩＤ」が使用される例、及びワーカノードがパーティションに割り当てられないカラムの値が「ｎｕｌｌ」に設定されるを考える。このような場合においては、識別子ＷＩＤ１を備えるワーカノードは、以下の論理的等価を要求し得る。「パーティションＰｋに対する入力においては、ワーカノードＩＤはｎｕｌｌであり、次に、その入力に対するワーカノードＩＤをＷＩＤ１に設定する」。このような条件付きの書き込み要求が成功する場合には、識別子ＷＩＤ１を有するワーカノードは、パーティションＰｋが割り当てられると仮定され得る。ワーカノードは次に、パーティションＰｋのデータレコードを検索し、例えば、矢印２５５４（例えば、ワーカノード２５４０Ａ、２５４０Ｂ、２５４０Ｋ及び２５４０Ｌに対し、それぞれ２５５４Ａ、２５５４Ｂ、２５５４Ｋ及び２５５４Ｌの矢印）で示されるように、ＳＭＳ検索サブシステム２０６のレコード検索インタフェースを使用して、及び検索レコード上の処理操作を実行し始め得る。条件付きの書き込みが失敗すると、ワーカノードは異なる未割り当てパーティションに対して検索を開始し得る。その他の実施形態では、トランザクションを支援する（リレーショナルデータベースのような）データベースサービスが使用されてよく、トランザクションの機能性は条件付きの書き込み操作の等価を実装するために使用され得る。例えば、ワーカノードの成功にパーティションを割り当てる、複数の同時（またはほぼ同時）の試みのうち１つのみを確保するために、このような同時の試みに含まれるワーカノードは確実に成功または失敗を通知される条件付きの書き込みまたはトランザクションの支援のどちらにも依存しない同期技術は、いくつかの実施形態で使用され得る。データベースサービスが使用されなくてよい、いくつかの実装においては、その代わりに、ロッキングサービスが、ＰＡテーブルに類似の永続性データ構造における入力をアップデートするため、排他アクセスを取得するために、ワーカノードによって使用され得る。
その他のワーカノード２５４０は、ＰＡテーブルにおける入力を調査し、どちらのパーティションが未割り当てかを決定し、それらに１つ以上のパーティションを割り当てすることに結果的に成功し得る。このように、ステージの入力ストリームのパーティションまたはストリームのためのワークロードを処理することは、結果的に、ステージのワーカノードにより、それらに分散され得る。
任意の所与のストリームの初期のパーティションマッピングは、例えば、前述した動的再分割操作の結果として、時間の経過とともに変化し得る。したがって、図２５に示された実施形態に示すように、１つ以上のワーカノード２５４０は、場合により（または以下に記載されるようにトリガ条件に対応して）、現在のパーティションメタデータを取得するために、ステージの入力ストリーム（単数または複数）のＳＭＳ制御サブシステム２１０に要求を送信し得る。いくつかの実装においては、このような要求は、矢印２５４４Ａ、２５４４Ｂ、２５４４Ｋ及び２５４４Ｌによって示されたｇｅｔＳｔｒｅａｍＩｎｆｏ ＡＰＩの起動のように、ＳＭＳ制御プレーンＡＰＩの起動を含み得る。ＳＭＳ制御サブシステムは、例えば、ストリームのパーティションの最新のリスト及び／またはパーティションの有効時間のようなその他の詳細で応答し得る。ＳＭＳ制御サブシステム２１０によって提供されたパーティション情報がＰＡテーブル中の入力に合致しない場合には、例えば、１つ以上のパーティションに入力を挿入または削除することによって、ＰＡテーブルはワーカノードによって修正され得る。ＳＭＳ制御サブシステムへのこのような要求２５５４は、典型的には、少なくともいくつかの実施形態においては、矢印２５５４Ａの「低頻度」ラベルによって示されたように、レコード検索要求２５５４（及び／またはデータベースの読み出しまたは書き込み操作２５６４）よりもかなり低頻度である。例えば、一旦、パーティションに割り当てられると、ワーカノードは、典型的には、（例えば、ストリームの所有者がストリームを閉鎖する場合、またはパーティションが動的再分割の結果閉鎖する場合には）パーティションデータが完全に消費されるまで、または（例えば、異なるワーカノードが、以下に記載されるように、負荷の不均衡を検出したため、パーティションの移動を要求する場合には）何か他の確立の低い環境に遭遇するまで、そのパーティションのデータレコードを検索し、処理し続け得る。このため、たとえ実質的な情報量が任意の所与の起動に対応して提供される場合でも、ｇｅｔＳｔｒｅａｍＩｎｆｏまたはｓｉｍｉｌａｒＡＰＩの起動に関連したオーバーヘッドは、典型的には、様々な実施形態で非常に小さくてよい（何十万かのパーティションがステージの入力ストリームに定義される場合にはあり得る）。
したがって、分散された制御ＳＰＳ環境のキーワークロード管理操作のいくつかは、図２５に図示された実施形態において、以下のように要約され得る。（ａ）ストリーム処理ステージの第１のワーカノードによって、データベースのテーブルに少なくとも一部アクセスすることに基づいて、ステージに定義された処理操作のセットを実装する、ストリーム処理ステージの入力データストリームの特定のパーティションを選択し、（ｂ）テーブルに格納された特定の入力に、第１のワーカノードに特定のパーティションの割り当ての表示を書き込みし、（ｃ）第１のワーカノードによって、マルチテナントのストリーム管理サービスで実装されるプログラムによるレコード検索のインタフェースを使用して、特定のパーティションのレコードを検索し、（ｄ）第１のワーカノードによって、特定のパーティションのレコード上の処理操作のセットを実装し、（ｅ）第２のワーカノードによって、少なくとも部分的に特定のデータベーステーブル中の特定の入力に基づいて、第１のワーカノードが特定のパーティション上の処理操作のセットを実行するために割り当てられることを決定し、及び（ｆ）第２のワーカノードによって、処理操作のセットを実行するための異なるパーティションを選択する。ワーカノードがこれ以上のレコードが割り当てられないパーティション内に留まることを決定する場合またはするときに、ワーカノードはＳＭＳ制御サブシステムから入力ストリーム上でメタデータを要求してよく、メタデータが不一致を示した場合にはＰＡテーブルをアップデートしてよい。
図２６は、少なくともいくつかの実施形態による、ワークロードの調節に使用されるパーティションの割り当てテーブル２５５０に格納され得る入力の例を示す。ここに示すように、テーブル２５５０は、パーティション識別子カラム２６１４，割り当てられたワーカノード識別子カラム２６１８，ワーカノードヘルスインジケータカラム２６２０及びワークロードレベルインジケータカラム２６２２の４つのカラムを備える。その他のカラムセットがその他の実装において実装され得る。例えば、パーティション作成時間を示すカラムまたはパーティション機能出力値範囲がいくつかの実施形態で使用され得る。またはワークロードレベルインジケータカラムは使用されなくてよい。
いくつかの実施形態においては、ＳＭＳ制御サブシステム（例えば、パーティション入力ツリーの一部として、前述したグラフまたはその他の組み合わされたデータ構造）によって維持されたパーティションリスト２６５０は、少なくともある時点において、ＰＡテーブル２５５０に含まれるよりも多くのパーティションを含むことに注意する。図示された実施例において、パーティションリスト２６５０は、パーティションＰ１、Ｐ２、Ｐ３、Ｐ４及びＰ５を含み、パーティションＰ１及びＰ４は再分割の結果、閉じられた状態に示され、一方、パーティションＰ２、Ｐ３及びＰ５は動作中である（すなわち、データレコードが現在検索され処理されているパーティション）。ＰＡテーブル２６５０は、図示された実施形態において動作中のパーティションのための入力を含み、閉じられたパーティションのための入力を含まない（例えば、再分割が行われた後、ｇｅｔＳｔｒｅａｍＩｎｆｏの起動に対応して取得されたときに、ワーカノードによって削除された可能性がある）少なくともいくつかの実装においては、ストリームの現在開いているパーティションのすべてが、所与の時間でＰＡテーブルにおいてそれぞれの入力を必ずしも有しない可能性がある。その代わりに、例えば、現在割り当てられ、または処理中の、それらのパーティションのサブセットのみが示され得る。
図２６に示された例示的な場合においては、パーティションＰ１及びＰ２は、識別子Ｗ７及びＷ３をそれぞれ有するワーカノードに割り当てられ、一方、Ｐ５は現時点では、割り当てられていない。ヘルスインジケータカラム２６２０は、異なる実装において、異なる種類の値を格納し得る。いくつかの実装においては、ワーカノードは定期的に（例えば、毎Ｎ秒に一度、またはヒューリスティックスのいくつかのセットに基づいたスケジュールによって）、割り当てられたパーティションのＰＡ入力中のヘルスインジケータカラムのコンテンツをアップデートして、ワーカノードが動作中であり、検索及び処理操作を継続可能であることを示す役割をし得る。図２６において、その入力のためのワーカノードがヘルスインジケータカラムをアップデートした（「最後に修正された時間」）、直近の時間の表示は、格納され得る。例えば、ワーカＷ７が、２０１３年１２月１日の０２：２４：５４及び５３秒に入力を修正したと示されている。いくつかの実施形態では、その他のワーカノードは最後に修正された時刻値を使用して、割り当てられたワーカノードが健全化否かを判断する。例えば、ステージのためのフェイルオーバポリシにて定義されるようにＸ秒またはＸ分が経過した場合、割り当てられたワーカノードは健全ではないか、またはアクセス不可能であるとされ、パーティションは再割り当てされ得る。その他の実装においては、カウンタはヘルス状態のインジケータとして使用されてよく、（例えば、カウンタ値がＹ秒で変化しない場合には、割り当てられたワーカノードはフェイルオーバのための候補と判断され得る。または、割り当てられたワーカノードが最後に入力を読み出した時を示す「最終の読み出し時刻」値が使用され得る。
少なくともいくつかの実施形態においては、ワークロードレベルのインジケータ値２６２２は、例えば、いくつかの最近の時間間隔中（例えば、最後に修正された時刻の前５分間で）に処理された、いくつかのレコードのような割り当てられたワーカノード、ＣＰＵ利用、メモリ利用、ストレージ利用などのような最近の性能に関連するワーカノードのメトリクスによって、入力に格納され得る。いくつかの実施形態において、このようなワークロードレベルのインジケータ値は、図２９に関して下記に記載されるように、負荷の不均衡が存在するか否かを決定し、検出された不均衡に対応して行動をするために、ワーカノードによって使用され得る。例えば、ワーカノードＷｋは、ワークロードレベルが平均のワークロードレベルより上であることを判定し、パーティションの一つに割り当てず、または動的再分割を要求し得る。あるいは、ワーカノードＷｋは、ワークロードがその他のワーカノードまたはパーティションのワークロードと比較して低すぎると判定し、追加のパーティション自体に割り当て得る。したがって、図２６に示されたＰＡテーブルのカラムを使用して、ワーカノードは、集中化制御ＳＰＳの実装における、専用のＳＰＳ制御ノードによって典型的に実行され得る、図示された実施形態における制御プレーンの機能の類似の種類のいくつかを実行し得る。
図２７は、少なくともいくつかの実施形態による、処理操作を実行するパーティションを選択するために、ストリーム処理ステージのワーカノードによって実行され得る操作の態様を示す。要素２７０１に示されるように、ＰＡテーブルＰＡＴ１は、分散された制御ＳＰＳ処理ステージＳＰ１のために、データベースサービスで初期化され得る。例えば、テーブルは、ＳＰＳクライアントのライブラリコンポーネントが起動されるときに、例えば、クライアントの設備のホストから、またはプロバイダネットワークのデータセンタのコンピュートインスタンスから作成され得る。クライアントのライブラリは様々な目的に使用され得る。例えば、ＳＰＳステージで実装される特定の処理操作のためのＪＡＲ（Ｊａｖａ（登録商標）アーカイブ）ファイルのような、実行可能なコンポーネントを提供するため、ワーカノードを識別するために使用され得るラベル（プログラム名、プロセス名またはコンピュートインスタンス名）を表示するため、ステージへの入力に使用されるストリームを表示するため、ステージの出力先（もしあれば）を表示するため、等である。ＰＡＴ１は、いくつかの実施形態では、ステージの入力ストリーム（単数または複数）に定義された少なくともパーティション｛Ｐ１，Ｐ２，・・・｝のサブセットのための入力または列に最初に格納され得る。いくつかの実装においては、テーブルは最初は空であってよく、例えば、ＳＭＳ制御サブシステムからのパーティションのメタデータを取得した結果として、１つ以上のワーカノードはテーブルを割り当てていないパーティションのための列をポピュレートし得る。ワーカノード｛Ｗ１，Ｗ２，・・・｝の初期のセットは、例えば、プロバイダネットワーク内の様々なコンピュートインスタンスで、またはクライアントが所有する計算装置で起動され得る（要素２７０４）。ワーカノードは、図示された実施形態において、ＰＡＴ１への読み出し及び書き込みアクセスを許可し得る。
ワーカノードがオンラインなると、それぞれが割り当てられていないパーティションを見つけるために、ＰＡＴ１にアクセスし得る。例えば、ワーカノードＷ１は、ＰＡＴ１を調べ、パーティションＰ１が割り当てていないことを見つける（要素２７０７）。Ｗ１は次にＰＡＴ１のＰ１の入力をアップデートする。例えば、使用されるデータベースサービスの種類に応じて、条件付き書き込み要求またはトランザクショナルアップデート要求を使用して、Ｐ１がＷ１に割り当てられることを示す（要素２７１０）。テーブルをアップデートし、Ｗ１は、ＳＭＳ検索サブシステムインタフェース（要素２７１３）を使用して、Ｐ１のデータレコードの検索を開始し得る。また、検索されたレコード上のステージＰＳ１の処理操作を実行し得る。
その間、ある時点で、異なるワーカノードＷ２が、割り当てられていないパーティションを見つめようとＰＡＴ１にアクセスし得る（要素２７１６）。Ｗ２は、Ｗ１の以前のアップデートに基づいて、Ｐ１がすでに割り当てられていること、しかし異なるパーティションＰ２が割り当てられていないことを判断し得る。いくつかの実施形態では、Ｐ２の現在の受託者ワーカノードは、Ｗ２によって健全ではないか、動作中ではないことを（Ｐ２の入力におけるヘルスインジケータカラムに基づいて）判断し、Ｗ２をＰ２を選択するよう導き得る。このように、少なくともいくつかの実施形態においては、割り当てられていない状態または現在のワーカノードの健全ではない状態の判断の何れかは、再割り当て（または最初の割り当て）のために所与のパーティションを選択するために使用され得る。Ｗ２は、次にＰＡＴ１をアップデートしてそれ自体をＰ２を割り当てるよう試み得る（要素２７１９）。アップデートが成功した場合には、Ｗ２はＰ２レコードをＳＭＳ検索インタフェース（要素２７２２）を使用して検索し始め、ステージのために定義された適切な処理操作を実行し始める。
前述のように、分散された制御ＳＰＳワーカノードは、典型的には低頻度で、ＳＭＳからマッピング情報を取得してよく、必要に応じてＰＡテーブルをアップデートするためのこのような情報を使用し得る。図２８は、少なくともいくつかの実施形態による、ストリーム管理サービス制御サブシステムから取得された情報に基づいて、パーティション割り当てテーブルをアップデートするために、ストリーム処理ステージのワーカノードによって実行され得る操作の態様を示す。要素２８０１に示されるように、割り当てられたパーティションの１つを閉鎖するようなワーカノードの初期化中、または様々なトリガ条件に対応して、ワーカノードＷ１は最新の若しくは現在のパーティションリストまたは非アクティブのパーティションリストを取得するために、ＳＭＳ制御サブシステムへ要求を送信し得る。いくつかの実装においては、ｇｅｔＳｔｒｅａｍＩｎｆｏまたは類似のＡＰＩは、この目的で起動され得る。その他のトリガ条件はいくつかの実施形態において使用され得る。例えば、ワーカノードは無作為な時間量後に新規のパーティションリストを取得するようそれぞれ構成され得る。またはワークロードレベルにおける予期しない減少若しくは増加に対応して取得するよう構成され得る。ＳＭＳによって返されたパーティションリストは、パーティションのためのＰＡテーブル中の入力と比較され得る（要素２８０７）。不一致が明らかになる場合には、（例えば、ＰＡテーブル中に存在しない、新規に取得されたパーティションリストにいくつかのパーティションがある場合、またはＳＭＳのリストに存在しないＰＡテーブル中の入力がある場合には、ワーカノードは、図示された実施形態の不一致を解決するために、ＰＡテーブル中の入力を挿入または削除し得る（要素２８１０）。（いくつかの実施形態においては、現在、削除を対象とする入力は、割り当てられたワーカノードを有する場合には、追加の調整が必要となり得る。例えば、割り当てられたワーカノードは、直接またはＰＡテーブル自体を介して通知され得る）。
不一致が修正された後、または不一致が検出された場合には、ワーカノードＷ１は、ステージの処理操作を実行すべきパーティションのセットを選択し（要素２８１３）、したがってＰＡテーブルをアップデートし得る。場合によっては、検索されたパーティションリストに導くトリガ条件に応じて、Ｗ１は、すでに割り当てられた１つ以上のパーティションを有し、割り当てを変更するかＰＡテーブルをアップデートする必要がない。Ｗ１は次に、ＳＭＳ制御サブシステムと相互作用し、ＰＡテーブルのいくつかの入力を変更する必要なく、割り当てられたパーティションのデータレコードの検索及びレコードの処理に進み得る（要素２８１６）。最終的に、トリガ条件が検出されると、（例えば、「パーティションの最後に到達した」ことに相当する応答が検索要求に受信され、パーティションが閉鎖されたことを示す。Ｗ１は新しいパーティション情報のためにＳＭＳ制御サブシステムへの要求を再度、送信し、要素２８０１以降の操作が繰り返され得る。
図２９は、少なくともいくつかの実施形態による、ストリーム処理ステージのワーカノードによって実行され得る負荷分散操作の態様を示す。要素２９０１に示されるように、ワーカノードＷ１は、負荷分散分析は、高リソース利用レベルの検出のような、様々なトリガ条件のいずれかの検出によって、または構成可能なスケジュールに基づいて、ステージ上で実行されると判断し得る。Ｗ１はステージのために様々なワークロードメトリクスを判断するためＰＡテーブル（要素２９０４）の入力を調査し得る。このようなメトリクスは、ワーカノードに割り当てられた平均の数のパーティション、（ワークロードレベルインジケータがテーブルに保存される実施形態において）ワーカノードの平均ワークロードレベルまたは異なるパーティションの平均ワークロードレベル、ワーカノードのワークロード毎の範囲または分散等を含み得る。
Ｗ１は、次にワークロードを、（例えば、Ｗ１に割り当てられたいくつかのパーティションに基づいて、及び／またはパーティション毎のワークロードレベルインジケータに基づいて）いくつかまたはすべてのメトリクスと比較する。一般的に、Ｗ１が過負荷であり、Ｗ１が負荷が少ない、またはＷ１のワークロードが高すぎもなく低過ぎもないという、３つの種類の結果のいずれかが描かれ得る。「高すぎる」または「低すぎる」ワークロードレベルは、いくつかの実施形態において、代表してステージが構成されるクライアントによって選択されたポリシによって、またはその他の実施形態における発見のいくつかのデフォルトのセットを使用して、定義され得る。Ｗ１がワークロードが、例えば、いくつかの最低負荷の閾値Ｔ１未満のように、低すぎると判断した場合には（要素２９０７）、よりビジーまたはより高負荷のワーカノードＷｋが識別され得る（要素２９１０）。Ｗ１は、次に、１つ以上のパーティションＰｍをＷｋからＷ１自身（要素２９１３）に転送するプロセスを開始し得る。例えば、ＰＡテーブルのＰｍ入力を修正することを試みることによって、このような（Ｗｋのために生成された通知がもたらされ得る）修正を要求することによって、またはＷｋを直接要求することによって、開始し得る。
Ｗ１は、ワークロードが、例えば、最大閾値Ｔ２を超えるように、高すぎると判断した場合には（要素２９１６）、放棄するために（すなわち、その他のワーカノードによって割り当てをリリースするために）（要素２９１９）、１つ以上の割り当てられたパーティションＰｎを識別し得る。Ｗ１は、次に、例えば、ＰＡテーブルのＰｎのための入力の受託者カラムから識別子を削除することによって、適切な入力を修正し得る（要素２９２２）。Ｗ１のワークロードが高すぎもなく低過ぎもない場合には、またはＷ１は、ワークロードを増加または減少するために、上述の動作の種類をとった後に、Ｗ１は、割り当てられるパーティションのレコードの処理を開始し得る（要素２９２５）。別の負荷分散の分析をトリガする条件が合致するとき、または合致する場合には、要素２９０１以降に対応する操作が繰り返され得る。図２９に示された操作において、Ｗ１は、ワークロードに対して不均衡を検出する場合に限り、ワークロードの変化を開始として示されるであることに注意する。その他の実施形態では、Ｗ１は、Ｗ１自身よりもその他のワーカノードの間の不均衡を検出する場合、例えば、Ｗ２がＷ３よりも低いワークロードレベルを有すると判断した場合には、再度均衡をとる動作を開始し得る。いくつかの実装においては、Ｗ１は、ワークロードの不均衡を検出した場合、または検出するとき、（例えば、図３またはその等価に示されたような、ｒｅｐａｒｔｉｔｉｏｎＳｔｒｅａｍ ＳＭＳ ＡＰＩを起動することによって）動的再分割を要求または開始し得る。いくつかの実施形態では、図２９に示された操作の種類は、新しく構成されたワーカノードによって実行され得る。例えば、ステージがすでにしばらくの間操作された後、新しいノードがステージに加えられるときに、新しいノードは、過負荷の現在のノードからパーティションの再割り当てを要求することによって、間接的に、現在のノードの有無を通知し得る。いくつかの実施形態では、ＳＰＳワーカノードのために、上記に類似する分散された制御技術は、１つ以上のＳＭＳサブシステムで使用され得るまたは代わりに使用される。例えば、取り込み、記憶または検索サブシステムのノードは、ＰＡテーブルに類似する共有されたデータ構造を使用してワークロードを調整し得る。
様々な実施形態では、図１７〜図２４及び図２７〜図２９のフローチャートに示されたもの以外の操作は、上記のストリーム管理サービス及び／またはストリーム処理機能を実装するために使用され得ることに注意する。示された操作のいくつかは、いくつかの実施形態において実装されなくてよい。または異なる順で実装されるか、または連続して実装されるよりもむしろ、並行して行われ得る。プログラムによるインタフェースが様々な実施形態において支援される、ＳＭＳ及びＳＰＳの機能のそれぞれに関して、１つ以上の技術の任意の組み合わせが、ウェブページ、ウェブサイト、ウェブサービスＡＰＩ、その他のＡＰＩ、コマンドラインツール、グラフィカルユーザインターフェース、モバイルアプリケーション（ａｐｐ）、タブレットアプリケーション等の使用を含む、インタフェースを実装するために使用され得ることにも注意する。
ユースケース
スケーラブルなパーティションベース、収集、検索及び段階的なストリームデータレコードの処理のため、動的に構成可能に管理されたマルチテナントサービスを確立する、上記の技術、いくつかの場合において有用であり得る。例えば、大きなプロバイダネットワークは、いくつかの異なるマルチテナントのサービスインスタンスまたは同時に何万ものクライアントに対するシングルテナントを実装する、何千ものインスタンスホストを備え得る。様々なインスタンス及びホストにインストールされた監視及び／または課金エージェントは、プロバイダネットワークのデータセンタに効果的なプロビジョニングプランを決定するため、ネットワーク攻撃等を検出するなどのために、正確な課金レコードを生成するために格納され分析される必要があり得る、何千ものメトリクスレコードを迅速に生成し得る。監視レコードは、スケーラブルな取り込み及び格納のために、ＳＭＳに入力ストリームを形成し得る。また、記載されたＳＰＳ技術は、収集されたメトリクスの分析のために実装され得る。同様に、多数のログソースから大多数のログレコードを収集し分析するアプリケーション（例えば、分散されたアプリケーションのノードからのアプリケーションログ、またはデータセンタにおけるホストまたはコンピュートインスタンスからシステムログ）は、また、ＳＭＳ及びＳＰＳの機能を利用可能であり得る。少なくともいくつかの環境においては、ＳＰＳ処理操作は、リアルタイムのＥＴＬ（抽出変換負荷）処理操作（すなわち、オフラインで変換する代わりに、宛先にロードするために、リアルタイムで受信されたデータレコードを変換する操作）またはデータウェアハウスに挿入するためにデータレコードの変換を備え得る。リアルタイムでデータウェアハウスにデータをロードするために、ＳＭＳ及び／またはＳＰＳの組み合わせを使用することは、データが分析のためにウェアハウスに挿入可能である前に、典型的には、１つ以上のデータソースからクリーンでキュレートなデータを必要とする遅延を回避し得る。
いくつかの異なる「ビッグデータ」のアプリケーションもまた、ＳＭＳ及びＳＰＳ技術を使用して構築され得る。例えば、様々な形式のソーシャルメディアの相互作用におけるトレンド分析が、ストリームを使用して効率的に実行され得る。ユーザの位置情報のような、携帯電話またはタブレット型コンピュータから収集されたデータはストリームレコードとして管理され得る。例えば、全監視カメラから収集されたオーディオまたはビデオ情報は、スケーラブルな方法で収集され処理され、場合により様々な種類の攻撃を防ぐ助けとなり得る、ストリーミングデータセットの別のカテゴリを表し得る。例えば気象衛星、海洋ベースのセンサ、森林ベースのセンサ、天体望遠鏡から収集された、増える一方のデータセットの分析を必要とする科学研究用のアプリケーションは、また、本明細書に記載されたストリーム管理及び処理能力から利益を得られ得る。適応性のあるポリシベースの構成の選択肢及び価格設定は、異なる種類のユーザがストリーミングの機能性を特定の予算及びデータの耐久性／可用性の必要条件に適合するように、カスタマイズするのを支援し得る。
本開示の実施形態は、以下の条項を考慮して記載され得る。
１．
システムは、
１つ以上の計算装置であって、
マルチテナントストリーム管理サービスのクライアントが、特定のデータストリームに、複数のデータ取り込みポリシの中からデータ取り込みポリシを選択するのを可能にするプログラムによるインタフェースの第１のセットを実装し、複数のデータ取り込みポリシは、レコード送信者が１回以上データレコードの表示をストリーム管理サービスに肯定応答が受信されるまで伝送することによる少なくとも１回の取り込みポリシを含み、
クライアントが特定のデータストリームのために、複数のデータ永続性ポリシから、データの永続性ポリシを選択するのを可能にするプログラムによるインタフェースの第２セットを実装し、データレコードの多数の複製のどちらがストリーム管理サービスによってそれぞれの記憶位置に格納されるかにより、複数のデータ永続性ポリシは多数の複製の永続性ポリシを含み、
第１及び第２のセットのそれぞれのプログラムによるインタフェースを介してストリーム管理サービスで、クライアントが特定のデータストリームのために、少なくとも１回の取り込みポリシを選択したことの第１の表示と、クライアントが特定のデータストリームのために多数の複製永続性ポリシを選択したという第２の表示を受信し、
特定のデータレコードをストリーム管理サービスに示す複数の伝送に対応して、少なくとも１回の取り込みポリシによる複数の転送に対応する少なくとも１つの肯定応答を送信し、
複数の伝送の特定の伝送に対応して、多数の複製の永続性ポリシによる複製の記憶位置で、特定のデータレコードのコピーを格納するよう構成された計算装置を備える、システム。
２．
どちらのストリーム管理サービスが、対応する肯定応答をレコード送信者に提供せずに、少なくともいくつかの特定したストリームのデータレコードを受け入れ及び格納するべきかにより、複数のデータ取り込みポリシがベストエフォートの取り込みポリシを備える、条項１にて説明されるシステム。
３．
クライアントによって選択された多数の複製永続性ポリシが、データレコードのコピーの格納に使用される記憶位置の種類の表示を備え、記憶位置の種類は、（ａ）磁気ディスクベースのストレージ、（ｂ）ソリッドステートドライブ（ＳＳＤ）、（ｃ）揮発性ＲＡＭ（ランダムアクセスメモリ）、（ｄ）不揮発性ＲＡＭ、（ｅ）データベース管理システム、または（ｆ）プロバイダネットワークによって実装されるネットワークにアクセス可能なストレージサービスのストレージノード、のうち１つを備える、条項１にて説明されるシステム。
４．
クライアントによって選択された多数の複製永続性ポリシは、要求されたデータ耐久性レベルの表示を備え、１つ以上の計算装置がさらに、少なくとも部分的に要求されたデータの耐久性レベルに基づいて複数の記憶位置を選択するよう構成される、条項１にて説明されるシステム。
５．
１つ以上の計算装置はさらに、特定のクライアントが少なくとも部分的に、（ａ）特定のクライアントによって選択されたデータ取り込みポリシ、及び（ｂ）特定のクライアントによって選択されたデータ永続性ポリシのうち、１つ以上に基づいてストリーム管理操作に請求される請求額を決定するよう構成される、条項１にて説明されるシステム。
６．
プログラムによるインタフェースのセットを実装して、ストリーム管理サービスのクライアントが、複数のデータ取り込みポリシの中から、特定のデータストリームのためにデータ取り込みポリシを選択するのを可能にし、
複数のデータ取り込みポリシは、どちらのレコード送信者が１回以上データレコードの表示を、ストリーム管理サービスに肯定応答が受信されるまで伝送するべきかによって、少なくとも１回の取り込みポリシを含み、
プログラムによるインタフェースのセットを介して要求を受信し、クライアントが少なくとも１回の取り込みポリシを特定のデータストリームのために選択したことを示し、
ストリーム管理サービスにおいて特定のデータレコードを示す複数の送信の受信に対応して、
少なくとも１回の取り込みポリシによって、複数の伝送の各伝送に対応する、それぞれの肯定応答を送信し、
複数の伝送のうち特定の伝送の受信に応答して格納し、特定のデータストリームのために選択されたデータ永続性ポリシにより、１つ以上の記憶位置での特定のデータレコードのコピーを格納することを、１つ以上の計算装置によって実行することを含む方法。
７．
どちらのストリーム管理サービスが、対応する肯定応答をレコード送信者に提供せずに、特定されたストリームの少なくともいくつかのデータレコードを受け入れ及び格納するべきかにより、複数のデータ取り込みポリシがベストエフォートの取り込みポリシを備える、条項６にて説明される方法。
８．
少なくとも１回の取り込みポリシにより、ストリーム管理サービスが複製されたデータレコードを削除するよう構成される、条項６にて説明される方法。
９．
少なくとも１回の取り込みポリシにより、ストリーム管理サービスが、複数の伝送に対応して、特定のデータレコードのうち２つ以上のコピーを格納するよう構成される、条項６にて説明される方法。
１０．
クライアントが特定のデータストリームのために、複数のデータ永続性ポリシから、データの永続性ポリシを選択するのを可能にするプログラムによるインタフェースの第２セットの実装を、１つ以上の計算装置によって実行することをさらに含む、条項６にて説明される方法。
１１．
複数のデータ永続性ポリシが、多数の複製永続性ポリシと、単一の複製永続性ポリシを含む、条項１０にて説明される方法。
１２．
データ永続性ポリシがデータレコードを格納するために使用される記憶位置の種類の表示を備え、記憶位置の種類は、（ａ）磁気ディスクベースのストレージ、（ｂ）ソリッドステートドライブ（ＳＳＤ）、（ｃ）揮発性ＲＡＭ（ランダムアクセスメモリ）、（ｄ）不揮発性ＲＡＭ、（ｅ）データベース管理システム、または（ｆ）プロバイダネットワークによって実装されるネットワークにアクセス可能なストレージサービスのストレージノードのうちの１つを備える、条項１０にて説明される方法。
１３．
データ永続性ポリシは特定のデータストリームの第１パーティションに使用される記憶位置の第１種類の表示と、特定のデータストリームの第２のパーティションに使用される記憶位置の異なる種類の表示と、を備える、条項１０にて説明される方法。
１４．
クライアントによって選択されたデータ永続性ポリシは、データレコードを格納するために使用される記憶位置の種類の表示を含まず、データレコードは、１つ以上の計算装置によって、ストリーム管理サービスの１つ以上のコンポーネントにより、データレコードを格納するために使用される記憶位置の種類の選択を実行することをさらに含む、条項１０にて説明される方法。
１５．
記憶位置の種類を選択することが、特定のデータストリームの第１のパーティションのための記憶位置の第１の種類を選択し、特定のデータストリームの第２のパーティションのための記憶位置の異なる種類を選択することを含む、条項１４にて説明される方法。
１６．
データ永続性ポリシが目標の待ち時間の表示を含み、ストリーム管理サービスの１つ以上のコンポーネントによって、データレコードを少なくとも部分的に目標の待ち時間に基づいて格納するために使用される記憶位置の種類を選択１つ以上の計算装置によって実行されることをさらに含む、条項１０にて説明される方法。
１７．
クライアントによって選択されたデータ永続性ポリシが、要求されたデータの耐久性レベルの表示を含み、１つ以上の計算装置によって、少なくとも部分的に要求されたデータ耐久性レベルに基づいてストリームのデータレコードが格納された複数の記憶位置の選択をさらに含む、条項１０にて説明される方法。
１８．
１つ以上の計算装置によって、（ａ）特定のクライアントによって選択されたデータ取り込みポリシ、及び（ｂ）特定のクライアントによって選択されたデータ永続性ポリシのうち少なくとも部分的に１つ以上に基づいて、特定のクライアントがストリーム管理操作に対して請求されるべき請求額を決定することの実行をさらに含む、条項６にて説明される方法。
１９．
（ａ）特定のデータレコードの１つ以上の属性に基づいて、特定のデータレコードが特定のパーティションのメンバとして指定され、（ｂ）いくつかのデータ取り込みノードのうちのデータ取り込みノードが、特定のパーティションのデータレコードを取り込むために選択されることによる、少なくとも部分的にパーティションポリシに基づいて特定のデータストリームのために構成されるいくつかのデータ取り込みノードの決定を１つ以上の計算装置によって実行することをさらに含む、条項６にて説明される方法。
２０．
（ａ）特定のデータレコードの１つ以上の属性に基づいて、特定のデータレコードが特定のパーティションのメンバとして指定され（ｂ）いくつかのデータストレージノードのうちのデータストレージノードが、特定のパーティションのデータレコードを格納するために選択されることにより、少なくとも部分的にパーティションポリシに基づいて、いくつかのデータストレージノードが特定のデータストリームを構成するよう決定することを、１つ以上の計算装置によって、実行することをさらに含む、条項６にて説明される方法。
２１．
特定のデータストリームの複数のデータレコードの各データレコードに対応して、特定のデータレコードを含む、並べられたデータレコードのセットに対する読み出し要求に応答することが不可能な、それぞれのシーケンス番号を格納し、
データストリームの異なるデータレコードの送信者から、異なるデータレコードに対応する格納される最小のシーケンス番号の表示を受信し、
異なるデータレコードに対応して、最小のシーケンス番号より大きいかまたは等しい特定のシーケンス番号を格納することを、１つ以上の計算装置によって実行することをさらに含む、条項６にて説明される方法。
２２．
特定のデータストリームのために、クライアントがストリーム管理サービスを選択可能にするプログラムによるインタフェースのセットを実装し、そのデータレコードは、選択されたデータ取り込みポリシに基づいてストリームに取り込まれ、複数のデータ永続性ポリシは、（ａ）特定のデータストリームのデータレコードの多数のコピーによる多数の複製永続性ポリシがそれぞれの記憶位置に格納され、（ｂ）特定のデータストリームのデータレコードの単一コピーが格納される、単一の複製永続性ポリシを含み、
プログラムによるインタフェースのセットを介して要求を受信し、クライアントが多数の複製永続性ポリシを特定のデータストリームのために選択したことを示し、
特定のデータストリームのデータレコードのために、多数の複製永続性ポリシを実装するために、複数のストレージノードを構成する、１つ以上のプロセッサ上で実行される場合に、プログラムの命令を格納する、非一時的にコンピュータにアクセス可能な記憶媒体。
２３．
条項２２にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体であって、複数のデータ永続性ポリシのうちの、少なくとも１つのデータ永続性ポリシがデータレコードを格納するために使用される記憶位置の種類を示すことを含み、記憶位置の種類は、（ａ）磁気ディスクベースのストレージ、（ｂ）ソリッドステートドライブ（ＳＳＤ）、（ｃ）揮発性ＲＡＭ（ランダムアクセスメモリ）、（ｄ）不揮発性ＲＡＭ、（ｅ）データベース管理システム、または（ｆ）プロバイダネットワークによって実装されるネットワークにアクセス可能なストレージサービスのストレージノードのうちの１つを備える、記憶媒体。
２４．
条項２２にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体であって、クライアントによって選択された多数の複製永続性ポリシが、要求されたデータの耐久性レベルの表示を含み、１つ以上のプロセッサ上で実行される命令は、少なくとも部分的に要求されたデータ耐久性レベルに基づいて、構成されるいくつかのストレージノードを決定する、記憶媒体。
２５．
条項２２にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体であって、１つ以上の計算装置によって、少なくとも部分的に特定のクライアントによって選択されたデータ永続性ポリシに基づいて、特定のクライアントがストリーム管理操作に対して請求される請求額の決定を実行することをさらに含む、記憶媒体。
２６．
条項２２にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体であって、（ａ）特定のデータレコードの１つ以上の属性に基づいて、特定のパーティションのメンバとして特定のデータレコードが指定され、（ｂ）いくつかのデータストレージノードのうちのデータストレージノードが、特定のパーティションのデータレコードを格納するために選択されることにより、少なくとも部分的にパーティションポリシに基づいて、特定のデータストリームのために構成されるいくつかのデータストレージノードの決定を１つ以上の計算装置によって実行することをさらに含む、記憶媒体。
２７．
マルチテナントストリーム管理サービスの複数のノードのうち、データストリームのデータレコードを分散するために適用されるパーティションポリシを決定し、パーティションポリシは、データレコードに関連する、少なくとも部分的に１つ以上の属性値に基づいて、複数のパーティションにデータレコードの初期のマッピングを含み、
初期のマッピングを使用して、少なくとも部分的に特定の属性値に基づいて、データストリームの特定のデータレコードがメンバを指定される第１のパーティションを識別し、
特定のデータレコードに対応して、ストリーム管理サービスの取り込みノードでレコード取得シーケンス内の特定のデータレコードの位置を示す、シーケンス番号を生成し、取り込みノードは少なくとも部分的に初期のマッピングに基づいて選択され、
複数のデータレコードのそれぞれのシーケンス番号に少なくとも部分的に基づいて、ストリーム管理サービスのデータ記憶位置の順で第１のパーティションの複数のデータレコードを格納し、データ記憶位置は、少なくとも部分的に初期のマッピングに基づいて選択され、
データストリームを再分割するためのトリガ条件が合致したという決定に対応して、データレコードの修正されたマッピングをパーティションに生成し、データストリームのデータレコード取得における一時停止をスケジューリングなしに修正されたマッピングの使用を開始し、特定の属性値で別のデータレコードのために選択し、その他のデータレコードは、（ａ）ストリーム管理サービスの異なる取り込みノードまたは（ｂ）ストリーム管理サービスの異なるデータ格納位置のうち少なくとも１つで修正されたマッピングの使用の開始に続いて受信されるよう構成された、１つ以上の計算装置を備えるシステム。
２８．
シーケンス番号は（ａ）特定のデータレコードの取り込みに関連するタイムスタンプ、及び（ｂ）追加のサブシーケンス値の表示を含む、条項２７にて説明されるシステム。
２９．
条項２８にて説明されるシステムであって、１つ以上の計算装置がさらに
修正されたマッピングを使用してマップされたデータレコードのシーケンス番号に使用される初期のタイムスタンプ値を選択し、
特定のシーケンス番号を示すデータレコードの検索要求に対応して特定のシーケンス番号によって示された特定のタイムスタンプの値が初期のタイムスタンプ値よりも低いという決定に対応して、１つ以上のデータレコードを検索するために初期のマッピングを利用し、
特定のタイムスタンプ値が初期のタイムスタンプ値よりも低くないという決定に対応して、１つ以上のデータレコードを検索するために修正されたマッピングを利用するよう構成される、システム。
３０．
トリガ条件が（ａ）オーバーロードの状態の検出、（ｂ）ワークロードの不均衡の検出、（ｃ）再分割のクライアントの要求、（ｄ）データストリームにおけるデータの耐久性要件の変更を決定、（ｅ）ソフトウェアのバージョン変更のスケジュールの決定、（ｆ）データストリームの使用状況の変化を検出（ｇ）データストリームの再分割の価格の影響の決定、または（ｈ）データストリームに関連する性能ターゲットの決定のうち、１つ以上を含む、条項２７にて説明されるシステム。
３１．
１つ以上の計算装置であって、データストリームに使用される１つ以上のパーティション基準を示すクライアントの要求を受信し、少なくとも部分的にクライアントの要求に基づいて、初期のマッピングを生成することをさらに含む、条項２７にて説明されるシステム。
３２．
データレコードの少なくとも部分的に１つ以上の属性値に基づいて複数のパーティションにデータストリームのデータレコードの初期のマッピングを決定し、
初期のマッピングを使用して、少なくとも部分的に特定の属性値に基づいて、データストリームの特定のデータレコードがメンバを指定する第１のパーティションを識別し、
初期のマッピングに少なくとも部分的に基づいて選択された記憶位置で特定のデータレコードを格納し、
トリガ条件が合致するという決定に対応して、修正されたデータレコードのマッピングをパーティションに生成し、特定の属性値で別のデータレコードのために選択し、
その他のデータレコードは、修正されたマッピング、異なる記憶位置の使用の開始に続いて受信されることを、ストリーム管理サービスの１つ以上の計算装置によって実行することを含む方法。
３３．
トリガ条件が合致したという決定の前に特定のデータレコード上で、少なくとも部分的に初期のマッピングに基づいて、選択されたワーカノードで処理操作を実行し、
トリガ条件が合致したという決定の後に、特定の属性値で異なるデータレコード上で、少なくとも部分的に修正されたマッピングに基づいて選択された、異なるワーカノードで処理操作を１つ以上の計算装置によって実行することをさらに含む、条項３２にて説明される方法。
３４．
特定のデータレコードに対応して、ストリーム管理サービスの取り込みノードでレコード取得シーケンス内の特定のデータレコードの位置を示す、シーケンス番号を生成し、
取り込みノードは少なくとも部分的に初期のマッピングに基づいて選択され、
シーケンス番号に対応して第１のパーティションのデータレコードを順番に格納することを、１つ以上の計算装置によって実行することをさらに含む、条項３２にて説明される方法。
３５．
シーケンス番号は（ａ）特定のデータレコードの取り込みに関連するタイムスタンプ、及び（ｂ）追加のサブシーケンス値を含む、条項３４にて説明される方法。
３６．
タイムスタンプが、特定のデータレコードが取り込まれた時刻を示し、１つ以上の計算装置によって、少なくとも部分的に特定のレコードの取り込む時間範囲に基づいて、１つ以上のデータレコードが検索されることを要求する検索要求に対応して、１つ以上のデータレコードを検索するために、インデックスキーとして１つ以上のデータレコードに関連するシーケンス番号の使用を実行することをさらに含む条項３５にて説明される方法。
３７．
修正されたマッピングを使用してマップされたデータレコードのシーケンス番号に使用される初期のタイムスタンプ値を選択し、
特定のシーケンス番号を示すデータレコードの検索要求の受信に対応して、
特定のシーケンス番号によって示された特定のタイムスタンプの値が初期のタイムスタンプ値よりも低いという決定に対応して、１つ以上のデータレコードを検索するために初期のマッピングを利用し、
特定のタイムスタンプの値が初期のタイムスタンプ値よりも低くないという決定に対応して、１つ以上のデータレコードを検索するために修正されたマッピングの使用を１つ以上の計算装置によって実行することをさらに含む、条項３５にて説明される方法。
３８．
修正されたマッピングは少なくとも１つの追加の属性値を使用してデータレコードのパーティションを決定する、条項３２にて説明される方法。
３９．
１つ以上の計算装置によって、
データストリームに使用される１つ以上のパーティション基準を示すクライアントの要求を受信し、
少なくとも部分的にクライアントの要求に基づいて、初期のマッピングの生成を実行することをさらに含む、条項３２にて説明される方法。
４０．
１つ以上の計算装置によって、トリガ条件を示すクライアントの要求を受信を実行することをさらに含む、条項３２にて説明される方法。
４１．
１つ以上の計算装置によって、データストリームを再分割するクライアントの要求を受信し、クライアントの要求は修正されたマッピングの１つ以上のパラメータを示すことを実行することをさらに含む、条項３２にて説明される方法。
４２．
１つ以上の計算装置によって、再分割を介して潜在的な解決のために問題状態を示すクライアントの要求の受信を実行することをさらに含む、条項３２にて説明される方法。
４３．
選択されたビット数を含む、バイナリ値として表されるハッシュ結果を取得するために、特定のデータレコードのコンテンツの少なくとも部分的にハッシュ関数を適用し、
選択されたビット数を使用してバイナリ値が表され得る範囲の、ハッシュ結果が属する特定の副範囲を決定し、
少なくとも部分的に副範囲に基づいて第１パーティションの識別を、１つ以上の計算装置によって、実行することをさらに含む、条項３２にて説明される方法。
４４．
（ａ）データレコードのソースによって提供されたパーティションキー、（ｂ）データレコードのソースの識別、（ｃ）データレコードのコンテンツの少なくとも一部、または（ｄ）データレコードのソースのネットワークアドレスのうち、１つ以上の属性値が少なくとも１つを含む、条項３２にて説明される方法。
４５．
１つ以上の計算装置によって、修正されたマッピングの生成の後に、ストリーム管理システムの異なる数のノードを、（ａ）データレコードの取り込み、（ｂ）データレコードの格納、または（ｃ）修正されたマッピングの生成前に構成されたよりもデータストリームのためのデータレコードの検索のうち１つ以上実行するよう構成されることを実行することをさらに含む、条項３２にて説明される方法。
４６．
初期のマッピング及び修正されたマッピングを表す組み合わされたデータ構造を格納し、
組み合わされたデータ構造は、（ａ）初期のマッピングによる特定のデータレコードの属性がマップされる第１のパーティションを示す第１の入力、及び第１のパーティションに適用可能な初期のマッピングの時間範囲、及び（ｂ）修正されたマッピングによる特定のデータレコードの属性がマップされる異なるパーティションを示す第２の入力、及び異なるパーティションに適用可能な修正されたマッピングの異なる時間範囲を含む、条項３２にて説明される方法。
４７．
組み合わされたデータ構造が（ａ）ツリーまたは（ｂ）有向非巡回グラフのうち１つを備える、条項４６にて説明される方法。
４８．
修正されたマッピングが初期のマッピングによって示されたパーティションの対の統合を示すことを含む、条項３２にて説明される方法。
４９．
ストリーム管理サービスの複数のノードのうち、データストリームのデータレコードを分散するために適用されるパーティションポリシを決定し、
パーティションポリシは、データレコードに関連する、複数のパーティションにデータレコードの初期のマッピングを示すことを含み、
初期のマッピングにより、及び、初期のマッピングによるデータレコードを格納するためにストリーム管理サービスのデータ格納ノードの第１セットにより、ストリームのデータレコードを受信するためにストリーム管理サービスの取り込みノードの第１セットを構成し、
異なる複数のパーティションにデータレコードの修正されたマッピングを生成し、修正されたマッピングの生成の後に受信されたデータレコードのために、取り込みノードの異なるセット及びデータストレージノードの異なるセットを構成し、到着するデータレコードが修正されたマッピングによって格納される、少なくとも特定の時刻のために、初期のマッピングによるデータノードの第１セットに格納されたデータレコードを保持する、１つ以上のプロセッサ上で実行される場合に、プログラムの命令を格納する、非一時的にコンピュータにアクセス可能な記憶媒体。
５０．
条項４９にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体であって、１つ以上のプロセッサ上で実行される命令は、初期のマッピングによるデータストリームのためのデータ検索ノードの初期のセットを構成し、トリガ条件が合致したという決定に対応して、データストリームのためのデータ検索ノードの異なるセットを構成する、記憶媒体。
５１．
トリガ条件が（ａ）オーバーロードの状態の検出、（ｂ）ワークロードの不均衡の検出、 （ｃ）再分割のクライアントの要求、（ｄ）データストリームにおけるデータの耐久性要件の変更を決定、（ｅ）ソフトウェアのバージョン変更のスケジュールの決定、（ｆ）データストリームの使用状況の変化を検出（ｇ）データストリームの再分割の価格の影響の決定、または（ｈ）データストリームに関連する性能ターゲットの決定のうち、１つ以上を含む、条項４９にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体。
５２．
１つ以上のプロセッサ上で実行される命令は、データストリームに使用される１つ以上のパーティション基準を示すクライアントの要求を受信し、少なくとも部分的にクライアントの要求に基づいて、初期のマッピングを生成する、条項４９にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体。
５３．
１つ以上のプロセッサ上で実行される命令が、データストリームを再分割するためのトリガ条件を示すクライアントの要求を受信する、条項４９にて説明されるように、非一時的コンピュータでアクセス可能な記憶媒体。
コンピュータシステムの例
少なくともいくつかの実施形態においては、ＳＭＳサブシステム（例えば、取り込み、格納、検索及び制御サブシステム）のコンポーネントを実装する技術を含む、本明細書に記載された、一部またはすべての１つ以上の技術を実装するサーバは、ＳＰＳワーカ及び制御ノードと同様に、１つ以上のコンピュータがアクセス可能な媒体にアクセスすることを含むか、またはアクセスするよう構成された汎用コンピュータシステムを含み得る。図３０は、このような汎用計算装置９０００を示す。図示した実施形態では、計算装置９０００は、入力／出力（Ｉ／Ｏ）インタフェース９０３０を介して、システムメモリ９０２０に接続された１つ以上のプロセッサ９０１０を含む。計算装置９０００は、さらに、Ｉ／Ｏインタフェース９０３０に接続されたネットワークインタフェース９０４０を含む。
様々な実施形態では、計算装置９０００は、１つのプロセッサ９０１０を含む、単一プロセッサまたは、いくつかのプロセッサ９０１０を含む、マルチプロセッサシステムであり得る（例えば、２、４、８または別の好適な数）。プロセッサ９０１０は、命令を実行可能な任意の好適なプロセッサであり得る。例えば、様々な実施形態では、プロセッサ９０１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣまたはＭＩＰＳ ＩＳＡ、または任意のその他の好適なＩＳＡのような、任意の様々な命令セットアーキテクチャ（ＩＳＡ）を実行する汎用または組込型プロセッサであり得る。いくつかの実装においては、グラフィックス処理ユニット（ＧＰＵ）は、従来のプロセッサの代わりに、または追加して使用され得る。
システムメモリ９０２０は、プロセッサ（単数または複数）９０１０によってアクセス可能な命令及びデータを格納するよう構成され得る。様々な実施形態では、システムメモリ９０２０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、シンクロナスダイミックランダムアクセスメモリ（ＳＤＲＡＭ）、不揮発性／フラッシュタイプのメモリまたは任意のその他の種類のメモリの種類を使用して実装され得る。図示した実施形態では、１つ以上の所望の機能を実装する、プログラムの命令及びデータは、これらの方法、技術及び上述のデータが示され、コード９０２５及びデータ９０２６のように、システムメモリ９０２０内に記憶される。
一実施形態では、Ｉ／Ｏインタフェース９０３０は、プロセッサ９０１０と、システムメモリ９０２０と、データオブジェクトパーティションの物理複製を格納するために使用される、様々な種類の永続的及び／または揮発性記憶装置のような、ネットワークインタフェース９０４０またはその他の周辺インタフェースを含む、装置内の任意の周辺装置との間のＩ／Ｏトラフィックを調節するよう構成され得る。いくつかの実施形態では、Ｉ／Ｏインタフェース９０３０は、１つのコンポーネント（例えば、システムメモリ９０２０）からデータ信号を変換するために、任意の必要なプロトコル、タイミングまたはその他のデータ変換を別のコンポーネント（例えば、プロセッサ９０１０）によって使用するのに適したフォーマットに実行し得る。いくつかの実施形態では、Ｉ／Ｏインタフェース９０３０は、例えば、周辺構成要素相互接続装置（ＰＣＩ）バス規格の変形またはユニバーサルシリアルバス（ＵＳＢ）規格のような、様々な種類の周辺のバスを通して取り付けられる装置への支援を含み得る。いくつかの実施形態では、Ｉ／Ｏインタフェース９０３０の機能は、例えば、ノースブリッジ及びサウスブリッジのように、２つまたはそれ以上の分離したコンポーネントに分かれ得る。また、いくつかの実施形態では、システムメモリ９０２０へのインタフェースのような、いくつかの、またはすべてのＩ／Ｏインタフェース９０３０の機能は、プロセッサ９０１０に直接組み込まれ得る。
ネットワークインタフェース９０４０は、コンピュータシステムまたは例えば、図１から図２９に図示された装置のような、ネットワークまたはネットワーク９０５０に取り付けられた、データが計算装置９０００とその他の装置９０６０との間で交換できるように構成され得る。様々な実施形態では、ネットワークインタフェース９０４０は、例えばイーサネット（登録商標）ネットワークの種類のような、任意の好適な有線または無線の一般的なデータネットワークを介して、通信を支援し得る。さらに、ネットワークインタフェース９０４０は、ファイバチャネルＳＡＮのようなストレージエリアネットワークを介して、または任意のその他の好適な種類のネットワーク及び／またはプロトコルを介して、アナログ音声ネットワークまたはデジタルファイバ通信ネットワークのような、電気通信／電話網を介した通信を支援し得る。
いくつかの実施形態では、システムメモリ９０２０は、対応する方法及び装置の実施形態を実装するために、図１から図２９のために上記に記載されたように、プログラムの命令及びデータを格納するよう構成された、コンピュータでアクセス可能な媒体の一実施形態であり得る。しかしながら、その他の実施形態では、プログラムの命令及び／またはデータが受信され、送信され、または異なる種類のコンピュータがアクセス可能な媒体に格納され得る。一般に、コンピュータがアクセス可能な媒体は、磁気または光学媒体のような、非一時的記憶媒体またはメモリ媒体を含み得る。例えば、Ｉ／Ｏインタフェース９０３０を介して計算装置９０００に接続されたディスクまたはＤＶＤ／ＣＤである。非一時的コンピュータがアクセス可能な記憶媒体は、また、いくつかの実施形態において、システムメモリ９０２０または別の種類のメモリのように、計算装置９０００中に含まれてよい、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等のような、任意の揮発性または不揮発性媒体を含み得る。さらに、コンピュータがアクセス可能な媒体は、ネットワークインタフェース９０４０を経由して実装され得るような、ネットワーク及び／または無線接続のような、電気信号、電磁波信号またはデジタル信号のような、通信媒体を経由して伝達される伝送媒体または信号を含み得る。図３０に示されたような、多数の計算装置の一部または全部は、様々な実施形態において、記載された機能を実装するために使用され得る。例えば、様々に異なる装置及びサーバで実行するソフトウェアコンポーネントは、機能性を提供するために一緒に動き得る。いくつかの実施形態では、汎用コンピュータシステムを使用して実装されることに加えて、またはその代わりに、記憶装置、ネットワーク装置または専用コンピュータシステムを使用して、記載された機能性の一部は実装され得る。「計算装置」という用語は、本発明で使用する場合、少なくともすべてのこれらの種類の装置を意味し、これらの種類の装置に限定されない。
結論
様々な実施形態は、さらに、コンピュータがアクセス可能な媒体についての前述の記載により実装される、受信し、送信し、または命令及び／またはデータを格納することを含み得る。一般に、コンピュータがアクセス可能な媒体は、磁気媒体または光媒体のような、記憶媒体またはメモリ媒体を含み得る。ネットワーク及び／または無線接続のような、通信媒体を経由して伝達される、伝送媒体または電気信号、電磁波信号またはデジタル信号のような信号と同様に、例えば、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭ、ｅｔｃ．），ＲＯＭ等のような、ディスクまたはＤＶＤ／ＣＤ−ＲＯＭ、揮発性媒体または不揮発性媒体が含み得る。
図面に示され、本明細書で記載された、様々な方法は、例示的な方法の実施形態を表す。この方法はソフトウェア、ハードウェアまたはこれらの組み合わせにおいて実施され得る。方法の順序は変更されてよく、様々な要素が追加され、順序が変更され、組み合わされ、省略され、修正等され得る。
様々な修正及び変更が、本開示の利益を有する当業者には明白であるため、成され得る。すべてのこのような修正及び変更を受け入れることを目的としており、したがって、上記の記載は制限を意味するよりもむしろ、例証としてみなされるべきである。

Claims (14)

  1. ストリーム管理サービスのクライアントが、特定のデータストリームのために、複数のデータ取り込みポリシの中から、データ取り込みポリシを選択するのを可能とするプログラムによるインタフェースのセットを実装し、
    前記複数のデータ取り込みポリシは、レコード送信者が、データレコードの表示を、肯定応答が受信されるまで、前記ストリーム管理サービスに１回以上伝送することに従う少なくとも１回の取り込みポリシを含み、
    プログラムによるインタフェースの前記セットを介して、前記クライアントが、前記特定のデータストリームのために、前記少なくとも１回の取り込みポリシを選択したことを示す要求を受信し、
    前記ストリーム管理サービスで、特定のデータレコードを示す複数の伝送を受信することに対応して、
    前記少なくとも１回の取り込みポリシに従って、前記複数の伝送の各伝送に対応するそれぞれの肯定応答を送信し、
    前記複数の伝送のうち特定の伝送の受信に応答して、前記特定のデータストリームのために選択されたデータ永続性ポリシに従って、１つ以上の記憶位置において前記特定のデータレコードのコピーを格納する、１つ以上の計算装置による実行を含み、
    前記データ永続性ポリシは、前記特定のデータストリームの第１パーティションに使用される記憶位置の第１種類の表示と、前記特定のデータストリームの第２のパーティションに使用される記憶位置の異なる種類の表示と、を備える、
    方法。
  2. どちらの前記ストリーム管理サービスが、対応する肯定応答をレコード送信者に提供せずに、特定したストリームの少なくともいくつかのデータレコードを受け入れ及び格納するべきかにより、前記複数のデータ取り込みポリシがベストエフォートの取り込みポリシを備える、請求項１に記載の方法。
  3. 前記少なくとも１回の取り込みポリシにより、前記ストリーム管理サービスが複製されたデータレコードを削除するよう構成される、請求項１に記載の方法。
  4. 前記少なくとも１回の取り込みポリシにより、前記ストリーム管理サービスが、前記複数の伝送に対応して、２つ以上の前記特定のデータレコードのコピーを格納するよう構成される、請求項１に記載の方法。
  5. 前記クライアントが前記特定のデータストリームのために、複数のデータ永続性ポリシから、前記データ永続性ポリシを選択するのを可能にするプログラムによるインタフェースの第２セットを実装する、前記１つ以上の計算装置によって実行されることをさらに含む、請求項１に記載の方法。
  6. 前記複数のデータ永続性ポリシが、複数の複製永続性ポリシと、単一の複製永続性ポリシとを含む、請求項５に記載の方法。
  7. 前記データ永続性ポリシがデータレコードを格納するために使用される記憶位置の種類の表示を備えるデータ永続性ポリシであって、
    前記記憶位置の種類は、（ａ）磁気ディスクベースのストレージ、（ｂ）ソリッドステートドライブ（ＳＳＤ）、（ｃ）揮発性ＲＡＭ（ランダムアクセスメモリ）、（ｄ）不揮発性ＲＡＭ、（ｅ）データベース管理システム、または（ｆ）プロバイダネットワークによって実装されるネットワークにアクセス可能なストレージサービスのストレージノードのうちの１つを備える、請求項５に記載の方法。
  8. 前記データ永続性ポリシが目標の待ち時間の表示を含み、前記１つ以上の計算装置によって実行されることをさらに含み、
    前記ストリーム管理サービスの１つ以上のコンポーネントによって、データレコードを少なくとも部分的に前記目標の待ち時間に基づいて格納するために使用される記憶位置の種類を選択することをさらに含む、請求項５に記載の方法。
  9. 前記１つ以上の計算装置によって、
    （ａ）前記特定のデータレコードの１つ以上の属性に基づいて、前記特定のデータレコードが特定のパーティションのメンバとして指定され（ｂ）いくつかのデータストレージノードのうちのデータストレージノードが、前記特定のパーティションのデータレコードを格納するために選択されることにより、少なくとも部分的にパーティションポリシに基づいて、いくつかのデータストレージノードが特定のデータストリームの構成の決定を実行することをさらに含む、請求項１に記載の方法。
  10. 前記１つ以上の計算装置によって、
    前記特定のデータストリームの複数のデータレコードの各データレコードに対応して、格納し、
    前記特定のデータレコードを含み、それぞれのシーケンス番号はデータレコードの並べられたセットに対する読み出し要求に応答することが不可能であり、
    前記データストリームの異なるデータレコードの送信者から、前記異なるデータレコードに対応して格納される最小のシーケンス番号の表示を受け取ること、
    前記異なるデータレコードに対応して、
    前記最小のシーケンス番号より大きなまたは等しい特定のシーケンス番号の格納を実行することをさらに含む、請求項１に記載の方法。
  11. １つ以上のプロセッサと１つ以上のメモリを含むシステムであって、
    プログラムによる命令を含む前記１つ以上のメモリが、１つ以上のプロセッサが実行されるとき、
    選択されたデータ取り込みポリシに基づいて、ストリーム管理サービスによってデータレコードが取り込まれた特定のデータストリームのために、前記ストリーム管理サービスのクライアントが、複数のデータ永続性ポリシからデータ永続性ポリシを選択することを可能とするプログラムによるインタフェースのセットを実行し、
    前記複数のデータ永続性ポリシは、
    （ａ）前記特定のデータストリームのデータレコードの複数のコピーが、それぞれの格納位置に格納されることに従う複数の複製永続性ポリシと、（ｂ）前記特定のデータストリームのデータレコードの単一コピーが格納される、単一の複製永続性ポリシを含み、
    プログラムによるインタフェースの前記セットを介して、前記クライアントが、前記特定のデータストリームのために、前記複数の複製永続性ポリシを選択したことを示す要求を受信し、
    前記特定のデータストリームのデータレコードのために、前記複数の複製永続性ポリシを実装するために、複数のストレージノードを構成し、
    前記データ永続性ポリシは、前記特定のデータストリームの第１パーティションに使用される記憶位置の第１種類の表示と、前記特定のデータストリームの第２のパーティションに使用される記憶位置の異なる種類の表示と、を備える、
    システム。
  12. 前記クライアントによって選択された前記複数の複製永続性ポリシが、要求されたデータの耐久性レベルの表示を含み、
    前記１つ以上のプロセッサ上で実行される前記命令は、少なくとも部分的に前記要求されたデータ耐久性レベルに基づいて、構成されるいくつかのストレージノードを決定する、請求項１１に記載のシステム。
  13. １つ以上のプロセッサが実行されるとき前記システムに
    少なくとも部分的に前記特定のクライアントによって選択されたデータ永続性ポリシに基づいて、特定のクライアントがストリーム管理操作に対して請求される請求額の決定を生じるプログラムの命令をさらに含む、請求項１１に記載のシステム。
  14. １つ以上のプロセッサが実行されるとき前記システムに
    （ａ）前記特定のデータレコードの１つ以上の属性に基づいて、前記特定のデータレコードが特定のパーティションのメンバとして指定され（ｂ）いくつかのデータストレージノードのうちのデータストレージノードが、前記特定のパーティションのデータレコードを格納するために選択されることにより、少なくとも部分的にパーティションポリシに基づいて、いくつかのデータストレージノードが前記特定のデータストリームの構成の決定を生じさせることをさらに含む、請求項１１に記載のシステム。
JP2016553274A 2013-11-11 2014-11-11 データストリーム取り込み及び永続性ポリシ Active JP6357243B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US14/077,162 US9858322B2 (en) 2013-11-11 2013-11-11 Data stream ingestion and persistence techniques
US14/077,171 US9720989B2 (en) 2013-11-11 2013-11-11 Dynamic partitioning techniques for data streams
US14/077,171 2013-11-11
US14/077,162 2013-11-11
PCT/US2014/065052 WO2015070232A1 (en) 2013-11-11 2014-11-11 Data stream ingestion and persistence techniques

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2018084896A Division JP6510112B2 (ja) 2013-11-11 2018-04-26 データストリーム取り込み及び永続性ポリシ

Publications (2)

Publication Number Publication Date
JP2017501515A JP2017501515A (ja) 2017-01-12
JP6357243B2 true JP6357243B2 (ja) 2018-07-11

Family

ID=53042245

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2016553274A Active JP6357243B2 (ja) 2013-11-11 2014-11-11 データストリーム取り込み及び永続性ポリシ
JP2018084896A Active JP6510112B2 (ja) 2013-11-11 2018-04-26 データストリーム取り込み及び永続性ポリシ

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2018084896A Active JP6510112B2 (ja) 2013-11-11 2018-04-26 データストリーム取り込み及び永続性ポリシ

Country Status (5)

Country Link
EP (1) EP3069275A4 (ja)
JP (2) JP6357243B2 (ja)
CN (1) CN105765575B (ja)
CA (1) CA2930026C (ja)
WO (1) WO2015070232A1 (ja)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9942272B2 (en) 2015-06-05 2018-04-10 Microsoft Technology Licensing, Llc. Handling out of order events
US10868741B2 (en) 2015-06-05 2020-12-15 Microsoft Technology Licensing, Llc Anchor shortening across streaming nodes
US10148719B2 (en) 2015-06-05 2018-12-04 Microsoft Technology Licensing, Llc. Using anchors for reliable stream processing
US9880769B2 (en) 2015-06-05 2018-01-30 Microsoft Technology Licensing, Llc. Streaming joins in constrained memory environments
US9602455B2 (en) * 2015-08-07 2017-03-21 Machine Zone, Inc. Scalable, real-time messaging system
WO2017201127A1 (en) 2016-05-17 2017-11-23 Ab Initio Technology Llc Reconfigurable distributed processing
CN107783834B (zh) * 2016-08-30 2021-05-07 伊姆西公司 用于处理数据的方法和系统
US10594760B2 (en) * 2017-01-25 2020-03-17 Futurewei Technologies, Inc. Intelligent event streaming
US11314648B2 (en) 2017-02-08 2022-04-26 Arm Limited Data processing
US10719495B2 (en) * 2017-02-09 2020-07-21 Micron Technology, Inc. Stream selection for multi-stream storage devices
CN107612687B (zh) * 2017-09-25 2021-04-27 西安建筑科技大学 一种基于ElGamal加密的动态多副本数据持有性验证方法
US10884644B2 (en) * 2018-06-28 2021-01-05 Amazon Technologies, Inc. Dynamic distributed data clustering
US11120052B1 (en) 2018-06-28 2021-09-14 Amazon Technologies, Inc. Dynamic distributed data clustering using multi-level hash trees
US11163737B2 (en) * 2018-11-21 2021-11-02 Google Llc Storage and structured search of historical security data
US11989186B2 (en) * 2018-11-23 2024-05-21 Amazon Technologies, Inc. Scalable architecture for a distributed time-series database
DE112019005842T5 (de) * 2018-11-23 2021-08-12 Amazon Technologies, Inc. Skalierbare architektur für eine verteilte zeitreihendatenbank
US11934409B2 (en) 2018-11-23 2024-03-19 Amazon Technologies, Inc. Continuous functions in a time-series database
US11409725B1 (en) 2019-02-04 2022-08-09 Amazon Technologies, Inc. Multi-tenant partitioning in a time-series database
US11853317B1 (en) 2019-03-18 2023-12-26 Amazon Technologies, Inc. Creating replicas using queries to a time series database
CN110147354B (zh) * 2019-04-19 2023-06-02 平安科技（深圳）有限公司 批量数据编辑方法、装置、计算机设备及存储介质
US11599516B1 (en) 2020-06-24 2023-03-07 Amazon Technologies, Inc. Scalable metadata index for a time-series database
JP7564449B2 (ja) 2021-03-29 2024-10-09 富士通株式会社 データ処理プログラム、情報処理システム及びデータ処理方法
US11461347B1 (en) 2021-06-16 2022-10-04 Amazon Technologies, Inc. Adaptive querying of time-series data over tiered storage
US11941014B1 (en) 2021-06-16 2024-03-26 Amazon Technologies, Inc. Versioned metadata management for a time-series database
CN114116732B (zh) * 2022-01-24 2022-04-05 北京奥星贝斯科技有限公司 处理事务的方法、装置、存储装置以及服务器
US11941029B2 (en) 2022-02-03 2024-03-26 Bank Of America Corporation Automatic extension of database partitions
CN114676117B (zh) * 2022-05-27 2022-08-16 成都明途科技有限公司 一种岗位数据存储方法、装置及岗位机器人
US11960774B2 (en) 2022-07-20 2024-04-16 The Toronto-Dominion Bank System, method, and device for uploading data from premises to remote computing environments
CN117666928A (zh) * 2022-08-30 2024-03-08 华为云计算技术有限公司 一种数据访问方法和系统
CN115480914B (zh) * 2022-09-02 2023-07-21 江苏安超云软件有限公司 一种多租户服务的实现方法及系统

Family Cites Families (26)

* 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
JP4057074B2 (ja) * 1996-04-25 2008-03-05 富士通株式会社 ストリームデータのストライピング方法およびストリームサーバ
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
WO2005109212A2 (en) * 2004-04-30 2005-11-17 Commvault Systems, Inc. Hierarchical systems providing unified of storage information
US7814056B2 (en) * 2004-05-21 2010-10-12 Computer Associates Think, Inc. Method and apparatus for data backup using data blocks
US7606844B2 (en) * 2005-12-19 2009-10-20 Commvault Systems, Inc. System and method for performing replication copy storage operations
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
US7716186B2 (en) * 2007-01-22 2010-05-11 International Business Machines Corporation Method and system for transparent backup to a hierarchical storage system
US8190960B1 (en) * 2007-12-13 2012-05-29 Force10 Networks, Inc. Guaranteed inter-process communication
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 富士通株式会社 データ処理プログラム、サーバ装置およびデータ処理方法
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
US20100306232A1 (en) * 2009-05-28 2010-12-02 Harris Corporation Multimedia system providing database of shared text comment data indexed to video source data and related methods
JP5303038B2 (ja) * 2009-09-18 2013-10-02 株式会社日立製作所 重複したデータを排除するストレージシステム
CN103125102B (zh) * 2010-09-17 2016-02-24 甲骨文国际公司 用于在中间件机器环境中提供基于无限带宽的以太网虚拟集线器可伸缩性的系统和方法
US9137304B2 (en) * 2011-05-25 2015-09-15 Alcatel Lucent Method and apparatus for achieving data security in a distributed cloud computing environment
JP5544523B2 (ja) * 2011-07-19 2014-07-09 日本電信電話株式会社 分散処理システム、分散処理方法、負荷分散装置、負荷分散方法、及び、負荷分散プログラム
JP2013058101A (ja) * 2011-09-08 2013-03-28 Interlink:Kk クラウドコンピューティングシステム
US20130085995A1 (en) * 2011-09-29 2013-04-04 International Business Machines Corporation Managing back up operations for data
WO2013069073A1 (ja) * 2011-11-07 2013-05-16 株式会社日立製作所 時系列データ管理システム、装置および方法
WO2013070873A1 (en) * 2011-11-10 2013-05-16 Treasure Data, Inc. System and method for operating a big-data platform
US8886781B2 (en) * 2011-12-13 2014-11-11 Microsoft Corporation Load balancing in cluster storage systems
US9098344B2 (en) * 2011-12-27 2015-08-04 Microsoft Technology Licensing, Llc Cloud-edge topologies

Also Published As

Publication number Publication date
JP2018133105A (ja) 2018-08-23
JP2017501515A (ja) 2017-01-12
CN105765575A (zh) 2016-07-13
EP3069275A1 (en) 2016-09-21
EP3069275A4 (en) 2017-04-26
CA2930026A1 (en) 2015-05-14
JP6510112B2 (ja) 2019-05-08
CA2930026C (en) 2020-06-16
CN105765575B (zh) 2019-11-05
WO2015070232A1 (en) 2015-05-14

Similar Documents

Publication Publication Date Title
JP6510112B2 (ja) データストリーム取り込み及び永続性ポリシ
US10795905B2 (en) Data stream ingestion and persistence techniques
US10691716B2 (en) Dynamic partitioning techniques for data streams
EP3069495B1 (en) Client-configurable security options for data streams
AU2014346369B2 (en) Managed service for acquisition, storage and consumption of large-scale data streams
AU2014346366B2 (en) Partition-based data stream processing framework

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170531

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170704

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171004

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20171226

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180426

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

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20180508

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: 20180612

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180615

R150 Certificate of patent or registration of utility model

Ref document number: 6357243

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

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250