JP2016540298A - 大規模データストリームの取得、記憶、及び消費のための管理型サービス - Google Patents

大規模データストリームの取得、記憶、及び消費のための管理型サービス Download PDF

Info

Publication number
JP2016540298A
JP2016540298A JP2016529931A JP2016529931A JP2016540298A JP 2016540298 A JP2016540298 A JP 2016540298A JP 2016529931 A JP2016529931 A JP 2016529931A JP 2016529931 A JP2016529931 A JP 2016529931A JP 2016540298 A JP2016540298 A JP 2016540298A
Authority
JP
Japan
Prior art keywords
data
record
stream
node
nodes
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2016529931A
Other languages
English (en)
Other versions
JP6246358B2 (ja
Inventor
サイマー，マーヴィン・マイケル
ガーレ，ガウラヴ・ディ
デュナガン，ジョン・デイヴィッド
バージェス，グレッグ
ション，イン
Original Assignee
アマゾン・テクノロジーズ・インコーポレーテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by アマゾン・テクノロジーズ・インコーポレーテッド filed Critical アマゾン・テクノロジーズ・インコーポレーテッド
Publication of JP2016540298A publication Critical patent/JP2016540298A/ja
Application granted granted Critical
Publication of JP6246358B2 publication Critical patent/JP6246358B2/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/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24568—Data stream processing; Continuous queries
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/18—Delegation of network management function, e.g. customer network management [CNM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/24—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using dedicated network management hardware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5051—Service on demand, e.g. definition and deployment of services in real time

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

マルチテナントストリームマネジメントサービスの制御ノードは複数のデータ記録からなるデータストリームを初期化する要求を受信する。該制御ノードは、パーティション分割の方針にしたがって、データ記録の取得、記憶、検索用のサブシステムを構成するために使用するパラメータを決定する。該制御ノードは、検索サブシステムのノードに使用されるソースを特定する。検索ノードは、プログラム記録検索インターフェースを実装するよう構成されて、非順次アクセスパターン及び順次アクセスパターンを実装する各インターフェースを含む。該制御ノードは、選択された資源を用いて検索ノードを構成する。【選択図】図５

Description

データストレージの費用は何年にもわたって下がってきて、種々のコンピューティングインフラストラクチャの構成要素を相互に接続することができるようになったことにより、幅広い種類のアプリケーションに関連するますます多くのデータを、収集し、かつ解析することができるようになった。例えば、携帯電話は、その位置、または携帯電話ユーザで使用されているアプリケーションなどを示すデータを発信することができ、少なくともそのデータのうちのいくつかは、カスタマイズされたクーポン券、広告などをユーザに見せるために収集され、解析されることがある。監視カメラで集められたデータの解析は、犯罪防止及び／または犯罪解決に役立つことができ、飛行機のエンジン、自動車、または複合機の中の様々な場所に埋め込まれたセンサが集めたデータは、予防保守など種々の目的に使用することができ、効率を上げ費用を下げている。
ストリーミングデータの量の増加は、コモディティハードウェアの使用の増加を伴った（場合によっては、それによって可能になった）。コモディティハードウェアのための仮想化技術の到来により大規模コンピューティング資源を扱う利点を多くのタイプのアプリケーションに与えることができ、種々のコンピューティング資源を多数の顧客が効率よく安全に共有できるようになった。例えば、仮想化技術により、各ユーザに、単一の物理コンピューティングマシンにホストされた１つまたは複数の仮想マシンを提供することで、単一の物理コンピューティングマシンを複数のユーザ間で共有できるようになった。そのような各仮想マシンは、別個の論理コンピューティングシステムとして働くソフトウェアの擬態であり、種々の仮想マシン間でアプリケーションの分離及び安全を提供すると同時に、ユーザに自身が所与のハードウェアコンピューティング資源の唯一の操作者でありかつ管理者であるとの錯覚をもたらす。さらに、仮想化技術によっては、複数のまったく別のコンピューティングシステムに及ぶ多数の仮想プロセッサを備える単一仮想マシンなどの２つ以上の物理資源に及ぶ仮想資源を備えることができる。また、コンピューティングプラットフォームに加え、大きな組織では、仮想化技術を使用するよう組み込まれた様々なタイプの記憶サービスを提供している。そのような記憶サービスを使用することにより、大容量のデータを所望の耐久性レベルで保存することができるようになる。
様々なプロバイダから比較的安価な仮想化されたコンピューティング及び／または記憶資源が利用できるようになってきたが、収集の管理と組織化、動的で激しく変動するデータの流れの記憶及び処理は、種々の理由で困難な課題のままである。大容量データストリームを処理するため構成されたシステムにより多くの資源を加えたため、例えば、システムの異なる部品間で負荷の不均衡が起きる恐れがある。未対策のまま放置されていた場合、他の資源が未活用（ひいては消耗）であるのに加え、そのような不均衡により厳しい性能上の問題が一部の資源に生じる可能性がある。また、そのようなデータまたは結果をクライアントが制御できない設備に記憶する場合、クライアントは自分たちのストリーミングデータの安全性、またはストリーミングデータの解析結果に関して不安になるかもしれない。分散型システムのサイズが大きくなると、接続不能及び／またはハードウェア障害など、当然、頻度を増して起こりがちになる障害も、効果的に処理して、ストリームデータの収集、記憶、または解析の費用のかかる中断を予防しなければならない可能性がある。
少なくともいくつかの実施形態によるデータストリームの概念の簡易概観である。 少なくともいくつかの実施形態によるストリーム処理段階の収集を含むストリーム管理システム（ＳＭＳ）及びストリーム処理システム（ＳＰＳ）の種々のサブコンポーネントの中のデータの流れの概観である。 少なくともいくつかの実施形態によるＳＭＳ及びＳＰＳで実装され得る各組のプログラムインターフェースの例示である。 少なくともいくつかの実施形態によるＳＰＳのクライアントがストリーム処理段階のグラフを生成することができるよう実装され得るウェブベースのインターフェースの例示である。 少なくともいくつかの実施形態によるＳＭＳで実装され得るプログラムの記録提出インターフェース及び記録検索インターフェースの例示である。 少なくともいくつかの実施形態によるＳＭＳの取得サブシステムの要素の例示である。 少なくともいくつかの実施形態によるＳＭＳの記憶サブシステムの要素の例示である。 少なくともいくつかの実施形態によるＳＭＳの検索サブシステムの要素及びＳＰＳとの検索サブシステムの相互作用の例示である。 少なくともいくつかの実施形態によるＳＭＳまたはＳＰＳのノード用に用意され得る冗長グループの例示である。 少なくともいくつかの実施形態による所与の冗長グループのノードを複数のデータセンタ間に行き渡らせ得るプロバイダ網環境を示す。 少なくともいくつかの実施形態によるＳＭＳまたはＳＰＳのノード用に選択され得る複数の配置先を示す。 少なくともいくつかの実施形態によるＳＰＳクライアント及びＳＭＳクライアントそれぞれにより提出され得るセキュリティオプション要求の例示である。 少なくともいくつかの実施形態によるＳＰＳクライアント及びＳＭＳクライアントそれぞれにより提出され得るセキュリティオプション要求の例示である。 少なくともいくつかの実施形態によるＳＭＳのストリームデータプロデューサと取得ノード間の相互作用の例示である。 少なくともいくつかの実施形態によるＳＭＳで取得したデータ記録用に生成され得るシーケンス番号の要素の例示である。 少なくともいくつかの実施形態によるＳＭＳでのストリーミングデータ記録の保存及び検索の順番の例示である。 少なくともいくつかの実施形態によるＳＭＳ及びＳＰＳノード用になされ得るストリームパーティションマッピングならびに対応する構成決定の例示である。 少なくともいくつかの実施形態による動的ストリーム再パーティション分割の例示である。 少なくともいくつかの実施形態によるストリーム記録取得及びストリーム記録検索用プログラムインターフェースの各組に対応するよう実行され得る動作の態様を示す流れ図である。 少なくともいくつかの実施形態によるストリーム処理段階を構成するよう実行され得る動作の態様を示す流れ図である。 少なくともいくつかの実施形態によるストリーム処理ワーカーノードの構成用クライアントライブラリの構成要素の呼び出しに応答して実行され得る動作の態様を示す流れ図である。 少なくともいくつかの実施形態によるストリーム処理用の１つまたは複数のリカバリ方針を実装するよう実行され得る動作の態様を示す流れ図である。 少なくともいくつかの実施形態によるデータストリーム用の複数のセキュリティオプションを実装するよう実行され得る動作の態様を示す流れ図である。 少なくともいくつかの実施形態によるデータストリーム用のパーティション分割方針を実装するよう実行され得る動作の態様を示す流れ図である。 少なくともいくつかの実施形態によるデータストリーム用の動的再パーティション分割を実装するよう実行され得る動作の態様を示す流れ図である。 少なくともいくつかの実施形態によるデータストリーム記録用の少なくとも１度の記録取得方針を実装するよう実行され得る動作の態様を示す流れ図である。 少なくともいくつかの実施形態によるデータストリーム用の複数の持続性方針を実装するよう実行され得る動作の態様を示す流れ図である。 少なくともいくつかの実施形態によるデータベーステーブルを用いて、処理段階のワーカーノードが作業負荷を調整するストリーム処理システムの例示である。 少なくともいくつかの実施形態による作業負荷の調整に使用するパーティション分割割り当てテーブルに保存され得る記載の例示である。 少なくともいくつかの実施形態による処理動作を実行するパーティション選択のためのストリーム処理段階のワーカーノードにより実行され得る動作の態様を示す図である。 少なくともいくつかの実施形態によるストリーム管理サービス制御サブシステムから入手した情報に基づいてパーティション割り当てテーブルを更新するためのストリーム処理段階のワーカーノードにより実行され得る動作の態様を示す図である。 少なくともいくつかの実施形態によるストリーム処理段階のワーカーノードにより実行され得る負荷のバランス動作の態様を示す図である。 少なくともいくつかの実施形態に使用され得るコンピューティング装置を例示するブロック図である。
いくつかの実施形態及び説明図を例示して本明細書で説明したが、実施形態は説明した当該実施形態または図面に限定されないことは当業者なら理解するであろう。該図面及び詳細説明は開示の特定の形状に実施形態を限定するものではなく、添付の特許請求の範囲により定義される精神と範囲内に含まれるあらゆる修正態様、等価物、変更態様を含有することが意図される。本明細書で使用の見出し条項は構成目的のみであり明細書または特許請求の範囲に限定して使用されるものではない。本出願を通して、「ｍａｙ」は、強制の意（すなわち、しなければならないを意味する）ではなく、許可の意（すなわち、可能の意味を有する）、で使われる。同様に、「ｉｎｃｌｕｄｅ」、「ｉｎｃｌｕｄｉｎｇ」及び「ｉｎｃｌｕｄｅｓ」は、「含む」を意味するが、これに限定するものではない。
数百または数千もの同時に発生するデータのプロデューサならびにコンシューマを扱うよう設計された大規模データストリームの生成、記憶、検索、と処理を管理する方法及び装置の種々の実施形態について説明する。本明細書で使用される「データストリーム」という言葉は、１つまたは複数のデータプロデューサによって生成されて、１つまたは複数の消費者によってアクセスされるデータ記録の連続のことを言い、そこでは個々のデータ記録を変更不可能なバイトの連続であると仮定する。ストリーム管理サービス（ＳＭＳ）は、いくつかの実施形態では、プログラムインターフェース（例えば、アプリケーションプログラミングインターフェース（ＡＰＩ）、ウェブページまたはウェブサイト、グラフィカルユーザインターフェース、あるいはコマンドラインツール）をストリームの作成、構成、及び削除ならびにストリームデータ記録の提出、記憶、検索のために提供することができる。ＳＭＳ制御構成要素を備える相互作用を含むストリーム動作のいくつかのタイプ（ストリーム作成または削除、あるいは以下に説明する動的再パーティション分割の動作類）は、ここでは「制御プレーン」動作と呼ぶが、一方で、一般に（例えば正常動作状況下で）制御構成要素を備える相互作用を必要としないデータ記録提出、記憶及び検索などの動作は、ここではデータプレーン動作と呼んでもよい。動的に提供される数組の計算、記憶及びネットワーキング資源は、例えば、種々のパーティション分割方針に基づいて、いくつかの実施形態でそのサービスを実装するために使用されてもよい。その結果、以下にさらに詳細を説明するがストリーム管理の作業負荷を拡張性に優れた形式で多数のサービス構成要素間に広めることができるようになる。ここで使用される頭文字ＳＭＳは、ストリームマネジメントサービスのことを言い、またストリームマネジメントサービスを実装するために使用される仮想資源及び／または物理的資源の収集を含むストリームマネジメントシステムのことを言う。
一部のＳＭＳの顧客は種々の実施形態で、ＳＭＳのプログラムインターフェースを直接呼び出すアプリケーションを開発できる。しかし、少なくともいくつかの実施形態では、ＳＭＳインターフェースに加えて、より高いレベルの抽出またはアプリケーションレベルの加工フレームワークを顧客に提供することで、ＳＭＳが直接サポートする低いレベルのストリームマネジメント機能を使用してアプリケーションを開発したくないクライアント用に加工する種々のストリームの態様を簡単にすることができる。そのようなフレームワークは独自のプログラムインターフェース（例えば、ＳＭＳのインターフェースの上に作られた）を提供するので、顧客が低いレベルのストリームマネジメント動作上より、ストリーム記録を使用して実装されるもビジネスロジック上により集中できるようになる。一部の実施形態では、より高いレベルのフレームワークを、独自の制御プレーン及びデータプレーン構成要素を備えるストリームプロセシングサービス（ＳＰＳ）として実装してもよく、ＳＰＳは、ストリーム処理用の自動資源プロビジョニング、処理ノードの自動フェールオーバー、任意のストリーム処理ワークフローグラフを構成する能力、一時的ストリーム支援、作業負荷変更または他のトリガー条件に基づく動的再パーティション分割などの進んだ機能を提供できる。少なくともいくつかの実施形態では、ストリーム管理サービス、ストリーム処理サービスまたは両方のサービスのいずれかを、仮想化環境でマルチテナント管理型ネットワークアクセス可能サービスとして実装してもよい。すなわち、種々の物理資源（コンピュータサーバまたはコンピュータホスト、記憶デバイス、ネットワークデバイスなど）は、少なくとも一部のケースで、そのような実施形態では、どのように資源が共有されているか正確に顧客に知らせる必要はなく、むしろ顧客に所与の資源が皆に共有されているとまったく知らせず、異なる顧客のストリーム間で共有されてもよい。管理されたマルチテナントストリーム管理の制御構成要素及び／または処理管理型サービスは、そのいくつかはクライアントが選択可能な、種々の適用可能なポリシーに基づき特定のストリームに使用されるノードまたは資源を動的に追加、削除、または再構成してもよい。さらに、制御構成要素はまた、様々なタイプのセキュリティプロトコル（例えば、たとえ双方のクライアントが少なくともいくつかのハードウェアとソフトウェアを共有していても、一方のクライアントのストリームアプリケーションは他方のクライアントのデータに確実にアクセスできないようにすること）の実装、課金のための資源使用状態の監視、監査またはデバッグ用に使用されるログ情報の発行、などを透明な形で行う役割を持つことができる。管理型マルチテナントサービスのクライアントの観点から、サービスが実装する制御／管理機能は大規模ストリーミングアプリケーションに対応することに伴う多くの複雑さをなくす可能性がある。一部のシナリオでは、そのようなマルチテナントサービスの顧客は、少なくともストリームに関する一部の動作の種類について資源の共有を望まないと示すことができるかもしれない。その場合、物理資源の一部は少なくとも一時的にそれらの種類の動作をシングルテナントと指定することができる（すなわち、１人の顧客またはクライアントのために実行される動作に制限する）。
種々の実施形態で、ＳＭＳ及び／またはＳＰＳの制御プレーンとデータプレーンの動作の実施に対して複数の異なるアプローチを採ることができる。例えば、制御プレーン動作に関して、いくつかの実施形態では制御サーバまたはノードの冗長グループを立ててもよい。冗長グループは複数の制御サーバを含み、あるサーバは種々のストリームに関する管理要求に応答する役割の主サーバとして指定されるが、別のサーバは現行の主サーバでの故障（または、接続問題）などトリガー条件のイベントの場合、主サーバとして引き継ぐよう指定されてもよい。他の実施形態では、ネットワークアクセス可能データベースサービスで生成された１つまたは複数のテーブルが種々のストリームの制御プレーンメタデータ（パーティションマップなど）を保存するために使用されてもよい。種々の取得、記憶または検索ノードは、データプレーン動作を要求するメタデータのいくつかのサブセットを取得することが必要な時、テーブルにアクセスすることができてもよい。異なる実施形態のＳＰＳとＳＭＳデータプレーンと制御プレーン機能の様々な態様に関する詳細は以下で説明する。ストリーム管理サービスが実装されている実施形態のいくつかでは、高いレベルのプリミティブを提供するストリーム処理サービスを実装する必要はないかもしれないことに留意されたい。他の実施形態では、ストリーム処理サービスの高いレベルのプログラムインターフェースだけが顧客の目に触れ、顧客の使用する低いレベルのストリーム管理インターフェースはクライアントに対して入手可能になされていない。
いくつかの実施形態では、ストリーム管理システムは複数の独立して構成可能なサブシステムを備え、主としてデータ記録を取得または収集する役割を持つ記録取得サブシステム、主として適用可能な持続性または耐久性方針にしたがってデータ記録内容を保存する役割を持つ記録記憶サブシステム、及び主として保存記録向けの読み出し要求に応答する役割を持つ記録検索サブシステムを含む。また、制御サブシステムは、一部の実施形態で実装されて、例えば、各取得、記憶、及び検索サブシステムの要求された数のノードを仮想サーバまたは物理サーバなど選択資源で動的に決定及び／または初期化することにより、残りのサブシステムを構成する役割を持つ１つまたは複数の管理構成要素または制御構成要素を備える。各取得、記憶、検索及び制御サブシステムはそれぞれ複数のハードウェア及び／またはソフトウェア構成要素を使用して実装され、それら構成要素は総称してサブシステムの「ノード」またはサブシステムの「サーバ」と呼ばれる。したがってＳＭＳの種々の資源は論理上、取得、記憶、検索及び制御の４つのカテゴリの１つに属すると言われる。いくつかの実施形態では、各セットの制御構成要素を他のサブシステムそれぞれに対して設定してもよく、例えば、独立の取得制御サブシステム、記憶制御サブシステム及び／または検索制御サブシステムを実装してもよい。そのような各制御サブシステムは対応するサブシステムの他のノードに使用される資源を特定する役割及び／またはクライアントまたは他のサブシステムからの管理クエリに応答する役割を持ってもよい。いくつかの実施形態では、種々のタイプのＳＭＳ及び／またはＳＰＳ機能を実行することができるノードのプールが事前に設置されて、このプールの選択されたメンバは必要に応じて新しいストリームまたは新しい処理段階に割り当てられてもよい。
ストリームのパーティション分割方針及び関連のマッピングは、例えば、異なる取得ノード、記憶ノード、検索ノード及び／または制御ノードのセット間でデータ記録のサブセットを配布するため、少なくとも一部の実施形態で実装されてもよい。例えば、特定のデータストリーム用に選択されたパーティション分割方針ならびに記録取得レート及び／または検索レートの期待などの他の要素に基づいて、制御構成要素は、取得、記憶、及び検索用にいくつのノード（例えば、プロセスまたはスレッド）を最初（すなわち、ストリーム生成時）に設定すべきかを決定し、これらのノードを仮想及び／または物理機械装置に如何にマッピングさせるかを決めてもよい。時間とともに、所与のストリームに関する作業負荷は増加または減少してよいが、作業負荷の増減は（他のトリガー条件の中で）ストリームの再パーティション分割につながる可能性がある。そのような再パーティション分割は、記録のパーティション、使用されるパーティション分割キー、パーティションの総数、取得ノードの数、記憶ノードの数、もしくは検索ノードの数、あるいは異なる物理または仮想資源上のノードの配置を決定するために使用される関数などの種々のパタメータの変更を含んでもよい。少なくともいくつかの実施形態では、以下に詳細を説明する手法を用いて、再パーティション分割をデータ記録の流れを中断することなく動的に実装することができる。異なるパーティション分割スキーム及び再パーティション分割トリガー基準は、いくつかの実施形態では、例えば、クライアント提供のパラメータまたはＳＭＳ制御ノードの発見的問題解決に基づいて、異なるデータストリームに使用されてもよい。いくつかの実施形態では、例えば、クライアントの選好、ストリームの期待されるライフタイム、または他の要因に基づいて、再パーティション分割の数及び／または頻度を制限してもよい。
複数の異なる記録取得方針とインターフェースが異なる実施形態で実装されてもよい。例えば、いくつかの実施形態では、クライアント（例えば、ＳＭＳの顧客の代わりにＳＭＳのプログラムインターフェースを呼び出すように構成される実行可能な構成要素またはモジュール）は、インライン提出インターフェースまたは参照提出インターフェースを利用してもよい。インライン提出にとって、データ記録のコンテンツまたは主要部はその実施形態の提出要求の一部に含まれてもよい。一方で、参照提出要求ではアドレス（記憶装置アドレス、データベース記録アドレスまたはＵＲＬ（Ｕｎｉｆｏｒｍ ｒｅｃｏｒｄ Ｌｏｃａｔｏｒ））が提供されて、データ記録のコンテンツまたは主要部を取得できる。いくつかの実施形態では、ハイブリッド提出インターフェースにもまた、あるいは代わりに対応して、データ記録の最初のＮバイトまでをインラインに含み、残りのバイト（もしあれば）は参照により提供される。そのような状況では、短い記録（主部がＮバイトより短い）は提出要求により完全に特定されるが、長い記録の部分は対応するアドレスから取得されなければならないことがある。
取得の間、記録の内容を特定する異なる代替手段に加えて、いくつかの実施形態では、様々な承認または重複排除に関連する取得方針も実装されてよい。例えば、一部のストリームアプリケーションでは、クライアントは各データ及びすべてのデータを確実にＳＭＳに取得してほしいと望む場合がある。大規模分散型ストリーム管理環境では、経路の途中、データプロデューサと取得ノード間で随時、パケットが紛失する、または種々の障害が発生する可能性があり、結果、一部の提出データが紛失することがあり得る。したがって、いくつかの実施形態では、肯定承認を取得サブシステムから受信するまで、記録サブミッタが１度または複数回、同じ記録を提出するということにしたがって、ＳＭＳは、１度は取得の方針を実装してもよい。通常の動作条件では、記録を一度提出すると、受信取得ノードが取得して記録を保管した後、サブミッタは承認を受信することができる。承認が紛失または遅延した場合、または記録提出要求自体が紛失した場合、最終的に承認を受信するまで、サブミッタは同じデータ記録を１度または複数回再提出してもよい。取得ノードは例えば、二重であるなしにかかわらず、サブミッタが承認を受信していれば記録は再提出されないという予想に基づいて、各提出に対して承認を発生してもよい。しかし、取得ノードは、少なくとも一部の実施形態では、同じデータ記録が複数回提出されたことを認識し、不要な重複データの新しい部数の保存を避ける役割を持つことができる。一実施形態では、１度は取得方針の少なくとも２つのバージョンに対応することができる。一方は（「少なくとも１度取得、重複不許可」、と呼んでもよい）ＳＭＳがデータ記録の重複排除の役割を持ち（すなわち１組の２回以上の提出の１つだけに応答してデータを確実にＳＭＳ記憶サブシステムに保存する）、他方は、ＳＭＳにより重複したデータ記録の保存が許可される（「少なくとも１度、重複許可」、と呼んでもよい）。少なくとも１度、重複許可のアプローチは、ストリームアプリケーションにとって有益であるかもしれず、データ記録の重複、及び／または、それ自体が重複を消去するストリームアプリケーションに対する否定的な帰結はほとんどない。ベストエフォート型取得方針など承認が提出されたすべてのデータ記録に対して必要ではない他の取得方針もまた、支持されてよい。ベストエフォート型取得方針が少なくとも一部の実施形態で実施されている場合、少しのデータ記録紛失は受け入れられてもよい。クライアントは種々の実施形態の中で種々のストリーム用にどの取得方針を使用したいかを選択してよい。
ストリーム記録の記憶に関して、少なくともいくつかの実施形態では複数の代替方針にも対応することができる。例えば、クライアントはＳＭＳが対応するいくつかの中から持続性方針を選択することができてもよく、ＳＭＳはそのような記録の記憶の態様を、保存すべき所与のデータ記録複写の数、複写に用いられるべき記憶技術のタイプ（例えば、揮発性または不揮発性ＲＡＭ、回転ディスク型記憶、ソリッドステートデバイス（ＳＳＤ）、ネットワーク接続記憶装置など）など、として管理する。例えば、クライアントがディスク型の記憶へのＮ個の複製の持続性方針を選択した場合、データ記録提出は、Ｎ部の記録の複写がＮ個の各ディスクデバイスに無事に書き込まれた時点で、初めて完了すると考えることができる。ディスク型の記憶装置が使用されている少なくともいくつかの実施形態では、ＳＭＳ記憶サブシステムは所与のパーティションに入ってくるデータ記録を、例えばディスクシークの性能への影響を避けるため、順次ディスクに書き込んでもよい。シーケンス番号は、例えば、取得時間に基づいて順序付けされた記録の検索を可能にするタイムスタンプ型技術を含む、以下で説明する種々の技術を用いてデータ記録に生成する（保存する）ことができる。所与のパーティションのデータ記録は、いくつかの実施形態では、例えば、ディスク上に近接して、他のパーティションのデータ記録と別にして、一緒に保存されてもよい。一部の実施形態では、保持の方針（クライアントまたはＳＭＳが選択する）、または重複排除時間ウィンドウの方針（いずれかの所定のデータ記録の提出後、たとえ複製が提出されても、その所定のデータ記録の複製がＳＭＳの記憶サブシステムに保存されないようＳＭＳに要求する期間を示す）の期間にしたがって、少なくとも一部のデータ記録を異なるタイプの記憶サービスにアーカイブする、及び／または所与の時間後ＳＭＳから削除することができる。そのような削除動作はここではストリーム「トリミング」と呼ぶことができる。クライアントは、いくつかの実施形態では、ストリームトリミング要求を提出してもよい。例えば、指定したデータ記録はもはや必要なく、そのためクライアントの見通しから削除してもよいことをトリミングの要求を提出してＳＭＳに知らせるか、または、はっきりと指定のデータ記録の削除を要求してよい。多数のクライアントが所与のストリームのデータ記録を消費するというシナリオでは、すべての興味を持つコンシューマがアクセスする前に、ＳＭＳは所与のデータが削除されていない、または早まってトリムされることがないことを確実にする役割を持つことができる。いくつかの実施形態では、もし所与のストリームのＮデータコンシューマがいる場合、ストリームの所与の記録Ｒを削除する前に、ＳＭＳはすべてのＮデータコンシューマがＲを読んだ、またはＲを処理したと決定するまで、待つことができる。ＳＭＳは、Ｒは消費者からの各トリミング要求に基づいて、例えば、ストリーム内でどれだけ遠くまでデータコンシューマが進んだかという各表示に基づいて、すべての消費者がＲを読んだと決定してもよい。一部の実施形態では、データコンシューマの一部のタイプ（テストに関連するアプリケーションなど）は、少なくとも小さな１つのサブセットのデータ記録の削除を、それらにアクセスしていなくても承諾することがある。したがって、少なくとも一部の実施形態では、アプリケーションはデータ削除の受諾に関して検索より前にＳＭＳに通知することができ、ＳＭＳはその通知にしたがい、削除の予定を立ててもよい。いくつかの実施形態では、例えば、データ保持方針の一部として、例えば、ストリームデータ記録が複写されるべき記憶装置のタイプ、またはそのような複写に使用される日程計画方針を示して、アーカイブ方針を実装してもよい。
少なくともいくつかの実施形態では、複数のプログラムインターフェースも記録検索のために対応されてもよい。一実施形態では、反復子型アプローチが用いられて、あるプログラムインターフェース（例、ｇｅｔＩｔｅｒａｔｏｒ）をインスタンス化のために使用し、反復子またはカーソルを、ストリームのパーティション内の指定した論理オフセットに配置してもよい（例えば、シーケンス番号またはタイムスタンプに基づき）。異なるプログラムインターフェース（ｇｅｔＮｅｘｔＲｅｃｏｒｄｓなど）は、現在の反復子の位置から初めて順次、指定された番号のデータ記録を読み込むために使用されてもよい。反復子のインスタンス化は、事実上、ストリームのパーティション内の記録検索のため、クライアントが任意のまたはランダムな開始位置を指定することができてもよい。クライアントが、そのような実施形態でランダムなアクセスパターンでデータ記録を読み出したい場合、そのクライアントは繰り返し新しい反復子を作成しなくてはならない。回転ディスク型記憶システムでは、頻繁にランダムアクセスを要求するディスクシークのためにＩ／Ｏ応答時間に与える影響が大きくなる恐れがある。したがって、ランダムより順次ストリームデータ記録を読み込むクライアントの奨励のため、少なくともいくつかの実施形態で、順次読み出しアクセスよりランダム読み出しアクセスに、異なる（例えば、高い）課金レートが課せられることがある。このように、例えば、クライアントはｇｅｔＩｔｅｒａｔｏｒの呼び出し毎にＸ通貨単位、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓを介して検索した記録毎にＹ通貨単位課金されてもよく、いくつかの実施形態では、ＸがＹより多い場合がある。代替のクライアントのインターフェースが他の動作のカテゴリ（取得など）に対応する場合、少なくともいくつかの実施形態では、代替の課金レートまたは金額は異なる可能性がある。例えば、順次読み出しよりランダム読み出しに多く課金されたように、あるクライアントは参照提出要求の方がオンライン提出要求より多く課金される可能性がある。データ記録のサイズ、書き込み対読み出しの配分、選択の持続性方針などの他の要因もまた種々の実施形態において課金に影響を与える可能性がある。
いくつかの実施形態によれば、ストリーム処理サービス（ＳＰＳ）ではクライアントが多くの処理段階を含む、複雑な処理作業を任意に指定することができ、所与の段階で実行される処理の出力がゼロ以上の他の段階で入力として使用されてもよい。パーティション分割方針（取得、保存及び検索データ記録用のＳＭＳの説明と同様）は、いくつかの実施形態では、処理作業負荷を様々な段階の複数のワーカーノード間でパーティション分割して使用してもよい。そのような一実施形態では、プログラムＳＰＳインターフェースが実装されて、例えば、クライアントが、その段階用（例えば、ストリーム用のパーティション分割方針と共に、データ記録が検索されるべき１つまたは複数のストリーム）の入力データソース、その段階で実行される処理動作、及びその段階からの出力もしくは結果送出用の記述子または仕様（例えば、異なるストリームの形で、出力が記録位置に保存されるか、ネットワーク終点に送信されるか、または１つまたは複数の処理段階に供給されるかどうか）を含むいずれの所与の段階にも様々な構成セッティングを指定できるようにしてもよい。少なくともいくつかの実施形態では、ＳＰＳ段階に指定される処理動作は冪等であってもよい。すなわち、所与の処理動作が同じ入力データで複数回実行された場合、動作の結果は、動作が一度であった場合に得られる結果と同じである。障害からのリカバリ（例えば、ＳＰＳ段階でのワーカーノード障害）は処理動作が冪等である場合、下記に詳細を説明するように単純化されてもよい。いくつかの実施形態によれば、冪等でない処理動作を一部またはすべてのＳＰＳ段階で行うことは可能である。
入力ストリームパーティション分割方針及びＳＰＳプログラムインターフェースを介して受領した処理動作の性質など少なくとも構成情報の一部に基づいて、種々の実施形態では、ＳＰＳ制御サーバはいくつのワーカーノードを、最初に、処理ワークフローの種々の段階用に設置すべきかを決定してもよい。ワーカーノードに使用される資源の実行能力（例えば、使用する仮想または物理機械装置）は、 ワーカーノードの初期数値及び配置を決定する際に考慮に入れてもよい。選択の数のワーカーノード（いくつかの実施形態では、それぞれが実行可能なスレッドまたは実行可能プロセスを含んでよい）がインスタンス化されてもよい。各ワーカーノードは、例えば、適切な入力ソースから（例えば、１つまたは複数のストリームパーティションの検索ノードから）データ記録を取得するよう構成されて、データ記録上で指定された処理動作を実行して、処理の結果を指定された出力先に送信する。さらに、いくつかの実施形態ではチェックポイントスキームが実装されて、それにしたがって、パーティション記録が順次処理されているという仮定で、所与のワーカーノードが、進行記録またはそのワーカーノードで処理されたパーティションの一部を示すチェックポイントを保存するよう構成されてもよい。例えば、ワーカーノードはいくつかの実施形態では定期的に、及び／またはＳＰＳ制御サーバからのチェックポイント要求に応答して、進行記録を持続性記憶に書き込んでもよい（例えば、Ｎ秒間に１回またはＲデータ記録の処理毎）。
進行記録はいくつかの実施形態では、ワーカーノード障害からの急速リカバリに使用されてもよい。例えば、ＳＰＳ制御サーバは様々なワーカーノードのヘルス状態を例えば、ハートビート機構を用いて及び／または資源使用率レベル（ＣＰＵ使用率、Ｉ／Ｏデバイス使用率またはネットワーク使用率レベルなど）を監視することで、長期にわたり監視してもよい。特定のワーカーノードは望ましくないまたは不健康状態にあるというＳＰＳ制御サーバによる決定に応答して、交換ワーカーノードがインスタンス化されて、特定のワーカーノードの役割を引き継いでよい。交換ワーカーノードは、交換されたワーカーノードにより保存された最新の進行記録にアクセスして、交換ワーカーノードが処理すべき１組のデータ記録を特定することができる。処理動作が冪等である実施形態では、一部の動作が繰り返された場合でも（例えば、最新の進行記録が交換ワーカーのインスタンス化よりいくらか前に書き込まれたため）、処理の全体の結果は障害及び交換によって影響を受けないであろう。いくつかの実施形態では、処理されたサブセットの所与のストリームまたはパーティションを示す進行記録の保存に加えて、ワーカーノードも蓄積したアプリケーション状況情報を保存するよう構成されてもよい。例えば、ストリーム処理ワークフローが、サービス使用基準を示すストリーミングデータ記録の解析に基づいて、特定のサービスに対するクライアントの請求額を決定する役割を持つ場合、ワーカーノードは定期的に様々なクライアントに対して決定した累積請求額を保存してもよい。
少なくともいくつかの実施形態では、ＳＰＳ制御サーバは、種々の段階の入力ストリームの動的再パーティション分割など他の行動を開始することによる作業負荷レベルの変更または検出された作業負荷の不均衡（例えば、あるパーティションの取得レートが他に比べて異様に高い場合）など種々の他のトリガーに応答するよう構成されて、所与の段階で所与のパーティションに割り当てられるワーカーノードの数を変更し、より高い能力のワーカーノードを一部の段階に割り当て、またはワーカーノードをある物理資源から異なる性能能力を備える他の物理資源へ移動することができる。いくつかの実施形態では、例えば、ベストエフォート型のリカバリ方針が所与の段階用にはチェックポイント型のリカバリ方針より実装されるＳＰＳ制御サーバによる決定に応答して、上記に記載の型の進行記録が、少なくともいくつかのＳＰＳ段階のワーカーノードによっては保存されることがないかもしれない。そのようなベストエフォート型のリカバリ方針のいくつかの実施形態では、交換ワーカーノードは新しいデータ記録を受信したように単純に処理するだけで進行記録へのアクセスを要求することはない可能性がある。いくつかの実施形態では、クライアントがＳＰＳ段階でベストエフォート型リカバリ方針を実装したい場合、その段階で実施されるストリーム処理動作は冪等である必要はない。冪等でない処理動作がＳＰＳ段階でのストリーム記録で実行されるいくつかの実施形態では、チェックポイント型のリカバリに対応できないが、ベストエフォート型のリカバリなどの異なるリカバリスキームを用いることができる。少なくとも一実施形態では、冪等であるストリーム処理動作だけがＳＰＳ段階で許可されてもよい。
一部のストリームのデータ記録は、要注意または機密扱いの情報を含み、またはＳＰＳ段階で実行される処理動作は独自のアルゴリズムを使用することを含んでいるので、競合にそれを見つかることは問題になる恐れがある。このようにクライアントは特にクライアント自身がすべてを制御していないプロバイダ網データセンタにある資源を用いて動作を実行する場合に、様々な種類のストリーム管理及び処理動作の安全を懸念している。インターネット及び／または分散型クライアントのセットに対する他のネットワークを介してアクセス可能な１つまたは複数のネットワークアクセス可能サービス（種々のタイプのクラウド型データベース、コンピューティングまたは記憶サービスなど）を提供する会社または公共部門組織などの団体によるネットワーク設立は、ここではプロバイダ網と呼んでもよい。いくつかの実施形態では、クライアントは、それらの複数のデータストリーム用に複数のセキュリテティ関連のオプションの中から選択することができてもよい。上記に記載のように、組み合わせたＳＰＳとＳＭＳの組み合わせ構成は、ＳＭＳ及び／またはＳＰＳ用の制御ノード、ＳＭＳ取得ノード、ＳＭＳ記憶ノード、ＳＭＳ検索ノード、及びＳＰＳ処理またはワーカーノードなど、複数の異なる機能カテゴリに属するノードを備えることができる。クライアントが入手可能なセキュリティ関連の選択は、いくつかの実施形態では、種々のタイプのノードの配置または位置用のオプションを含んでもよい。例えば、一実施形態では、ストリーム記録が最初はプロバイダ網に配置された資源を用いて収集及び／または保存されたとしても、クライアントは、１つまたは複数のストリームワークフローの処理段階用のＳＰＳワーカーノードをクライアント自身の設備上に配置されたコンピューティング装置で実装するよう要求する可能性がある。そのような配置の要求に答えて、所与のストリームの異なる機能のカテゴリのノードは異なるセキュリティの特性またはプロファイルを備えるそれぞれの資源のセットで、インスタンス化されてもよい。
資源のセットは、異なる実施形態では、例えば、物理的位置、使用される物理的セキュリティプロトコル（例えば、誰が資源への物理的アクセスを有するか）、ネットワーク隔離レベル（例えば、資源のネットワークアドレスが様々な団体の目に見える範囲）、マルチテナント機能対単一テナント機能など、様々なセキュリティ関連の特性が互いに異なる可能性がある。一部の実施形態では、クライアントはプロバイダ網内に隔離仮想網（ＩＶＮ）を設立し、所与のクライアントがクライアントのＩＶＮ内に含まれる様々なデバイスのネットワーキング構成を、実質制御することができる。特に、クライアントは、それらのＩＶＮ内の様々なサーバまたは計算事例に割り当てるネットワークアドレス（例えばインターネットプロトコルまたはＩＰアドレス）へのアクセスを制限することができる可能性がある。そのような実施形態では、クライアントはＳＭＳまたはＳＰＳノードの所定のサブセットを指定のＩＶＮ内でインスタンス化することを要求してもよい。仮想化インスタンスホスト（一般にマルチテナントホストとして構成されてもよい）などのプロバイダ網資源がＳＭＳまたはＳＰＳノードの種々のカテゴリ用に使用されている実施形態では、クライアントは、数セットのノードを、そのクライアントだけに属する事例を実装することに限られるインスタンスホストにインスタンス化するよう要求してもよい（すなわち、あるＳＭＳまたはＳＰＳのノードは単一テナントホストとして構成されるインスタンスホストで実装されてもよい）。
いくつかの実施形態では、他のセキュリティ関連のオプションとして、クライアントは、特定のストリームのデータ記録が暗号化された後で、ネットワークリンクに送信されることを要求してもよい。例えば、暗号化された後で、取得サブシステムと記憶サブシステム間で、記憶サブシステムと検索サブシステム間で、検索サブシステムとＳＰＳワーカーノード間で、及び／またはワーカーノードとＳＰＳ出力先間で、ＳＭＳで取得される。クライアントは使用される暗号化アルゴリズムをいくつかの実施形態では、指定してもよい。一実施形態では、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）またはＳＳＬ（ｓｅｃｕｒｅ ｓｏｃｋｅｔｓ ｌａｙｅｒ）プロトコルがデータ記録送信及び／またはＳＰＳ処理結果を送信するために使用されてもよい。
データストリーム概念及び概要
図１は少なくともいくつかの実施形態による、データストリームの概念の簡略化した概観である。表示の通り、ストリーム１００は、ＤＲ１１０Ａ、１１０Ｂ、１１０Ｃ、１１０Ｄ及び１１０Ｅなどの複数のデータ記録（ＤＲ）１１０を含む。データプロデューサ１２０Ａ及び１２０Ｂなどの１つまたは複数のデータプロデューサ１２０（データソースと言ってもよい）は、書き込み動作１５１をストリーム１００のデータ記録の内容を生成するため実行してもよい。複数の異なるタイプのデータプロデューサが、例えば、携帯電話またはタブレットコンピュータのアプリケーション、センサアレイ、ソーシャルメディアプラットフォーム、ログアプリケーションまたはシステムログ構成要素、種々の監視代理人など異なる実施形態でデータのストリームを生成してもよい。１つまたは複数のデータコンシューマ１３０（データコンシューマ１３０Ａ及び１３０Ｂなど）は、読み出し動作１５２を実行してデータプロデューサ１２０が生成したデータ記録のコンテンツにアクセスする。データコンシューマ１３０は例えば、いくつかの実施形態では、ストリーム処理段階のワーカーノードを備える。
少なくともいくつかの実施形態では、ＳＭＳに保存されている所与のデータ記録１１０は、データ部分１０１（例えば、ＤＲ１１０Ａ、１１０Ｂ、１１０Ｃ、１１０Ｄ及び１１０Ｅそれぞれのデータ部分１０１Ａ、１０１Ｂ、１０１Ｃ、１０１Ｄ及び１０１Ｅ）及びシーケンス番号ＳＮ１０２（例えば、ＤＲ１１０Ａ、１１０Ｂ、１１０Ｃ、１１０Ｄ及び１１０Ｅそれぞれの、ＳＮ１０２Ａ、１０２Ｂ、１０２Ｃ、１０２Ｄ及び１０２Ｅ）を備えてもよい。シーケンス番号１０２は順序を示していて、図示した実施形態ではＤＲをストリーム管理システム（またはストリーム管理システムの特定のノードで）で受信することができる。データ部分１０１は、いくつかの実施形態では、変更不能な未解釈のバイトのシーケンスを含んでもよい。すなわち、書き込み動作１５２が完了したら、ＤＲの内容は、書き込みの結果、ＳＭＳにより変更できないとして生成されて、また一般にＳＭＳはデータの意味に気付くことができない。いくつかの実施形態では、所与のストリーム１００の異なるデータ記録は異なるデータ量を含んでもよいが、他の実施形態では、所要のストリームのすべてのデータ記録は、同じサイズの場合がある。少なくともいくつかの実施では、ＳＭＳのノード（例えば、取得サブシステムのノード及び／または記憶サブシステムのノード）は、ＳＮ１０２を生成する役割を持つことができる。下記でさらに詳細を説明するように、データ記録のシーケンス番号は常に連続していなくてもよい。ある実施形態では、クライアントまたはデータプロデューサ１２０は、書き込み要求の一部として、対応するデータ記録に使用される最小のシーケンス番号を示してもよい。一部の実施形態では、データプロデューサ１２０は、例えば、そこからデータ部分が取得できる記憶デバイスのアドレスまたはネットワークアドレス（ＵＲＬなど）を与えることで（例えば、デバイスの名前及びデバイス内のオフセットなど）、データ記録のデータ部分へのポインタ（またはアドレス）を含む書き込み要求を送付してもよい。
ストリーム管理サービスは、様々な実施形態で、データプロデューサ１２０からデータを受領し、データを保存し、データコンシューマ１３０が１つまたは複数のアクセスパターンでデータにアクセスできるようにする役割を持つことができる。少なくともいくつかの実施形態では、ストリーム１００はパーティション分割または「シャード分割」により、データ記録の受信、保存及び検索による作業負荷を配分してもよい。そのような実施形態では、パーティションまたはシャードは、１つまたは複数のデータ記録及びパーティションに基づき特定することができるデータ記録を取得、保存または検索する特定のノードの属性に基づき、入ってくるデータ記録１１０用に選択されてもよい。いくつかの実施形態では、データプロデューサ１２０は各書き込み動作でパーティション分割の属性として働くことのできる明示的パーティション分割キーを発行してもよく、そのようなキーをパーティションの識別子に対しマップすることができる。他の実施形態では、ＳＭＳは、データプロデューサ１２０と一致する要素、データプロデューサのＩＰアドレス、または提出のデータのコンテンツに基づいて、パーティションＩＤを推定することができる。データストリームがパーティション分割されているいくつかの実施形態では、シーケンス番号はパーティション毎に割り当てられていてもよい。例えば、シーケンス番号が特定のパーティションのデータ記録を受領した順番を示すが、２つの異なるパーティションにあるデータ記録ＤＲ１及びＤＲ２のシーケンス番号はＤＲ１及びＤＲ２を受信した相対的順序を示す必要がないかもしれない。他の実施形態では、シーケンス番号はパーティションに基づくより、ストリームワイドに割り当てられ、その結果、データ記録ＤＲ１に割り当てられたシーケンス番号ＳＮ１がデータ記録ＤＲ２に割り当てられたＳＮ２より低い場合、ＤＲ１とＤＲ２が属するパーティションに関係なく、ＤＲ１はＳＭＳによりＤＲ２より早く受領されたことを意味する。
ＳＭＳに対応する検索または読み出しインターフェースは、種々の実施形態で、データコンシューマ１３０がデータ記録に順次及び／またはランダムな順序でアクセスすることを可能にする。一実施形態では、１組の反復子型読み出しアプリケーションプログラムインターフェース（ＡＰＩ）に対応することができる。データコンシューマ１３０は、反復子の初期位置が指定したシーケンス番号及び／またはパーティション識別子によって示される、データストリーム用の反復子を取得する要求を提出してもよい。イニシエータをインスタンス化した後、データコンシューマはデータ記録をストリーム内またはパーティション内の初期位置から初めて順次読み出す要求を提出してもよい。データコンシューマがデータ記録をあるランダムな順序で読み出したい場合、そのような実施形態で各読み出しのために新しい反復子をインスタンス化する必要がある場合がある。少なくともいくつかの実施形態では、所与のパーティションまたはストリームのデータ記録はディスク型記憶装置に、ディスクのシークを避ける順次書き込み動作を通常用いて、シーケンス番号の順で書き込んでよい。順次読み出し動作もディスクシークのオーバーヘッドを避けるであろう。したがって、いくつかの実施形態では、データコンシューマは価格インセンティブにより、ランダムな読み出しより順次読み出しを好んで実施する場合がある。例えば、反復子のインスタンス化などのランダムアクセスの読み出し動作は順次アクセス読み出し動作よりも課金レートにより高く結びつく可能性がある。
例示のシステム環境
図２は、少なくともいくつかの実施形態による、ストリーム処理段階の収集を含むストリーム管理システム（ＳＭＳ）及びストリーム処理システム（ＳＰＳ）の種々のサブコンポーネント間のデータの流れの概観である。図示の通り、ＳＭＳ２８０は取得サブシステム２０４、記憶サブシステム２０６、検索サブシステム２０８及びＳＭＳ制御サブシステム２１０を備えてもよい。各ＳＭＳサブシステムは１つまたは複数のノードまたはコンポーネントを含み、下記に説明する通り、それらは、例えば、プロバイダ網（またはクライアント所有またはサードパーティの設備）の種々の資源でインスタンス化される各実行可能スレッドまたは実行可能処理を用いて実装されてもよい。取得サブシステム２０４のノードは、ストリーム用に使用されるパーティション分割方針に基づき、データプロデューサ１２０（１２０Ａ，１２０Ｂ及び１２０Ｃなど）から特定のデータストリームのデータ記録を取得するよう構成する（例えば、ＳＭＳ制御サブシステム２１０のノードによって）ことができる。そして、各取得ノードは受領したデータ記録を対応する記憶サブシステム２０６のノードに渡すことができる。記憶サブシステムのノードはデータ記録を種々のタイプの任意の記憶デバイスにストリーム用に選択された持続性方針にしたがって保存することができる。検索サブシステム２０８のノードは、ＳＰＳ２９０のワーカーノードなどのデータコンシューマからの読み出し要求に答えてもよい。ＳＰＳ２９０の段階２１５Ａ、２１５Ｂ、２１５Ｃ、２１５Ｄなどのストリーム処理段階２１５は、ＳＰＳ制御サブシステム２２０の助けを借りて設定することができる。各段階２１５は、ＳＰＳ制御サブシステム２２０により構成された、１つまたは複数のワーカーノードを含み、受領したデータ記録毎に１組の処理動作を実行することができる。図示の通り、いくつかの段階２１５（２１５Ａ及び２１５Ｂ）はデータ記録を直接ＳＭＳ２８０から受領するが、他（２１５Ｃ及び２１５Ｄ）は入力を他の段階から受領してもよい。複数のＳＰＳ段階２１５はいくつかの実施形態では、並行して動作することができる。例えば、異なる処理動作を段階２１５Ａ及び２１５Ｂの同じストリームから引き出したデータ記録に同時に実行することができる。特定のストリーム用に図２で示したものと同様の各サブシステム及び処理段階を他のストリーム用にもインスタンス化してもよいことに留意されたい。
少なくともいくつかの実施形態では、図２に示すサブシステム及び処理段階のノードの少なくとも一部は、プロバイダ網の資源を用いて実装されてもよい。上記で留意を促したように、１組の分散したクライアントに対してインターネット及び／または他のネットワークを介してアクセス可能な１つまたは複数のネットワークアクセス可能サービス（種々のタイプのクラウド型データベース、コンピューティングまたは記憶サービス）を提供する会社または公共部門組織などの団体によるネットワークの設立は、ここではプロバイダ網と呼んでもよい。サービスのいくつかは、より高いレベルのサービスを構築するために使用することができる。例えば、コンピューティング、記憶またはデータベースサービスはストリーム管理サービスまたはストリーム処理サービス用の基礎的要素として使用することができる。少なくともプロバイダ網のコアサービスのいくつかは、「インスタンス」と呼ばれるクライアント使用のサービス単位でパッケージ化することができる。例えば、仮想化コンピューティングサービスでインスタンス化された仮想機械装置は「コンピュートインスタンス」を表し、記憶サービスによりインスタンス化されたブロックレベルのボリュームなどの記憶デバイスは「記憶インスタンス」と呼んでもよく、データベース管理サーバは「データベースインスタンス」と呼んでもよい。種々のネットワークアクセス可能なプロバイダ網の数単位のサービスが実装されるサーバなどのコンピューティングデバイスは「インスタンスホスト」または単純に「ホスト」とここでは呼んでもよい。取得サブシステム２０４のノード、記憶サブシステム２０６、検索サブシステム２０８、ＳＭＳ制御システム２１０、処理段階２１５及び／またはＳＰＳ制御サブシステム２２０は、いくつかの実施形態では、複数のインスタンスホスト上に様々なコンピュートインスタンスで実行するスレッドまたはプロセスを備えることができる。所与のインスタンスホストはいくつかのコンピュートインスタンスを備え、特定のインスタンスホストのコンピュートインスタンスの集合は１つまたは複数のクライアントの種々の異なるストリーム用ノードを実装するために使用することができる。記憶インスタンスはいくつかの実施形態では、種々のストリームのデータ記録を保存するために、またはストリーム処理段階の結果の送り先として使用されてもよい。徐々に、制御サブシステムのノードは、例えば、ノードの追加、削除、プロセス、コンピュートインスタンもしくはインスタンスホストへのノードのマッピングの変更、または所与のストリームの再パーティション分割などによる、種々のトリガー条件に応答して他のサブシステムの個体数を動的に修正することができるが、同時に、図１５及び図１６を参照して以下に記載の通り、受領、保存、及びデータ記録処理を継続して行うことができる。
プロバイダ網資源がストリーム関連の動作に使用されている実施形態の文脈では、「クライアント」という言葉は、所与の通信の資源または目的先として使われた時、任意のコンピューティングデバイス、プロセス、ハードウェアモジュールまたはソフトウェアモジュールのことを言ってもよく、それらは、１つの団体（複数のユーザまたは単一のユーザを有する組織、グループなど）に所有され、管理され、または配分されていて、その団体は少なくともあるプロバイダ網のネットワークアクセス可能サービスにアクセスし、また利用することができる。あるサービスのクライアントは自身を実装して他のサービスの資源を使用することができる。例えば、ストリームデータコンシューマ（ストリーム管理サービスのクライアント）はコンピュートインスタンス（仮想化したコンピューティングサービスで提供される資源）を備えることができる。
所与のプロバイダ網は、物理及び／または仮想化コンピュータサーバ、１つまたは複数の各記憶デバイスを備える記憶サーバ、ネットワーキング装置など様々な資源プールをホストし、プロバイダが提供するインフラストラクチャ及びサービスを実装し、構成し、また配布するために必要な多数のデータセンタ（いろいろな地域のいたるところに分散することができる）を含んでもよい。いくつかの異なるハードウェア及び／またはソフトウェア構成要素は、その一部は異なるデータセンタまたはいろいろな地域でインスタンス化され、または実行されて、様々な実施形態で、全体として各サービスを実行するため使用されることができる。クライアントは、クライアントが所有し、クライアントが管理する前提の、またはプロバイダ網の外のデータセンタに配置されたデバイスから、及び／またはプロバイダ網の中のデバイスから、プロバイダ網で資源及びサービスと相互に作用し合うことができる。プロバイダ網は、１つの実施例環境として働き、ここで説明する多くのストリーム管理及び処理技術が実装されてもよいが、それらの技術はプロバイダ網だけでなく他のタイプの分散型システムにも、例えば、それ独自のアプリケーション用に単一の法人が運営する大規模分散型環境などに適用することができる。
プログラム的インターフェース例
上述の通り、少なくともいくつかの実施形態では、ＳＰＳはＳＭＳプログラムインターフェースを利用して、ＳＰＳクライアントがより簡単に使用できるより高いレベルの機能を作ることができ、それは様々なストリーム型アプリケーション用に所望のビジネスロジックを実装するものである。ＳＰＳとＳＭＳの機能の違いを検討すると、類比が助けとなる。ＳＰＳの機能は、一般に、Ｃ＋＋などのより高いレベルの言語内のプログラム言語の構造体に例えることができるが、ＳＭＳの機能は一般にプログラム言語の構造体をコンパイラで翻訳するアセンブリ言語命令に例えられる。アセンブリ言語命令を直接用いて同じ動作を実行することができる可能性があるが、より高いレベルの言語でプログラミングすることは通常多くのカテゴリの顧客またはユーザにとりより簡単かもしれない。同様に、ＳＭＳにより提供される基本要素を用いて種々のアプリケーションを実装することができるかもしないが、ＳＰＳの特徴を用いてそうする方が簡単かもしれない。ＳＰＳ処理動作（データレコードで実施される冪等である処理動作など）は、ストリーム記録のデータ内容に実装してもよいが、ＳＭＳの動作は記録自体を取得、保存、また検索するために実行されて、通常記録の中身を検討しない。図３は、少なくともいくつかの実施形態による、ＳＭＳとＳＰＳで実装することができるプログラムインターフェースのそれぞれのセットの例示である。いくつかの異なるアプリケーションプログラミングインターフェース（ＡＰＩ）をＳＭＳ及びＳＰＳの両方に実施例として示す。例示されたＡＰＩはいずれの所定の実施においても対応するすべてを網羅するリストと考えるものではなく、またいくつかの図示したＡＰＩはある所定の実施形態では対応しないかもしれない。
矢印３５０が示すように、ＳＰＳクライアント３７５はＳＰＳプログラムインターフェース３０５を呼び出して、処理段階を構成することができる。種々のタイプのＳＰＳプログラムインターフェース３０５は異なる実施形態で実装されてもよい。例えば、ｃｒｅａｔｅＳｔｒｅａｍＰｒｏｃｅｓｓｉｎｇＳｔａｇｅ ＡＰＩにより、クライアントが指定した入力ストリーム用の新しい処理段階２１５の構成を要求することができる。その結果、段階のワーカーノードは、インターフェースの呼び出しで指定される１組の冪等である動作を実行し、結果を出力配分記述子または方針に示される目的先へ送出するようそれぞれ構成される。ｃｒｅａｔｅＳｔｒｅａｍＰｒｏｃｅｓｓｉｎｇＳｔａｇｅ ＡＰＩの一部のバージョンまたは同等物で、クライアントは、入力ストリームの生成を要求してもよく、他のバージョンでは入力ストリームは処理段階が生成される以前に生成されなければならないかもしれない。リカバリ方針はワーカーノード用に指定されてもよく、例えば、チェックポイント型リカバリ技術を使うか、またはベストエフォート型リカバリ技術が好ましいかを示すことができる。いくつかの実施形態では、ｉｎｉｔｉａｌｉｚｅＷｏｒｋｅｒＮｏｄｅ ＡＰＩに対応して、特定の段階でワーカーノードの明示的インスタンス化を要求することができる。チェックポイント型リカバリが実装される実施形態では、ｓａｖｅＣｈｅｃｋｐｏｉｎｔ ＡＰＩが支持されて、進行記録がワーカーノードで生成されることをクライアントが要求することができるかもしれない。
異なる実施形態では、ｓｅｔＯｕｔｐｕｔＤｉｓｔｒｕｂｕｔｉｏｎ ＡＰＩなど様々なタイプのＳＰＳ出力管理ＡＰＩに対応するので、そのようなＡＰＩにより、特定の段階で実行される処理動作の結果及び新しく生成されるストリームのために用いる特定のパーティション分割方針を用いて１つまたは複数のストリームが生成されるとクライアントは示すことができる。いくつかの処理段階は主として再パーティション分割用に構成されてもよい。例えば、記録属性セットＡ１に基づき、データ記録をＮ１パーティションにマップするあるパーティション分割機能ＰＦ１を、入力ストリームＳ１用に使用してもよく、処理段階は、異なるパーティション分割機能ＰＦ２を実装するために使用されてこの同じデータ記録をＮ２パーティションにマップしてもよい（異なる属性セットＡ２または同じ属性セットＡ１を用いて）。ｌｉｎｋＳｔａｇｅｓなどのいくつかのＳＰＳ ＡＰＩは、複数の段階を備える任意のグラフ（例えば、有向非巡回グラフ）を構成するために使用されてもよい。一部の実施形態では、サードパーティ、オープンソースストリーム処理フレームワークまたはサービスへのコネクタに対応することができる。そのような一実施形態では、ＳＰＳ段階が、データ記録（例えば、段階で実施される処理動作の結果を適切にフォーマットして）を既存のサードパーティまたはオープンソースシステムによる消費用に準備するために使用されてもよい。ｃｒｅａｔｅＴｈｉｒｄＰａｒｔｙＣｏｎｎｅｃｔｏｒなどのＡＰＩは、図示の実施形態では、そのようなコネクタを設定するために使用されてもよく、またＳＰＳ段階の結果をサードパーティのシステムと互換性がある形式へ適切に変換することは、ｃｒｅａｔｅＴｈｉｒｄＰａｒｔｙＣｏｎｎｅｃｔｏｒの革新の結果としてインスタンス化された１つまたは複数のコネクタモジュールにより実施されてもよい。
ＳＰＳはＳＭＳ ＡＰＩ ３０７を呼び出して、矢印３５２で示すように少なくともその機能のいくつかを実行してもよい。図示の実施形態では、ＳＭＳ ＡＰＩ ３０７は、例えば、ｃｒｅａｔｅＳｔｒｅａｍ及びｄｅｌｅｔｅＳｔｒｅａｍ（それぞれストリームを生成し削除する）とｇｅｔＳｔｒｅａｍＩｎｆｏ（所与のパーティションの役割を持つ種々のタイプのノードのネットワークアドレスなど、ストリーム用にメタデータを取得する）を含んでもよい。ｐｕｔＲｅｃｏｒｄインターフェースはデータ記録を書き込むために使用されて、同時にｇｅｔＩｔｅｒａｔｏｒ及びｇｅｔＮｅｘｔＲｅｃｏｒｄｓインターフェースは、それぞれ非連続ならびに連続読み出しのために使用されてもよい。ｒｅｐａｒｔｉｔｉｏｎＳｔｒｅａｍインターフェースは、いくつかの実施形態では、特定のストリームの動的再パーティション分割を要求するために使用されてもよい。そのようにしたいクライアント３７０は、矢印３５４が示す通り、ＳＭＳ ＡＰＩ ３０７を直接呼び出してもよい。すでに説明の通り、種々の他のＳＭＳ及び／またはＳＰＳ ＡＰＩ は、他の実施形態でも実装されてよいが、図３に示したＡＰＩのいくつかは、一部の実施形態では実装することができない。
様々な実施形態では、ＡＰＩ以外のプログラムインターフェースもまた、あるいは代わりにＳＰＳまたはＳＭＳ用に実装されてもよい。そのようなインターフェースはグラフィカルユーザインターフェース、ウェブページまたはウェブサイト、コマンドラインインターフェースなどを含んでもよい。いくつかのケースでは、ウェブベースのインターフェースまたはＧＵＩは基礎的要素としてＡＰＩを使用してもよく、例えば、ウェブベースの相互作用は、ＳＭＳまたはＳＰＳの制御構成要素で１つまたは複数のＡＰＩを呼び出すことになってもよい。図４は、いくつかの実施形態による、ＳＰＳクライアントがストリーム処理段階のグラフを生成することができるよう実装されてもよいウェブベースのインターフェースの実施例を示す。図示の通り、インターフェースはメッセージ領域４０２、グラフメニュー領域４０４及びグラフデザイン領域４０３を備えるウェブページ４００を備える。
ユーザはメッセージ領域４０２でストリーム処理グラフの構造に関する一般的手順と同様にストリームの概念及び基本要素についてより学ぶために使用可能なリンクを得ることができる。いくつかのグラフィカルアイコンをメニュー領域４０４でストリーム処理グラフのツールセットの一部として得ることができる。例えば、クライアントは種々のＳＰＳ処理段階の入力または出力として、持続性ストリーム４５１、一時的ストリーム４５２、またはサードパーティ処理環境へのコネクタ４５３を示すことが許されてもよい。ウェブベースのインターフェースが実装されるＳＰＳ／ＳＭＳに関して、持続性ストリーム４５１はストリームとして規定され、そのデータ記録は、ディスク、非不揮発性ＲＡＭまたはＳＳＤなどの持続記憶デバイスに保存されてもよく、一時的ストリーム４５２はデータ記録が持続性記憶デバイスに保存される必要がないものと規定されてもよい。一時的ストリームは、例えば、ＳＰＳ段階の出力から生成されてもよく、ＳＰＳ段階はベストエフォート型リカバリ方針が実装される異なるＳＰＳ段階による入力として消費されるものと期待される。
ＳＰＳグラフ作成ウェブページ４００の例では２つのタイプの処理段階が支持される。それらは、チェックポイント型ワーカーノードリカバリが用いられる段階４５５（例えば、各ワーカーノードは進行記録を時々保存し、特定のワーカーノードで障害が発生した場合、交換ノードが故障したノードの進行記録を参照し、処理を始めるデータ記録を決定する）、及びベストエフォート型リカバリが用いられる段階４５６（例えば、交換ワーカーノードは進行記録を参照せず、単純に受領したように新しいデータ記録の処理を開始する）である。各段階で実行される処理動作に関する詳細には、メッセージ領域４０２の手順で示すように、グラフ構造領域４０３の対応するアイコンをクリックして入ることができる。ストリーム、コネクタ及び処理段階のアイコンに加えて、メニュー領域４０４はまた、サードパーティまたは外部ストリーム処理システムを示すアイコンタイプ４５９、及び資源が処理段階に使用されているプロバイダ網で実装されてもよい記憶サーバのノードを示すアイコンタイプ４６０を含む。
図４で示すシナリオの例では、クライアントは４１２，４１５及び４１６の３つの処理段階を備えるグラフ４０５をグラフデザイン領域４０３に作成している。処理段階４１２はチェックポイント型リカバリを用いるよう構成されて、持続性ストリーム４１１を入力として使用する。出力または段階４１２での処理結果は２つの宛先に、段階４１５の入力を形成する異なる持続性ストリーム４１３の形式と段階４１６の入力を形成する一時的ストリーム４１４の形式で送信される。段階４１５と４１６は両方ともベストエフォート型リカバリ方針をそのワークノードに用いる。段階４１５の出力は、一時的ストリームの形式で記憶サービスノード４１９へ送信される。段階４１５の出力はコネクタ４１７を介してサードパーティ処理システム４１８へ送信される。「グラフ保存」ボタン４２０は処理段階グラフの図示を、例えば、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎａｔａｔｉｏｎ）、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）またはＹＡＭＬなどの任意に適切な形式で保存するために使用することができる。任意の複雑な処理作業フローは、種々の実施形態では、図４に示すものと同様のツールを使用して作成することができる。そのようなツールを用いて生成された作業フローはその後作動されて、例えば、図４の段階４１２などの処理段階用データ記録を取得するために、ＳＭＳ ＡＰＩを呼び出しできるようになり、ｇｅｔＩｔｅｒａｔｏｒ及び／またはｇｅｔＮｅｘｔＲｅｃｏｒｄｓインターフェースは、ストリーム４１１上で呼び出すことができるようになる。
図５は、少なくともいくつかの実施形態によれば、ＳＭＳで実装することができるプログラム記録提出インターフェース及び記録検索インターフェースの実施例を図示したものである。図示されたＤＲ１１０Ｋ及び１１０Ｑなどのデータ記録は、図示の実施形態では、種々のタイプのプログラム取得インターフェース５１０を介してＳＭＳへ提出することができる。ＤＲ１１０はいくつかの実施形態では４つのタイプの要素を備えることができる。すなわち、５０１Ａ（ストリームＳ１用）、５０１Ｂ（ストリームＳ２用）、データまたは記録の主要部の表示、オプショナルパーティションキー５０４（５０４Ａまたは５０４Ｂ）、及びオプショナル配列優先表示５０６（配列優先表示５０６Ａ及び５０６Ｂ）などのストリーム識別子である。データ自体はいくつかのデータ記録のインラインで与えられてもよく（例えば、ＤＲ１１０Ｋのインラインデータ５０２）、同時に他のデータ記録用には、ポインタまたはアドレス５０３を与えて、ＳＭＳに対してネットワークアクセス可能位置を表示する（またはネットワーク転送を必要としないローカルデバイスのアドレス）。一部の実施形態では、所与のストリームがインライン及び参照（アドレス型）データ記録提出の両方を支持してもよい。その他の実施形態では、所与のストリームはデータプロデューサを必要とするが、すべてのデータをインラインまたは参照で供給できる。いくつかの実施形態では、データ記録提出は記録に使用されるパーティション識別子を含んでもよい。
入ってくるデータ記録１１０は、図示の実施形態では、パーティション分割方針に基づいて、各取得及び／または記憶ノードへ向けることができる。同様に、記録検索もパーティションベースで、例えば、１つまたは複数の検索ノードは、所与のパーティションの記録宛ての読み出し要求に応答するよう指定されてもよい。いくつかのストリーム用に、データプロデューサは、各データ記録書き込み要求を有する明示のパーティションキーを与えるよう要求される場合がある。他のストリーム用には、ＳＭＳはパーティション分割スキームにしたがい、データ記録を送出することができる。パーティション分割スキームは、明示的に供給されたパーティションキー以外のメタデータまたは属性に依存して、例えば、提出データプロデューサに属する識別情報をパーティションキーとして使用することができる、または提出データプロデューサのＩＰアドレスの一部またはすべてを使用することができる、または提出されたデータの一部を使用することができる。いくつかの実施形態では、例えば、ハッシュ関数をパーティションキーに適用して、１２８ビットの整数など所定の大きさの整数値を取得することができる。その大きさ（例えば、０から２の１２８乗−１）の正の整数の総範囲は、Ｎ個の連続サブ範囲に分けることができ、各サブ範囲はそれぞれのパーティションを表す。したがって、そのような実施例では、データ記録用に決定したまたは供給されたいずれの所与のパーティションキーも、対応する１２８ビット整数に対してハッシュされて、その整数が属する１２８ビット整数の連続サブ範囲はデータ記録が属するパーティションを示すことができる。パーティション分割方針とその使用についてのさらなる詳細は以下図１５に関して説明する。
図５に示す、特定のパーティションのデータ記録を取得または承諾し、データ記録を保存し、また特定のパーティションに対する読み出し要求に応答する役割を持つ１組のノードは、総称してパーティション用のＩＳＲ（取得、記憶及び検索）ノードと呼ばれる。Ｓｊ−Ｐｋの表記はストリームＳｉのｋ番目のパーティションを示すために使用される。図示の実施形態では、ＩＳＲノード５２０Ａは、パーティションＳ１−Ｐ１の取得、保存及び検索記録用に構成され、ＩＳＲノード５２０ＢはパーティションＳ１−Ｐ２の記録用に設定され、ＩＳＲノード５２０ＣはパーティションＳ１−Ｐ３の記録用に設定され、ＩＳＲノード５２０ＫはパーティションＳ２−Ｐ１の記録用に設定され、ＩＳＲノード５２０ＬはパーティションＳ２−Ｐ２の記録用に設定される。いくつかの実施形態では、取得サブシステム、記憶サブシステムまたは検索サブシステムの所与のノードは複数のパーティション（または複数のストリームの複数のパーティション）のデータ記録を扱うよう構成されてもよい。いくつかの実施形態では、所与のストリームの単一のパーティションの記録は、複数のノードによって取得され、保存され、または検索されてもよい。所与のパーティションＳｊ−Ｐｋ用に指定された取得ノードの数は、少なくともいくつかのケースでは、異なるパーティションＳｊ−Ｐ１用に指定された取得ノードの数と違ってもよく、またＳｊ−Ｐｋ用に指定された記憶ノードの数及び／またはＳｊ−Ｐｋ用に指定された検索ノードの数と異なってもよい。取得及び／または検索に関して、ＳＭＳ制御ノードは、いくつかの実施形態では、ＡＰＩ（ｇｅｔＳｔｒｅａｍＩｎｆｏなど）を実装して、クライアントがどのノードがどのパーティションを受け持つか決定できるようにしてもよい。データ記録とパーティション間及びパーティションとＩＳＲノード（または制御ノード）間で構成されたマッピングは、下記の動的再パーティション分割に関する検討で説明するように、時間とともに修正されてもよい。
いくつかの実施形態では、いくつかの異なるプログラムインターフェース５８０が所与のパーティションからストリームデータ記録を検索するまたは読み出すだめに実装されてもよい。図５に示すように、いくつかの検索インターフェース５８１は、ｇｅｔＩｔｅｒａｔｏｒ（反復子のインスタンスを作成するまたは指定されたシーケンス番号を有するデータ記録をカーソルが置かれた場所で読み出しするまたはカーソルの後で読み出しする）またはｇｅｔＲｅｃｏｒｄ（指定されたシーケンス番号を有するデータ記録を読み出すこと）など、非順次アクセスのため実装されてもよい。他の検索インターフェース５８２は、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓ（Ｎ個の記録が反復子の現在の位置から、小さいシーケンス番号から順に読み出されることを要求するインターフェース）などの順次の検索のために実装されてもよい。回転ディスク型記憶システムでは、すでに述べた通り、順次Ｉ／Ｏが多くの場合、ランダムＩ／Ｏよりずっと効率的かもしれない。というのも要求されるディスクヘッドシークのＩ／Ｏ当たり平均数は通常ランダムＩ／Ｏ用より順次Ｉ／Ｏ用が圧倒的に低いからである。多くの実施形態で、所与のパーティションのデータ記録はシーケンス番号順に書き込まれ、その結果、シーケンス番号順に基づく（例えばｇｅｔＮｅｘｔＲｅｃｏｒｄｓまたは同様のインターフェースを用いて）順次読み出し要求がランダム読み出し要求より圧倒的に効率的な可能性がある。したがって、少なくともいくつかの実施形態では、異なる課金レートが順次対非順次検索インターフェースに設定されてもよく、例えば、クライアントは、非順次読み出しにより多く請求される可能性がある。
取得サブシステム
図６は、少なくともいくつかの実施形態による、ＳＭＳの取得サブシステム２０４の実施例の要素を図示する。図示の実施形態では、取得動作は論理的にフロントエンドとバックエンドに分けられて、フロントエンド機能はデータプロデューサ１２０（例えば、１２０Ａ，１２０Ｂまたは１２０Ｃ）との相互作用を含み、バックエンド機能はＳＭＳ記憶サブシステムとの相互作用を含む。このようなフロントエンド／バックエンドの分離は、記憶サブシステムのセキュリティを高め、データプロデューサにパーティション分割方針の詳細を提供しなければならないことを避けるなど、いくつか利点がある。ＳＭＳクライアントライブラリ６０２は種々のデータプロデューサ１２０でのインストールのために提供されて、データプロデューサはライブラリ６０２に含まれるプログラムインターフェースを呼び出して取得のためデータを提出する。例えば、一実施形態では、データプロデューサ１２０は数百または数千のプロバイダ網の物理及び／または仮想サーバでインスタンス化した記録エージェントまたは監視エージェントを備えることができる。そのようなエージェントは、種々のログメッセージ及び／または測定基準を自身の各サーバで収集し、定期的に収集したメッセージまたは測定基準を、終点を１つまたは複数のＳＭＳの取得制御ノード６６０によりインスタンス化されるフロントエンドの負荷ディストリビュータ６０４へ提出してもよい。いくつかの実施形態では、１つまたは複数の仮想ＩＰアドレス（ＶＩＰ）を負荷ディストリビュータのために設定し、データプロデューサはストリームデータをそこへ提出することができる。ある実施形態では、ラウンドロビンＤＮＳ（ドメインネームシステム）技術をＶＩＰ用に使用し、特定の負荷ディストリビュータをいくつかの等しく構成された負荷ディストリビュータの中から選択して、それに対してデータをデータプロデューサ１２０が送信することができる。
受信したデータ記録を図示の実施形態では、いくつかのフロントエンドのノード６０６のいずれかへ（例えば、６０６Ａ、６０６Ｂまたは６０６Ｃ）向けてもよい。少なくともいくつかの実施形態では、負荷ディストリビュータ６０４はデータ記録を使用する際、パーティション分割方針６５０に気付かない可能性がある。したがって、フロントエンドのノード６０６が所与のデータ記録用に選択されて、パーティション型負荷平均化よりラウンドロビン負荷平均化（またはある他の一般的な目的の負荷平均化アルゴリズム）を使用することができる。フロントエンドのノード６０６は種々のストリーム用のパーティション分割方針６５０に気付く可能性がある。そして、取得制御ノード６６０と相互作用して、所与のパーティションのデータ記録用に構成される特定のバックエンド取得ノード６０８（例えば、６０８Ａ、６０８Ｂ、または６０８Ｃ）のアイデンティティを取得することができる。したがって、図示の実施形態では、フロントエンドのノード６０４は各データ記録をデータ記録が属する各パーティションに基づいて複数のバックエンドノード６０６へ送信することができる。先に確認した通り、データ記録が属するパーティションはデータプロデューサが提供するパーティションキー、データプロデューサのアイデンティティまたはアドレスなど１つまたは複数の属性、あるいはデータの内容など、種々の要素のいかなる組み合わせに基づいても決定することができる。
各バックエンドノード６０６は１つまたは複数のストリームの１つまたは複数のパーティションに属するデータ記録を受信し、記憶サブシステムの１つまたは複数のノードへデータ記録を送信することができる。バックエンドノードはいくつかの実施形態では、「ＰＵＴサーバ」と呼ばれ、データはＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）「ＰＵＴ」ウェブサービスＡＰＩ経由で提出される。所与のバックエンドノードは、クエリを制御ノード６６０へ提出することにより、データ記録が送信されるべき１組の記憶サブシステムノードを決定することができる。（制御ノード６６０は、異なるサブシステムの制御機能が分離した１組のノードにより取り扱われる実施形態では、対応するクエリを記憶サブシステムの制御ノードに提出する。）
少なくともいくつかの実施形態では、少なくとも１度取得方針またはベストエフォート型取得方針などの複数の異なる取得承認方針６５２に対応することができる。少なくとも１度の方針では、データプロデューサ１２０は提出した各データ記録に対して肯定承認を要求し、承認が得られるまで、同じデータ記録を何度も提出する可能性がある（第１の提出に対して承認が得られなかった場合）。ベストエフォート型取得方針では、少なくとも提出したいくつかのデータ記録に対しては、肯定の承認は要求できない（しかし取得サブシステムは時折承認を出す、またはデータプロデューサからの明示的な承認要求には応答する）。取得サブシステム２０４がデータプロデューサに承認を提示するよう要求される実施形態では、承認が発行される前、所与のデータ記録を管理するバックエンド取得ノード６０８は要求した数のデータ記録の複製が記憶サブシステムで生成されるまで待つことがある（例えば、ストリーム用に設定された持続性方針にしたがって）。種々の実施形態では、シーケンス番号は、例えば、同じパーティションまたはストリームの他の記録と比較してその記録の取得された順序を示し、取得サブシステムが受信した各データ記録に対して生成してもよい。そのようなシーケンス番号はデータプロデューサに承認として、または承認の一部として返信されてもよい。シーケンス番号に関するより詳細については図１３ａ及び図１３ｂを参照して以下で説明する。承認及び／またはシーケンス番号は、いくつかの実施では、データプロデューサにフロントエンドノード６０６を介して返信することができる。少なくともある実施形態では、少なくとも１度方針はフロントエンド及び取得サブシステム自身のバックエンドノード間で実装されてもよい。例えば、所与のフロントエンドのノード６０６はデータ記録を適正なバックエンドノード６０８にバックエンドノードが承認を与えるまで、繰り返し提出する可能性がある。
取得制御ノード６６０は、他の機能の中でも、フロントエンド及びバックエンドノードをインスタンス化する、ノードのヘルス及び作業負荷レベルを監視する、必要に応じてフェールオーバーを指揮する、どのノードが所与のパーティションを受け持つかということに関するクエリに応答するまたは方針に関連するクエリに応答する役割を持つことができ、取得に関連する構成に対して、動作はストリームの動的再パーティション分割に起因する。所与の１組の１つまたは複数のストリームに指定された取得制御ノードの数は、いくつかの実施形態では、時間とともに変わる可能性がある。例えば、１つまたは複数の主制御ノードは、必要に応じて制御ノードのプールを再構成する役割を持つことができる。冗長グループが取得フロントエンドまたはバックエンドノードに対して設定されるいくつかの実施形態では、図９及び図１０を参照して以下でさらに詳細を説明する通り、制御ノード６６０は、どのノードが主でどれが非主かの記録を取る役割を持ち、フェールオーバーのトリガー条件を検出し、またフェールオーバーが要求されたときは交換品を選択する役割を持つことができる。図６に示す多層化取得サブシステムの構造は、いくつかの実施形態では実装することはできないことに留意されたい。例えば、単一の１組の取得ノードだけを一部のシナリオで構成することができる。
ストレージサブシステム
図７は少なくともいくつかの実施形態によるＳＭＳの記憶サブシステムの実施例の要素を図示するものである。図示の通り、取得ノード６０８（例えば、フロントエンド及びバックエンド取得責任が異なるノードのセットにより扱われている実施形態でのバックエンド取得ノード）は、ストリームの１つまたは複数のパーティションのデータ記録をそれらのパーティションのために構成される各記憶ノード７０２へ送信することができる。例えば、パーティションＳ１−Ｐ１のデータ記録１１０Ａは記憶ノード７０２Ａへ送信され、パーティションＳ２−Ｐ３のデータ記録１１０Ｂは記憶ノード７０２Ｂ及び７０２Ｃへ送信され、パーティションＳ３−Ｐ７のデータ記録１１０Ｃは記憶ノード７０２Ｄへ送信され、またパーティションＳ４−Ｐ５のデータ記録１１０Ｄは最初に記憶ノード７０２Ｅへ送信される。記憶制御ノード７８０は異なるストリームのデータ記録に適用される持続性方針７５０を強制する役割を持ち、必要に応じて記憶ノードを構成及び再構成し、記憶ノードの状態を監視し、フェールオーバーを管理し、記憶構成クエリまたは記憶方針クエリ、及び図示の実施形態で他の種々の管理タスクに応答する役割を持つことができる。
持続性方針７５０は、異なる実施形態では、種々の方法で互いに異なってもよい。例えば、ストリームＳｊに適用される持続性方針Ｐ１は、（ａ）保存される各データ記録の複製の数、（ｂ）複製が保存されるべき記憶デバイスまたはシステムのタイプ（複製が、揮発性メモリ、不揮発性キャッシュ、回転ディスク型記憶装置、ソリッドステートドライブ（ＳＳＤ）、各種記憶装置、各種ＲＡＩＤ（高価でない複数のディスクからなる冗長配列）、データベース管理システムに、プロバイダ網で実装される記憶サービスのノードで、などに保存されるべきかどうか）、（ｃ）複製の地理的分散（例えば、異なるデータセンタに複製を配置することにより、ストリームデータが大規模障害または所定の種類の災害に対して強くなされているか）、（ｄ）書き込み承認プロトコル（例えば、Ｎの複製が保存される場合、取得ノードに承認が与えられる前に何個のＮの複製が正常に書き込まれなければならないか）、及び／または（ｅ）複数のデータ記録の複製が保存される必要がある場合、複製は並行してまたは順次生成されなければならない、という条件のストリームＳｋに適用される方針Ｐ２と異なってもよい。複数の複製が保存される必要があるいくつかのケースでは、データ記録１１０Ｄの場合のように、所与の記憶ノードはデータ記録を他の記憶ノードへ送信してもよい（例えば、記憶ノード７０２Ｅはデータ記録１１０Ｄをさらに複製を作るため記憶ノード７０２Ｆへ送信し、記憶ノード７０２Ｆはそれを記憶ノード７０２Ｇへ送信する）。 多重複製の持続性方針が用いられる他のケースでは、２つのインメモリ複製が保存される必要があるデータ記録１１０Ｂのケースと同様に、取得ノードは並行して多重複製を始めてもよい。少なくともいくつかの実施形態では、クライアントの選択する持続性方針はストリームのデータ記録に使用される記憶場所のタイプを指定することはできないが、代わりにＳＭＳは適切なタイプの記憶技術及び／または場所を費用、性能、データソースの近傍、耐久性要件などの様々な基準に基づいて選択することができる。一実施形態では、クライアントまたはＳＭＳどちらかが、異なる記憶技術または記憶場所の型を所与のストリームの別のパーティションまたは別のストリームに使用することを決定できる。
図７に示す実施例では、ストリームＳ１に適用される持続性方針は（または少なくともストリームＳ１のパーティションＳ１−Ｐ１）、単一複製インメモリ方針であるが、ストリームＳ２には２個並行複製インメモリ方針が適用される。したがって、データ記録１１０Ａのインメモリ複製７０４Ａは、記憶ノード７０２Ａで生成されるが、データ記録１１０Ｂに対応する２個インメモリ複製７０５Ａ及び７０５Ｂは並行して記憶ノード７０２Ｂ及び７０２Ｃで生成される。ストリームＳ３のデータ記録１１０Ｃに対しては、単一オンディスク複製７０６Ａが生成される。ストリームＳ４に対しては、連続３個複製オンディスク方針が適用可能で、その結果、各オンディスク複製７０７Ａ、７０７Ｂ及び７０７Ｃは順次、記憶ノード７０２Ｅ，７０２Ｆ及び７０２Ｇで生成される。他の種々の型の持続性方針は、異なる実施形態では、データストリームに適用されてもよい。検索サブシステムのノードは、適切な記憶ノードからデータコンシューマによる種々の型の検索ＡＰＩの呼び掛けに応答して、データ記録を取得することができる。
検索サブシステム及びプロセッシング段階
図８は、少なくともいくつかの実施形態による、ＳＭＳの検索サブシステムの実施例の要素及びＳＰＳを備える検索サブシステムの相互作用の実施例を示す。図示のように、検索サブシステム２０６は、検索ノード８０２Ａ、８０２Ｂ及び８０２Ｃなどの複数の検索ノード８０２ならびに検索制御ノード８８０の収集を備えてもよい。各検索ノード８０２は、以下で説明するように、ＳＰＳのワーカーノード８４０などの様々なクライアントまたはデータコンシューマ１３０からのストリームデータ検索要求に応答するよう構成されてもよい。先に説明した非順次及び順次検索インターフェースなどの別の実施形態では、様々なプログラム検索インターフェース８０２を検索ノードが実行してもよい。いくつかの実施形態では、ＨＴＴＰ ＧＥＴ要求などのウェブサービスＡＰＩがデータ記録検索に使用されてもよく、したがって検索ノード８０２は、ＧＥＴサーバと呼ばれてもよい。所与の検索ノード８０２は、図示の実施形態では、例えば、検索制御ノード８８０によって、記憶ノード７０２Ａ及び７０２Ｂなど記憶サブシステムのノード７０２の適切なセットから１つまたは複数のストリームパーティションのデータ記録を取得するよう構成されてもよい。
図示の実施形態では、検索ノード８０２は１つまたは複数の記憶ノード７０２と相互に作用してもよく、また、１つまたは複数のＳＰＳワーカーノード８４０から受領した検索要求に応答してもよい。例えば、パーティションＳ４−Ｐ５のデータ記録（例えばデータ記録１１０Ｋ）及びＳ５−Ｐ８のデータ記録（例えばデータ記録１１０Ｌ）は記憶ノード７０２Ａから検索ノード８０２Ａによって読み出されて、それぞれワーカーノード８４０Ａ及び８４０Ｋに提供される。１１０ＭなどのパーティションＳ６−Ｐ７のデータ記録は検索ノード８０２Ｂによって、記憶ノード７０２Ａから読み出されて、ワーカーノード８４０Ｋに提供される。パーティションＳ４−Ｐ７のデータ記録は検索ノード８０２Ｃによって記憶ノード７０２Ｂから読み出されて、ワーカーノード８４０Ｂ及び他のデータコンシューマ１３０（例えば、ＳＰＳを介してＳＭＳと相互に作用する代わりにＳＭＳ検索ＡＰＩを直接呼び出すデータコンシューマ）へ提供される。
少なくともいくつかの実施形態では、一部またはすべての検索ノード８０２は各キャッシュ８０４（検索ノード８０２Ａでキャッシュ８０４Ａ、検索ノード８０２Ｂでキャッシュ８０４Ｂ及び検索ノード８０２Ｃでキャッシュ８０４Ｃ）を実装して、そこで種々のパーティションのデータ記録を将来の検索要求を見越して、一時的に保管することができる。検索制御ノード８８０は、例えば、キャッシング方針（例えば、所与のパーティションを構成するキャッシュのサイズ、データ記録がキャッシュされる期間）、記憶ノード選択方針（データ記録の多重複製が保存されるシナリオ内の所与のデータ記録を取得するためどの特定の記憶ノードに最初にコンタクトするか）など複数の検索方針８８２を実装する役割を持ってもよい。 さらに、検索制御ノードは検索制御ノード８０２をインスタンス化し、かつ監視して、どの検索ノードがどのパーティションを受け持つかに関するクエリに応答して、再パーティション分割動作を開始または再パーティション分割動作に応答するなどの役割も持ってもよい。
図示の実施例では、ＳＰＳ２９０は２つの処理段階２１５Ａ及び２１５Ｂを含む。ＳＰＳ制御ノード８８５は、ワーカーノード８４０ＡをパーティションＳ４−Ｐ５の処理記録へ、ワーカーノード８４０ＢをパーティションＳ４−Ｐ７の処理記録へ、またワーカーノード８４０ＫをパーティションＳ５−Ｐ８及びＳ６−Ｐ７の処理記録へなど、ワーカーノード８０４を種々の処理段階２１５でインスタンス化する役割を持ってもよい。ＳＰＳ制御ノード８８５は、プログラムインターフェースを実装して（図３及び図４で図示したように）、ＳＰＳクライアントが処理作業フローを設計できるようにすることができる。種々のチェックポイント方針８５０は別の処理段階または作業フローのために実装されて、ワーカーノードがどれだけ各パーティションを処理しているか、進行記録用に使用される記憶デバイスのタイプなどを示す進行記録を保存する時または場合を示すことができる。フェールオーバー／リカバリ方針８５２は、異なるノードを有するワーカーノードを交換するようにするトリガー条件または閾値及び、ベストエフォート型リカバリが使用されるかまたはチェックポイント型リカバリが所与の進行段階に使用されるかを示すことができる。少なくともいくつかの実施形態では、ＳＰＳ制御ノード８８５は、例えば、検索ノードを所与のストリームのどのデータ記録から取得するかを指定する、特定の処理作業フロー用に要求される可能性がある新しい一時的または持続性ストリームを設定するなど、様々な型のＳＭＳ制御ノードと相互作用することができる。少なくとも一実施形態では、例えば、ＳＭＳ制御インターフェースを利用する代わりに、一部のクライアントはより高いレベルのＳＰＳインターフェースのみを呼び出すことを望む場合があり、クライアントはストリームをインスタンス化するためＳＰＳ制御ノードと相互作用することができる。分散する制御ノードのセットはＳＭＳ取得、記憶及び検索サブシステム用、及びＳＰＳ段階用の図６、７、及び８で図示されるが、少なくともいくつかの実施形態では、所与の制御ノードをいくつかのサブシステム及び／またはＳＰＳ用に使用することができることを留意されたい。
ノード冗長群
少なくともいくつかの実施形態では、ノードの冗長グループが１つまたは複数のＳＭＳのサブシステム用に構成されてもよい。すなわち、例えば、ストリームパーティションＳｊ−Ｐｋ用のデータ記録を検索する１つの検索ノードを構成する代わりに２つ以上のノードがそのような検索用に設定されてもよく、一方のあるノードがある時点での「主な」または能動的な役割を認められ、他方のあるノードまたは複数のノードが「非主」ノードと指定される。現在の主ノードは、例えば、クライアントまたは他のサブシステムのノードのいずれかから受信した要求などの作業要求に応答する役割を持つことができる。１つの非主ノードまたは複数の非主ノードはフェールオーバーが、例えば、障害、主ノードへの接続喪失、または他のトリガー条件により、選択の非主ノードが以前の主ノードの役割を引き継ぐよう制御ノードに通知された時点など、トリガーされるまで休止状態を維持してもよい。こうして、主要な役割はフェールオーバーの間、現行の主ノードから取り消されて現行の非主ノードに与えられてもよい。いくつかの実施形態では、非主ノードは、例えば、明示的通知を要求できない、フェールオーバーが起こるという決定がなされた場合、自身を主として引き継いでもよい。このようなノードの冗長グループは、種々の実施形態で、ＳＭＳでの取得、記憶、検索及び／または制御機能用として設定することができる。また同様のアプローチを、少なくともいくつかの実施形態で、ＳＰＳでのワーカーノード用に採ることができる。いくつかの実施形態では、所与の機能のために少なくとも１つの主ノードと少なくとも１つの非主ノードを備えるこのようなグループを、「冗長グループ」または「複製グループ」と呼んでもよい。記憶ノードの冗長グループは、保存されたデータ記録の物理複写部数を独立して、実装されてもよく、例えば、データ記録の保存されるべき複写の数は持続性方針により決定されるが、対応するパーティション用に構成された記憶ノードの数は冗長グループの方針に基づいて決定することができることに留意されたい。
図９は、少なくともいくつかの実施形態によるＳＭＳまたはＳＰＳのノード用に設定することができる冗長グループの実施例を図示する。図示の実施形態では、所与のストリームパーティションＳｊ−Ｐｋに対する、各冗長グループ（ＲＧ）９０５、９１５、９２５及び９３５が取得ノード、記憶ノード、検索ノード、及び制御ノード用に設定される。制御ノード用の共通のＲＧ９３５が図示の実施形態では実装されるが、いくつかの実施形態では、取得制御ノード、記憶制御ノード、または検索制御ノード用には分散するＲＧを実装してもよい。各ＲＧは、主ノード（例えば、主取得ノード９１０Ａ、主記憶ノード９２０Ａ、主検索ノード９３０Ａ及び主制御ノード９４０Ａ）及び少なくとも１つの非主ノード（例えば、非主取得ノード９１０Ｂ、非主記憶ノード９２０Ｂ、非主検索ノード９２０Ｃ及び非主制御ノード９２０Ｄ）を備える。各フェールオーバー方針９１２（取得ノード用）、９２２（記憶ノード用）、９３２（検索ノード用）及び９４２（制御ノード用）にしたがって、現行の非主に対して、主要な役割を無効化及び承認してもよい。例えば、フェールオーバー方針は、主状態の中の変化へつながるトリガー条件、主または非主のヘルス状態を監視するかどうか及びどうやって監視するか、所与の冗長グループ内で構成される非主の数などを管理してもよい。少なくともいくつかの実施形態では、単一のＲＧを複数のパーティション用に設定することができる。例えば、ＲＧ９０５はパーティションＳｊ−ＰｋならびにＳｐ−Ｐｑの記録取得を設定することができる。いくつかの実施では、一方のパーティションに主として指定されたあるノードは、同時に他方のパーティションに非主として指定される可能性がある。一実施形態では、多重ノードは所与のＲＧ内で同時に主ノードとして指定されてもよい。例えば、主で障害が起きた場合でも一方のノードを非主として指定して、所与のパーティションの取得関連の作業負荷を２つの主ノード間で分散することができる。所与のＲＧでインスタンス化されたノードの数は対応する機能に対して望まれる可用性レベルまたは強度レベルによって決まる可能性がある（例えば、いくつの同時または重複障害に対してグループが耐えられるようになっているか）。いくつかの実施形態では、ＳＭＳノードに追加してまたはＳＭＳノードに使用される代わりに、冗長グループはＳＰＳ処理段階のワーカーノード用に設定されてもよい。所与のＲＧのメンバは、例えば、図１０に示すように、いくつかのデータセンタを横切って、地理的に分散される場合があってもよい。選択された制御ノードはいくつかの実施形態では、例えば、ハートビート機構または他のヘルス監視技術を用いて、適切な非主ノードを故障した主との交換として選択し、選択した交換ノードを通知／起動することによりフェールオーバーを指揮するなど、フェールオーバートリガー条件を検出するように構成されてもよい。
いくつかの実施形態では、プロバイダ網は複数の地理的地域に組織化されて、各地域はここでは「可用性ゾーン」と呼んでもよい、１つまたは複数の可用性コンテナを含んでもよい。可用性コンテナは、１つまたは複数のまったく別の場所またはまったく別のデータセンタを備え、所与の可用性コンテナ内の資源は他の可用性コンテナの障害から隔離されるように（例えば、電源関連の装置、冷却装置、物理セキュリティ構成部品などの独立したインフラストラクチャ構成部品を備えて）設計される。１つの可用性コンテナでの障害が他の可用性コンテナでの障害の原因になってはならない。したがって、資源インスタンスまたは制御サーバの入手可能プロファイルは異なる可用性コンテナにある資源インスタンスまたは制御サーバの入手可能プロファイルと無関係になるようにしている。種々のタイプのアプリケーションは単一の場所では各可用性コンテナで複数のアプリケーションインスタンスを起動すること、または（ＳＭＳ及びＳＰＳの場合では）複数の可用性コンテナにわたって所与の冗長グループのノードを分散することにより、障害から保護されるようになる。同時に、いくつかの実施形態では、安価で低遅延のネットワーク接続を、同じ地理的地域内にある資源間（ホストまたはＳＭＳ及びＳＰＳノードに用いられるコンピュートインスタンスなど）で得ることができ、同じ可用性コンテナの資源間のネットワーク送信速度はさらに速い可能性がある。一部クライアントは、例えば、地域レベル、可用性コンテナレベル、またはデータセンタレベルのいずれかで、自身のアプリケーションの種々の構成要素が正確にどこで実行されているか望む範囲で制御を維持するためにストリーム管理またはストリーム処理資源が確保及び／またはインスタンス化されている場所を特定したいかもしれない。他のクライアントは資源が、例えば、性能、高入手性などに対してクライアントの要求に合う限りは自身の資源が正確にどこに確保してあるかまたはインスタンス化してあるかは重要ではない。一部の実施形態では、一方の可用性コンテナに配置される制御ノード（またはデータセンタ）は、他方の可用性コンテナ（または他のデータセンタ）にある他のＳＭＳまたはＳＰＳノードを離れて構成することができる可能性がある、すなわち、特定の可用性コンテナまたはデータセンタがＳＭＳ／ＳＰＳノードを管理するためのローカル制御ノードを有する必要がないかもしれない。
図１０は、少なくともいくつかの実施形態による、所与の冗長グループのノードを複数のデータセンタ間で分散することができるプロバイダ網環境を示す。プロバイダ網１００２は、図示の実施形態では、３つの可用性コンテナ１００３Ａ、１００３Ｂ及び１００３Ｃを備える。各可用性コンテナは１つまたは複数のデータセンタの一部または全部を含む。例えば、可用性コンテナ１００３Ａは、データセンタ１００５Ａ及び１００５Ｂを含み、可用性コンテナ１００３Ｂは、データセンタ１００５Ｃを含み、また可用性コンテナ１００３Ｃは、データセンタ１００５Ｄを含む。ＳＭＳ及び／またはＳＰＳのいくつかの異なる冗長グループ１０１２が図示されている。ＲＧ１０１２のいくつかを、データセンタ１００５Ａに配置されたＲＧ１０１２Ａの場合のように、完全に単一のデータセンタ内で実装することができる。他のＲＧは、可用性コンテナ１００３Ａのデータセンタ１００５Ａと１００５Ｂに広がるＲＧ１０１２Ｂなど所与の可用性コンテナ内の多重データセンタの資源を使用することができる。さらに異なる可用性コンテナを横切って広がる資源を使用して、他のＲＧを実装することができる。例えば、ＲＧ１０１２Ｃは、各可用性コンテナ１００３Ａ及び１００３Ｂのデータセンタ１００５Ｂ及び１００５Ｃに配置された資源を使用し、ＲＧ１０１２Ｄは可用性コンテナ１００３Ａ、１００３Ｂ、及び１００３Ｃそれぞれにあるデータセンタ１００５Ｂ、１００５Ｃ及び１００５Ｄで資源を利用する。ある実施例の展開では、ＲＧ１０１２が１つの主及び２つの非主ノードを備える場合、３つのノードをそれぞれ異なる可用性コンテナに配置することができるので、大規模障害イベントが２つの異なる可用性コンテナで同時に発生しても、少なくとも１つのノードが高い可能性で確実に機能したままになる。
図示の実施形態で、それぞれＳＭＳ及びＳＰＳと関連するコンソールサービス１０７８及び１０７６は、プロバイダ網１００２内のストリーム関連の設定を構成する使いやすいウェブベースのインターフェースを提供することができる。ＳＭＳ及び／またはＳＰＳが少なくともそのいくつかを使用することができる複数の追加サービスを、１つまたは複数のデータセンタにわたって、または１つまたは複数の可用性コンテナにわたって広がる資源を用いてプロバイダ網１００２内で実装することができる。例えば、仮想コンピューティングサービス１０７２を実装すると、クライアントは、種々の異なる能力レベルのコンピュートインスタンスとしてパッケージ化した選択した量の計算能力を利用することができるようになる。そのようなコンピュートインスタンスをＳＭＳ及び／またはＳＰＳノードを実装するために使用することができる。１つまたは複数の記憶サービス１０７０を実装すると、クライアントは、例えば、ブロックデバイスのボリュームインターフェースを介して、またはウェブサービスのインターフェースを介して所望のデータ持続レベルを備えたデータオブジェクトを保存またはデータオブジェクトにアクセスすることができるようになる。いくつかの実施形態では、記憶オブジェクトはサービス１０７２のコンピュートインスタンスに取り付け可能か、またはコンピュートインスタンスからアクセス可能であって、種々のストリーム持続性方針をＳＭＳ記憶サブシステムで実装して使用することができる。一実施形態では、高機能キーバリューデータベース管理サービス１０７４などの１つまたは複数のデータベースサービスまたは関係データベースサービスをプロバイダ網１００２で実装して、そのようなデータベースサービスは、ＳＭＮＳ記憶サブシステムによりストリームデータ記録を保存するために及び／または制御サブシステム、取得サブシステム。記憶サブシステム、検索サブシステムまたは処理段階のメタデータ保存のために使用される。
ストリームセキュリティオプション
少なくともいくつかの実施形態では、ＳＭＳ及び／またはＳＰＳのユーザがデータストリーム用の複数のセキュリティ関連オプションを取得すると、クライアントは、取得、記憶、検索、処理及び／または制御など種々の機能性カテゴリに用いられる資源のセキュリティプロファイル（例えば、仮想または物理機械装置）を選択することができるようになる。そのようなオプションは、例えば、種々のノード（例えば、プロバイダ網設備を使うか、またはプロバイダ網設備と異なるセキュリティ特徴を有するクライアント保有の設備を使うか）に用いる資源の物理的場所のタイプに関する選択、ストリームデータの暗号化に関する選択及び／またはストリーム操作インフラストラクチャの種々の部分でのネットワークの分離の選択を含んでもよい。クライアントの一部は、例えば、貴重な所有者のビジネス論理またはアルゴリズムへのアクセスを得ようとする侵入者または攻撃者の可能性を懸念して、ストリーム処理ワーカーノードを実装してクライアント自身の保証内でコンピューティング装置を使用したいと思う可能性がある。１組のＳＭＳ及び／またはＳＰＳノードを実装するために使用される資源のタイプはここではそれらノード用の「配置先タイプ」と呼ぶことができる。図１１は、少なくともいくつかの実施形態による、ＳＭＳまたはＳＰＳのノード用に選択されてもよい複数の配置先のタイプを示す。
配置先は、図示の実施形態では、一部のタイプのＳＭＳ／ＳＰＳ機能カテゴリ（例えば、取得、記憶、検索、制御または処理）用にプロバイダ網１１０２内で、及び他のタイプのＳＭＳ／ＳＰＳ機能カテゴリ用にプロバイダ網１１０２の外で選択することができる。プロバイダ網１１０２内では、コンピュートインスタンス、記憶インスタンス、またはデータベースインスタンスなどのいくつかの資源は、マルチテナントインスタンスホスト１１０３を使用して実装されてもよい。１つまたは複数のクライアントがインスタンス化される各ＳＭＳまたはＳＰＳノードでのそのようなマルチテナントインスタンスホストは第１カテゴリ「Ａ」の配置先タイプを形成することができる。他のクライアントと物理資源を共有しなければならないことを避けるため、クライアントの一部はＳＭＳ／ＳＰＳノードに単一のクライアントに限定されたインスタンスホストを使用して実装するよう要求することができる。そのようなシングルテナントインスタンスホストは配置カテゴリタイプ「Ｂ」を形成することができる。シングルテナントインスタンスホストはいくつかの理由で一部のクライアントの観点からより好まれる可能性がある。マルチテナントインスタンスホストは他のクライアントに属するコンピュートインスタンスを含むため、他のクライアントのインスタンスからのセキュリティ攻撃に合う可能性はシングルテナントインスタンスホストよりマルチテナントインスタンスホストの方が高い可能性がある。さらに、「迷惑な隣人」現象では、マルチテナントホスト上で起動中のあるクライアントのコンピュートインスタンスＣＩ１が作業負荷の急増に合い、ホストのコンピュートサイクルまたは他の資源の大部分を消費し始めて、別のコンピュートインスタンスＣＩ２上で起動する他のクライアントのアプリケーションの性能に影響を及ぼす可能性があり、シングルテナントインスタンスホストを使う場合、それも避けることができる。
ＩＶＮ１１０６Ａ及び１１０６Ｂなどの隔離型仮想ネットワーク（ＩＶＮ）１１０６は図示の実施形態では、配置先タイプが他のカテゴリ「Ｃ」を示すことができる。ＩＶＮ１１０６はいくつかの実施形態ではプロバイダ網のクライアントの要求で、プライベートネットワークの論理同値として生成されてもよく、プロバイダのネットワーク資源を使用して構築されるが、ネットワーク構成はクライアントによってほとんど制御される。例えば、クライアントはＩＶＮ１１０６内で使用するＩＰアドレスを決定することができ、ＩＶＮの外側ですでに使用されているかもしれないＩＰアドレスと重複する可能性を懸念する必要がない。図示の実施形態では、１つまたは複数のＩＶＮ内の様々なタイプのＳＭＳ及びＳＰＳノードを実行することにより格外レベルのネットワークセキュリティをクライアントのストリームデータの管理及び／または処理に追加することが可能になる。一部のケースでは、所与のクライアントは、あるＩＶＮ１１０６内のＳＭＳノード／ＳＰＳノードのある機能カテゴリ及び別のＩＶＮ内の別の機能カテゴリを配置したいと思うかもしれない。種々の実施形態で、所与のＩＶＮ１１０６はシングルテナントインスタンスホスト、マルチテナントインスタンスホストまたは両方のインスタンスホストのいずれかを備える。一部の実施形態では、図１１には図示しないが、プロバイダ網の資源を使用する他のセットの配置先型を選択（またはセキュリティプロファイルを選択）することが少なくともクライアントの一部にはできる可能性がある。クライアントがコンピュートインスタンスをストリーム関連の動作のためにプロバイダ網の仮想化コンピューティングサービスから取得または使用することが可能な実施形態では、コンピュートインスタンスを２つのモードの一方で使用することができる。一方のモードでは、クライアントはＳＰＳまたはＳＭＳに、実行可能な１つまたは複数のプログラムを提供して、ＳＰＳワーカーノードとして構成されるコンピュートインスタンスで（または取得ノード、記憶ノードもしくは検索ノードで）起動させて、ＳＭＳまたはＳＰＳにプログラムを起動させてノードを管理させることができる。この第１のモードはストリーム動作用のコンピュートインスタンスを使用する「ストリームサービス管理型」モードと呼んでもよい。他方のモードでは、クライアントは、ＳＰＳまたはＳＭＳからあまり支援を受けずに実行プログラムを起動してコンピュートインスタンスを管理したいと思うかもしれない。この第２のモードは、ストリーム動作用のコンピュートインスタンスを使用する「クライアント管理型」モードと呼んでもよい。これら２つの動作モードはクライアントが選択可能な配置先の型またはセキュリティプロファイルに関する追加的選択を示すことができる。クライアントは、例えば、実行プログラムが、クライアントの組織の対象分野の専門家が最も活躍するデバッグ（含むシングルステップ）を要求するような場合、クライアント管理型モードを選択してもよいが、デバッグを要求しないようなより成熟したコードには、ストリームサービス管理型モードが合理的な選択かもしれない。いくつかの実施形態では、これらの２つのモードには異なる価格体系が適用される場合がある。
図１１で示す実施形態では、複数の配置オプションをプロバイダ網の外側の設備でサポートすることができる。例えば、ＳＭＳライブラリ１１７１及び／またはＳＰＳライブラリ１１７２が組み込まれたホスト１１６０をクライアントの設備内（例えば、クライアント所有のデータセンタまたは施設）１１１０Ａまたは１１１０Ｂから、２つのクライアントの設備がプロバイダ網への接続の仕方が異なったまま、ストリーム管理または処理用に使用することができる。クライアントの設備１１１０Ａはプロバイダ網１１０２に少なくともいくつかの共有インターネットリンク１１５１（すなわち、他のエンティティのネットワークトラフィックもクライアントの設備１１１０Ａとプロバイダ網１１０２間のいくつかのリンク上を流れている）を介して接続される。反対に、一部のクライアントの設備（１１１０Ｂなど）をプロバイダ網に特別な非共有で専用の物理リンク１１０６（「ダイレクトコネクト」リンクと呼ばれることがある）を介して接続することができる。これらの２つの異なるタイプのクライアントの施設は、図１１で用いられる用語でそれぞれ配置先オプション「Ｄ」及び「Ｅ」を備える。いくつかの実施形態では、ＳＭＳ及び／またはＳＰＳの部分は、サードパーティの設備（例えばデータセンタを使用するがＳＭＳ／ＳＰＳのクライアントが所有または管理していない）で実装されて、そのようなサードパーティの設備は配置先タイプ「Ｆ」と指定することができる。少なくともいくつかのクライアント及び／またはサードパーティの設備では、ＳＭＳ及び／またはＳＰＳのライブラリはプロバイダ網から取得されて、ＳＭＳ／ＳＰＳノード用に使用されるホストに組み込まれなくてはいけない可能性がある。少なくとも一実施形態では、すべての異なる機能カテゴリのノードが適切なライブラリの助けを借りてプロバイダ網の外部に実装されてもよい。
いろいろな配置先のタイプは、別の実施形態では、ネットワーク隔離機能実装型、侵入検出機能対応型、物理的セキュリティ方針実装型、対応済み暗号化レベルなど種々のセキュリティ関連の態様の中で互いに異なってもよい。したがって、種々の各配置先のタイプは、それぞれのセキュリティプロファイルを有すると考えられ、１つまたは複数の方法で他の配置先のセキュリティプロファイルと頃なる可能性がある。いくつかの実施形態では、ＳＭＳ及び／またはＳＰＳのクライアントは各配置先のタイプを、例えば、図１２ａ及び１２ｂに記載の通り、ＳＭＳまたはＳＰＳの１つまたは複数の制御ノードに要求を送信して、プログラムで種々のサブシステムまたはノードのセット用に選択することができる。いくつかの実施形態では、所定のタイプのストリームアプリケーションに対して、クライアントは、セキュリティの理由のためだけでなく、性能及び／または機能的な理由で配置先のタイプを制御したいと考える可能性があることに留意されたい。例えば、上述の迷惑な隣人現象は専用のクライアント施設資源またはシングルテナントインスタンスホストを用いることにより避けることができる。いくつかの実施形態では、クライアントは、ＳＰＳ段階またはＳＭＳノード用に使用したい特別目的のまたは専有のハードウェア及び／またはソフトウェアを有することができ、そのような構成要素を用いて達成可能な機能または性能レベルはプロバイダ網で簡単に複製することなどできないものであり、または単純にプロバイダ網で対応されるものでもない。クライアントは外側のデータセンタでスーパーコンピュータレベルの処理能力を備えるコンピュータサーバにアクセスすることができ、例えば、そのサーバはＳＰＳ処理を単独のプロバイダ網を使って可能な速度よりさらに高速で実行することができる。クライアントが種々のノード用に配置先を選択することができることで、そのような特別目的のデバイスまたはソフトウェアの使用が可能になる。
図１２ａ及び１２ｂは、少なくともいくつかの実施形態による、ＳＰＳクライアント及びＳＭＳクライアントそれぞれが提出するセキュリティオプション要求の実施例を示す。図１２ａは、クライアントが、識別子１２１０を備える１つまたは複数の処理段階用に、段階の制御ノード（要素１２１２）を要求する配置先タイプ（ＰＤＴ）及びワーカーノード（要素１２１４）を要求するＰＤＴを表すＳＰＳのセキュリティオプション要求１２００を図示する。少なくとも一実施形態では、クライアントはまた、例えば、種々のネットワークリンクにわたって送信の前に指定のアルゴリズムまたはプロトコルを用いてデータ記録を暗号化すること、あるいは種々の制御または管理的相互作用を暗号化することを要求することにより、ストリームデータ記録またはストリームデータ記録処理結果用に暗号化設定を構成するための要求を提出することができるかもしれない。例えば、図１２ａでは、段階用の暗号化設定は段階処理動作の結果に適用可能な暗号化技術、及び／または段階の制御ノードと段階のワーカーノード間の通信用に使用する暗号化を示すことができる。
同様に、図１２ｂでは、クライアントのＳＭＳセキュリティオプション要求１２５０は指定の識別子１２５２を備える１つまたは複数のストリーム用のクライアントのセキュリティ選好を示す複数の要素を備える。取得ノード、記憶ノード、及び検索ノードに対する配置先タイプの選好はそれぞれ要素１２５４、１２５８及び１２６２に示される。取得制御ノード、記憶制御ノード、及び検索制御ノードに対するＰＤＴ選好は各要素１２５６、１２６０、及び１２６４で示される。例えば、暗号化はデータ記録が一方のノードのカテゴリから他方へ送信されるときにデータ記録について実装されるかどうか、及び／またはどのように実装されるか、といったデータ記録に対する暗号化選好は、要素１２６６を介して表示される。図１２ａ及び１２ｂで示すようなセキュリティオプション要求を用いて、クライアントは、場所（例えば、プロバイダ網内かまたはプロバイダ網の外側）、自身のストリーム管理及び処理環境の様々な部分に対する種々の他のセキュリティプロファイル構成要素を選択することができる。
いくつかの実施形態では、ノード配置先の選択をセキュリティ以外の理由で提供する場合があることに留意されたい。例えば、クライアントは一部のタイプのＳＭＳまたはＳＰＳのノードを性能が理由でシングルテナントホストに実装したいと思うかもしれない（例えば、以前にセキュリティの理由よりも主に示した「迷惑な隣人」問題を避けるために）。配置の選択を少なくともいくつかの実施形態では、ストリームのライフタイム中に変更することができる。例えば、クライアントは、最初にＳＭＳノードをマルチテナントインスタンスホストでインスタンス化するようにするが、少なくともいくつかのノードのサブセットをシングルテナントインスタンスホストへ後で移動したいと考えるようになる。種々の価格体系が、少なくともいくつかの実施形態では、種々のセキュリティ関連のオプションに適用されてもよい。例えば、特定の機能カテゴリのＳＭＳノードをＩＶＮの外側のマルチテナントインスタンスホストよりＩＶＮで実装する方がより費用がかかる場合がある。またはＳＭＳノードをマルチテナントインスタンスホストよりシングルテナントインスタンスホストで実装する方がより費用がかかる場合がある。
ストリーム記録の連続記憶及び検索
ストリームアプリケーションの多くのタイプでは、データ記録をＳＭＳで非常に速いレートで複数のデータプロデューサ１２０から受信していて、データコンシューマは通常保存されたデータ記録に記録が発生した順でアクセスしたいと考えるものである。特に、回転磁気ディスクがストリームデータ記録用記憶デバイスとして使用されている環境では、上述のように、連続Ｉ／Ｏアクセスパターン（読み出しと書き込みの両方）は、ランダムＩ／Ｏアクセスパターンより大幅に性能上の利点がある。いくつかの実施形態では、ストリーム特定のまたはパーティション特定のシーケンス番号をＳＭＳが受信した際にデータ記録に割り当て、シーケンス番号に基づくシーケンス検索動作を支援することができる。図１３ａは、少なくともいくつかの実施形態による、ストリームデータプロデューサとＳＭＳの取得システム間での相互作用を示す。ストリームデータプロデューサはデータ記録１１０を取得サブシステムに提出して、図示の実施形態では、取得サブシステムは、提出した記録用に選択したシーケンス番号１０２で応答することができる。少なくともいくつかの実施形態では、取得ノードはシーケンス番号の一部を記憶サブシステムから取得することができる。例えば、シーケンス番号１０２をそのような実施形態では適用可能な持続性方針にしたがって、受信したデータ記録の記憶に続いて決定してもよく、記憶サブシステムはデータ記録用に自身の数列表示を発生して、その表示を取得ノードがデータ記録に割り当てた、より大きいシーケンス番号に含ませることができる。
シーケンス番号は種々の実施形態で実装されて、安定して一貫性のある順序のデータ記録を提供し、データコンシューマによる記録のすべてにわたって再現可能な反復を可能にする。特定のパーティションのデータ記録に割り当てられたシーケンス番号は時間とともに単調に増えるが、少なくとも一部の実施形態では、連続である必要はない。種々の実施形態では、シーケンス番号は少なくとも以下の意味論のいくつかのサブセットを備えて割り当てられる。（ａ）シーケンス番号は、ストリームの中で固有である、すなわち、所与のストリームの２つのデータ記録には同じシーケンス番号は割り当てられない。（ｂ）シーケンス番号はストリームのデータ記録のインデックスとして働き、所与のストリームのパーティション内でデータ記録を反復するために使用することができる。（ｃ）いずれの所与のデータプロデューサに対しても、データプロデューサがデータ記録を提出することができた順序はデータ記録に割り当てられたシーケンス番号に反映される。（ｄ）所与のパーティションキー値を備えるデータ記録に対するシーケンス番号の採番は、動的な再パーティション分割動作にわたり、単調に意味論を増加し続ける。例えば、再パーティション分割後にパーティションキー値Ｋ１を備えたデータ記録に割り当てられた各シーケンス番号は、動的再パーティション分割の前にパーティションキー値Ｋ１を備えたデータ記録に割り当てられたいずれのシーケンス番号より大きくなる。（動的再パーティション分割は、以下でさらに詳細に図１６について説明する。）
いくつかの実施形態では、データプロデューサは、少なくともいくつかのデータ記録用に選択されたシーケンス番号１０２の選択に影響を与えたいと考える可能性がある。例えば、データプロデューサ１２０は、ストリームの割り当てられたシーケンス番号内の境界またはセパレータと境界を定めたいと考えていて、その結果、そのストリームのデータコンシューマにとって、特定のストリームのサブセットを目標にした読み出し要求を提出することはより簡単になる。いくつかの実施形態では、データプロデューサ１２０は、最小のシーケンス番号の表示を記録と一緒に提出することができる。そして、ＳＭＳは、上述のシーケンス番号意味論とも一致する要求した最小にしたがってシーケンス番号を選択することができる。
図１３ｂは、少なくともいくつかの実施形態による、ＳＭＳで取得されたデータ記録用に生成されたシーケンス番号の要素の実施例を示す。シーケンス番号は４つの要素を図示の実施形態では、備える。ｎ１ビットのＳＭＳバージョン番号１３０２、ｎ２ビットのタイムスタンプまたはエポック値１３０４、ｎ３ビットサブシーケンス番号１３０６、及びｎ４ビットパーティション番号１３０８である。いくつかの実施形態では、１２８ビットのシーケンス番号は、例えば、ｎ１、ｎ２、ｎ３及びｎ４、おそらく４、４４、６４及び１６ビットそれぞれを使用することができる。バージョン番号１３０２は、単純にＳＭＳのソフトウェアバージョンのロールアウトと交差する混乱を回避するために使用されてもよく、例えば、その結果、どのバージョンのＳＭＳソフトウェアがシーケンス番号を発生するのに使用されたか簡単にわかる。バージョン番号１３０２は少なくともいくつかの実施形態では、頻繁に変更することを期待できない。タイムスタンプ値１３０４は、例えば、局所クロック源またはグローバルにアクセス可能なクロック源（例えば、ｇｅｔＣｕｒｒｅｎｔＥｐｏｃｈまたはｇｅｔＣｕｒｒｅｎｔＴｉｍｅ ＡＰＩを実装するプロバイダ網の状態管理システム）から取得サブシステムノードにより取得することができる。少なくともいくつかの実施形態では、よく知られている時点からのずれ（例えば、協定世界時１９７０年１月１日００：００：００から経過した秒数、Ｕｎｉｘ（商標）ベースのオペレーティングシステムで呼び出す種々の時間に関するシステムを呼び出すことで取得可能になる）をタイムスタンプ値１３０４に使用してもよい。一部の実施形態では、シーケンス番号１０３６を記憶サブシステムが生成して、特定のパーティションのデータ記録が記憶デバイスに書き込まれる順序を示すことができる。このように、膨大なデータ記録を所与の秒間で受信し、タイムスタンプ値１３０４がわずか約１秒の間隔で変換する実施形態では、シーケンス番号１３０６は、同じ秒内に到着することがあり、同じタイムスタンプ値を割り当てられるデータ記録の記録到着（または記憶）順を示す働きをすることができる。いくつかの実施形態では、パーティション番号１３０８はパーティションを所与のストリーム内で独自に特定することができる。シーケンス番号のタイムスタンプが対応するデータ記録を取得したクロック時間（少なくともおよその）を示す少なくとも一部の実施形態では、シーケンス番号を所定のタイプの時間ベースの取得要求用のインデックス機構に用いることができる。例えば、クライアントは特定の日または指定した時間の範囲の期間に生成されたまたは取得されたストリーム記録を検索したいと思うかもしれない。シーケンス番号を暗に示された副次的インデックスのキーとして使用すると、適切なデータ記録のセットを検索することができる。このように少なくともいくつかの実施形態では、規則正しい記憶及び検索用タイムスタンプを含むシーケンス番号を使用すると、１組の保存されたデータ記録の一時的なインデックスとして利用できるという利点をさらに有することができる。
所与のパーティションのデータ記録は一般にシーケンス番号順に書き込まれて（ディスクに）、大規模順次書き込み動作をよく用いる。一部の実施形態では、上述の通り、反復子ベースのプログラムインターフェースが実装されて、データコンシューマがシーケンス番号順にデータ記録を読み出しできるようにする。図１４は、少なくともいくつかの実施形態による、ＳＭＳでの規則正しいストリームデータ記録の記憶及び検索の実施例を示す。パーティションＳｊ−Ｐｋ（ストリームＳｊのｋ番目のパーティション）の６個のデータ記録１１０Ａ〜１１０Ｆがシーケンス番号順に保存された状態を示す。図示の通り、シーケンス番号は少なくとも一部の実施形態では、連続していない。例えば、上述した値をタイムスタンプ部分１３０４またはシーケンス番号１３０６に割り当てるやり方がこれらの要素では必ずしも連続の値にならないためである。
図１４で示す実施例では、データコンシューマは、起動シーケンス番号８６５を指定して、反復子を生成するよう要求した。要求に応答して、ＳＭＳは反復子１を初期化して、要求された起動シーケンス番号以上の最も近いシーケンス番号を有するデータ記録に配置した。この場合、次に低いシーケンス番号（データ記録１１０Ｂに割り当てられた８６０）が消費者の要求の起動シーケンス番号より小さいので、シーケンス番号８７０を有するデータ記録１１０Ｃが反復子の起動位置として選択された。ｇｅｔＩｔｅｒａｔｏｒインターフェースは、要求の論理同値にパーティション内の要求の位置にカーソルを設定させると考えることができ、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓインターフェースは、例えば、シーケンス番号順にストリームに沿ってカーソルを移動するなどカーソルの位置から始めてデータ記録を読み出すために使用され得る。図示の実施例では、データコンシューマは、パラメータ「ｉｔｅｒａｔｏｒ」をＩｔｅｒａｔｏｒ１に設定し「ｍａｘＮｕｍＲｅｃｏｒｄｓ」（返信のデータ記録の最大数）を３に設定して、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓインターフェースを呼び出した。それに応じて、ＳＭＳ検索サブシステムはデータ記録を１１０Ｃ、１１０Ｄ及び１１０Ｅの順でデータコンシューマへ返信する。反復子Ｉｔｅｒａｔｏｒ１は新しい位置に、例えば、データ記録１１０Ｆへ、移動してもよい。ｇｅｔＮｅｘｔＲｅｃｏｒｄｓの呼び出しが完了した後、その後ｇｅｔＮｅｘｔＲｅｃｏｒｄが同じ反復子を呼び出すとデータ記録の返信は１１０Ｆで始まることになる。ｇｅｔＩｔｅｒａｔｏｒの呼び出しの意味論はいくつかの実施形態で異なる可能性がある。例えば、いくつかの実施形態では、反復子を指定されたシーケンス番号以上で最も近いシーケンス番号を有するデータ記録に配置する代わりに、反復子を要求されたシーケンス番号以下の最も高いシーケンス番号を有するもっと近いデータ記録に配置してもよい。他の実施形態では、クライアントはｇｅｔＩｔｅｒａｔｏｒの呼び出しで存在するシーケンス番号を指定しなければいけない場合がある。例えば、要求したシーケンス番号がストリーム中に存在しない場合、エラーが返信される場合がある。
パーティションマッピング
上述の通り、種々のパーティション分割方針及び再パーティション分割方針にしたがった種々の実施形態では、所与のストリームの記録の取得、記憶、検索及び処理に関する作業負荷は、細分されて、いくつかのノードに分散することができる。図１５は、少なくともいくつかの実施形態による、ストリームパーティションマッピング１５０１及びＳＭＳ及びＳＰＳノード用になされた構成決定に対応する実施例を図示する。例えば、クライアントのｃｒｅａｔｅＳｔｒｅａｍ ＡＰＩの呼び出しに応答して、特定のデータストリームを生成する時または初期化した時、パーティション分割方針を、ストリームのいずれの所与のデータ記録もメンバとみなすパーティションを決定するために使用されるストリーム用に起動することができる。所与のデータ記録のための動作を実行する取得サブシステム２０４、記憶サブシステム２０６、検索サブシステム２０８及び任意の関連のあるＳＰＳ段階２１５の特定のノードは、記録パーティションに基づいて選択されてもよい。一実施形態では、所与のデータ記録のために使用される少なくとも１つのサブセットの制御ノードが同様にパーティションに基づき選択されてもよい。少なくともいくつかの実施形態では、データストリームの動的再パーティション分割は、例えば、方針に示されたトリガー条件に応答してまたは明示の要求に応答して、パーティション分割方針の一部分として支持され得る。
様々な実施形態では、所与のデータ記録のために選択されたパーティションはキーの値をデータプロデューサが直接（例えば、書き込みまたは要求のパラメータとして）または間接（例えば、識別子もしくはデータプロデューサクライアントの名前、データプロデューサのＩＰアドレスまたはパーティションキーとしてのデータ記録の実際のコンテンツの一部分などのメタデータをＳＭＳが使用する）に提供する記録用のパーティション分割キーに依存する。１つまたは複数のマッピング機能１５０６は、図１５に示す実施形態では、データ記録パーティションキーまたは属性１５０２に適用されて、データ記録パーティション識別子１５１０を決定することができる。例えば、ある実施形態では、所与のパーティション識別子１５１０は、１２８ビット整数値の空間を超える連続する範囲を表すことができ、その結果、ストリームのすべてのパーティションの範囲の結合により１２８ビット整数が装うことのできるすべての可能な値を覆うことができる。そのような実施例のシナリオでは、ある単純なマッピング機能１５０６が１２８ビットのハッシュ値をパーティションキー値またはデータ記録の選択の属性値から発生することができ、パーティション識別子をハッシュ値が不用意に横たわる特定の隣接する範囲に基づいて決定することができる。いくつかの実施形態では、隣接する範囲は少なくとも最初は同じ大きさであってもよく、他の実施形態では、別のパーティションは互いにサイズが異なる隣接する範囲と一致してもよい。また、再パーティション分割はある実施形態では、範囲の境界の調整という結果になる場合がある。他のパーティション分割機能１０６は別の実施に使用される場合がある。
データストリームが動的再パーティション分割を受ける場合（以下で詳細を説明するように）、特定のキーを備えた記録がマップされているパーティションが変化する。したがって、少なくともいくつかの実施形態では、ＳＭＳ及び／またはＳＰＳ制御ノードが、ストリームのライフタイムの期間、ストリームに適用するいくつかの異なるマッピングの記録を取らなければならない可能性がある。いくつかの実施形態では、タイムスタンプの有効範囲１５１１またはシーケンス番号有効範囲などのメタデータは制御ノードにより各パーティションマッピングに保存することができる。例えば、タイムスタンプの有効範囲１５１１は特定のマッピングＭ１がストリームの生成時からタイムＴ１まで適用され、別のマッピングＭ２がＴ１からＴ２まで適用されることなどを示すようになる。ストリームに向けられた読み出し要求に応答する時、検索ノードはどのマッピングを使うべきかを最初に決定しなければならず（例えば、読み出し要求に示すシーケンス番号により）、その後そのマッピングを適切な記憶ノードを指定するために使用することができる。
ＳＭＳ及びＳＰＳ制御ノードは少なくともいくつかの実施形態では、いくつかの異なる粒度で資源へのパーティションをマッピングする役割を持つことができる。例えば、図１５の実施例１５９９で示すように、ある実施形態では、各取得、記憶、検索、または処理（ワーカー）ノードを各プロセスまたは各実行されたスレッドとして、Ｊａｖａ（登録商標）Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ（ＪＶＭ）またはコンピュートインスタンスなどのサーバ仮想マシン内で実装することができる。そして、各ＪＶＭまたはコンピュートインスタンスは特定の物理ホストでインスタンス化される。いくつかの実施形態では、複数のＪＶＭはシングルコンピュートインタンス内で起動されて、資源マッピングを決定する他の層を加えることができる。したがって、所与のパーティションでは、１つまたは複数の制御ノードがどの特定の資源を取得ノード１５１５、記憶ノード１５２０、検索ノード１５２５、または処理段階ワーカーノード１５３０として使用するかを選択することができる（例えば、それぞれ段階ＰＳ１またはＰＳ２用にノード１５３０Ａまたは１５３０Ｂ）。制御ノードはまた、サーバ（取得サーバ１５３５、記憶サーバ１５４０、検索サーバ１５４５または処理サーバ１５５０など）、及びサーバとホスト間のマッピング（取得ホスト１５５５、記憶ホスト１５６０、検索ホスト１５６５またはＳＰＳホスト１５７０Ａ／１５７０Ｂ）へのこれらノードのマッピングを決定することができる。いくつかの実施形態では、パーティションマッピングは、例示された種々の資源の各粒度で（例えば、ノード、サーバ及びホスト粒度）識別情報を含む（例えば資源識別子）とみなされて、データ記録の属性の表示は機能または複数の機能１５０６への入力の際に使用することができ、複数の機能１５０６自身も同様である。制御サーバはメタデータ保存でパーティションマッピングの表示を保存し、いくつかの実施形態では、種々のＡＰＩ（ｇｅｔＰａｒｔｉｔｉｏｎＩｎｆｏ ＡＰＩなど）または他のプログラムインターフェースを明らかにして、マッピング情報をデータプロデューサ、データコンシューマ、またはＳＭＳサブシステムまたはＳＰＳのノードへ提供することができる。
パーティションへの及びパーティションから資源へのデータ記録のマッピングはいくつかの実施形態では、（ａ）所与のノード、サーバまたはホストが一部の実施形態では、複数のパーティションを管理するよう指定される、あるいは（ｂ）障害または他のトリガーは新しいノード、サーバ、もしくはホストが所与の１つのパーティションまたはパーティションのセットに割り当てられることになるなど、様々な要素のためにとても複雑になっていることがある。加えて、上述しまた以下で説明する通り、所与のストリームへのパーティションマッピングは時間とともに動的に修正されるが、ストリーム記録は引き続きＳＭＳ及び／またはＳＰＳノードにより扱われてもよい。その結果、いくつかのバージョンのメタデータのマッピングはいくつかの実施形態では、それぞれが異なる時間の期間に対応して、少なくとも一時的に所与のストリームに留めることができる。
ダイナミックストリーム再パーティション分割
図１６は少なくともいくつかの実施形態による、動的ストリーム再パーティション分割の実施例を図示する。図１６に示す時間帯の時間Ｔ１で、ストリームＳ１は生成または初期化される。パーティションマッピングＰＭ１はストリームＳ１のために生成されて、期間Ｔ１からＴ２の間、有効状態を継続する。Ｔ１からＴ２間でＳＭＳが受領する３つのデータ記録を実施例として示す。データ記録１１０Ａ（ＤＲ１１０Ａ）はクライアント提供のパーティションキー値「アリス」とともに提出され、ＤＲ１１０Ｂはクライアント提供のパーティションキー値「ビル」とともに提出され、またＤＲ１１０Ｃはクライアント提供のパーティションキー値「チャーリー」とともに提出される。初期マッピングＰＭ１では、３つのデータ記録１１０Ａ、１１０Ｂ及び１１０Ｃのすべてが同じパーティションにパーティション識別子「Ｐ１」を備えてマップされる。Ｐ１データ記録のために、単一ノードＩ１が取得を扱うため構成されて、単一ノードＳ１が記憶を扱うために構成されて、単一ノードＲ１が検索を扱うために構成されて、単一ワーカーノードＷ１がＳＰＳ処理を扱うために構成される。マッピングＰＭ１の有効範囲の起動タイムスタンプはＴ１に設定される。
時間Ｔ２では、ストリームＳ１は図１６の実施例の時間帯で動的に再パーティション分割される。データ記録は継続して到着して、図示の実施形態では、いつ再パーティション分割が起こったかにかかわりなく、ＳＭＳ及びＳＰＳにより取り扱われている。ＳＭＳもＳＰＳもオフラインにしなくてもよい。再パーティション分割は任意の複数の要素、例えば、取得、記憶、検索または処理ノードで過負荷条件の検出に応答する、種々のサブシステムの異なるホストでの作業負荷レベル間のゆがみまたは不均衡の検出に応答する、またはデータコンシューマまたはデータプロデューサクライアントからの要求に応答する、の結果として始まる。図示の実施形態では、ＰＭ２に示す有効範囲スタートタイムスタンプ設定が示すように、新しいマッピングＰＭ２が時間Ｔ２で（Ｔ２のわずか後）有効になる。少なくともいくつかの実施形態では、種々のデータ記録属性のセットが、再パーティション分割前に使用された以上にパーティション分割データ記録のために使用される場合がある。一部のケースでは、追加のパーティション分割属性はデータプロデューサが提出するが（例えば、ＳＭＳの要求で）、他のケースでは追加の属性をＳＭＳ取得ノードが生成することができる。そのような追加の属性は「塩で味をつけた」属性と呼び、再パーティション用に追加の属性を使用する技術は「加塩」と呼ぶことができる。ある実施例の実施形態では、過重負荷の取得サーバはデータプロデューサに（例えば、データプロデューサが実行したＳＭＳクライアントライブラリコードに）再パーティション分割用として、ランダムに選択した小さい整数値を以前使用したパーティションキーに追加して提供することを示す場合がある。元のパーティションキーと塩で味をつけた追加の整数の組み合わせは、その後、別の取得ノードのセット間で取得作業負荷を分散するために使用することができる。いくつかの実施形態では、検索ノード及び／またはデータコンシューマは、再パーティション分割に使用されている追加の属性に関して通知されなければならない場合がある。このような追加の属性は少なくともいくつかの実施形態では再パーティション分割に使用することができない。
図１６に示す実施形態では、新しいパーティションマッピングはＴ２以前に同じキー用に選択したパーティションに関係する、Ｔ２後に受信した少なくともデータ記録の一部のために選択された、異なるパーティションをもたらす。ＤＲ１１０ＰはＴ２後にパーティションキー値「アリス」を備えて提出され、ＤＲ１１０ＱはＴ２後にパーティションキー値「ビル」を備えて提出され、ＤＲ１１０ＲはＴ２後にパーティションキー値「チャーリー」を備えて提出される。ＰＭ２マッピングを使用すると、図示の実施例のシナリオでは、ＤＲ１１０Ｐはパーティションのメンバ「Ｐ４」を示され、ＤＲ１１０Ｑはパーティションのメンバ「Ｐ５」を示され、ＤＲ１１０Ｒはパーティションのメンバ「Ｐ６」を示される。図示の実施形態では、Ｔ２後に受信されたと示される実施例のデータ記録のいずれも以前使用したパーティションメンバ「Ｐ１」を示さない。代わりにまったく新しいパーティションが再パーティション分割後に使用されることになる。いくつかの実施形態では、少なくとも以前使用したパーティションの一部が再パーティション後に引き続き使用される場合がある。それぞれの新しいパーティションＰ４、Ｐ５、及びＰ６に対しては、取得、記憶、検索、及び／または処理用に異なるノードを示してもよい。例えば、ノードＩ４、Ｓ４、Ｒ４及びＷ４はパーティションＰ４用に構成され、ノードＩ５、Ｓ５、Ｒ５及びＰ５はパーティションＰ５用に構成され、ノードＩ６、Ｓ６、Ｒ６及びＰ６はパーティションＰ６用に構成されてもよい。いくつかの実施形態では、同じ記憶ノードは、再パーティション前に記録に使用されていたように、再パーティション後に特定のパーティションキーまたは属性を備える記録用に使用されてよいが、そのノード内の異なる記憶場所（例えば、別のディスク、別のディスクパーティションまたは別のＳＳＤ）が再パーティション後には使用されることになる。
Ｔ２での動的再パーティション後の少なくともある期間、再パーティション分割前にＳＭＳ取得及び／または記憶サブシステムが処理したデータ記録のために検索要求は継続して検索できる。少なくともいくつかのケースでは、要求されたデータ記録は、データ記録が取得されたときに有効であったＰＭ１マッピングに基づいて検索されなければならない。したがって、図１６で示す通り、データ検索のために、ＰＭ１及びＰＭ２両方ともＴ２後のある期間継続して使用することができる。少なくともいくつかの実施形態では、データ記録は古くなると結局ストリームから削除されることがあり、古いパーティションマッピングもまた、例えばすべての対応するデータ記録が削除されたとき、結局廃棄されることになる。いくつかの実施形態では、削除される代わりに（またはその前に）、ストリーム記録は別の１組の記憶場所またはデバイスにアーカイブされるので（クライアント選択のアーカイブ方針に基づき）、その結果、ＳＭＳが使用したパーティションマッピングはアーカイブ後も記録を検索することに使用することができる可能性がある。このような実施形態では、ＰＭ１及びＰＭ２などのパーティションマッピングは、アーカイブ記憶の方へ向かう検索要求を支援する必要がある限り維持されるものでもよい。アーカイブ実施の一部では、維持されるストリームパーティションマッピングを必要としない異なる検索アプローチを使うことができる（例えば、新しいインデックスがアーカイブされたデータ記録用に生成されてもよい）。いくつかの実施形態では、Ｐ２などのパーティションは再パーティション分割の前に使用されていても、再パーティション分割後はそれに対して書き込みはもはや向かわず、再パーティション分割後のある時点で「読み出し」を辞める可能性がある。例えば、「パーティション終端に到着」と同値のエラーメッセージが検索要求に応答して発生する可能性がある。
いくつかの実施形態では、所与のデータストリームは多数のパーティションに分割することができる（例えば、数百または数千）。ストリームＳ１が最初に１０００のパーティション、Ｐ１，Ｐ２，…，Ｐ１０００に分割される場合の実施例を考えてみよう。例えば、Ｐ７というあるパーティションに該当する過重負荷条件が検出された場合、Ｐ７に対するデータ記録の初期マッピングを変更することが有益かもしれないが他のパーティションのマッピングは変更する必要がない場合がある。あるアプローチでは、２つの新しいパーティションＰ１００１及びＰ１００２が再パーティション分割動作を介して生成される。再パーティション分割後に受信した記録は、その属性が元は（すなわち、元のマッピングに基づいて）Ｐ７内の構成員であることに結びついていたが、再パーティション分割後はＰ１００１とＰ１００２のどちらかにマップすることになり、したがいＰ７の作業負荷を２つのパーティション間に分散することができるようになる。残りのパーティション、例えば、Ｐ１〜Ｐ６及びＰ８〜Ｐ１０００は、修正する必要がないかもしれない。このような再パーティション分割によりほんのわずかなパーティションのサブセットが影響を受けるので、少なくともいくつかの実施形態では、パーティションエントリ（またはパーティションエントリのツリー）の有向非巡回グラフなどの複合型データ構造が生成され保存される。各エントリはパーティション分割機能出力範囲及び有効期間（エントリのパーティション分割情報が有効であると考えられる期間）を示すことができる。上記実施例では、Ｐ７を含む再パーティション分割を時間Ｔ２で実行するが、ストリームＳ１（及びその初期マッピング）は時間Ｔ１で生成されると仮定する。このようなシナリオでは、Ｐ７に関するエントリの有効期間はＴ１〜Ｔ２であろう。Ｐ１００１及びＰ１００２の有効期間は「Ｔ２以後」であり、残りのパーティションに対する有効期間は「Ｔ１以後」であろう。そのような複合データ構造を用いると、少なくともいくつかの実施形態では、パーティションマッピングメタデータに使用する記憶または保存容量が実質減少することになる恐れがある。上記実施例では、パーティションＰ７を２つの新しいパーティションに分割することが説明されている。少なくともいくつかの実施形態では、パーティションは再パーティション分割中に結合することも可能である。例えば、２つの隣接するパーティションのうち比較的検索要求の受信が少ない方、または比較的提出される記録が少ない方へ結合して１つのパーティションになることができる。いずれの所与の時点に対しても、データ記録が属するパーティションを、パーティション機能及び有効期間の情報を用いて明確に決定することができる。時間とともに複合データ構造はより分割及び／または結合を実行して展開するが、パーティション分割メタデータに要求される総空間（分割の頻度、及び分割が影響を及ぼすパーティション数量の平均による）は劇的に増加できない。反対に、別の実施形態では、再パーティション分割が起きる毎に、ストリーム用の変更しないメタデータの完全なセットの複製が作られて再パーティション分割により影響を受けるパーティションのエントリと結合することがある。パーティションマッピングメタデータに対する保存及び記憶の要求は、特に古いマッピングが、上述のように再パーティション分割後少なくともしばらくの期間、維持されなければならない場合、後者の実施形態でははるかに速いスピードで増える可能性がある。
タイムスタンプ値（図１３ｂに示すタイムスタンプ値１３０４など）を含むシーケンス番号が使用される少なくともいくつかの実施形態では、特別なタイプのシーケンス番号の変移が動的再パーティション分割のために実装される場合がある。図１３ｂに示すものと同様のタイムスタンプ型のシーケンス番号スキームが、新しいタイムスタンプ値がシーケンス番号に含まれるために毎秒発行されるストリームＳ１に使用されている実施例の方法で仮定してみよう。動的再パーティション分割に対応する少なくともいくつかの実施形態では、動的再パーティション分割後に割り当てられたシーケンス番号すべてが、動的再パーティション分割前に使用された以外の異なる１組のタイムスタンプ値（再パーティションイベントに対応する選択の初期タイムスタンプ値で始まる）を使う可能性がある。例えば、動的再パーティション分割が実行された時（すなわち有効になる）に使用されていたタイムスタンプ値がＴｋの場合、実行後に発行されたいずれかの新しいシーケンス番号もタイムスタンプ値Ｔｋ＋１を以後使用するよう要求される可能性がある。図１３ｂで使用されるスキームでは、シーケンス番号値は上位ビットの少なくとも一部でタイムスタンプ値をエンコードするので、説明したようにタイムスタンプの境界と一致する再パーティションイベントは、検索要求に応答して使用されるマッピングを特定することに含まれる記憶処理を確実に簡単にできる。したがって、このような実施形態では、特定のシーケンス番号を指定する検索要求を受信した場合、タイムスタンプ値はそのシーケンス番号から抽出されて、再パーティション分割後のマッピングを使うか、または再パーティション分割前のマッピングを使うべきかを簡単に決定することができる。抽出されたタイムスタンプ値が再パーティション用に選択された初期タイムスタンプより小さい場合、再パーティション分割前のマッピングが使用されて、抽出されたタイムスタンプ値が再パーティション用に選択された初期タイムスタンプ値以上の場合、再パーティション分割後のマッピングが使用されることになる。
ストリームマネジメント及びプロセッシング方法
図１７は、少なくともいくつかの実施形態によるストリーム記録取得及びストリーム記録検索のためのプログラムインターフェース各セットを支援するために実行される動作の態様を示す流れ図である。要素１７０１に示すように、データストリームを生成するまたは初期化する要求を、例えば、ＳＭＳクライアントまたはデータプロデューサクライアントから受領する。ストリームに使用される初期パーティションマッピングを決定し（要素１７０４）、例えば、特定のデータ記録が属するパーティションを特定するために使用される機能及びその機能のために使用される入力パラメータをパーティション分割方針に基づいて特定することができる。上述のように、種々の実施形態では、ＳＭＳの制御構成要素はストリーム生成要求を受信し応答する役割を持ってもよい。ストリームの生成及び初期化（同様に他の制御プレーン動作も）が実行されるやり方は、実施形態によって異なってもよい。例えば、一実施形態では、制御サーバの冗長グループが設定されて、その冗長グループの第１の制御サーバがストリーム生成の要求に、適切なメタデータを持続性記憶場所に新しいストリーム用（例えば、初期パーティションマッピング、取得ノード、記憶ノード、及び検索ノードの初期セットなど）に発生させて保存することにより応答することができる。ストリームに関する後続のクエリ（例えば、所与のパーティションを担当するバックエンドノードに関するフロントエンドの取得ノードからの要求）への応答は、第１の制御サーバが保存するメタデータを使用して発生させることができる。ＳＭＳ制御プレーン機能性の他の実施形態では、ストリーム構成メタデータは少なくとも取得、記憶、または検索サブシステムのノードの少なくとも一部により直接アクセス可能なデータベースに保存されていてもよい。ストリームが生成され、初期化された後、記録提出、記憶及び検索などのデータプレーン動作が始まり、通常、制御構成要素を備えた追加の相互作用なしに、対応するサブシステムの各構成要素により取り扱うことができる。
いくつかの実施形態では、データプロデューサは書き込み要求を伴う明示的パーティションキーを提出することを要求される場合があるが、他の実施形態では、パーティション分割機能に使用される入力は、データプロデューサのアイデンティティ、データ記録を受信したＩＰアドレス、またはデータ記録自体のコンテンツなど、書き込み要求に関連したメタデータに基づいて決定されてもよい。少なくともある実施形態では、クライアントはデータ記録提出の中のパーティション識別子を任意の方法で供給するが、そのような実施形態では、追加のパーティション分割機能を要求されることはない。
ストリームのために取得機能、記憶機能及び検索機能用のノードの初期セットを決定または構成する場合、いくつかの異なる要因を考慮に入れることができる（要素１７０７）。例えば、パーティションマッピング自体（ストリームを分割するパーティションの数及びパーティションの相対的期待サイズを決定することができる）、入手可能な期待取得レート及び／または検索レートについての情報、ストリームデータ記録に対する耐久性／持続性要求、及び／または種々のサブシステムに対する高い可用性要求（図９及び１０に図示したものと同様の冗長グループの設定に至る）は異なるサブシステムのノードの数及び配置に影響を与える可能性がある。さらに、クライアントがノードの様々なカテゴリに対する配置先のタイプの選好を示す実施形態では（図１１、１２ａ及び１２ｂに示すように）、そのような選好はまたＳＭＳ及び／またはＳＰＳノードに使用される資源を決定する１つの役割を担うことができる。少なくともいくつかの実施形態では、取得機能、記憶機能及び／または検索機能を実行可能なノードの各プールが事前に設定されて、制御構成要素がそのようなプールの選択したメンバを生成された各新しいストリームに割り当てることができる。他の実施形態では、ストリームが生成または初期化された時に、少なくとも一部のケースで新しい取得ノード、記憶ノードまたは検索ノードがインスタンス化されなければならない場合がある。
図示の実施形態の取得ノードで、例えばインライン提出インターフェース（データが提出要求に含まれる）及び参照提出インターフェース（アドレスが提出要求内に提供されるので、例えば、ウェブサービス要求または他のインターフェースを用いて、そこからデータをＳＭＳ取得ノードまたはＳＭＳ記憶ノードが検索することができる）を含むデータ記録提出用に実装された任意の１組のプログラムインターフェースを介して記録を受信することができる（要素１７１０）。別の実施形態では、例えば、各アプリケーションプログラミングインターフェース（ＡＰＩ）がインライン対参照提出に対応して、ウェブページまたはウェブサイトを設立し、グラフィカルユーザインターフェースを実装、またはコマンドラインツールを開発するなど、任意の複数の別のタイプのプログラムインターフェースを、記録を提出するための各方法用に提供することができる。少なくともいくつかの実施形態では、ＳＭＳはシーケンス番号を各取得記録に割り当てることができて、例えば、記録が取得されて保存された順序を示し、シーケンス番号がデータコンシューマの検索要求に使用可能になる。検索システムノードで、記録検索要求は任意の１組の実装されたプログラム検索インターフェースを介して受領することができ、要求したデータ記録のコンテンツは応答して提供される（要素１７１３）。非順次アクセスのために、例えば、インターフェースはＧｅｔＩｔｅｒａｔｏｒ（ｇｅｔＩｔｅｒａｔｏｒ呼び出しに示すシーケンス番号に基づいて反復子をパーティション内で選択された位置でインスタンス化するように要求する）またはｇｅｔＲｅｃｏｒｄＷｉｔｈＳｅｑｕｅｎｃｅＮｕｍｂｅｒ（指定のシーケンス番号を備えたデータ記録を取得すること）を含んでもよい。順次アクセスのために、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓなどのインターフェース（反復子の現在の位置または指定のシーケンス番号から始まる複数の記録を順番に要求する）が、実装されてもよい。少なくともいくつかの実施形態では、異なる検索インターフェースはそれらに関する異なる課金レートを有してよい。例えば、順次検索用の記録毎の課金レートは非順次検索用の記録毎の課金レートより低く設定されてもよい。また、いくつかの実施形態では、別の提出インターフェースは異なる課金レートを有することができる。例えば、参照提出はインライン提出より記録毎の費用が高くてもよい。
時間が経つに連れ、制御ノードまたは専門の課金サーバが、ストリーム管理サービス（要素１７１６）の様々なサブシステムで実装された別のプログラムインターフェース用の使用測定基準を収集することができる。測定基準は、例えば、異なるプログラムインターフェースの呼び出し回数、取得された記録または検索された記録の総数（１回の呼び出しで複数の記録を検索することに使用できるｇｅｔＮｅｘｔＲｅｃｏｒｄｓなど少なくともいくつかのインターフェースに対する呼び出し回数と異なる）、取得されたデータまたは検索されたデータの総量などを含むことができる。ストリームを所有するクライアント、またはデータを生成するクライアント及び／またはストリームからのデータを消費するクライアントに課金される請求額は、少なくとも一部、使用測定基準及びプログラムインターフェースに関連する各課金レート（要素１７１９）に基づいて任意の方法で発行されてもよい。少なくともいくつかの実施形態では、課金作業はストリームの取得動作／検索動作に対して非同期でもよい。例えば、請求書は月中に収集された測定基準に基づき毎月の請求期間の終わりに発行されてよい。
図１８ａは、少なくともいくつかの実施形態によりストリーム処理段階（ＳＰＳ）を構成するよう実行される動作の態様を示す流れ図である。要素１８０１に示すように、プログラムインターフェースは、クライアントがストリームデータ記録の処理段階の数を構成することができるよう実装されてもよい。例えば、特定の段階を構成するために、クライアントは段階でパーティション分割されたストリームデータ記録上で実行されるべき処理動作、処理動作の出力のための分散方針、ならびに処理すべきデータを取得すべき入力ストリームのアイデンティティなどの他のパラメータを示すことができる。いくつかの実施形態では、ＳＰＳ段階での処理動作は冪等であることを要求できる。他の実施形態では、冪等でない動作も少なくとも一部の段階でサポートされてもよい。所与の段階で実行されるべき処理が冪等でない場合でも、クライアントはいくつかの実施形態で、定期的に動作の出力をある持続性の外部の場所に向けて洗い流すようにワーカーノードを構成し、その洗い流し操作が記録検索シーケンスに対して実行される場合に記録し、また後にリカバリ中の洗い流し操作を再現するよう交換ワーカーノードを構成することにより、リカバリ関連の冪等性の利点を得ることができる。少なくとも一部の実施形態では、並行してストリームデータで動作しているいくつかの異なる状態及び一部の段階の結果を他の段階のための入力ストリームとして使用して、クライアントが有向非巡回グラフ（ＤＡＧ）または他の処理段階のグラフを構成することができてもよい。一部の実施形態では、例えば、ある段階からのデータ記録出力は異なる段階へ入力として与えられるまでは持続性記憶デバイスに保存される必要がなく、持続性ストリームよりは１つまたは複数の一時的ストリームが、異なる段階間で生成されてもよいことがある。
任意の複数の異なるリカバリ方針はいくつかの実施形態では、例えば、チェックポイント型リカバリ方針またはベストエフォートリカバリ方針を含んでＳＰＳ段階で実装されてもよい。一実施形態では、クライアントは異なるＳＰＳ段階用にリカバリ方針を選択するためにプログラムインターフェースを使用してもよい。チェックポイント型リカバリが使用される段階では、ワーカーノードが、ストリームのパーティション内でどこまで到達したかを示す（例えば、最近処理された記録のシーケンス番号が進行の表示として保存される）間隔毎に、進行記録またはチェックポイントを保存するよう構成されてもよい。進行記録は、図１９を参照して以下で説明するように、故障後、後のリカバリ動作中に使用される。ベストエフォートリカバリ方針では、進行記録は保存される必要がなく、障害に応答して構成された交換ワーカーノードが単純に新しいデータ記録を受信した際に処理することでよい。所与のＳＰＳ段階グラフまたは作業フローでは、いくつかの実施形態で異なるリカバリ方針が異なる段階に適用されることがある。
ＳＰＳ制御サーバは、例えば、要素１８０１に示す１つのプログラムインターフェース経由で、出力分散記述子ＤＤｅｓｃ１にしたがって分散されるべき処理の結果を備え（要素１８０４）、パーティション分割方針ＰＰｏｌ１にしたがってストリームＳ１の特定の段階ＰＳ１で実行される冪等動作Ｏｐ１の表示を受信することができる。状態ＰＳ１用に構成されるワーカーノードの数及びノードに必要な仮想または物理資源は、Ｐｐｏｌ１、冪等動作Ｏｐ１の複雑さ及びワーカーノード用に使用される資源の性能（要素１８０７）などの様々な要因に基づいて、決定される。
ワーカーノードは例えば、選択の仮想または物理機械装置資源でのプロセスまたはスレッドとして、インスタンス化されてもよく、また構成されてもよい（要素１８１０）。例えば、ある単純な実施形態では、あるワーカーノードが初期にＳ１の各パーティションに割り当てられてもよい。所与のワーカーノードは、（ａ）データ記録をＳ１の検索ノードの適切なサブセットから受信する、（ｂ）受信したデータ記録上でＯｐ１を実行する、（ｃ）任意の方法で、例えばＰＳ１に対するリカバリ方針に基づいて、どのセットのパーティション記録が処理されたかを示す進行記録／チェックポイントを保存する、（ｄ）出力をＤＤｅｓｃ１が示す先へ送信する（例えば、持続性ストリームまたは一時的ストリームの間へ、または直接、他の処理段階または記憶システムへ入力するように）よう構成されてもよい。少なくとも一部の実施形態では、ＳＰＳ処理が、継続的に他の場所へ送信されなければならない出力を発生する必要はないかもしれないことに留意されたい。例えば、いくつかのＳＰＳアプリケーションは単純に一時的なデータ記録の保存場所として働き、及び／またはユーザがデータ記録を見るようにできるクエリインターフェースを実装することができる。そのようなアプリケーションはそれ自体の出力を管理することができ、例えば、出力は分散記述子にしたがってではなく受信したクエリに応答して発生される。ログ関連のＳＰＳアプリケーションは、大規模分散システムから取得した最後の日のログ記録を維持することができ、例えば、クライアントがデバッグまたは解析目的でログデータを見ることができるようにする。したがって、一部の実施形態では、出力分散記述子は少なくともＳＰＳの一部の段階、少なくとも一部のストリーム、または少なくとも一部のパーティションでは特定される必要がない。そして、ワーカーノードはデータ記録の検索及び処理を各構成の設定毎に開始することができる（要素１８１３）。ＳＰＳ制御ノードはワーカーノードのヘルス状態（例えばハートビートプロトコルなど応答性チェックを使って）ならびに少なくとも一部の実施形態でワーカーノードに使用されている資源で資源利用率レベルなどの様々な他の測定基準（要素１８１６）を監視することができる。ワーカーノードから収集される情報は、例えば、ワーカーノードを交換して、以下で説明するリカバリ方針を実装する場合、フェールオーバーが必要かどうかを決定することに使用することができる。
いくつかの実施形態では、インストール可能なＳＰＳクライアントライブラリを、クライアント所有の施設で及び／またはクライアント選定のプロバイダ網の資源でＳＰＳワーカーノードを実装したいクライアントに提供してもよい。また、クライアントライブラリはＳＰＳクライアントが、ヘルス監視機能、自動作業負荷監視及び調整、セキュリティ管理、動的再パーティション分割などのＳＰＳ管理型サービスの様々な制御プレーン機能を使用したい範囲を選択できるようにすることができる。図１８ｂは少なくともいくつかの実施形態による、ストリーム処理ワーカーノードの構成用にクライアントライブラリの構成要素の呼び出しに応答して実行される動作の態様を示す流れ図である。要素１８５１に示すように、ＳＰＳクライアントライブラリを提供することができる（例えば、図１８ａに示す種類の操作を実行するよう構成可能なマルチテナントＳＰＳ管理型サービスのウェブサイトからのダウンロードを介して）。ライブラリは複数の実行可能な構成要素及び／またはクライアントのアプリケーションとつながることができる構成要素を含んでもよい。一部のライブラリ構成要素は，クライアントが、１つまたは複数のＳＰＳ段階のストリーム処理動作が実行される種々のワーカーノードを選択し、ＳＰＳ管理型サービスに登録し、または所望のプロパティを指定することができるようにする。例えば、一方のクライアントはワーカーノード用にプロバイダ網の仮想コンピューティングサービスを実装する自身が所有するコンピュートインスタンスのセットを使用したいと思う可能性があるが、他方のクライアントはストリーム記録を処理するためにクライアントが所有するデータセンタ（プロバイダ網に対応していない特別目的装置など）に配置されているコンピューティング装置を使用したいと思う可能性がある。クライアントはワーカーノードを自身が所有する施設で必要に応じてオンラインにつなぐ、または希望通りに、仮想コンピューティングサービスのコンピュートインスタンスを使用することができる。そのようなワーカーノードのオンデマンドインスタンス化に追加してまたは代わりに、いくつかの実施形態では、クライアントは必要な時に展開可能な将来再利用可能なワーカーノードのプールを事前設定することができる。いくつかの実施形態では、ライブラリ構成要素は実行されてまたは呼び出されて、クライアントが、ＳＰＳ管理型サービスに、指定の段階のワーカーノードとしてクライアントにインスタンス化された特定のプロセスまたはスレッドを登録できるようにして、後続の制御プレーン動作をＳＰＳ管理型サービスにより取り扱うことができるようにする。一実施形態では、クライアントは、種々のレベルの制御プレーンの中からワーカーノード用ＳＰＳ管理型サービスにより扱われる役割を選択することができる。例えば、一方のクライアントは自身が所有する特別注文のモジュールをワーカーノードのヘルスを監視するために使用したいと考える可能性があるが、他方のクライアントはＳＰＳ管理型サービスを利用してワーカーノードのヘルスを監視して障害を検出した場合、適切な作業を取れるようにしたいと考える可能性がある。
ＳＰＳ管理型サービスは特定のクライアントが、ワーカーノード及び／または特定のＳＰＳ段階ＰＳ１の制御プレーン動作を構成するクライアントライブラリを使いたいと思う兆候を受け取ることができる（要素１８５４）。（ＰＳ１自体はライブラリに含まれるプログラムインターフェースを使用する、または図４に示すウェブベースインターフェースと同様のＳＰＳ管理型サービスにより公開されたプログラムインターフェースを使用する目的で作成されたものでもよい。）クライアントは、またストリームのデータがＰＳ１による入力として使用するため検索されるべきであると示す。少なくともいくつかの実施形態では、任意の方法で、クライアントはＰＳ１用の制御プレーンの設定、例えば、クライアントがノード用サービスのヘルス監視機能を使いたいかどうか、または特別注文のヘルス監視ツールを使いたいと思っているかどうか（要素１８５７）を示す。クライアントが示した選好により、クライアントの使用に合わせて構成されるＳＭＳ及び／またはＳＰＳの１つまたは複数のノードを決定することができる（要素１８６０）。ネットワーク接続性がクライアントのワーカーノードとＳＭＳ／ＳＰＳノード間で設定され、及び／または他の構成操作が所望通りにデータ記録の流れ及び処理結果ができるよう実行される。データ記録は検索要求を受信後ＳＰ１ワーカーノードに提供されて、所望の制御プレーン動作（何かクライアントが要求した場合）は、必要に応じて実行される。少なくともいくつかの実施形態では、クライアントがＳＭＳ管理型サービスの種々のサブシステムの制御プレーンの機能を使いたいと思う範囲を制御できるようにする同様のアプローチがまた、または代わりに実装されることに留意されたい。
図１９は、少なくともいくつかの実施形態によるストリーム処理のための１つまたは複数のリカバリ方針を実装するよう実行される動作の態様を示す流れ図である。要素１９０１に示すように、ＳＰＳ制御ノードは、例えば、ワーカーノードが無反応または不健康になる、現在のノードの作業負荷レベルがフェールオーバーの閾値に到達する、ワーカーノードで検出されるエラーの数が閾値を超える、またはある別の予期しないワーカーノードの状態が確認されたなどにより、特定のワーカーノードを交換するトリガー基準を満たしたと判定してもよい。交換ワーカーノードは特定されるまたはインスタンス化されてもよい（要素１９０４）。いくつかの実施形態では、可用性ワーカースレッドのプールが設定されると、例えば、そこから１つが交換用として選定されるか、または新しいスレッドもしくはプロセスが起動されてもよい。
ベストエフォートリカバリ方針が、特定のワーカーノードが稼働中（要素１９０７で決定したように）のＳＰＳ段階で使用される場合、交換ワーカーノードは単純に追加のデータ記録が入手可能になり次第それを処理し始め（要素１９１６）、例えば、交換済みワーカーノードの進行状況の記録を調査する必要はない。チェックポイント型リカバリ方針を使用する場合、交換ワーカーノードが交換済みワーカーノードにより保存された進行記録にアクセスする場所の表示（例えば、記憶装置のアドレスまたはＵＲＬ）が提供される（要素１９１０）交換ワーカーノードは、交換済みノードが保存した最近の進行記録を検索して、進行記録を使って交換ワーカーノードが段階の冪等性動作を実行すべき１組のデータ記録を決定することができる（要素１９１３）。そのようなチェックポイント型リカバリ方針では、最後の進行記録と交換ワーカーノードがインスタンス化される時間との間の期間と同様に交換済みワーカーノードが保存された進行記録に続く追加の記録を処理したレートによっても一部のデータ記録が２回以上処理される可能性がある。実行された動作が冪等である場合、そのような反復動作は少なくともいくつかの実施形態では負の効果を与えることはない。交換ワーカーノードが早期に保存された進行記録に基づいた反復リカバリ動作を実行した後で、少なくともいくつかの実施形態では交換ワーカーノードのスレッドはリカバリが完了したことを示す自身の進行記録を保存して、通常のワーカースレッド動作を新しく受信したデータ記録上で始めることができる（要素１９１６）。
図２０は、少なくともいくつかの実施形態によるデータストリーム用の複数のセキュリティオプションを実装するために実行される動作の態様を示す流れ図である。要素２００１に示すように、クライアントが、例えば異なる機能カテゴリのノード用（例えば、取得、記憶、検索、処理または制御ノード）の配置先タイプのオプションを含むデータストリーム管理及び処理用の種々のセキュリティオプションから選択することができる１つまたは複数のプログラムインターフェースを実装することができる。配置先タイプはそのセキュリティプロファイルの種々の態様の中で互いに異なる。ＳＭＳまたはＳＰＳノードに使用される資源の物理場所はいくつかの実施形態では配置先タイプ毎に異なってもよい。例えば、プロバイダ網のデータセンタに配置されたインスタンスホストなどの資源、クライアント所有の施設にある資源、またはサードパーティ資源はノード用に使用されてもよい。ネットワーク隔離レベルまたは他のネットワーキング特性は少なくともいくつかの実施形態では、配置先タイプ毎に異なってもよい。例えば、ＳＭＳまたはＳＰＳノードの一部は隔離された仮想ネットワーク内、または専用の隔離された物理リンクを介してプロバイダ網に接続されたクライアント所有の施設でインスタンス化されてもよい。一実施形態では、クライアントは所定のタイプのＳＭＳまたはＳＰＳノードを、入手可能なマルチテナントインスタンスホストを使用する代わりに、プロバイダ網のシングルテナントインスタンスホストで設定すべきことを示す可能性がある。少なくともいくつかの実施形態では、種々のタイプの暗号化オプションもセキュリティ関連のプログラムインターフェースを介して選択可能であってもよい。
ストリームＳ１用の１つまたは複数の機能カテゴリのノードに関するクライアントのセキュリティプロファイルの選択または選好はセキュリティ関連のプログラムインターフェースを介して受領することができる。例えば、クライアントは機能カテゴリＦＣ１（例えば、クライアントはクライアント所有の施設でＳＰＳワーカーノードを実装したいと思う可能性がある）のノード用のあるセキュリティプロファイル及び別の機能カテゴリＦＣ２（例えば、クライアントはプロバイダ網のデータセンタでＳＭＳ取得ノードまたは記憶ノードを実装したいと思う可能性がある）のノード用の別のセキュリティプロファイルを選択することができる（要素２００４）。一部のケースでは、クライアントは同じセキュリティプロファイルを備える種々の機能カテゴリのすべてのノードを設定することを決定してもよい。ＳＭＳ及び／またはＳＰＳはいくつかの実施形態では、種々の機能カテゴリのための初期設定の配置先タイプを画成することができる。例えば、特にクライアントが示さない限り、すべての機能カテゴリのノードはプロバイダ網の隔離された仮想ネットワーク内で設定されてもよい。
様々な機能カテゴリのノードはセキュリティプロファイル及び／または場所に対するクライアントの選好に基づいて構成されてもよい（またはクライアントが選好を示さない機能カテゴリ用の初期設定に基づいて）（要素２００７）。例えば、構成は適切な物理ホストまたは機械装置を選択すること、適切なコンピュートインスタンス、仮想機械装置、プロセス及び／またはスレッドを種々の機能カテゴリのノード用にインスタンス化すること、及びノード間の適切なネットワーク接続を設立することを含んでもよい。いくつかの実施形態では、異なるストリーム管理及び処理機能用の実行可能ライブラリ構成要素が構成の一部分としてプロバイダ網の外にあるホストで設置用に提供されてもよい。
少なくともいくつかの実施形態では、暗号化モジュールを、例えば、クライアントが示した暗号化の選好にしたがって、または暗号化初期設定に基づいて１つまたは複数のノードのカテゴリで起動することができる（要素２０１０）。種々の機能カテゴリのノードを起動すると、その結果、ストリームデータがクライアントの所望の通り取得、保存、検索及び／または処理される（要素２０１３）。
図２１は、少なくともいくつかの実施形態による、データストリームのパーティション分割方針を実装するために実行される動作の態様を示す流れ図である。要素２１０１に示すように、パーティション分割方針をデータストリーム用に決定することができる。方針は、例えば、データプロデューサが提供するキーまたは提出されたデータ記録の様々な属性に基づいたパーティションに対するデータ記録の初期マッピングならびにデータストリームを再パーティション分割するための１つまたは複数のトリガー基準を含んでもよい。一部の実施形態では、例えば、ハッシュ機能を１つまたは複数のパーティションキーに適用して、１２８ビットの整数ハッシュ値を生じることができる。考えられる１２８ビットハッシュの範囲をＮ個の連続するサブ範囲に分割すると、それぞれがストリームのＮ個のパーティションの１つを示すことができる。パーティションの数及び／またはサブ範囲の比較サイズはいくつかの実施形態では、ストリーム毎に異なる可能性がある。少なくともいくつかの実施形態では、クライアントを代表するストリームが構成されていてそのクライアントが、例えば、所望のパーティションの数、または使用されるパーティション機能の所望の特性など使用されるパーティションスキームに関する入力を提供してもよい。少なくとも一実施形態では、クライアントはパーティション識別子、またはサブセットの一部、または提出されたデータ記録のすべての名前を提供することができる。
ストリームのデータ記録を受信すると、提供のキー及び／または他の属性に基づいてその各パーティションを決定して、適切な取得、記録及び検索ノードのセットを指定されたパーティションに選択することができる（要素２１０４）。少なくともいくつかの実施形態では、各シーケンス番号を、例えば、所与のパーティションの記録を受信した順序を示すデータ記録用に生成する（要素２１０７）。いくつかの実施形態では、シーケンス番号はタイムスタンプ値（例えば、既知の紀元、協定世界時１９７０年１月１日００：００：００から経過した秒数）、記憶サブシステムから取得したサブシーケンス値、ＳＭＳソフトウェアのバージョン番号、及び／またはパーティションの識別子などの複数の要素を含んでもよい。いくつかの実施形態では、シーケンス番号を、例えば、提供されたデータ記録をうまく取得したことを知らせるためにデータプロデューサに供給してもよい。いくつかの実施形態では、シーケンス番号をデータコンシューマが使用して、ストリームまたはパーティションのデータ記録を取得順に検索することができる。
少なくともいくつかの実施形態では、データ記録は、パーティション分割方針に基づいてデータ記録を誘導する記憶ノードでシーケンス番号順に保存されてもよい（要素２１１０）。回転磁気ディスク記憶装置を用いる実施形態では、一般に順次書き込みを使用して受信データ記録をディスクに保存するので、ディスクのシーク遅れを回避することができる。少なくともいくつかの実施形態では、記録をディスクに保存する前に、例えば、ディスクシークの可能性をさらに減らすため、不揮発性バッファをライトキャッシュとして使うことができる。シーケンス番号順に並べられた多数のデータ記録の読み出し要求に応答して（例えば、ｇｅｔＮｅｘｔＲｅｃｏｒｄｓまたは同様のインターフェースの呼び出し）、記憶装置からの順次読み出しを使ってデータ記録を後で読み出すことができる（要素２１１３）。
図２２は、少なくともいくつかの実施形態によるデータストリームの動的再パーティション分割を実装するために実行される動作の態様を示す流れ図である。要素２２０１に示すように、ストリームは動的に再パーティション分割されるという決定がなされる（例えば、ＳＭＳまたはＳＰＳの制御構成要素で）。１つまたは複数の取得、記憶、検索、処理または制御ノードでの過重負荷の検出、または、異なるノードの作業負荷レベルの不均衡、またはクライアント（例えば、データプロデューサまたはデータコンシューマ）から受領した再パーティション分割の要求など複数の種々のトリガー条件によりストリームを再パーティション分割する決定がなされる。クライアントの再パーティション分割要求は、いくつかの実施形態では、生成される修正されたマッピングの種々のパラメータなど（例えば、追加されるまたは削除されるパーティションの数、どの特定のパーティションを結合するべきかまたは分割するべきか、など）要求された再パーティション分割の特定の詳細を含んでもよい。ある実施形態では、クライアントの再パーティション分割要求はクライアントが解決したい問題状態（負荷不均衡など）を示してもよく、ＳＭＳまたはＳＰＳは問題状態の記述を適切な再パーティション分割動作へ変換する役割を持つことができる。いくつかのケースでは、再パーティション分割の要求または問題状態の記述の代わりに、クライアントは再パーティション分割のために使用されるトリガー基準を特定することができる。いくつかの実施形態では、例えば、ストリーム記録用の異なる１組の記憶装置または異なる記憶技術の選択につながるデータストリームのデータ耐久性要求への変更の決定は再パーティション分割のきっかけとなる可能性がある。データストリームの使用パターンに対する変化の検出（例えば、データ記録が生産されまたは消費されるレート）もまた、いくつかのケースでは、再パーティション分割をもたらし、また変更した使用パターンのためにより適切な別の記憶技術の使用または別の１組の記憶装置の使用ももたらす。例えば、再パーティションの決定は、所与のパーティションまたはストリーム全体に対する期待する読み出し及び書き込みのレートに対して、ＳＳＤが回転磁気ディスクよりも適切な記憶技術であるという決定に基づいていてもよい。予定されたまたは差し迫ったソフトウェア及び／またはハードウェアのバージョン変更が一実施形態では、再パーティション分割のきっかけとなる可能性がある。いくつかのケースでは、異なるパーティション分割アプローチまたは異なる記憶へのアプローチを使用することでより効果的に予算制約が満たされることをクライアントが示すことが、価格または請求の懸念も再パーティション分割のきっかけとなる可能性がある。変更した性能目標もまた少なくともいくつかの実施形態では再パーティション分割のきっかけとなる可能性がある。図２２で図示する実施形態では、再パーティション分割後割り当てられたシーケンス番号用に使用される初期タイムスタンプ値（協定世界時１９７０年１月１日００：００：００からの秒数の差、一般にいくつかのオペレーティングシステムでシステムコールを介して入手可能な紀元値）を選択することができる（要素２２０４）。いくつかの実施では、プロバイダ網で実装されたグローバル状態マネージャがｇｅｔＥｐｏｃｈＶａｌｕｅ ＡＰＩに対応することにより、例えば、ＳＭＳ及び／またはＳＰＳの様々な構成要素がシーケンス番号発行のために使用する一貫性のあるタイムスタンプ値を取得することができるようになる。他の実施形態では、他の時間資源を使用して、例えば、ＳＭＳまたはＳＰＳ制御ノードを指定して、他の構成要素に対して一貫して順に並ぶタイムスタンプ値を提供する、またはローカルシステムコールの呼び出しを用いることができる。いくつかの実施形態では、タイムスタンプ値は、例えば、単調に増加するカウンタの整数値を単純に使うので、特定の任意のホストの実際の経過時間と一致する必要はない。
再パーティション分割の決定時に使用中のマッピングと異なる、修正されたパーティションマッピングをストリーム用に生成してもよい（要素２２０７）。少なくともいくつかの実施形態では、変更したマッピングは特定のパーティションキーを備えたデータ記録を、同じキーを備えたデータ記録が再パーティション分割前にマップされた以外の異なるパーティションへマップしてもよい。再パーティション分割のトリガー条件及び／または観測された作業負荷測定基準によって、一部のパーティション（一般に使用頻度の高いパーティション）は分割されるが、他の（一般に使用頻度の低い）パーティションは結合される可能性がある。いくつかの実施形態では、再パーティション分割前と再パーティション分割後で、例えば、別のハッシュ関数を使用する、またはパーティションへのハッシュ関数の成果としての一区分への別のアプローチを使用するなど、別のパーティション分割機能が使われてもよい。例えば、パーティションが１２８ビット整数の連続する範囲に相当する一部の実施では、１２８ビット整数空間は、再パーティション分割後に別の１組のサブ範囲に分割されてもよい。少なくとも一部の実施形態では、取得ノード、記憶ノード、検索ノード、処理ノードまたは制御ノードの新しいセットは新しく生成されたパーティションに割り当てられる可能性がある。一部の実施形態では、空間効率の良い複合データ構造が初期マッピング及び修正されたマッピングを代表して使用されてもよい（要素２２０８）。例えば、各エントリがパーティション分割機能出力範囲（例えば、所与のパーティションに相当するハッシュ関数の結果のパーティション分割の範囲）及び有効期間範囲を含む有向非巡回グラフまたはツリー構造を保存すると、その結果、修正されたパーティションに相当する記録だけが再パーティション分割の結果、変更されなければならない可能性がある。再パーティション分割の間、変更しなかったパーティション用のエントリはデータ構造中で修正される必要がないかもしれない。新しいノードは修正されたパーティションマッピングを実装するよう構成されてもよい（要素２２１０）。少なくともいくつかの実施形態では、以前のマッピングに基づいて保存されたデータ記録の検索要求は少なくともしばらくの間、受信され続けるので、以前のノード及び以前のマッピングはしばらくの間、維持される可能性がある。特定のシーケンス番号またはタイムスタンプを指定する読み出し要求を受信した場合（要素２２１３）、読み出し要求が新しいパーティションマッピングを使用すると満たされるのかまたは以前のパーティションマッピングを使用すると満たされるのかにしたがって、決定がなされてもよい（例えば、制御ノードまたは検索ノードで）。そして、選択されたマッピングを、要求されたデータが取得される適切な記憶ノードを指定するために使用することができる。
図２３は、少なくともいくつかの実施形態によるデータストリーム記録用の少なくとも一度記録取得方針を実装するよう実行される動作の態様を示す流れ図である。要素２３０１に示すように、１つまたは複数のプログラムインターフェースを実装して、クライアントが、例えば、（ａ）肯定応答を受信するまで記録サブミッタが１つまたは複数の記録を提出することにしたがう少なくとも一度方針、または（ｂ）少なくとも一部の記録提出に対する承認が得られないことにしたがうベストエフォート取得方針を含むいくつかの取得方針オプションの中からデータストリーム用記録取得方針を選択できるようになってもよい。データ生産をするクライアントの一部は、他のクライアントほど、自身の記録のわずかな部分がなくなる可能性を心配することはないのでベストエフォート取得のアプローチを選択する可能性がある。いくつかの実施形態では、ベストエフォート方針はすべてのデータ記録に対して承認を要求しないにも関わらず、ベストエフォート取得用に構成されたストリームに対してさえ、ＳＭＳは一部のサブセットのデータ記録に対して承認を与える場合があり、すべてのデータ記録に対してさえも承認を与えようとする場合がある。
プログラムインターフェースの１つを介して、指定のストリーム用に使用される特定の取得方針を示す要求を受信することができる（要素２３０４）。取得ノードは、ストリームに対して実施されているパーティション分割方針にしたがってインスタンス化されてもよい（要素２３０７）。１つまたは複数の同じデータ記録の提出を取得ノードで受信した場合（要素２３１０）、実施中の取得方針によって異なる動作が取られてもよい。少なくとも一度取得方針が実施中の場合（要素２３１３で決定されたように）、承認は、１つまたは複数の各提出に対してデータプロデューサへ送信されるが、データ記録は記録サブシステムで一度しか保存されなくてもよい（２３１６）。（ストリームに実施中の持続性方針にしたがって、一部のケースではＮ個の所与の記録の複製は保存されるかもしれないが、所与のデータ記録がＭ度、提出される場合、複製は１度の提出に対してのみ生成されることに留意されたい。すなわち、保存される記録の複製の総数は、ずっとＮ個であり、ＮｘＭ個ではない。）ベストエフォート取得方針が実施中の場合（これも要素２３１３で検出される）、データ記録はまたも記憶デバイスで１度保存されるが、データプロデューサに承認を送付する必要はない（要素２３１９）。少なくともいくつかの実施形態では、クライアントの請求額は少なくとも選択の取得方針に一部基づいて任意の方法で決定されてもよい（要素２３２２）。先に注意したように、一部の実施形態では、２つのバージョンの少なくとも一度取得方針に対応することができる。一方のバージョンでは、図２３で図示されたものと同様に、ＳＭＳがデータ記録を重複排除する役割を持ってもよい（すなわち、ＳＭＳ記憶サブシステムで２つ以上の提出セットの１つだけに応答してデータを確実に保存する）。別のバージョンの少なくとも一度取得では、ＳＭＳがデータ記録の複製を行うことが許されてもよい。後者のアプローチはデータ記録複製の否定的な結果がほとんどないストリームアプリケーション及び／または独自の複製除去を実行するストリームアプリケーションにとって役立つ可能性がある。
図２４は、少なくともいくつかの実施形態によるデータストリーム用の複数の持続性方針を実装するために実行されてもよい動作の態様を示す流れ図である。要素２４０１に示すように、複数の持続性方針の中からストリームデータ記録用にクライアントが選択することができる１つまたは複数のプログラムインターフェースを実装することができる。持続性方針は任意の種々の態様において互いに異なる可能性がある。例えば、（ａ）保存される複製の数が異なる（例えば、Ｎ個の複製対２個の複製対単一の複製方針に対応する）、（ｂ）記憶場所／使用されるデバイスの型が異なる（例えば、回転磁気ディスク対ＳＳＤ対ＲＡＭ対データベースサービスまたはマルチテナント記憶サービス）及び／または（ｃ）方針は大規模障害への期待される強度の程度で異なる（例えば、多重データセンタ対単一データセンタ方針に対応する）。 指定されたストリームのための特定の持続性方針のクライアントの選択を示す要求を受信することができる（要素２４０４）。いくつかの実施形態では、クライアントが選択した持続性方針は所与のストリームの各パーティション用の別の記憶場所タイプまたは別のデバイスタイプの使用をもたらす可能性がある。一実施形態では、クライアントよりもＳＭＳが、ストリームレベルでまたはパーティションレベルで記憶場所タイプまたはデバイスタイプを選択してもよい。いくつかの実施形態では、クライアントはデータ耐久性目標及び／または性能目標（所望の読み出しまたは書き込み処理能力あるいは待機時間）を示してもよく、持続性方針を選択する場合、一部の実施形態では、これらの目標をＳＭＳが使用して、適切な記憶デバイスタイプまたは場所を選択することができる。例えば、短い待機時間を所望の場合、回転磁気ディスクの代わりにＳＳＤを使用して、１つまたは複数のパーティションまたはストリームのデータ記録を保存することができる。
１組の取得ノードはデータプロデューサから選択したストリームのデータ記録を受信するために決定または構成されてもよい。また１組の記憶ノードは選択された持続性方針を実装するために構成されてもよい（要素２４０７）。データ記録が取得ノードで受信された時（要素２４１０）、１つまたは複数のデータ記録の複写が、選択された持続性方針に基づいて、データ記録が属するパーティションを扱う記憶ノードが選択する記憶装置で保存されてもよい（要素２４１３）。少なくともいくつかの実施では、請求額は、クライアントが選択する指定の持続性方針に基づいて任意の方法（及び／または非同期的に）で決定されてもよい（要素２４１６）。
ストリームプロセッシングのための分散ワークロードマネジメント
いくつかの実施形態では、ＳＰＳの実質的な部分またはすべての制御プレーン機能が、例えば、ワーカーノードが所与のＳＰＳ段階内でデータベーステーブルなどの共有されたデータ構造を介して様々な制御動作を連携させる（動的再パーティション分割、ヘルス監視、及び／または負荷均衡化に応答するワーカーノードへのパーティション割り当てなど）、分散化した方法で実装されてもよい。所与のワーカーノードＷ１は共有データ構造内のエントリを検査して、例えば、段階の入力ストリームのどのパーティションが（もしあるなら）現在処理されていないかを判定することができる。そのようなパーティションＰ１を見つけた場合、Ｗ１は共有データ構造内のエントリを更新して、Ｗ１が段階の処理動作をＰ１の記録上で実行することを示すことができる。他のワーカーノードは、Ｗ１はＰ１記録を処理するために割り当てられていることを知り、それらを異なるパーティションへ割り当てることができる。ワーカーノードは定期的にまたは時折、クエリをＳＭＳ制御プレーンに提出して、入力ストリーム用に実行中の現在のパーティションマップを決定して、共有データ構造を更新して必要に応じてマップの変更を示すことができる（例えば、再パーティション分割の結果として）。負荷均衡及び他の動作も、様々な実施形態で、以下に説明するように共有されたデータ構造を介して連携させることができる。このような分散化された実施形態では、専用の制御ノードをＳＰＳに要求できないので、ＳＰＳの作業フローを実装するために要求される負荷を減らすことになる。このような分散化ＳＰＳ制御プレーンの実施は、例えば、顧客に割り当てられているプロバイダ網内のコンピュートインスタンスでまたはプロバイダ網の外側の場所で、ＳＰＳクライアントライブラリを利用してストリーム処理の様々な態様を実装する経費意識の高い顧客には特に一般的な場合がある。分散化ＳＰＳ制御プレーンの技術は、例えば、ＳＭＳ及びＳＰＳに使用されるすべての資源がプロバイダ網内で構成される場合、クライアントライブラリが使用されない実施形態でも使用することができる。ワーカーノードが、少なくとも一部の処理段階用に一部またはすべてのＳＰＳ制御プレーンの機能を実装するＳＰＳを、ここでは「分散型制御ＳＰＳ」と呼んでもよい。
図２５は、少なくともいくつかの実施形態による処理段階のワーカーノードがデータベーステーブルを使用して作業負荷を調整するストリーム処理システムの実施例を示す。分散型制御ＳＰＳ２５９０内にそれぞれワーカーノード１式を備える２つの段階２１５Ａ及び２１５Ｂが画成される。段階２１５Ａはワーカーノード２５４０Ａ及び２５４０Ｂを備え、段階４１５Ｂはワーカーノード２５４０Ｋ及び２５４０Ｌを備える。各段階２１５Ａ及び２１５Ｂに対して、対応するパーティション割り当て（ＰＡ）テーブル２５５０、段階２１５Ａ用ＰＡテーブル２５５０Ａ、及び段階２１５Ｂ用ＰＡテーブル２５５０Ｂなどがデータベースサービス２５２０で生成される。所与の段階に対するＰＡテーブル２５５０はいくつかの実施形態では、例えば、クライアントのライブラリ構成要素または機能の呼び出しに応答して段階の初期化の間に生成されてよい。各ＰＡテーブル２５５０はエントリの初期セットまたは段階の入力ストリームの未割り当てパーティションを示す列を備えて事前設定されてもよい（すなわち、ワーカーノードが現在割り当てられていないパーティション）。ＰＡテーブルエントリのコラムまたは属性の実施例を図２６に示し、以下で説明する。段階用に起動されたワーカーノード２５４０（例えば、コンピュートインスタンスまたは他のサービスで起動されたプロセスあるいはスレッド）は段階のＰＡテーブルへの読み出し／書き込みアクセスを認可されてもよい。ワーカーノードからＰＡテーブルへ向けられた読み出し及び書き込みをそれぞれ矢印２５６４Ａ、２５６４Ｂ、２５６４Ｋ及び２５６４Ｌによりワーカーノード２５４０Ａ、２５４０Ｂ、２５４０Ｋ及び２５４０Ｌについて図２５に示す。
所与のワーカーノード２５４０はＰＡテーブルのエントリを調査することで、段階の処理動作を実行する特定のパーティションを選択するよう構成されてもよい。ある実施形態では、ワーカーノード２５４０Ａは未割り当てパーティションＰｋのエントリを見つけるまで、ＰＡテーブル２５５０Ａ内のエントリを走査して、例えば、ワーカーノードの識別子をエントリのコラムの１つに挿入することによりエントリを更新することでパーティションＰｋをワーカーノード２５４０Ａ自体に割り当てようとすることができる。そのような挿入は、ワーカーノードによってパーティションをロックすることに似ていると考えられてもよい。使用されているデータベースサービスのタイプにより、ＰＡテーブルのエントリに対して起こり得る同時書き込み（２つ以上のワーカーノードが未割り当てのパーティションをたまたまほぼ同時に指定することによる）を管理する様々なアプローチが用いられてもよい。
一実施形態では、プロバイダ網の非リレーショナルマルチテナントデータベースサービスを使用して、リレーショナルデータベース処理意味論に必ずしも対応することなく強い整合性と条件付き書き込み動作に対応することができる。条件付き書き込み動作はワーカーノードによる更新の場合に用いられる。コラム「ワーカーノードＩＤ」がＰＡテーブル内のパーティションに割り当てられた特定のワーカーノードの識別子を示すために使用されて、ワーカーノードがパーティションに割り当てられない場合、コラムの値が「ヌル」に設定される実施例を考えられたい。そのようなシナリオでは、識別子ＷＩＤ１を備えるワーカーノードは以下の論理同値を要求してもよい。「パーティションＰｋへのエントリで、ワーカーノードＩＤがヌルの場合、そのエントリに対するワーカーノードＩＤをＷＩＤ１へ設定する。」そのような条件付き書き込み要求が成功したら、識別子ＷＩＤ１を備えるワーカーノードはパーティションＰｋがワーカーノードに割り当てられたとみなすことができる。そして、ワーカーノードは、例えば、矢印２５５４で示すＳＭＳ検索サブシステム２０６の記録検索インターフェースを使用して（例えば、ワーカーノード２５４０Ａ、２５４０Ｂ、２５４０Ｋ及び２５４０Ｌについてそれぞれ矢印２５５４Ａ、２５５４Ｂ、２５５４Ｋ及び２５５４Ｌ）パーティションＰｋのデータ記録を検索し始めて、検索された記録上で処理動作を実行することができる。条件付き書き込みに失敗した場合、ワーカーノードは別の割り当てられていないパーティションを再度検索し始めてもよい。他の実施形態では、例えば、パーティションをワーカーノードに割り当てようとする複数の同時（ほとんど同時）の試みのうちのただ１つが確実に成功するために、及び、そのような同時の試みに巻き込まれたワーカーノードが成功または失敗を確実に報告するために、取引を支援するデータベースサービス（リレーショナルデータベースなど）を使用して、また処理機能を使用して、条件付き書き込み動作の同値を実装することができる。条件付き書き込みにも取引支援にも依存しない同期技術をいくつかの実施形態で使用してもよい。一部の実施形態では、データベースサービスを使用することができない。代わりに、ロッキングサービスをワーカーノードが使用して、ＰＡテーブルに類似の持続性データ構造でのエントリの更新に対する唯一のアクセスを取得することができる。
他のワーカーノード２５４０はＰＡテーブル内のエントリを調査して、どのパーティションが未割り当てかを判定し、最終的に１つまたは複数のパーティションをワーカーノード自体にうまく割り当てることができる。このように段階の入力ストリームまたは複数のストリームのパーティションへの処理作業負荷を最終的に段階のワーカーノードがワーカーノード自体のなかで分散することができる。
いずれの所与のストリームの初期パーティションマッピングでも、例えば、すでに説明した動的再パーティション分割動作の結果として、時間とともに変化してもよい。したがって、図２５で図示する実施形態では、１つまたは複数のワーカーノード２５４０は時折（または以下で説明するトリガー条件に応答して）自身の段階の入力ストリームのＳＭＳ制御サブシステム２１０に要求を送付して、現在のパーティションメタデータを取得してもよい。いくつかの実施形態では、このような要求は、矢印２５４４Ａ、２５４４Ｂ、２５４４Ｋ及び２５４４ＬによるｇｅｔＳｔｒｅａｍＩｎｆｏ ＡＰＩの呼び出しなどＳＭＳ制御プレーンＡＰＩの呼び出しを含んでもよい。ＳＭＳ制御サブシステムは、例えば、ストリームのパーティションの最新のリスト及び／またはパーティションの有効期間などの他の詳細を備えて応答することができる。ＳＭＳ制御サブシステム２１０が与えるパーティション情報がＰＡテーブル内のエントリと一致しない場合、例えば、１つまたは複数のパーティションのエントリを挿入または削除して、ワーカーノードがＰＡテーブルを修正してもよい。ＳＭＳ制御サブシステムに対するこのような要求２５５４は、少なくともいくつかの実施形態では、矢印２５５４Ａの付箋「まれな」が示すように、通常、記録検索要求２５５４（及び／またはデータベース読み出しまたは書き込み動作２５６４）よりずっと少ない頻度で起こるものでよい。例えば、一度パーティションに割り当てられた場合、ワーカーノードは一般に、パーティションのデータを完全に消費する（例えば、ストリームの所有者がストリームを閉じた場合、またはパーティションが動的再パーティション分割の結果、閉じられた場合）まで、またはなんらかの他の低確率の状況に出会うまで（例えば、以下に説明するように負荷の不均衡が検出されたため別のワーカーノードがパーティションの移動を要求する場合）、パーティションのデータ記録を検索及び処理し続ける可能性がある。このようにｇｅｔＳｔｒｅａｍＩｎｆｏまたは同様のＡＰＩの呼び出しに関連する負荷は一般に、実際の情報量がいずれかの特定の呼び出しに応答して提供されたとしても（数百または数千のパーティションを段階の入力ストリーム用に画成した場合であっても）、種々の実施形態では、極めて小さい。
一部の分散型制御ＳＰＳ環境のキー作業負荷管理型動作は図２５で示す実施形態では以下の通り要約することができる。（ａ）ストリームの処理段階の第１のワーカーノードによる少なくとも一部、データベーステーブルへのアクセスに基づいて、ストリームの処理段階用に規定された１組の処理動作を実装するための、ストリームの処理段階の入力データストリームの特定のパーティションを、選択すること、（ｂ）テーブル内に保存された特定のエントリへ、第１のワーカーノードへの特定のパーティションの割り当ての表示を書き込むこと、（ｃ）第１のワーカーノードが、マルチテナントストリーム管理型サービスで実装されたプログラム記録検索インターフェースを使用して特定のパーティションの記録を検索すること、（ｄ）第１のワーカーノードが、特定のパーティションの記録上に１組の処理動作を実装すること、（ｅ）第２のワーカーノードが、特定のデータベーステーブル内の特定のエントリの少なくとも一部に基づいて、第１のワーカーノードを特定のパーティションで１組の処理動作を実行するよう割り当てることを決定すること、及び（ｆ）第２のワーカーノードが１組の処理動作を実行するための異なるパーティションを選択すること。自身に割り当てる記録がパーティションに残っていないとワーカーノードが判定した場合及び判定したとき、ワーカーノードはＳＭＳ制御サブシステムから入力ストリーム上のメタデータを要求して、メタデータが不一致を示した場合、ＰＡテーブルを更新することができる。
図２６は少なくともいくつかの実施形態による、作業負荷の調整のため使用されるパーティション割り当てテーブル２５５０に保存されてもよいエントリの実施例を示す。表示の通り、テーブル２５５０は４つのコラムを備え、それらは、パーティション識別子コラム２６１４、割り当て済みワーカーノード識別子コラム２６１８、ワーカーノードヘルス表示コラム２６２０及び作業負荷レベル表示コラム２６２２である。他のコラムの数組は他の実施形態では実装される。例えば、パーティション生成時間またはパーティション機能出力値範囲を示すコラムはいくつかの実施形態で使用されるが、作業負荷レベル表示コラムは使用されないかもしれない。
ＳＭＳ制御サブシステムが維持するパーティションリスト２６５０（例えば、パーティションエントリツリー、グラフまたは上述の複合データ構造の一部として）は、一部の実施形態では、少なくともいくつかの時点で、ＰＡテーブル２５５０に含まれる以上のパーティションを含んでいる可能性があることに留意されたい。図示の実施例では、パーティションリスト２６５０はパーティションＰ１、Ｐ２、Ｐ３、Ｐ４及びＰ５を含み、そのうちＰ１とＰ４は再パーティション分割の結果として閉鎖状態で、Ｐ２、Ｐ３及びＰ５は稼働中と示されている（すなわち、データ記録が現在検索され処理されているパーティション）。ＰＡテーブル２６５０は、図示の実施形態では稼働中のパーティション用のエントリを含み、閉鎖したパーティションのエントリは含まない（例えば、再パーティション分割が起こった後、ｇｅｔＳｔｒｅａｍＩｎｆｏの呼び出しに対する応答を取得したとき、すでにワーカーノードが削除している）。少なくともいくつかの実施では、現在開放中のストリームのパーティションのすべてが必ずしもＰＡテーブルに所定の時点で対応するエントリを有するわけではない。むしろ、例えば、現在割り当てられ、または処理されているサブセットのパーティションだけを表示していることがある。
図２６に示す実施例のシナリオでは、パーティションＰ１及びＰ２は各識別子Ｗ７及びＷ３を備えるワーカーノードに割り当てられるが、Ｐ５は現在割り当てられていない。ヘルス表示コラム２６２０は別の実施形態では、異なるタイプの値を保存してもよい。いくつかの実施形態では、ワーカーノードは定期的に（例えば、Ｎ秒毎にまたは数セットのヒューリスティックスに基づいた予定にしたがって）自身が割り当てられたパーティションのＰＡエントリのヘルス表示コラムの内容を更新して、ワーカーノードが稼働中で検索及び処理動作を継続できることを示す役割を持ってもよい。図２６では、そのエントリに対するワーカーノードがヘルス表示コラム（最後に修正した時間）を更新した直近の時間の表示を保存することができる。例えば、ワーカーＷ７は２０１３年１２月１日０２：２４：５４及び５３秒でエントリを修正したと示される。いくつかの実施形態では、他のワーカーノードは最後に修正した時間値を使用して、割り当てられたワーカーノードがヘルシーかまたはそうでないかを決定することができる。例えば、その段階のフェールオーバー方針に規定されているようにＸ秒またはＸ分が経過した場合、割り当てられたワーカーノードは不健康またはアクセス不可とみなされてパーティションが再割り当てされる可能性がある。他の実施形態では、カウンタをヘルス表示として使われてもよく（例えば、カウンタの値がＹ秒間変化しなかった場合、割り当てられたワーカーノードはフェールオーバーの候補と考えられる）、または割り当てられたワーカーノードが最後にエントリを読み出したときを示す「最後の読み出し時間」値が使われてもよい。
少なくともいくつかの実施形態では、例えば、ある最新の時間間隔の間に処理された記録の数（例えば、最後に修正された時間の前の５分間）、ＣＰＵ使用率、メモリ使用率、ストレージ使用率などワーカーノードの最近の性能に関係する測定基準などを割り当てられたワーカーノードが、作業負荷レベル表示値２６２２をエントリに保存する。ワーカーノードはこのような作業負荷レベル表示値をいくつかの実施形態で使用して、図２９を参照して以下で説明するように負荷不均衡が存在するかを判定し、検出された不均衡に応答して措置を講じることができる。例えば、ワーカーノードＷｋはその作業負荷レベルが平均的作業レベルを超えていると判定して、そのパーティションの１つの割り当てを解除する、あるいは動的再パーティション分割を要求することができる。あるいは、ワーカーノードＷｋはその作業負荷が他のワーカーノードまたはパーティションの作業負荷と比べて低すぎると判定して、追加のパーティションをそれ自身に割り当てることができる。こうして、図２６に示すＰＡテーブルのコラムを使用すると、ワーカーノードは図示の実施形態では、通常、特定のＳＰＳ制御ノードが集中管理ＳＰＳ実施で実行する一部の制御プレーンと同じタイプの機能を実行することができる。
図２７は少なくともいくつかの実施形態による、処理動作を実行するためのパーティションを選択するストリーム処理段階のワーカーノードにより実行される動作の態様を示す。要素２７０１に示すように、ＰＡテーブルのＰＡＴ１はデータベースサービスで分散型制御ＳＰＳ処理段階ＳＰ１用に初期化されてもよい。例えば、そのテーブルは、ＳＰＳクライアントライブラリ構成要素を呼び出した時に生成されてもよく、例えば、クライアントの施設でホストから、またはプロバイダ網のデータセンタでコンピュートインスタンスから呼び出した時でよい。クライアントライブラリは、例えば、ＳＰＳ段階で実装される特定の処理動作のためのＪＡＲ（Ｊａｖａ（商標）アーカイブ）ファイルなど実行可能コンポーネントを与えるため、ワーカーノードを特定するために使用することができる付箋を表示するため（プログラム名、プロセス名またはコンピュートインスタンス名など）、段階用の入力として使用されるストリームを表示するため、段階の出力先（もしあれば）を表示するためなど種々の目的に使うことができる。ＰＡＴ１は、いくつかの実施形態では、段階の入力ストリーム用に規定された少なくとも１サブセットのパーティション（Ｐ１，Ｐ２，．．．）用にエントリまたは列を備えて初期に投入される。いくつかの実施形態では、テーブルは最初空欄であるが、１つまたは複数のワーカーノードが、例えば、ＳＭＳ制御サブシステムからパーティションのメタデータを取得した結果として未割り当てのパーティション用に列を伴うテーブルを投入する。ワーカーノードの初期セット（Ｗ１，Ｗ２，．．．．）を、例えば、プロバイダ網内の種々のコンピュートインスタンスで、またはクライアント所有のコンピューティングデバイスで（要素２７０４）起動してもよい。ワーカーノードは図示の実施形態ではＰＡＴ１への読み出し及び書き込みアクセスを許可されることになる。
ワーカーノードはオンライン化すると、未割り当てのパーティションを探してそれぞれがＰＡＴ１にアクセスすることができる。例えば、ワーカーノードＷ１はＰＡＴ１を調査して、パーティションＰ１が未割り当てであることを見つけることができる（要素２７０７）。そして、Ｗ１は、例えば、使用しているデータベースサービスのタイプによって条件付き書き込み要求またはトランザクショナル更新要求を用いて、Ｐ１はＷ１に割り当てられたということを示すよう、ＰＡＴ１のＰ１のエントリを更新することができる（要素２７１０）。テーブルを更新した後、Ｗ１はＰ１のデータ記録の検索を、ＳＭＳ検索サブシステムインターフェースを用いて始めることができる（要素２７１３）。そして、検索した記録の段階ＰＳ１の処理動作を実行することができる。
一方で、ある時点で、異なるワーカーノードＷ２が未割り当てのパーティションを探して独自にＰＡＴ１にアクセスしてもよい（要素２７１６）。Ｗ２はＷ１の以前の更新に基づいて、Ｐ１はすでに割り当てられたが別のパーティションＰ２は割り当てられていないと判定することができる。いくつかの実施形態では、現在のＰ２を割り当てられているワーカーノードが不健康または停止中（Ｐ２エントリのヘルス表示コラムに基づいて）というＷ２による決定によってもＷ２がＰ２を選択するようになる。このように、少なくともいくつかの実施形態では、割り当てられていない状態または現在のワーカーノードの不健康な状態の決定のいずれかが再割り当て（または初期割り当て）のため所与のパーティションを選択するために使われてよい。Ｗ２はＰＡＴ１を更新して、Ｐ２を自身に割り当てようとしてもよい（要素２７１９）。うまく更新できた場合、Ｗ２はＳＭＳ検索インターフェースを用いて、また段階のために規定された適切な処理動作を実行してＰ２の記録を検索し始めてもよい（要素２７２２）。
前述のように、分散型制御ＳＰＳ（一般にまれに）のワーカーノードは、ＳＭＳからパーティションマッピングの情報を取得することができ、そのような情報を使用して必要な場合、ＰＡテーブルを更新することができる。図２８は、少なくともいくつかの実施形態による、ストリーム管理型サービス制御サブシステムから取得した情報に基づいてパーティション割り当てテーブルを更新するためにストリーム処理段階のワーカーノードにより実行される動作の態様を示す。要素２８０１に示すように、ワーカーノードの初期化の間、またはそれに割り当てられたパーティションの１つの閉鎖などの種々のトリガー条件に応答して、ワーカーノードＷ１はＳＭＳ制御サブシステムへ要求を提出して、最新のまたは現在のパーティションリストまたは稼働中のパーティションリストを取得することができる。いくつかの実施形態では、ｇｅｔＳｔｒｅａｍＩｎｆｏまたは同様のＡＰＩをこの目的のために呼び出してもよい。一部の実施形態では、他のトリガー条件を使用してもよい。例えば、ワーカーノードが、ランダムな時間の後、または予期せぬ作業負荷レベルの減少もしくは増加に応答して、新しいパーティションリストを取得するためにそれぞれ構成されてもよい。ＳＭＳが返却したパーティションリストはパーティション用にＰＡテーブル内のエントリと比較することができる（要素２８０７）。不一致が見つかった場合（例えば、新しく取得したパーティションリストの中のあるパーティションがＰＡテーブルにない場合、またはＳＭＳリストになくてＰＡテーブルにエントリがある場合）、図示の実施形態では、ワーカーノードはＰＡテーブル内でエントリを挿入するかまたは削除して、不一致を解決することができる（要素２８１０）。（一部の実施形態では、削除対象のエントリが現在割り当てられたワーカーノードを有する場合、例えば、割り当てられたワーカーノードに、直接またはＰＡテーブル自体を介して通知するなど、追加の調整が必要な場合がある。）
不一致が修正された後で、または不一致が検出されなかった場合、ワーカーノードＷ１は段階の処理動作を実行すべき１組のパーティションを選択することができ（要素２８１３）、それに応じてＰＡテーブルを更新することができる。いくつかの場合、パーティションリストを検索させようとしたトリガー条件次第で、Ｗ１はそれに割り当てられた１つまたは複数のパーティションをすでに有していて、その割り当てを変更するまたはＰＡテーブルを更新する必要がない場合がある。Ｗ１はその割り当てられた１つまたは複数のパーティションのデータ記録を検索することを進行して、ＳＭＳ制御サブシステムと相互作用する必要なく、またはＰＡテーブル内のエントリの数を変更することなく、記録を処理することができる（要素２８１６）。結局、トリガー条件を検出した時（例えば、パーティションが閉鎖したことを示す、「パーティションの終端に到達」と同意義の応答を検索要求に対して受領した時）、Ｗ１は再度ＳＭＳ制御サブシステムに対して新しいパーティション情報の要求を送信し、要素２８０１以降の動作を繰り返してもよい。
図２９は、少なくともいくつかの実施形態による、ストリーム処理段階のワーカーノードにより実行される負荷均衡動作の態様を示す。要素２９０１に示すように、ワーカーノードＷ１は負荷均衡解析を、高い資源使用レベルの検出などいずれかの種類のトリガー条件の検出により、または設定可能スケジュールに基づいて、その段階で実行することを決定してもよい。Ｗ１はＰＡテーブル内のエントリを調査して（要素２９０４）、段階のための種々の作業負荷の測定基準を決定することができる。そのような測定基準はワーカーノードに割り当てられるパーティションの平均数、ワーカーノードの平均作業負荷レベルまたは種々のパーティションの平均作業負荷レベル（作業負荷レベルの表示がテーブルに保存された実施形態では）、ワーカーノード毎の作業負荷の範囲または分散などを含んでもよい。
Ｗ１は自身の作業負荷（例えば、Ｗ１に割り当てられたパーティションの数及び／またはパーティション毎の作業負荷レベル表示に基づいて）を測定基準の一部またはすべてと比較することができる。一般に、３つの型の結論のいずれかを引き出すことができる。すなわち、Ｗ１は過負荷である、Ｗ１は過少負荷である、またはＷ１は負荷が高すぎもせず低すぎもせずである。「高すぎる」または「低すぎる」という作業負荷のレベルは、いくつかの実施形態で代表する段階が構成されるクライアントにより選択される方針により、または他の実施形態では、ヒューリスティックスのある初期設定のセットを用いて、規定することができる。Ｗ１がその作業負荷が低すぎる（要素２９０７）と判定した場合、例えば、ある最低負荷閾値Ｔ１より下である場合、より忙しいまたは負荷の高いワーカーノードＷｋを指定してもよい（要素２９１０）。そして、Ｗ１は、例えば、ＰＡテーブル内のＰｍエントリを修正しようとして、そのような修正を要求して（Ｗｋ用に発生した通知につながる）、またはＷｋに直接要求することにより、１つまたは複数のパーティションＰｍをＷｋから自身へ移動するプロセスを始めることができる。（要素２９１３）。
Ｗ１が自身の作業負荷が高すぎる（要素２９１６）と判定した場合、例えば、最大閾値Ｔ２より大きい場合、１つまたは複数の割り当て済みのパーティションＰｎを指定して、放棄することができる（すなわち、他のワーカーノードに割り当てるために解除する）（要素２９１９）。そして、例えば、Ｐｎ用のエントリの割り当てのあるコラムから識別子を削除して（要素２９２２）、Ｗ１はＰＡテーブル内の適切なエントリを修正することができる。Ｗ１の作業負荷が高すぎもなく低すぎもない場合、またはＷ１がその作業負荷を増やしたり減らしたりする上述のような措置を講じた後で、Ｗ１は割り当てられたパーティションの処理記録を再開してもよい（要素２９２５）。要素２９０１以降に一致する動作は、他の負荷均衡解析をトリガーする条件に合った時または合った場合に繰り返される可能性がある。図２９で図示する動作では、Ｗ１は自身の作業負荷に対する均衡を検出した場合のみ、作業負荷の変更を開始するように示されていることに留意されたい。他の実施形態では、例えば、Ｗ２の作業負荷レベルがＷ３よりはるかに低いと判定した場合など、Ｗ１自身より他のワーカーノード間の不均衡を検出した場合、Ｗ１は是正の措置を開始してもよい。いくつかの実施形態では、Ｗ１は、作業負荷の不均衡を検出した場合及び検出した時、動的再パーティション分割を要求または始めてもよい（例えば、図３で示したｒｅｐａｒｔｉｔｉｏｎＳｔｒｅａｍ ＳＭＳＡＰＩまたはその均等物を呼び出すことにより）。いくつかの実施形態では、図２９に示すような動作を新しく構成されたワーカーノードが実行してもよい。例えば、新しいノードがある段階に追加される前から、その段階がすでにしばらくの間稼働していた時、負荷の大きい既存のノードからパーティションの再割り当てを要求することで、新しいノードは自身の存在を既存のノードに間接的に通知することができる。一部の実施形態では、ＳＰＳワーカーノード用の上述と同様の分散型制御技術も、または代わりに１つまたは複数のＳＭＳサブシステムで使用することができる。例えば、取得、記憶または検索サブシステムはＰＡテーブルと同様の共有データ構造を用いて、自身の作業負荷を調整することができる。
種々の実施形態では、図１７〜２４及び図２７〜２９の流れ図に示す以外の動作はストリーム管理型サービス及び／または上述のストリーム処理機能を実装して使用することができることに留意されたい。図示の一部の動作はいくつかの実施形態では実装されていない、または異なる順序で、または順次ではなく並行して実装されている可能性がある。種々の実施形態では、プログラムインターフェースに対応する各ＳＭＳ及びＳＰＳ機能に対して、１つまたは複数の技術のいずれの組み合わせも、ウェブページ、ウェブサイト、ウェブサービスＡＰＩ，他のＡＰＩ、コマンドラインツール、グラフィカルユーザインターフェース、携帯用アプリケーション（ａｐｐ）、タブレット用ａｐｐ、などを含むインターフェースを実装するために使用することができることにもまた留意されたい。
使用ケース
ストリームデータ記録の収集、記憶、検索及び段階型処理のための拡張可能なパーティション分割型動的構成可能管理型マルチテナントサービスを確立する上述の技術はいくつかのシナリオで役立つ可能性がある。例えば、大規模プロバイダ網は、数万のクライアントに同時にいくつかの異なるマルチテナントサービスまたはシングルテナントサービスのサービスインスタンスを実装する数千のインスタンスホストを備えることができる。種々のインスタンス及びホストにインストールされた監視及び／または課金エージェントはすばやく数千のメトリック記録を生成することができ、それらは保存及び解析される必要があるが、正確な請求記録を作成し、プロバイダ網のデータセンタ用の効果的な供給計画を決定し、ネットワーク攻撃を検出するなどを行うことができる。監視記録は、拡張可能な取得及び記憶用ＳＭＳに対して入力ストリームを形成することができ、説明されたＳＰＳ技術を収集された測定基準の解析用に実装することができる。同様に多くのログ資源から膨大なログ記録を収集し解析するアプリケーション（例えば、分散型アプリケーションのノードからのアプリケーションログまたはホストもしくはデータセンタのコンピュートインスタンスからのシステムログ）もまた、ＳＭＳ及びＳＰＳ機能を使用することができてもよい。少なくともいくつかの環境では、ＳＰＳ処理動作はリアルタイムＥＴＬ（Ｅｘｔｒａｃｔ−Ｔｒａｎｓｆｏｒｍ−Ｌｏａｄ）処理動作（すなわち、受信データ記録を目的先にロードするために、変換をオフラインで行う代わりに、リアルタイムで変換する）、またはデータ記録をデータウェアハウスへ挿入するための変換を含んでもよい。一般に、解析用にウェアハウスへデータを挿入できる前に、１つまたは複数のデータソースからのクリーンで選別されたデータを要求するデータウェアハウスへリアルタイムでデータをロードする組み合わせはＳＭＳ／ＳＰＳを使うことにより、遅延を避けることができる。
また、ＳＭＳ及びＳＰＳ技術を用いて、いくつかの異なる「ビッグデータ」アプリケーションを構築することができる。例えば、種々の形状のソーシャルメディアの相互作用のトレンドの解析はストリームを使うと効果的に実行することができる。ユーザの位置情報などの携帯電話またはタブレットコンピュータから収集されたデータはストリーム記録として管理することができる。例えば、１群の監視カメラから収集された音声または映像情報は、拡張可能な方法で収集され、加工される他のカテゴリのストリーミングデータのセットを表すことができ、様々な種類の攻撃を防ぐ潜在的な手助けとなる。例えば、気象衛星、海洋型センサ、森林型センサ、天体望遠鏡から収集された増え続けるデータセットの解析を必要とする科学的なアプリケーションもまた、本明細書に記載のストリーム管理及び処理能力が役立つ可能性がある。柔軟な方針に基づいた構成オプション及び価格オプションは種々のタイプのユーザがストリーミング機能をユーザの特定の予算及びデータ持続性／可用性要求に適合するようカスタマイズする助けとなることができる。
本開示の実施形態について、以下の条項に照らして説明することができる。
１
記録取得サブシステム、記録記憶サブシステム、及び記録検索サブシステムの各サブシステムが、パーティション分割方針を含む１つまたは複数の方針に基づく１つまたは複数の制御構成要素により動的に構成可能な１つまたは複数のノードを備える、（ａ）記録取得サブシステム、（ｂ）記録記憶サブシステム、及び（ｃ）記録検索サブシステムの各１組のノードを、１つまたは複数のデータプロデューサにより生じる複数のデータ記録を含む特定のデータストリームに割り当てられる、マルチテナントストリーム管理サービスの１つまたは複数の制御構成要素によって、決定し、
データ記録のインライン提出を支持する第１の提出インターフェース及びデータが記憶されているネットワークアドレスを参照してデータ記録提出を可能にする第２の提出インターフェースを含む、記録取得サブシステムで実装された１つまたは複数のプログラムによる記録提出インターフェースを介して提出されたデータ記録を受信し、
非順次アクセスパターンを可能にする第１の検索インターフェース及び順次アクセスパターンを可能にする第２の検索インターフェースを含み、第１の検索インターフェースの使用に関連する課金レートが第２の検索インターフェースの使用と関連する課金レートと異なる、記録検索サブシステムで実装された１つまたは複数のプログラムによる記録検索インターフェースを介して受領したデータ記録検索要求に応答してデータ記録の内容を提供し、
複数の記録検索インターフェース及び複数の記録提出インターフェースの個々の使用回数の測定基準の少なくとも一部分に基づいて特定のデータストリームと関連する課金額をクライアントに発信するように構成された１つまたは複数のコンピューティング装置を備えるシステム。
２
１つまたは複数のコンピューティング装置が、パーティション分割方針にしたがって、特定のデータ記録に対応する書き込みリクエストによって表示される特定のデータ記録と関連するキーの少なくとも一部分に基づいて、特定のデータストリームの特定のデータ記録を特定のデータストリームのパーティションに割り当てるようさらに構成される第１項に記載のシステム。
３
１つまたは複数のコンピューティング装置が、特定のデータ記録が割り当てられるパーティションの少なくとも一部分に基づいて、１つまたは複数の（ａ）特定のデータ記録を受諾する役割を持つ記録取得サブシステムの特定ノードと、（ｂ）特定のデータ記録の少なくとも１部の複写を記憶する役割を持つ記録記憶サブシステムの特定ノードと、（ｃ）読み出しリクエストに応答して記録記憶サブシステムから特定のデータ記録を入手する役割を持つ検索サブシステムの特定のノードとを選択するようさらに構成される第１項に記載のシステム。
４
記録取得サブシステム、記録記憶サブシステム、及び記録検索サブシステムのうち少なくとも１つのサブシステムが、冗長グループのメンバとして１つまたは複数の制御構成要素により構成される複数のノードを備え、冗長グループが、（ａ）１組のデータ記録上で作動するよう割り当てられている１つまたは複数の主ノード及び（ｂ）１つまたは複数のトリガーイベントの検出に応答して主要な役割を装うように構成される１つまたは複数の非主ノードを備える第１項に記載のシステム。
５
１つまたは複数のコンピューティング装置が、特定のデータ記録に対応して、特定のデータ記録が属するパーティションの他のデータ記録に関連する記録取得サブシステムで特定のデータ記録を受領する順番を示す特定のシーケンス番号を発信し、
記録記憶サブシステムによって、データ記録用に発信した各シーケンス番号上の少なくとも一部分に基づく順番で特定のデータ記録を含む複数のデータ記録を記憶し、
パラメータとして特定のシーケンス番号を備える第１の検索インターフェースを呼び出す読み出しリクエストに応答して、記録記憶サブシステムから特定のデータ記録を検索するようにさらに構成される第１項に記載のシステム。
６
複数のデータ記録を備える特定のデータストリーム用に、ストリームのパーティション分割方針を含む１つまたは複数の方針に基づいたストリーム管理動作を実行する１つまたは複数の制御構成要素によって構成可能な一式のノードを決定することと、
非順次アクセスパターンを可能にする第１の検索インターフェース及び順次アクセスパターンを可能にする第２の検索インターフェースを含み、第１の検索インターフェースの使用に関連する課金レートが第２の検索インターフェースの使用と関連する課金レートと異なる、１つまたは複数のプログラムによる記録検索インターフェースを介して受領した記録検索要求に応答してデータ記録を提供することと、
複数の記録検索インターフェースの個々の使用回数の測定基準の少なくとも一部分に基づいて特定のデータストリームと関連する課金額をクライアントに発信することとを、１つまたは複数のコンピューティング装置が実行することを含む方法。
７
パーティション分割方針にしたがって、特定のデータストリームの特定のデータ記録を特定のデータストリームの第１のパーティションに、特定のデータ記録と関連するキーの少なくとも一部分に基づいて割り当てることを１つまたは複数のコンピューティング装置が実行することをさらに含み、キーが特定のデータ記録に対応する書き込みリクエストによって表される、第６項に記載の方法。
８
特定のデータ記録が割り当てられるパーティションの少なくとも一部分に基づいて、１つまたは複数の（ａ）特定のデータ記録を受諾する役割を持つ記録取得サブシステムの特定ノードと、（ｂ）特定のデータ記録の少なくとも１部の複写を記憶する役割を持つ記録記憶サブシステムの特定ノードと、（ｃ）読み出しリクエストに応答して記録記憶サブシステムから特定のデータ記録を入手する役割を持つ検索サブシステムの特定のノードとを選択することを、１つまたは複数のコンピューティング装置が実行することをさらに含む第６項に記載の方法。
９
１つまたは複数のプログラムによる記録提出インターフェースを介して提出されたデータ記録を受信することを１つまたは複数のコンピューティング装置が実行することをさらに含み、１つまたは複数のプログラムによる記録提出インターフェースが、データ記録のインライン提出を支持する第１の提出インターフェース及び、（ａ）プロバイダ網で実装される記憶サービスの対象アドレスと、（ｂ）ユニバーサル記録ロケータと、（ｃ）データベース記録のうちの１つを参照してデータ記録提出を可能にする第２の提出インターフェースを含む第６項に記載の方法。
１０
（ａ）特定のデータストリームを構成するデータ重複排除ウィンドウ、（ｂ）特定のデータストリームと関連するデータアーカイブ方針、（ｃ）クライアントが指示するデータ保持方針、（ｄ）特定のデータ記録削除のクライアントの要請、または（ｅ）特定のデータ記録を１つまたは複数のデータコンシューマが処理したという表示のうちの１つの少なくとも一部分に基づく特定のデータ記録を、データ記憶サブシステムの特定のノードから、削除することを１つまたは複数のコンピューティング装置が実行することをさらに含む第６項に記載の方法。
１１
特定のデータストリーム用に構成される（ａ）記録取得サブシステム、（ｂ）記録記憶サブシステム、または（ｃ）記録検索サブシステムのうちの少なくとも１つのサブシステムが、冗長グループのメンバとして１つまたは複数の制御構成要素により構成される複数のノードを備え、冗長グループが、（ａ）１組のストリームのデータ記録上で作動するよう割り当てられている１つまたは複数の主ノード及び（ｂ）１つまたは複数のトリガーイベントに応答して主要な役割を装うように構成される１つまたは複数の非主ノードを備える第６項に記載の方法。
１２
１つまたは複数の主ノードのうちの特定の主ノードのインスタンスを特定のデータセンタで作成し、１つまたは複数の非主ノードの特定の非主ノードのインスタンスを別のデータセンタで作成する第１１項に記載の方法。
１３
１つまたは複数のトリガーイベントのうち１つのトリガーイベントを検出することと、
１つまたは複数の非主ノードの特定の非主ノードに主要な役割を装うよう通知することを１つまたは複数のコンピューティング装置が実行することをさらに含む第１１項に記載の方法。
１４
１つまたは複数の制御構成要素が冗長グループとして構成される複数の制御ノードを備え、特定のデータストリームを含む１つまたは複数のデータストリーム上の制御プレーン動作の要求に応答して構成される主制御ノード、及び１つまたは複数のトリガーイベントに応答して主要な役割を装うよう構成される少なくとも１つの非主制御ノードを備える第６項に記載の方法。
１５
プロバイダ網のネットワークにアクセス可能なデータベースに、ストリームのパーティション分割方針にしたがって発生したパーティションマップを含む特定のデータストリームのメタデータを記憶することと、
記録検索サブシステムから、特定の記録検索要求に応答してメタデータにアクセスすることとを１つまたは複数のコンピューティング装置が実行することをさらに含む第６項に記載の方法。
１６
データストリームの特定のデータ記録に対応して、特定のデータ記録が属するパーティションの他のデータ記録に関連する記録取得サブシステムで特定のデータ記録を受領する順番を示す特定のシーケンス番号を発信することと、
記録記憶サブシステムによって、データ記録用に発信した各タイムスタンプの少なくとも一部分に基づく順番で特定のデータ記録を含む複数のデータ記録を記憶することと、
パラメータとして特定のシーケンス番号を備える第１の検索インターフェースを呼び出す読み出しリクエストの受信に応答して、記録記憶サブシステムから特定のデータ記録を検索することを１つまたは複数のコンピューティング装置が実行することをさらに含む第６項に記載の方法。
１７
１組のノードのうち特定のノードが、（ａ）プロバイダ網で実装されるデータベースサービスのデータベーステーブルの少なくとも一部分、または（ｂ）プロバイダ網で実装される記憶サービスの記憶オブジェクトの少なくとも一部分のいずれかを含む第６項に記載の方法。
１８
１つまたは複数のプロセッサで実行された場合、マルチテナント型ストリーム管理サービスの制御ノードを実装するプログラム指令を保存する非一過性コンピュータアクセス可能記憶媒体であって、制御ノードが、
１つまたは複数のデータプロデューサによって発生する複数のデータ記録からなる特定のデータストリームを初期化する要求を受領するよう構成され、
特定のデータストリームと関連するパーティション分割方針の少なくとも一部分に基づいて、記録検索サブシステムを含む、特定のデータストリーム用の１つまたは複数のサブシステムを構成するために使用される１つまたは複数のパラメータを決定するよう構成されて、１つまたは複数のパラメータがノードの初期値のインスタンスを記録検索システムに生成することを含み、
記録検索サブシステムの特定のノードに使用される１つまたは複数の資源を特定するよう構成されて、特定のノードが非順次アクセスパターンを可能にする第１の検索インターフェース及び順次アクセスパターンが可能な第２の検索インターフェースを含む複数のプログラムによる記録検索インターフェースを実装するよう構成されて、
１つまたは複数の資源を用いて記録検索サブシステムの特定のノードを構成するよう構成される記憶媒体。
１９
１つまたは複数のサブシステムが特定のデータストリームのデータ記録を受信するよう構成することが可能な１つまたは複数のノードを備える記録取得サブシステム及び選択された１組の記憶場所でストリームのデータ記録を保存するよう構成することが可能な記録記憶サブシステムを含む第１８項に記載の非一過性コンピュータアクセス可能記憶媒体。
２０
記録取得サブシステム、記録記憶サブシステム、及び記録検索サブシステムのうちの少なくとも１つのサブシステムが冗長グループのメンバとして構成される複数のノードを備え、（ａ）１組のストリームのデータ記録上で作動するよう割り当てられている１つまたは複数の主ノード及び（ｂ）１つまたは複数のトリガーイベントに応答して主要な役割を装うよう構成される１つまたは複数の非主ノードを冗長グループが備える第１９項に記載の非一過性コンピュータアクセス可能記憶媒体。
２１
記録取得サブシステム、記録記憶サブシステム、または記録検索サブシステムのうちの少なくとも１つのノードがプロバイダ網で実装される仮想化コンピューティングサービスのコンピュートインスタンスの構成要素を含む第１９項に記載の非一過性コンピュータアクセス可能記憶媒体。
２２
１つまたは複数のデータプロデューサが、（ａ）コンピューティング装置のログ構成部品、（ｂ）ソーシャルメディアアプリケーション、（ｃ）コンピューティング装置の監視代理人、（ｄ）センサデバイス、（ｅ）携帯電話、または（ｆ）タブレットコンピュータを１つまたは複数備える第１９項に記載の非一過性コンピュータアクセス可能記憶媒体。
例示的コンピュータシステム
少なくともいくつかの実施形態では、ＳＭＳサブシステム（例えば、取得、記憶、検索、及び制御サブシステム）ならびにＳＰＳワーカー及び制御ノードの構成要素を実装する技術を含む、本明細書に記載の１つまたは複数の技術の一部またはすべてを実装するサーバは、１つまたは複数のコンピュータアクセス可能な媒体にアクセスすることを含むまたはアクセスするよう構成されている汎用コンピュータシステムを含んでもよい。図３０はこのような汎用コンピューティング装置９０００を示す。図示の実施形態では、コンピューティング装置９０００は、入力／出力（Ｉ／Ｏ）インターフェース９０３０を介してシステムメモリ９０２０に結合する１つまたは複数のプロセッサ９０１０を含む。さらに、コンピューティング装置９０００はＩ／Ｏインターフェース９０３０に結合するネットワークインターフェース９０４０を含む。
種々の実施形態では、コンピューティング装置９０００は１つのプロセッサ９０１０を含む単一プロセッサシステムまたはいくつかのプロセッサ９０１０（例えば、２個、４個、８個または他の適切な数）を含むマルチプロセッサシステムであってよい。プロセッサ９０１０は、命令を実行可能な任意の適切なプロセッサであってもよい。例えば、種々の実施形態では、プロセッサ９０１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、またはＭＩＰＳ ＩＳＡあるいはいずれかの他の適切なＩＳＡなど、任意の様々なインストラクションセットアーキテクチャ（ＩＳＡ）を実装する汎用または組み込みプロセッサであってよい。マルチプロセッサシステムでは、各プロセッサ９０１０は一般に、ただし必然ではなく、同じＩＳＡを実装することができる。いくつかの実施形態では、グラフィックスプロセッシングユニット（ＧＰＵ）は、代わりに、または追加的に、従来型プロセッサを使用してもよい。
システムメモリ９０２０はプロセッサ９０１０がアクセス可能な命令及びデータを保存するよう構成することができる。種々の実施形態では、システムメモリ９０２０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、同期式動的ＲＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュ型メモリ、または任意の他のタイプのメモリなど、任意の適切なメモリ技術を用いて実装することができる。図示の実施形態では、上述の方法、技術、及びデータなど１つまたは複数の所望の機能を実装するプログラム命令及びデータが、コード９０２５及びデータ９０２６としてシステムメモリ９０２０内に記憶されているよう示される。
一実施形態では、Ｉ／Ｏインターフェース９０３０はプロセッサ９０１０、システムメモリ９０２０及びネットワークインターフェース９０４０またはデータオブジェクトパーティションの物理複製を保存するために使用される種々のタイプの持続性及び／または揮発性記憶装置など他の周辺インターフェースを含む装置内の任意の周辺デバイスの間でＩ／Ｏトラフィックを調整するよう構成されてもよい。いくつかの実施形態では、Ｉ／Ｏインターフェース９０３０は任意の必要なプロトコル、タイミングまたは他のデータ変換を実行して、データ信号をある構成要素（例えば、システムメモリ９０２０）から他の構成要素（例えばプロセッサ９０１０）の使用に適切なフォーマットに変換することができる。いくつかの実施形態では、Ｉ／Ｏインターフェース９０３０は、例えば、ペリフェラルコンポーネントインタコネクト（ＰＣＩ）バスまたはユニバーサルシリアルバス（ＵＳＢ）標準の変形など種々のタイプの周辺バスを介して取り付けられたデバイスに対する対応を含んでもよい。いくつかの実施形態では、Ｉ／Ｏインターフェース９０３０の機能は、例えば、ノースブリッジ及びサウスブリッジなど２つ以上の分離した構成要素に分割されてもよい。また、いくつかの実施形態では、システムメモリ９０２０に対するインターフェースなど一部またはすべてのＩ／Ｏインターフェース９０３０の機能は、プロセッサ９０１０に直接、組み入れられてもよい。
ネットワークインターフェース９０４０はデータがコンピューティング装置９０００及び例えば、図１〜図２９に示す他のコンピュータシステムまたはデバイスなど、１つまたは複数のネットワーク９０５０に取り付けられた他のデバイス９０６０間で交換されても良いように構成されてもよい。種々の実施形態では、ネットワークインターフェース９０４０は、例えば、イーサネット（登録商標）網のタイプなど任意の適切な優先または無線一般データ網を介して通信をサポートすることができる。さらに、ネットワークインターフェース９０４０は、アナログ音声網またはデジタルファイバ通信網などの遠距離通信網／電話網、Ｆｉｂｒｅ Ｃｈａｎｎｅｌ ＳＡＮなどの記憶領域網、または任意の他の適切なタイプのネットワーク及び／またはプロトコルを介して、通信網をサポートすることができる。
いくつかの実施形態では、システムメモリ９０２０は、対応する方法及び装置の実施形態を実施するために図１〜図２９について上述したようにプログラム命令及びデータを保存するよう構成するコンピュータアクセス可能媒体の一実施形態であってもよい。しかし、他の実施形態では、プログラム命令及び／またはデータを、種々のタイプのコンピュータアクセス可能媒体に受信、送信、または保存することができる。一般的に言って、コンピュータアクセス可能媒体は、磁気媒体または光媒体などの非一過性記憶媒体または非一過性メモリ媒体、例えば、Ｉ／Ｏインターフェース９０３０を介してコンピューティング装置９０００に結合するディスクまたはＤＶＤ／ＣＤを含んでもよい。非一過性コンピュータアクセス可能記憶媒体はまた、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどの任意の揮発性または不揮発性媒体を含んでもよい。それらはコンピューティング装置９０００のいくつかの実施形態にシステムメモリ９０２０または他の型のメモリとして含まれてもよい。さらに、コンピュータアクセス可能媒体は、ネットワーク及び／または無線リンクなどの通信媒体を介して伝送された、電気的信号、電磁的信号、またはデジタル信号などの伝送媒体または伝送信号を含んでもよく、ネットワークインターフェース９０４０を介して実装されたものでもよい。図３０で例示される複数コンピューティング装置の一部またはすべては、種々の実施形態で、上述の機能を実装するために使用されてもよい。例えば、様々な種類のデバイス及びサーバ上で稼働するソフトウェア構成要素は協力して、機能を提供してもよい。いくつかの実施形態では、上述の機能の一部を、汎用コンピュータシステムを用いて実装することに加えてまたはその代わりに、記憶デバイス、ネットワークデバイス、または専用コンピュータシステムを用いて実装することができる。ここで使う「コンピューティング装置」という言葉は、少なくともこれらすべてのタイプのデバイスのことを言うが、これらのタイプのデバイスに限定されるわけではない。
結論
種々の実施形態は、コンピュータアクセス可能媒体に関する上述の説明にしたがって実装された命令及び／またはデータの受信、送信または保存をさらに含んでもよい。一般的に言って、コンピュータアクセス可能媒体は、例えば、ディスクまたはＤＶＤ／ＣＤ−ＲＯＭ、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭなど）などの揮発性媒体もしくは不揮発性媒体、ＲＯＭといった、磁気媒体または光媒体などの記憶媒体あるいはメモリ媒体と同様にネットワーク及び／または無線リンクなどの通信媒体を介して伝送された、電気的信号、電磁的信号またはデジタル信号などの伝送媒体あるいは伝送信号も含むことができる。
図に例示された及び明細書で説明された種々の方法は例示的な方法の実施形態を示す。その方法はソフトウェア、ハードウェアまたはそれらの組み合わせで実装することができる。方法の順序は変化する場合があり、種々の要素は追加、再順序付け、組み合わせ、省略、修正などがなされてもよい。
種々の修正形態及び変更形態がなされることは本開示の利益を有する当業者には明らかであろう。すべてのそのような修正形態及び変更形態を包含することは意図するものであり、したがって、上述の説明は限定的なものではなく例示的であるとみなされるべきである。

Claims (15)

  1. 複数のデータ記録を備える特定のデータストリーム用に、ストリームのパーティション分割方針を含む１つまたは複数の方針に基づいたストリーム管理動作を実行するため１つまたは複数の制御構成要素によって構成可能な一式のノードを決定することと、
    １つまたは複数のプログラム記録検索インターフェースが、非順次アクセスパターンを可能にする第１の検索インターフェース及び順次アクセスパターンを可能にする第２の検索インターフェースを含み、第１の検索インターフェースの使用に関連する課金レートが第２の検索インターフェースの使用と関連する課金レートと異なる、該１つまたは複数のプログラム記録検索インターフェースを介して受信した記録検索要求に応答してデータ記録を提供することと、
    前記複数の記録検索インターフェースの個々の使用回数の測定基準の少なくとも一部分に基づいて前記特定のデータストリームと関連するクライアントの課金額を生成することとを、１つまたは複数のコンピューティング装置が実行することを含む方法。
  2. 前記パーティション分割方針にしたがって、前記特定のデータストリームの特定のデータ記録を前記特定のデータストリームの第１のパーティションに、該特定のデータ記録と関連するキーの少なくとも一部分に基づいて割り当てることを前記１つまたは複数のコンピューティング装置が実行することをさらに含み、該キーが該特定のデータ記録に対応する書き込みリクエストによって表される、請求項１に記載の方法。
  3. 特定のデータ記録が割り当てられるパーティションの少なくとも一部分に基づいて、１つまたは複数の（ａ）前記特定のデータ記録を受諾する役割を持つ記録取得サブシステムの特定ノードと、（ｂ）前記特定のデータ記録の少なくとも１部の複写を保存する役割を持つ記録記憶サブシステムの特定ノードと、（ｃ）読み出しリクエストに応答して該記録記憶サブシステムから前記特定のデータ記録を入手する役割を持つ検索サブシステムの特定のノードとを選択することを、前記１つまたは複数のコンピューティング装置が実行することをさらに含む請求項１に記載の方法。
  4. １つまたは複数のプログラム記録提出インターフェースを介して提出されたデータ記録を受信することを前記１つまたは複数のコンピューティング装置が実行することをさらに含み、１つまたは複数のプログラム記録提出インターフェースが、データ記録のインライン提出に対応する第１の提出インターフェース及び、（ａ）プロバイダ網で実装される記憶サービスの対象アドレスと、（ｂ）ユニバーサル記録ロケータと、（ｃ）データベース記録のうちの１つを参照してデータ記録提出を可能にする第２の提出インターフェースを含む、請求項１に記載の方法。
  5. （ａ）前記特定のデータストリームを構成するデータ重複排除ウィンドウ、（ｂ）前記特定のデータストリームと関連するデータアーカイブ方針、（ｃ）クライアントが指示するデータ保持方針、（ｄ）前記特定のデータ記録削除のクライアントの要請、または（ｅ）前記特定のデータ記録を１つまたは複数のデータコンシューマが処理したという表示のうちの１つの少なくとも一部分に基づく特定のデータ記録を、データ記憶サブシステムの特定のノードから、削除することを前記１つまたは複数のコンピューティング装置が実行することをさらに含む請求項１に記載の方法。
  6. 前記特定のデータストリーム用に構成される（ａ）記録取得サブシステム、（ｂ）記録記憶サブシステム、または（ｃ）記録検索サブシステムのうちの少なくとも１つのサブシステムが、冗長グループのメンバとして１つまたは複数の制御構成要素により構成される複数のノードを備え、該冗長グループが、（ａ）１組の前記ストリームのデータ記録上で作動するよう割り当てられている１つまたは複数の主ノード及び（ｂ）１つまたは複数のトリガーイベントに応答して主要な役割を装うように構成される１つまたは複数の非主ノードを備える請求項１に記載の方法。
  7. 前記１つまたは複数の主ノードのうちの特定の主ノードのインスタンスを特定のデータセンタで作成し、１つまたは複数の非主ノードのうち特定の非主ノードのインスタンスを別のデータセンタで作成する請求項６に記載の方法。
  8. １つまたは複数のトリガーイベントのうち１つのトリガーイベントを検出することと、
    １つまたは複数の非主ノードのうち特定の非主ノードに主要な役割を装うよう通知することを前記１つまたは複数のコンピューティング装置が実行することをさらに含む請求項６に記載の方法。
  9. １つまたは複数の制御構成要素が冗長グループとして構成される複数の制御ノードを備え、前記特定のデータストリームを含む１つまたは複数のデータストリーム上の制御プレーン動作の要求に応答して構成される主制御ノード、及び１つまたは複数のトリガーイベントに応答して主要な役割を装うよう構成される少なくとも１つの非主制御ノードを備える請求項１に記載の方法。
  10. プロバイダ網のネットワークアクセス可能データベースに、前記ストリームのパーティション分割方針にしたがって発生したパーティションマップを含む前記特定のデータストリームのメタデータを記憶することと、
    記録検索サブシステムから、特定の記録検索要求に応答して前記メタデータにアクセスすること
    とを１つまたは複数のコンピューティング装置が実行することをさらに含む請求項１に記載の方法。
  11. 前記データストリームの特定のデータ記録に対応して、前記特定のデータ記録が属する前記パーティションの他の特定のデータ記録に関連する記録取得サブシステムで前記特定のデータ記録を受領する順番を示す特定のシーケンス番号を生成することと、
    記録記憶サブシステムによって、前記データ記録用に生成した各タイムスタンプ上の少なくとも一部分に基づく順番で前記特定のデータ記録を含む複数のデータ記録を記憶することと、
    パラメータとして前記特定のシーケンス番号を備える第１の検索インターフェースを呼び出す読み出しリクエストの受信に応答して、前記記録記憶サブシステムから前記特定のデータ記録を検索することを１つまたは複数のコンピューティング装置が実行することをさらに含む請求項１に記載の方法。
  12. １つまたは複数のプロセッサ及び１つまたは複数のメモリを含み、１つまたは複数のプロセッサで実行された場合、該１つまたは複数のメモリが、マルチテナント型ストリーム管理サービスの制御ノードを実装するプログラム命令を含むシステムであって、該制御ノードが、
    １つまたは複数のデータプロデューサによって発生する複数のデータ記録からなる特定のデータストリームを初期化する要求を受信するよう構成されて、
    前記特定のデータストリームと関連するパーティション分割方針の少なくとも一部分に基づいて、記録検索サブシステムを含む前記特定のデータストリーム用の１つまたは複数のサブシステムを構成するために使用される１つまたは複数のパラメータを決定するよう構成されて、該１つまたは複数のパラメータが記録検索サブシステム内でインスタンス化されたノードの初期値を含み、
    前記記録検索サブシステムの特定のノードに使用される１つまたは複数の資源を特定するよう構成されて、前記特定のノードが非順次アクセスパターンを可能にする第１の検索インターフェース及び順次アクセスパターンが可能な第２の検索インターフェースを含む複数のプログラム記録検索インターフェースを実装するよう構成されて、
    前記１つまたは複数の資源を用いて前記記録検索サブシステムの前記特定のノードを構成するシステム。
  13. 前記１つまたは複数のサブシステムが前記特定のデータストリームのデータ記録を受信するよう構成することが可能な１つまたは複数のノードを備える記録取得サブシステム及び選択された１組の記憶場所で前記ストリームのデータ記録を記憶するよう構成することが可能な記録記憶サブシステムを含む請求項１２に記載のシステム。
  14. 前記記録取得サブシステム、前記記録記憶サブシステム、及び前記記録検索サブシステムのうち少なくとも１つのサブシステムが冗長グループのメンバとして構成される複数のノードを備え、（ａ）１組の前記ストリームのデータ記録上で作動するよう割り当てられている１つまたは複数の主ノード及び（ｂ）１つまたは複数のトリガーイベントに応答して主要な役割を装うよう構成される１つまたは複数の非主ノードを前記冗長グループが備える請求項１３に記載のシステム。
  15. 前記記録取得サブシステム、前記記録記憶サブシステム、または前記記録検索サブシステムのうちの少なくとも１つのノードがプロバイダ網で実装される仮想化コンピューティングサービスのコンピュートインスタンスの構成要素を含む請求項１３に記載のシステム。
JP2016529931A 2013-11-11 2014-11-11 大規模データストリームの取得、記憶、及び消費のための管理型サービス Active JP6246358B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/077,173 2013-11-11
US14/077,173 US9794135B2 (en) 2013-11-11 2013-11-11 Managed service for acquisition, storage and consumption of large-scale data streams
PCT/US2014/065061 WO2015070239A2 (en) 2013-11-11 2014-11-11 Managed service for acquisition, storage and consumption of large-scale data streams

Publications (2)

Publication Number Publication Date
JP2016540298A true JP2016540298A (ja) 2016-12-22
JP6246358B2 JP6246358B2 (ja) 2017-12-13

Family

ID=53042359

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016529931A Active JP6246358B2 (ja) 2013-11-11 2014-11-11 大規模データストリームの取得、記憶、及び消費のための管理型サービス

Country Status (9)

Country Link
US (1) US9794135B2 (ja)
EP (1) EP3069274B1 (ja)
JP (1) JP6246358B2 (ja)
KR (1) KR101925696B1 (ja)
CN (1) CN105706086B (ja)
AU (1) AU2014346369B2 (ja)
BR (1) BR112016010555B1 (ja)
CA (1) CA2929777C (ja)
WO (1) WO2015070239A2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022534509A (ja) * 2019-05-31 2022-08-01 セールスフォース ドット コム インコーポレイティッド データベース変更ストリームのキャッシュ技術

Families Citing this family (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8332365B2 (en) 2009-03-31 2012-12-11 Amazon Technologies, Inc. Cloning and recovery of data volumes
NO335882B1 (no) * 2013-03-21 2015-03-16 Kezzler As En fremgangsmåte for å fremstille en gruppe med forpakningsmedier
WO2014163624A1 (en) * 2013-04-02 2014-10-09 Hewlett-Packard Development Company, L.P. Query integration across databases and file systems
US9720989B2 (en) 2013-11-11 2017-08-01 Amazon Technologies, Inc. Dynamic partitioning techniques for data streams
US9720991B2 (en) * 2014-03-04 2017-08-01 Microsoft Technology Licensing, Llc Seamless data migration across databases
US11868372B1 (en) 2014-06-20 2024-01-09 Amazon Technologies, Inc. Automated hierarchy detection for cloud-based analytics
US10430438B2 (en) 2014-06-20 2019-10-01 Amazon Technologies, Inc. Dynamic n-dimensional cubes for hosted analytics
US10769175B1 (en) * 2014-06-20 2020-09-08 Amazon Technologies, Inc. Real-time hosted system analytics
JP6428012B2 (ja) * 2014-07-16 2018-11-28 富士通株式会社 分散処理プログラム、分散処理管理装置及び分散処理方法
EP3180768B1 (en) * 2014-08-12 2020-04-22 Eingot LLC A zero-knowledge environment based social networking engine
US20180307515A1 (en) * 2014-10-06 2018-10-25 Red Bend Software Method and apparatus for controlling devices in a personal environment using a portable computing device
US9485310B1 (en) * 2014-12-23 2016-11-01 EMC IP Holding Company LLC Multi-core storage processor assigning other cores to process requests of core-affined streams
US10592500B2 (en) 2015-01-27 2020-03-17 International Business Machines Corporation Eviction stream for data joins
US10043006B2 (en) 2015-06-17 2018-08-07 Accenture Global Services Limited Event anomaly analysis and prediction
US10430384B1 (en) 2015-06-30 2019-10-01 EMC IP Holding Company LLC Global data deduplication across multiple distributed file systems
US10803020B1 (en) 2015-06-30 2020-10-13 EMC IP Holding Company LLC Data deduplication on a distributed file system
US10706042B1 (en) * 2015-06-30 2020-07-07 EMC IP Holding Company LLC Data deduplication on a distributed file system using conditional writes
EP3317998B1 (en) * 2015-07-02 2021-04-28 Leading Software Limited Resilient secret sharing cloud based architecture for data vault
US9703789B2 (en) * 2015-07-27 2017-07-11 Sas Institute Inc. Distributed data set storage and retrieval
CN106855858B (zh) * 2015-12-08 2020-09-29 阿里巴巴集团控股有限公司 数据库操作方法及装置
US10699325B2 (en) 2016-03-08 2020-06-30 Bruce Zak Web service method
US11544756B2 (en) 2016-03-08 2023-01-03 Bruce Zak Web service method
US10122788B2 (en) 2016-03-29 2018-11-06 Amazon Technologies, Inc. Managed function execution for processing data streams in real time
US10917324B2 (en) * 2016-09-28 2021-02-09 Amazon Technologies, Inc. Network health data aggregation service
US10560431B1 (en) * 2016-12-05 2020-02-11 Amazon Technologies, Inc. Virtual private gateway for encrypted communication over dedicated physical link
KR101714412B1 (ko) 2016-12-28 2017-03-09 주식회사 티맥스클라우드 클라우드 환경에서 데이터베이스 시스템을 구성하는 방법 및 장치
CN108287854B (zh) * 2017-01-10 2021-06-22 网宿科技股份有限公司 一种流计算中数据持久化的方法和系统
CN108667867B (zh) 2017-03-29 2021-05-18 华为技术有限公司 数据存储方法及装置
US10728186B2 (en) * 2017-05-24 2020-07-28 Sap Se Preventing reader starvation during order preserving data stream consumption
CN109104446B (zh) * 2017-06-20 2022-04-15 中兴通讯股份有限公司 一种消息保序方法、网络节点及存储介质
US11294853B1 (en) 2017-06-22 2022-04-05 Amazon Technologies, Inc. Archiver for data stream service
US10769126B1 (en) 2017-09-22 2020-09-08 Amazon Technologies, Inc. Data entropy reduction across stream shard
US11269731B1 (en) 2017-11-22 2022-03-08 Amazon Technologies, Inc. Continuous data protection
US10956246B1 (en) 2018-07-16 2021-03-23 Amazon Technologies, Inc. Isolated read channel management interfaces at streaming data service
US11075984B1 (en) 2018-07-16 2021-07-27 Amazon Technologies, Inc. Workload management at streaming data service supporting persistent connections for reads
US10798140B1 (en) 2018-07-16 2020-10-06 Amazon Technologies, Inc. Stream data record reads using push-mode persistent connections
US10768830B1 (en) 2018-07-16 2020-09-08 Amazon Technologies, Inc. Streaming data service with isolated read channels
US11070600B1 (en) 2018-07-16 2021-07-20 Amazon Technologies, Inc. Optimization techniques to support lagging readers at streaming data service
US10855754B1 (en) 2018-07-16 2020-12-01 Amazon Technologies, Inc. Isolated read channel categories at streaming data service
US11288715B2 (en) * 2018-07-31 2022-03-29 Zuora, Inc. Multi-tenant extensible billing system
KR20200036070A (ko) 2018-09-17 2020-04-07 최성률 데이터 수집 변환 및 연결을 위한 빅데이터 운영 방법, 이를 구현하기 위한 프로그램이 저장된 기록매체 및 이를 구현하기 위해 매체에 저장된 컴퓨터프로그램
US11032063B2 (en) * 2018-09-19 2021-06-08 International Business Machines Corporation Distributed platform for computation and trusted validation
CN112714903A (zh) * 2018-09-19 2021-04-27 亚马逊科技公司 使用客户端提供的决策元数据的基于可缩放小区的包处理服务
US11940978B2 (en) 2018-09-19 2024-03-26 International Business Machines Corporation Distributed platform for computation and trusted validation
CN111384707A (zh) * 2018-12-28 2020-07-07 中核核电运行管理有限公司 核电厂超高压联合开关站补充跳机装置及方法
CN109861922B (zh) * 2019-02-21 2022-03-29 北京百度网讯科技有限公司 用于控制流量的方法和装置
CN112860425A (zh) * 2019-11-28 2021-05-28 阿里巴巴集团控股有限公司 负载调度方法、装置、电子设备及计算机可读存储介质
CN112165508B (zh) * 2020-08-24 2021-07-09 北京大学 一种多租户云存储请求服务的资源分配方法
US20220283876A1 (en) * 2021-03-03 2022-09-08 NEC Laboratories Europe GmbH Dynamic resource allocation for efficient parallel processing of data stream slices
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 成都明途科技有限公司 一种岗位数据存储方法、装置及岗位机器人

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002010234A (ja) * 2000-06-19 2002-01-11 Sony Corp コンテンツ配信システム及び方法、情報提供装置、情報端末、記録媒体
JP2002163167A (ja) * 1999-08-03 2002-06-07 Vision Arts Kk 画像ファイルを記録したコンピュータ読み取り可能な記録媒体、この記録媒体の作成装置、画像ファイル作成プログラムを記録した媒体、画像ファイル送信装置、画像ファイル処理装置、画像ファイル処理プログラムを記録した媒体
JP2004235921A (ja) * 2003-01-30 2004-08-19 Sharp Corp コンテンツ配信システム、コンテンツ配信装置、プログラム、及び記録媒体
JP2007086869A (ja) * 2005-09-20 2007-04-05 Kddi Corp コンテンツ配信システム
JP2012080417A (ja) * 2010-10-04 2012-04-19 Pioneer Electronic Corp ストリーミング再生装置、ストリーミング再生方法、コンピュータプログラム及び記録媒体
JP2013069205A (ja) * 2011-09-26 2013-04-18 Oki Electric Ind Co Ltd 配信システムおよび仮想マシン割当装置

Family Cites Families (74)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5586264A (en) 1994-09-08 1996-12-17 Ibm Corporation Video optimized media streamer with cache management
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
US5768527A (en) 1996-04-23 1998-06-16 Motorola, Inc. Device, system and method of real-time multimedia streaming
US6374266B1 (en) 1998-07-28 2002-04-16 Ralph Shnelvar Method and apparatus for storing information in a data processing system
US7386586B1 (en) 1998-12-22 2008-06-10 Computer Associates Think, Inc. System for scheduling and monitoring computer processes
US6272598B1 (en) 1999-03-22 2001-08-07 Hewlett-Packard Company Web cache performance by applying different replacement policies to the web cache
US6505216B1 (en) 1999-10-01 2003-01-07 Emc Corporation Methods and apparatus for backing-up and restoring files using multiple trails
US8055894B2 (en) 1999-11-09 2011-11-08 Google Inc. Process and streaming server for encrypting a data stream with bandwidth based variation
AU2002234258A1 (en) 2001-01-22 2002-07-30 Sun Microsystems, Inc. Peer-to-peer network computing platform
EP1359722A1 (en) 2002-03-27 2003-11-05 BRITISH TELECOMMUNICATIONS public limited company Data streaming system and method
JP3808394B2 (ja) 2002-04-02 2006-08-09 松下電器産業株式会社 ストリームデータ処理装置、ストリームデータ処理方法、プログラム、及び、媒体
US7802001B1 (en) 2002-10-18 2010-09-21 Astute Networks, Inc. System and method for flow control within a stateful protocol processing system
US8943024B1 (en) 2003-01-17 2015-01-27 Daniel John Gardner System and method for data de-duplication
JP4062441B2 (ja) 2003-07-18 2008-03-19 日本電気株式会社 並列処理システム及び並列処理プログラム
JP4601969B2 (ja) * 2004-01-27 2010-12-22 株式会社日立製作所 ファイル入出力制御装置
JP2005250839A (ja) 2004-03-04 2005-09-15 Nomura Research Institute Ltd 耐障害性システム
US7343459B2 (en) 2004-04-30 2008-03-11 Commvault Systems, Inc. Systems and methods for detecting & mitigating storage risks
TWI370979B (en) 2004-05-14 2012-08-21 Ibm Grid computing system, information processing unit, job execution request generation unit, control method, program, and recording medium
US7814056B2 (en) 2004-05-21 2010-10-12 Computer Associates Think, Inc. Method and apparatus for data backup using data blocks
US8255422B2 (en) 2004-05-28 2012-08-28 Microsoft Corporation Highly reliable and scalable architecture for data centers
EP1781034A4 (en) 2004-07-27 2011-04-27 Sharp Kk PSEUDO VIDEO ON DEMAND SYSTEM, CONTROL PROCEDURE FOR A PSEUDO VIDEO ON DEMAND SYSTEM AND PROGRAM AND RECORDING MEDIUM THEREFOR
RU2369040C2 (ru) 2005-04-07 2009-09-27 Нокиа Корпорейшн Буферизация при потоковой передаче данных
TW200717246A (en) 2005-06-24 2007-05-01 Koninkl Philips Electronics Nv Self-synchronizing data streaming between address-based producer and consumer circuits
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
CN100591042C (zh) * 2006-07-17 2010-02-17 华为技术有限公司 半分布式p2p网络流量管理方法、系统及设备
US8095745B1 (en) 2006-08-07 2012-01-10 Marvell International Ltd. Non-sequential transfer of data from a memory
US7633864B2 (en) 2006-12-20 2009-12-15 Sun Microsystems, Inc. Method and system for creating a demilitarized zone using network stack instances
US7716186B2 (en) * 2007-01-22 2010-05-11 International Business Machines Corporation Method and system for transparent backup to a hierarchical storage system
US8315984B2 (en) 2007-05-22 2012-11-20 Netapp, Inc. System and method for on-the-fly elimination of redundant data
EP2605191A3 (en) 2007-11-10 2013-08-21 Landmark Graphics Corporation, A Halliburton Company Systems and methods for workflow automation, adaptation and integration
JP4800289B2 (ja) 2007-11-30 2011-10-26 富士通セミコンダクター株式会社 電源制御装置及びその電源制御装置を有するシステムｌｓｉ
US8190960B1 (en) 2007-12-13 2012-05-29 Force10 Networks, Inc. Guaranteed inter-process communication
US8126048B2 (en) 2008-03-18 2012-02-28 Seiko Epson Corporation Recording streaming delta-encoded data
US8488661B2 (en) 2008-06-13 2013-07-16 Verizon Patent And Licensing Inc. Systems and methods for data streaming
US8255739B1 (en) * 2008-06-30 2012-08-28 American Megatrends, Inc. Achieving data consistency in a node failover with a degraded RAID array
JP5557840B2 (ja) 2008-10-03 2014-07-23 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 分散データベースの監視メカニズム
US8533478B2 (en) 2008-10-24 2013-09-10 Hewlett-Packard Development Company, L. P. System for and method of writing and reading redundant data
US9996572B2 (en) 2008-10-24 2018-06-12 Microsoft Technology Licensing, Llc Partition management in a partitioned, scalable, and available structured storage
US8161255B2 (en) * 2009-01-06 2012-04-17 International Business Machines Corporation Optimized simultaneous storing of data into deduplicated and non-deduplicated storage pools
US20100257140A1 (en) * 2009-03-31 2010-10-07 Philip John Davis Data archiving and retrieval system
US8560639B2 (en) 2009-04-24 2013-10-15 Microsoft Corporation Dynamic placement of replica data
CN101621781A (zh) * 2009-07-13 2010-01-06 中兴通讯股份有限公司 一种基于ota的数据流量查询方法及其系统
US8495413B2 (en) 2009-12-15 2013-07-23 Unisys Corporation System and method for providing a computer standby node
US9501365B2 (en) 2009-12-28 2016-11-22 Netapp, Inc. Cloud-based disaster recovery of backup data and metadata
WO2011133443A1 (en) 2010-04-19 2011-10-27 Greenbytes, Inc. A method for optimizing the memory usage and performance of data deduplication storage systems
US8719362B2 (en) * 2010-09-09 2014-05-06 Riverbed Technology, Inc. Tiered storage interface
US9110936B2 (en) 2010-12-28 2015-08-18 Microsoft Technology Licensing, Llc Using index partitioning and reconciliation for data deduplication
US9262504B2 (en) 2011-02-15 2016-02-16 At&T Intellectual Property I, L.P. Methods, systems, and products for maintaining data consistency in a stream warehouse
US9213709B2 (en) 2012-08-08 2015-12-15 Amazon Technologies, Inc. Archival data identification
US8774213B2 (en) 2011-03-30 2014-07-08 Amazon Technologies, Inc. Frameworks and interfaces for offload device-based packet processing
US9628535B2 (en) 2011-04-15 2017-04-18 International Business Machines Corporation Data streaming infrastructure for remote execution in a constrained environment
US8745434B2 (en) 2011-05-16 2014-06-03 Microsoft Corporation Platform for continuous mobile-cloud services
US8751863B2 (en) 2011-05-23 2014-06-10 Microsoft Corporation Implementing failover processes between storage stamps
JP5905957B2 (ja) 2011-06-08 2016-04-20 コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ 空間的にセグメント化されたコンテンツの配信
US9251481B2 (en) 2011-06-13 2016-02-02 Accenture Global Services Limited Distributed metering and monitoring system
US8572091B1 (en) 2011-06-27 2013-10-29 Amazon Technologies, Inc. System and method for partitioning and indexing table data using a composite primary key
US8521705B2 (en) 2011-07-11 2013-08-27 Dell Products L.P. Accelerated deduplication
US8463633B2 (en) 2011-07-27 2013-06-11 Xerox Corporation Methods and systems for deploying a service workflow in a hybrid cloud environment
US20130067109A1 (en) 2011-09-12 2013-03-14 Tektronix, Inc. Monitoring Over-the-Top Adaptive Video Streaming
US9086923B2 (en) 2011-09-16 2015-07-21 Rutgers, The State University Of New Jersey Autonomic workflow management in dynamically federated, hybrid cloud infrastructures
US20130124483A1 (en) 2011-11-10 2013-05-16 Treasure Data, Inc. System and method for operating a big-data platform
WO2013074665A1 (en) 2011-11-14 2013-05-23 Google Inc. Data processing service
US9608899B2 (en) 2011-11-21 2017-03-28 Qualcomm Incorporated Packet-based aggregation of data streams across disparate networking interfaces
US9898393B2 (en) 2011-11-22 2018-02-20 Solano Labs, Inc. System for distributed software quality improvement
US8886781B2 (en) 2011-12-13 2014-11-11 Microsoft Corporation Load balancing in cluster storage systems
US8762378B2 (en) 2011-12-23 2014-06-24 Sap Ag Independent table nodes in parallelized database environments
US8775282B1 (en) 2012-05-18 2014-07-08 Amazon Technologies, Inc. Capacity management of draining-state platforms providing network-accessible resources
US9141685B2 (en) 2012-06-22 2015-09-22 Microsoft Technology Licensing, Llc Front end and backend replicated storage
US10623485B2 (en) 2012-07-16 2020-04-14 Seagate Technology Llc Method of, and apparatus for, file system replication
US8904231B2 (en) * 2012-08-08 2014-12-02 Netapp, Inc. Synchronous local and cross-site failover in clustered storage systems
US11086898B2 (en) 2013-03-13 2021-08-10 Amazon Technologies, Inc. Token-based admission control for replicated writes
US9336288B2 (en) 2013-06-03 2016-05-10 Bank Of America Corporation Workflow controller compatibility

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002163167A (ja) * 1999-08-03 2002-06-07 Vision Arts Kk 画像ファイルを記録したコンピュータ読み取り可能な記録媒体、この記録媒体の作成装置、画像ファイル作成プログラムを記録した媒体、画像ファイル送信装置、画像ファイル処理装置、画像ファイル処理プログラムを記録した媒体
JP2002010234A (ja) * 2000-06-19 2002-01-11 Sony Corp コンテンツ配信システム及び方法、情報提供装置、情報端末、記録媒体
JP2004235921A (ja) * 2003-01-30 2004-08-19 Sharp Corp コンテンツ配信システム、コンテンツ配信装置、プログラム、及び記録媒体
JP2007086869A (ja) * 2005-09-20 2007-04-05 Kddi Corp コンテンツ配信システム
JP2012080417A (ja) * 2010-10-04 2012-04-19 Pioneer Electronic Corp ストリーミング再生装置、ストリーミング再生方法、コンピュータプログラム及び記録媒体
JP2013069205A (ja) * 2011-09-26 2013-04-18 Oki Electric Ind Co Ltd 配信システムおよび仮想マシン割当装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022534509A (ja) * 2019-05-31 2022-08-01 セールスフォース ドット コム インコーポレイティッド データベース変更ストリームのキャッシュ技術
JP7322184B2 (ja) 2019-05-31 2023-08-07 セールスフォース インコーポレイテッド データベース変更ストリームのキャッシュ技術

Also Published As

Publication number Publication date
EP3069274A2 (en) 2016-09-21
JP6246358B2 (ja) 2017-12-13
BR112016010555A2 (ja) 2017-08-08
WO2015070239A2 (en) 2015-05-14
CN105706086B (zh) 2019-03-15
KR20160083941A (ko) 2016-07-12
AU2014346369A1 (en) 2016-06-02
US20150134797A1 (en) 2015-05-14
EP3069274A4 (en) 2017-06-21
WO2015070239A3 (en) 2015-12-23
US9794135B2 (en) 2017-10-17
KR101925696B1 (ko) 2018-12-05
BR112016010555B1 (pt) 2022-09-27
EP3069274B1 (en) 2018-08-22
AU2014346369B2 (en) 2017-05-11
BR112016010555A8 (pt) 2022-07-19
CN105706086A (zh) 2016-06-22
CA2929777A1 (en) 2015-05-14
CA2929777C (en) 2021-10-26

Similar Documents

Publication Publication Date Title
JP6246358B2 (ja) 大規模データストリームの取得、記憶、及び消費のための管理型サービス
JP6510112B2 (ja) データストリーム取り込み及び永続性ポリシ
JP6450756B2 (ja) パーティションベースのデータストリーム処理フレームワーク
JP6250189B2 (ja) データストリームのためのクライアント構成可能なセキュリティオプション
US10691716B2 (en) Dynamic partitioning techniques for data streams
US9858322B2 (en) Data stream ingestion and persistence techniques

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170529

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170613

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170913

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20171114

R150 Certificate of patent or registration of utility model

Ref document number: 6246358

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