IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-11-25
(45)【発行日】2022-12-05
(54)【発明の名称】イベントストリーム処理システム
(51)【国際特許分類】
   G06F 9/50 20060101AFI20221128BHJP
【FI】
G06F9/50 120A
G06F9/50 150B
【請求項の数】 25
【外国語出願】
(21)【出願番号】P 2018080307
(22)【出願日】2018-04-19
(65)【公開番号】P2018190406
(43)【公開日】2018-11-29
【審査請求日】2021-01-13
(31)【優先権主張番号】62/500,258
(32)【優先日】2017-05-02
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】62/554,860
(32)【優先日】2017-09-06
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】15/838,089
(32)【優先日】2017-12-11
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】506332063
【氏名又は名称】セールスフォース ドット コム インコーポレイティッド
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100091214
【弁理士】
【氏名又は名称】大貫 進介
(72)【発明者】
【氏名】スティーブン ポウィス
(72)【発明者】
【氏名】スタン レモン
(72)【発明者】
【氏名】ケヴィン ピーク
【審査官】坂東 博司
(56)【参考文献】
【文献】国際公開第2017/058734(WO,A1)
【文献】米国特許出願公開第2015/0032738(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 9/50
(57)【特許請求の範囲】
【請求項1】
1つ以上のデータソースからデータを取り込み、前記データをイベントストリームプロセッサの無限のストリームに変換するストリーム処理システムであって、
第1の時点に配置される第1の連携スパウトインスタンスであって、1つ以上の第2のスパウトインスタンスをインスタンス化し、前記第1の時点より以降の第2の時点で前記1つ以上の第2のスパウトインスタンスを配置する第1の連携スパウトインスタンスを有し、
前記1つ以上の第2のスパウトインスタンスは、
前記1つ以上のデータソースにそれぞれ接続し、前記1つ以上のデータソースの各自のものから前記データの各自の部分を取り込み、
前記データの取り込まれた部分に基づきメッセージを出力し、
前記イベントストリームプロセッサの無限のストリームは、前記メッセージに基づくシステム。
【請求項2】
前記出力されたメッセージを受信するメッセージバッファを更に有し、
前記無限のストリームは、前記メッセージバッファから出力される、請求項1記載のシステム。
【請求項3】
前記第1の連携スパウトインスタンスは、1つ以上の第3のスパウトインスタンスをインスタンス化し、前記第2の時点より以降の第3の時点に前記1つ以上の第3のスパウトインスタンスを配置し、
前記1つ以上の第3のスパウトインスタンスは、
1つ以上の更なるデータソースにそれぞれ接続し、前記1つ以上の更なるデータソースの各自のものから更なるデータの各自の部分を取り込み、
前記更なるデータの取り込まれた部分に基づきメッセージを出力し、
前記イベントストリームプロセッサの無限のストリームは、前記メッセージと前記更なるメッセージとに基づく、請求項1記載のシステム。
【請求項4】
前記データソースは、時系列の順序付けされたイベントログを含む、請求項1記載のシステム。
【請求項5】
前記データソースは、時系列の順序付けされたイベントログを含み、
前記更なるデータソースは、更なる時系列の順序付けされたイベントログを含む、請求項3記載のシステム。
【請求項6】
前記更なる時系列の順序付けされたイベントログは、前記時系列の順序付けされたイベントログのスタート時間後に始まる、請求項5記載のシステム。
【請求項7】
前記第1の連携スパウトインスタンスは更に、前記イベントストリームプロセッサからメッセージを受信し、前記メッセージのコンテンツに基づき前記1つ以上の第2のスパウトインスタンスと前記1つ以上の第3のスパウトインスタンスとの間に前記メッセージを分配する、請求項3記載のシステム。
【請求項8】
前記メッセージは、前記無限のストリームを処理したことに応答して、前記イベントストリームプロセッサによって生成されたメッセージ完了通知とメッセージ失敗通知とを含む、請求項7記載のシステム。
【請求項9】
前記メッセージは、前記イベントストリームプロセッサの単一の出力インタフェースを介し受信される、請求項8記載のシステム。
【請求項10】
前記第1の連携スパウトインスタンスは、前記1つ以上の第2のスパウトインスタンスの個別のものを選択し、前記1つ以上の第2のスパウトインスタンスの個別のものに非アクティブ化するよう通知し、前記1つ以上の第2のスパウトインスタンスの選択された個別のものをクローズする、請求項1記載のシステム。
【請求項11】
前記1つ以上の第2のスパウトインスタンスは、複数のスパウトインスタンスを含み、
前記複数のスパウトインスタンスの第1のスパウトインスタンスは、選択された期間について、前記データの取り込まれた部分のイベントログに1つ以上のフィルタリング基準を適用するよう構成され、
前記メッセージの第1のサブセットは、前記1つ以上のフィルタリング基準の適用に応答して、前記複数のスパウトインスタンスの第1のスパウトインスタンスによって生成され、
前記複数のスパウトインスタンスの第2のスパウトインスタンスは、前記選択された期間の終了後、前記1つ以上のフィルタリング基準のネゲーションを前記イベントログに適用するよう構成され、
前記メッセージの異なる第2のサブセットは、前記1つ以上のフィルタリング基準のネゲーションの適用に応答して、前記複数のスパウトインスタンスの第2のスパウトインスタンスによって生成される、請求項1記載のシステム。
【請求項12】
前記選択された期間は、前記イベントストリームプロセッサによって生成されたデータを格納するためのストレージデバイスの利用不可期間に対応する、請求項11記載のシステム。
【請求項13】
1つ以上のデータソースからデータを取り込み、前記データをイベントストリームプロセッサの無限のストリームに変換するストリーム処理システムであって、
第1の時点に配置される第1の連携スパウトインスタンスであって、第2のスパウトインスタンスと第3のスパウトインスタンスとをインスタンス化する第1の連携スパウトインスタンスを有し、
前記第1の連携スパウトインスタンスは、前記第2及び第3のスパウトインスタンスを順次配置し、前記第2のスパウトインスタンスは、前記第1の時点より以降の第2の時点で配置され、前記第3のスパウトインスタンスは、前記第2の時点より以降の第3の時点で配置され、
前記第2及び第3のスパウトインスタンスはそれぞれ、前記1つ以上のデータソースから同じイベントログを取り込み、第1のメッセージと第2のメッセージとをそれぞれ出力し、
前記イベントストリームプロセッサの無限のストリームは、前記第1及び第2のメッセージに基づくシステム。
【請求項14】
前記第2のスパウトインスタンスは、前記イベントログに第1のフィルタリング基準を適用するよう構成され、前記第3のスパウトインスタンスは、前記イベントログに第1のフィルタリング基準と異なる第2のフィルタリング基準を適用するよう構成される、請求項13記載のシステム。
【請求項15】
前記第2のフィルタリング基準は、前記第1のフィルタリング基準のネゲーションを含む、請求項14記載のシステム。
【請求項16】
1つ以上のデータソースからデータを取り込み、前記データをイベントストリームプロセッサの無限のストリームに変換する方法であって、
第1の時点で第1の連携スパウトインスタンスを配置するステップと、
前記第1の連携スパウトインスタンスを配置した後、前記第1の連携スパウトインスタンスを利用して、1つ以上の第2のスパウトインスタンスをインスタンス化し、前記第1の時点より以降の第2の時点で前記1つ以上の第2のスパウトインスタンスを配置するステップと、
前記1つ以上のデータソースに接続し、前記1つ以上の第2のスパウトインスタンスをそれぞれ利用して、前記1つ以上のデータソースから前記データの各自の部分を取り込むステップと、
前記データの取り込まれた部分に基づき、前記1つ以上の第2のスパウトインスタンスからメッセージを出力するステップと、
を有し、
前記イベントストリームプロセッサの無限のストリームは、前記メッセージに基づく方法。
【請求項17】
前記メッセージを単一のバッファに出力するステップを更に有し、
前記無限のストリームは、前記バッファから出力される、請求項16記載の方法。
【請求項18】
前記第1の連携スパウトインスタンスを配置した後、1つ以上の第3のスパウトインスタンスをインスタンス化し、前記第2の時点より以降の第3の時点で前記1つ以上の第3のスパウトインスタンスを配置するステップと、
1つ以上の更なるデータソースに接続し、前記1つ以上の第3のスパウトインスタンスをそれぞれ利用して、前記1つ以上の更なるデータソースから更なるデータの各自の部分を取り込むステップと、
前記更なるデータの取り込まれた部分に基づき、前記1つ以上の第3のスパウトインスタンスからメッセージを出力するステップと、
を更に有し、
前記イベントストリームプロセッサの無限のストリームは、前記メッセージと前記更なるメッセージとに基づく、請求項16記載の方法。
【請求項19】
前記データソースは、時系列の順序付けされたイベントログを含む、請求項16記載の方法。
【請求項20】
前記データソースは、時系列の順序付けされたイベントログを含み、
前記更なるデータソースは、更なる時系列の順序付けされたイベントログを含む、請求項18記載の方法。
【請求項21】
前記更なる時系列の順序付けされたイベントログは、前記時系列の順序付けされたイベントログのスタート時間後に始まる、請求項20記載の方法。
【請求項22】
前記第1の連携スパウトインスタンスにおいて前記イベントストリームプロセッサからメッセージを受信するステップと、
前記メッセージのコンテンツに基づき、前記1つ以上の第2のスパウトインスタンスと前記1つ以上の第3のスパウトインスタンスとの間で前記メッセージを分配するステップと、
を更に有する、請求項18記載の方法。
【請求項23】
前記メッセージは、前記無限のストリームを処理したことに応答して、前記イベントストリームプロセッサによって生成されたメッセージ完了通知とメッセージ失敗通知とを含む、請求項22記載の方法。
【請求項24】
前記メッセージは、前記イベントストリームプロセッサの単一の出力インタフェースを介し受信される、請求項23記載の方法。
【請求項25】
前記第1の連携スパウトインスタンスがオープンである間、クローズ対象の前記1つ以上の第2のスパウトインスタンスの個別のものを選択するステップと、
前記1つ以上の第2のスパウトインスタンスの個別のものに非アクティブ化するよう通知するステップと、
前記第1の連携スパウトインスタンスによって前記イベントストリームプロセッサとのインタフェースを維持しながら、前記1つ以上の第2のスパウトインスタンスの個別のものをクローズするステップと、
を更に有する、請求項16記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
[優先権]
本出願は、それぞれが参照によってその全体がここに援用される、2017年5月2日に出願された米国仮出願第62/500,258号(整理番号8665-0095)及び2017年9月6日に出願された米国仮出願第62/554,860号の利益を主張する。
[著作権表示]
本特許文献の開示の一部は、著作権保護を受ける題材を含む。著作権所有者は、それが米国特許商標庁の特許ファイル又はレコードに現れるとき、特許文献又は特許開示の何れかの者によるファクシミリ複製に対して異議を有さないが、そうでない場合、全ての著作権を留保する。
[技術分野]
1つ以上の実現形態は、一般に計算システムに関し、一部の実施例は、バーチャルスパウト(virtual spout)を利用するイベントストリーム処理システムに関し、一部の実施例では、バーチャルスパウトはサイドライニング(sidelining)を利用しうる。
【背景技術】
【0002】
アプリケーションシステム(Salesforce Pardotなど)は、イベントストリーム処理システム(例えば、Apache Storm)を多用して、順序付けされた時系列イベントログ(例えば、Apache Kafka)から消費する。イベントストリーム処理システム内において、スパウトはソースからデータを取り入れ、当該データをイベントストリームプロセッサが処理可能な無限のストリームに変換する。
【0003】
一部のシステムでは、スパウトはイベントストリーム処理システムが配置された時点で一度作成される。そのようなスパウトは、データストリーム処理システムが再配置されるまで、静的で不変なままである。
【0004】
単一のスパウトにより配置されたシステムでは、当該単一のスパウトは、マルチテナントシステムにおける単一のテナントなどのソースからデータを消費する。スパウトは、イベントストリームプロセッサからの完了及び失敗したメッセージ通知を処理すると共に、イベントストリームプロセッサへのメッセージの発信を処理する。スパウトは、固定され、テナントのデータストアとのみ通信可能である。
【0005】
一部のイベントストリーム処理システムは、複数のスパウトを含む。そのようなシステムでは、複数のテナントの各テナントについて別々のスパウトが存在しうる。そのようなスパウトは、トポロジ配置時に規定され、その後の何れかの時点でも追加又は削除されないかもしれない。新たなテナントがサインアップされると、トポロジが停止され、規定された新たなスパウトにより再配置されるまで、テナントのデータソースにサービス提供するため、更なる新たなスパウトコンポーネントを作成することはできない。テナントのサービス中断の可能性などの複数の理由のため、再配置は望ましくない。
【図面の簡単な説明】
【0006】
含まれる図面は例示的な目的のためであり、開示される発明のシステム、装置、方法及びコンピュータ可読記憶媒体のための可能な構成及び処理の具体例を提供するのに利用される。これらの図面は、開示される実現形態の精神及び範囲から逸脱することなく、当業者により行いうる形式及び詳細の変更を限定するものでない。
図1A】いくつかの実現形態によるオンデマンドデータベースサービスが利用可能な一例となる環境のブロック図を示す。
図1B】いくつかの実現形態による図1Aの要素の一例となる実現形態とこれらの要素の間の一例となる相互接続とのブロック図を示す。
図2】イベントストリーム処理システムを含む計算システム200を示す。
図3A】バーチャルスパウト対応スパウトインスタンスのライフサイクルを示すシーケンス図を示す。
図3B】バーチャルスパウト対応スパウトインスタンスのライフサイクルを示すシーケンス図を示す。
図4】単一のバーチャルスパウトを備えたイベントストリーム処理システムを示す。
図5】複数のバーチャルスパウトを備えたイベントストリーム処理システムを示す。
図6】テナントの1つのバーチャルスパウトが他のテナントのサービスを混乱させることなくクローズされるイベントストリーム処理システムを示す。
図7A】アクティブにサイドライニングしていないとき、サイドライニング中及びサイドライニングの停止後の図2のイベントストリーム処理システムの異なる状態をそれぞれ示す。
図7B】アクティブにサイドライニングしていないとき、サイドライニング中及びサイドライニングの停止後の図2のイベントストリーム処理システムの異なる状態をそれぞれ示す。
図7C】アクティブにサイドライニングしていないとき、サイドライニング中及びサイドライニングの停止後の図2のイベントストリーム処理システムの異なる状態をそれぞれ示す。
図8A図2及び/又は7A~7Cにおいて説明されるイベントストリーム処理システムによって実行されるプロセスを示す。
図8B図2及び/又は7A~7Cにおいて説明されるイベントストリーム処理システムによって実行されるプロセスを示す。
【発明を実施するための形態】
【0007】
開示される実現形態によるシステム、装置、コンピュータ可読記憶媒体及び方法の具体例が本セクションにおいて説明される。これらの具体例は、コンテクストを追加し、開示される実現形態の理解を支援するためだけに提供されている。従って、開示される実現形態は提供される具体的詳細の一部又は全てなく実施されうることは、当業者に自明であろう。他の例では、“ブロック”としてここで参照される特定のプロセス又は方法の処理は、開示される実現形態を不要に不明瞭にすることを回避するため詳細には説明されていない。他の実現形態及び適用もまた可能であり、以下の具体例は範囲又は設定において明確な又は限定するものとしてとられるべきでない。
【0008】
以下の詳細な説明では、例示によって特定の実現形態が示され、本説明の一部を構成する添付図面が参照される。これらの開示された実現形態は、当業者が実現形態を実施することを可能にするのに十分詳細に説明されるが、他の実現形態が利用されてもよく、それらの精神及び範囲から逸脱することなく開示された実現形態に変更が可能であるように、これらの具体例は限定的でないことが理解されるべきである。例えば、ここに図示及び説明される方法のブロックは、他の一部の実現形態において示される順序において必ずしも実行される必要はない。さらに、他の一部の実現形態では、開示される方法は説明されるより多くの又はより少ないブロックを含みうる。他の具体例として、別々のブロックとしてここに説明される一部のブロックは、他のいくつかの実現形態では組み合わせされてもよい。他方、単一のブロックとしてここに説明されうるものは、他のいくつかの実現形態では複数のブロックにおいて実現されうる。さらに、接続詞“又は”は、特段の断りがない場合、必要に応じて内包的な意味と意図され、すなわち、“A,B又はC”というフレーズは、“A”、“B”、“C”、“A及びB”、“B及びC”、“A及びC”並びに“A,B及びC”の可能性を含むことが意図される。
【0009】
いくつかのイベントストリーム処理システムにおけるいくつかのスパウトは、以下のライフサイクル段階を受けうる。
・インスタンス化-これは、イベント処理システムの実行前に行われる。スパウトは、規定、作成及び設定されうる。システム内の全てのコンポーネントは、ライフサイクルのこの段階において規定されうる。この段階が完了した後、更なるコンポーネントは作成されないか、あるいは、システムから削除されない。
・配置-スパウトコンポーネントは、他の全てのコンポーネント共にApache Stormクラスタに配置されてもよい。
・オープン-スパウトを含むイベント処理システムにおけるコンポーネントの全てには、配置されたシステムに関する情報が与えられ、何れか必要なランタイムコンフィギュレーションを実行するよう指示される。
・アクティブ化-イベント処理システムにおけるスパウトコンポーネントは、“スタート”するよう通知される。各スパウトは、それの外部データソースに接続し、イベント処理システムへのデータの取り込みを開始する。スパウトコンポーネントによって生成されるメッセージは、以下のライフサイクル段階を有しうる。
○次のメッセージ-イベント処理システムは、次のメッセージがスパウトからの処理のためシステムに取り込まれることを要求する。
○アクノリッジメント-イベント処理システムは、処理のためシステムに送信した特定のメッセージの処理が成功したことをスパウトコンポーネントに通知する。
○フェイル-イベント処理システムは、処理のためシステムに送信した特定のメッセージの処理が成功しなかったことをスパウトコンポーネントに通知する。
・非アクティブ化-典型的には、イベント処理システムのシャットダウン前に、全てのスパウトはイベント処理システムへのデータの取り込みを中止するよう指示される。
・クローズ-全てのスパウトコンポーネントは、何れか必要な“クリーンアップ”又は“シャットダウン”タスクを実行し、その後に実行を中止する。
【0010】
ここに説明及び参照されるいくつかの実現形態は、バーチャルスパウトを含むイベントストリーム処理システムのためのシステム、装置、コンピュータにより実現される方法及びコンピュータ可読記憶媒体に関する。
【0011】
バーチャルスパウトを利用する実施例は、単一の固定的な“連携”スパウトコンポーネント内で1つ以上の“スパウト”を実行する。連携スパウトのインスタンスは、配置時に単一の固定的なスパウトコンポーネントとして自らをストリーム処理エンジンに提供する。連携スパウトは、いくつかの実施例では、それらが要求されるとき、新たなバーチャルスパウトのインスタンスを内部的に動的に作成する。さらに、いくつかの実施例では、連携スパウトは、それらがもはや必要とされないとき、バーチャルスパウトのインスタンスをシャットダウンする。連携スパウトのインスタンスは、全ての内部的なバーチャルスパウトのインスタンスのスパウトライフサイクルを管理する。連携スパウトのインスタンスはまた、メッセージライフサイクルに関してストリーム処理エンジンとそれの内部的に管理されたバーチャルスパウトのインスタンスとの間の全ての通信を管理する。
【0012】
Pardotカスタマは、典型的には、それにリンクされたSalesforce.comアカウントを有する。Pardotが新たなカスタマを毎日サインオンするとき、彼らのSalesforce.comアカウントから彼らのPardotアカウントにデータをストリーミングする必要がある。Pardotが新たなカスタマをサインアップする毎に、新たなスパウトインスタンスを作成し、ストームトポロジーを再配置することは、実現可能でないかもしれない(新たなカスタマのサインアップの頻度のため)。バーチャルスパウトを利用する実施例では、連携スパウトは、新たなカスタマをモニタし、新たなバーチャルスパウトのインスタンスを作成/開始する。同様に、カスタマがPardotによる彼らのアカウントを終了させるとき、連携スパウトはこれを検出し、カスタマの対応するバーチャルスパウトのインスタンスをシャットダウンする。
【0013】
一部の実施例は、1つ以上のデータソースからデータを取り込み、データをイベントストリームプロセッサの無限のストリームに変換するためのストリーム処理システムを含む。ストリーム処理システムは、第1の時点に配置された第1の連携スパウトインスタンスを含み、当該第1の連携スパウトインスタンスは1つ以上の第2のスパウトインスタンスをインスタンス化し、第1の時点より以降の第2の時点で1つ以上の第2のスパウトインスタンスを配置する。
【0014】
1つ以上の第2のスパウトインスタンスのそれぞれは、1つ以上のデータソースにそれぞれ接続し、各自のデータ部分を1つ以上のデータソースの各自のものから取り込むよう構成される。1つ以上の第2のスパウトインスタンスは、データの取り込まれた部分に基づきメッセージを出力する。イベントストリームプロセッサの無限のストリームは、メッセージに基づくものであってもよい。
【0015】
そのような実施例では、データソースに関連する動的な変更がサポートされる。例えば、新たなデータソースが必要とされるか(いくつかの実施例では新たなテナントのため、あるいは、他の何れかの理由のため)、あるいは、既存のデータソースがもはや必要とされない場合、新たなバーチャルスパウトが作成可能であるか、あるいは、既存のスパウトが他のデータソースの処理を混乱させることなく完了可能である(例えば、新たなデータソース又はクローズされたデータソースに関連しないテナントに対するサービスを混乱させることなく)。
【0016】
いくつかの実施例では、イベントストリーム処理システムは、必須ではないが、1つ以上の第2のスパウトインスタンスを利用してサイドライニングを実行する。これらの実施例では、第1及び第2のスパウトインスタンスのそれぞれは、異なる時点におけるソースデータの同一部分を取り込む。
【0017】
サイドライニングを利用する1つの具体例は、1つ以上のデータソースからデータを取り込み、当該データをイベントストリームプロセッサのための無限のストリームに変換するストリーム処理システムである。ストリーム処理システムは、第1の時点で配置された第1の連携スパウトインスタンスを含んでもよく、第1の連携スパウトインスタンスは第2のスパウトインスタンス及び第3のスパウトインスタンスをインスタンス化し、第1の連携スパウトインスタンスは第2及び第3のスパウトインスタンスを順次配置し、第2のスパウトインスタンスは第1の時点より以降の第2の時点で配置され、第3のスパウトインスタンスは第2の時点より以降の第3の時点で配置され、第2及び第3のスパウトインスタンスはそれぞれ1つ以上のデータソースから同一のデータ部分を取り込み、それぞれ第1のメッセージ及び第2のメッセージを出力し、イベントストリームプロセッサの無限のストリームは第1及び第2のメッセージに基づく。第2のスパウトインスタンスは1つ以上のデータソースからのデータ部分に対して第1のフィルタリング基準を適用するよう構成され、第3のスパウトインスタンスは1つ以上のデータソースからのデータ部分に対して第1のフィルタリング基準と異なる第2のフィルタリング基準を適用するよう構成される。第2のフィルタリング基準は第1のフィルタリング基準のネゲーションを含む。
I.一例となるシステムの概略
図1Aは、いくつかの実現形態によるオンデマンドデータベースサービスが利用可能な環境10の具体例のブロック図を示す。環境10は、ユーザシステム12、ネットワーク14、データベースシステム16(また、“クラウドベースシステム”としてここでは参照される)、プロセッサシステム17、アプリケーションプラットフォーム18、ネットワークインタフェース20、テナントデータ23を格納するためのテナントデータベース22、システムデータ25を格納するためのシステムデータベース24、システム16の各種機能を実現するためのプログラムコード26及びアプリケーションホストサービスの一部としてアプリケーションを実行するなど、データベースシステムプロセス及びテナント固有プロセスを実行するためのプロセススペース28を含む。いくつかの他の実現形態では、環境10は、これらのコンポーネント又はシステムの全てを有しなくてもよいし、あるいは、上述したものの代わりに又は加えて他のコンポーネント又はシステムを有してもよい。
【0018】
いくつかの実現形態では、環境10はオンデマンドデータベースサービスが存在する環境である。システム16を用いて実現可能なものなどのオンデマンドデータベースサービスは、システム16を所有、維持又はアクセスを提供する企業の外部のユーザに利用可能とされるサービスである。上述したように、このようなユーザは、一般にシステム16の構築又は維持に関与する必要はない。代わりに、システム16によって提供されるリソースは、ユーザがシステム16によって提供されるサービスを必要とするとき、このようなユーザの利用のために、すなわち、ユーザの要求に応じて利用可能とされてもよい。いくつかのオンデマンドデータベースサービスは、マルチテナントデータベースシステム(MTS)を形成するため、1つ以上のテナントからの情報を共通のデータベースイメージのテーブルに格納可能である。“マルチテナントデータベースシステム”という用語は、データベースシステムのハードウェア及びソフトウェアの各種要素が1つ以上のカスタマ又はテナントによって共有されうるシステムを参照可能である。例えば、所与のアプリケーションサーバは、潜在的にはるかに多数のカスタマのためのフィードアイテムなどリクエストを同時に処理しうる。データベースイメージは、1つ以上のデータベースオブジェクトを含みうる。リレーショナルデータベースマネージメントシステム(RDBMS)又は等価なものが、データベースオブジェクトに対する情報の格納及び抽出を実行可能である。
【0019】
アプリケーションプラットフォーム18は、システム16のハードウェア又はソフトウェアインフラストラクチャなど、システム16のアプリケーションが実行可能なフレームワークとすることができる。いくつかの実現形態では、アプリケーションプラットフォーム18は、オンデマンドデータベースサービスのプロバイダ、ユーザシステム12を介しオンデマンドデータベースサービスにアクセスするユーザ又はユーザシステム12を介しオンデマンドデータベースサービスにアクセスするサードパーティアプリケーションデベロッパによって開発される1つ以上のアプリケーションの作成、管理及び実行を可能にする。
【0020】
いくつかの実現形態では、システム16は、ウェブベースカスタマ関係マネージメント(CRM)システムを実現する。例えば、そのようないくつかの実現形態では、システム16は、ユーザシステム12との間で関連するデータ、コード、フォーム、レンダリング可能なウェブページ及びドキュメント並びに他の情報を提供するため、CRMソフトウェアアプリケーションを実現及び実行し、データベースシステムとの間で関連するデータ、オブジェクト及びウェブページコンテンツを格納及び抽出するよう構成されるアプリケーションサーバを含む。いくつかのMTS実現形態では、複数のテナントのデータは、テナントデータベース22の同一の物理データベースオブジェクトに格納されうる。いくつかのそのような実現形態では、テナントデータはテナントデータベース22の記憶媒体に構成され、これにより、あるテナントのデータが他のテナントのものから論理的に分離され続け、データが明示的に共有されていない場合、あるテナントは他のテナントのデータにアクセスできない。システム16はまた、CRMアプリケーション以外又は加えてアプリケーションを実現する。例えば、システム16は、CRMアプリケーションを含む複数のホストされた(標準的及びカスタム)アプリケーションへのアクセスをテナントに提供できる。CRMを含んでもよいし、あるいは含まなくてもよいユーザ(又はサードパーティデベロッパ)アプリケーションは、アプリケーションプラットフォーム18によってサポートされうる。アプリケーションプラットフォーム18は、1つ以上のデータベースオブジェクトへのアプリケーションの作成及び格納と、システム16のプロセススペースにおける1つ以上のバーチャルマシーンのアプリケーションの実行とを管理する。
【0021】
いくつかの実現形態によると、各システム16は、システム16のテナントとしてユーザシステム12によるアクセスをサポートするよう、ウェブページ、フォーム、アプリケーション、データ及び目ディコンテンツをユーザ(クライアント)システム12に提供するよう構成される。また、システム16は、データが共有されない場合、各テナントのデータを分離して維持するためのセキュリティ機構を提供する。複数のMTSが利用される場合、それらは、互いに近接して配置されてもよいし(例えば、単一の建物又はキャンパスに配置されたサーバファームに)、あるいは、それらは互いに遠隔地に配置されてもよい(例えば、都市Aに配置された1つ以上のサーバ及び都市Bに配置された1つ以上のサーバ)。ここで利用されるように、各MTSは、1つ以上の地理的位置にわたって又は論理的に分散される1つ以上の論理的又は物理的に接続されたサーバを含みうる。さらに、“サーバ”という用語は、処理ハードウェア及びプロセススペースを含む計算デバイス又はシステム、メモリデバイス又はデータベースなどの関連する記憶媒体、及びいくつかの例では当該技術において周知であるようなデータベースアプリケーション(例えば、OODBMS又はRDBMS)を参照することが意図される。また、“サーバシステム”及び“サーバ”はここではしばしば互換的に利用されることが理解されるべきである。同様に、ここで説明されるデータベースオブジェクトは、単一のデータベース、分散されたデータベース、分散データベースの集まり、冗長オンライン又はオフラインバックアップ又は他の冗長性を備えたデータベースなどの一部として実現可能であり、分散されたデータベース又はストレージネットワーク及び関連する処理インテリジェンスを含みうる。
【0022】
ネットワーク14は、互いに通信するシステム又はデバイスの何れかのネットワーク又はネットワークの組み合わせとすることが可能であるか、あるいは、含むことが可能である。例えば、ネットワーク14は、LAN(ローカルエリアネットワーク)、WAN(ワイドエリアネットワーク)、電話網、無線ネットワーク、セルラネットワーク、ポイント・ツー・ポイントネットワーク、スターネットワーク、トークンリングネットワーク、ハブネットワーク又は他の適切なコンフィギュレーションの何れか1つ又は何れかの組み合わせとすることが可能であるか、あるいは、含むことが可能である。ネットワーク14は、“インターネット”(大文字“I”による)としてしばしば参照されるネットワークのグローバルインターネットワークなど、TCP/IP(Transfer Control Protocol and Internet Protocol)ネットワークを含むことが可能である。インターネットは、ここでは具体例の多くにおいて利用される。しかしながら、TCP/IPは頻繁に実装されるプロトコルであるが、開示される実現形態が利用可能なネットワークはそれに限定されないことが理解されるべきである。
【0023】
ユーザシステム12は、TCP/IP及びHTTP、FTP、AFS、WAPなどの通信するための上位のネットワークレベルにおける他の一般的なインターネットプロトコルを利用してシステム16と通信可能である。HTTPが利用される具体例では、各ユーザシステム12は、“ウェブブラウザ”として一般的に参照されるHTTPクライアント又はシステム16のHTTPサーバとの間でHTTP信号を送受信するための単なる“ブラウザ”を含むことができる。このようなHTTPサーバは、システム16とネットワーク14との間の単なるネットワークインタフェース20として実現可能であるが、他の技術はこれらの技術に加えて又は代わりに利用可能である。いくつかの実現形態では、システム16とネットワーク14との間のネットワークインタフェース20は、ロードをバランスさせ、複数のサーバを介し入力されるHTTPリクエストを均等に分配するためのラウンドロビンHTTPリクエストディストリビュータなどのロード共有機能を含む。MTS実現形態では、各サーバはMTSデータへのアクセスを有することが可能であるが、他の代わりのコンフィギュレーションが代わりに利用されてもよい。
【0024】
ユーザシステム12は、データベースシステム16にアクセスするため、ユーザにより利用可能な何れかの計算デバイス又は他のデータ処理装置若しくはシステムとして実現可能である。例えば、ユーザシステム12の何れかは、デスクトップコンピュータ、ワークステーション、ラップトップコンピュータ、タブレットコンピュータ、携帯計算デバイス、携帯電話(例えば、“スマートフォン”)又は他の何れかのWi-Fi対応デバイス、無線アクセスプロトコル(WAP)対応デバイス又はインターネット若しくは他のネットワークと直接的又は間接的にインタフェース可能な他の計算デバイスとすることができる。“ユーザシステム”及び“計算デバイス”という用語は、ここでは互いに及び“コンピュータ”という用語と交互に利用される。上述されるように、各ユーザシステム12は、例えば、ユーザシステム12のユーザ(例えば、システム16により提供されるオンデマンドサービスの加入者)がネットワーク14を介しシステム16から利用可能な情報、ページ及びアプリケーションにアクセス、処理及び閲覧することを可能にする、WebKitプラットフォーム、MicrosoftのInternet Exploreブラウザ、AppleのSafari、GoogleのChrome、Operaのブラウザ又はMozillaのFirefoxブラウザなどに基づくウェブブラウザなどのウェブブラウジング(又は単に“ブラウジング”)プログラムなどのHTTPクライアントを典型的に実行する。
【0025】
各ユーザシステム12はまた、典型的には、システム16又は他のシステム若しくはサーバによって提供されるページ、フォーム、アプリケーション及び他の情報に関連して、ユーザシステム12のディスプレイ(例えば、他の可能性のうち、モニタスクリーン、液晶ディスプレイ(LCD)、発光ダイオード(LED)ディスプレイ)上のブラウザによって提供されるグラフィカルユーザインタフェース(GUI)とやりとりするため、キーボード、マウス、トラックボール、タッチパッド、タッチスクリーン、ペン又はスタイラスなどの1つ以上のユーザ入力デバイスを含む。例えば、ユーザインタフェースデバイスは、システム16によってホストされるデータ及びアプリケーションにアクセスし、格納されているデータに対してサーチを実行し、ユーザがユーザに提示される各種GUIページとやりとりすることを可能にするのに利用可能である。上述されるように、イントラネット、エクストラネット、バーチャルプライベートネットワーク(VPN)、非TCP/IPベースネットワーク、何れかのLAN若しくはWANなどの他のネットワークが、インターネットの代わりに又は加えて利用可能であるが、実現形態はインターネットによる利用に適している。
【0026】
ユーザシステム12のユーザは、各自の能力において異なりうるものであり、特定のユーザシステム12の能力は、ユーザシステムの現在のユーザについてのパーミッション(パーミッションレベル)によって完全に決定可能である。例えば、販売員が特定のユーザシステム12を利用してシステム16とやりとりしている場合、当該ユーザシステムは、販売員に割り当てられた能力を有することができる。しかしながら、管理者がユーザシステム12を利用してシステム16とやりとりしている間、ユーザシステムは、当該管理者に割り当てられた能力を有することができる。階層的ロールモデルが利用される場合、あるパーミッションレベルのユーザは、下位のパーミッションレベルのユーザによりアクセス可能なアプリケーション、データ及びデータベース情報にアクセス可能であるが、上位のパーミッションレベルのユーザによりアクセス可能な特定のアプリケーション、データベース情報及びデータへのアクセスを有しないかもしれない。従って、異なるユーザは、一般にユーザ各自のセキュリティ又はパーミッションレベル(また、“権限”として参照される)に応じて、アプリケーション及びデータベース情報にアクセス及び修正することに関して、異なる能力を有することになる。
【0027】
いくつかの実現形態によると、各ユーザシステム12及びそれのコンポーネントの一部又は全ては、Intel Pentium(登録商標)プロセッサなどの中央処理ユニット(CPU)を用いて実行されるコンピュータコードを含む、ブラウザなどのアプリケーションを用いてオペレータにより設定可能である。同様に、システム16(及び複数存在する場合、MTSの更なるインスタンス)及びそれのコンポーネントの全ては、Intel Pentium(登録商標)プロセッサなどを含みうるCPU又は複数のCPUを含むよう実現されうるプロセッサシステム17を用いて実行されるコンピュータコードを含むアプリケーションを用いてオペレータにより設定可能とすることができる。
【0028】
システム16は、ここに説明されるプロセスの実現形態の一部を実行するようサーバ又は他の計算システム(又は当該サーバ又は計算システムの集まり)をプログラムするよう実行可能又は利用される非一時的な命令を格納して有形のコンピュータ可読媒体を含む。例えば、コンピュータプログラムコード26は、ここに説明されるようなウェブページ、アプリケーション及び他のデータ及びメディアコンテンツを相互通信及び処理するようシステム16を動作及び設定するための命令を実現可能である。いくつかの実現形態では、コンピュータコード26は、ハードディスク上にダウンロード及び格納可能であるが、プログラムコード全体又はその一部はまた、ROM又はRAMなどの周知な他の何れかの揮発性若しくは不揮発性記憶媒体に格納可能であるか、あるいは、フロッピーディスク、光ディスク、デジタル多用途ディスク(DVD)、コンパクトディスク(CD)、マイクロドライバ及び光磁気ディスクを含む何れかのタイプの回転媒体、磁気若しくは光カード、ナノシステム(分子メモリICを含む)又は命令若しくはデータを格納するのに適した他の何れかのタイプのコンピュータ可読媒体又はデバイスなど、プログラムコードを格納可能な何れかの媒体上で提供可能である。さらに、プログラムコード全体又はその一部は、例えば、周知であるインターネットを介し又は他のサーバから伝送媒体上のソフトウェアソースから送信及びダウンロードされてもよいし、あるいは、周知である何れかの通信媒体及びプロトコル(例えば、TCP/IP、HTTP、HTTPS、イーサネットTMなど)を用いて周知である他の何れか既存のネットワーク接続(例えば、エクストラネット、VPN、LANなど)を介し送信されてもよい。また、開示された実現形態のためのコンピュータコードは、例えば、C、C++、HTML、他の何れかのマークアップ言語、JavaTM、JavaScriptTM、ActiveX、VBScriptなどの他の何れかのスクリプト言語など、サーバ又は他の計算システム上で実行可能な何れかのプログラミング言語において実現可能であり、周知である他の多数のプログラミング言語が利用されうる(JavaTMは、Sun Microsystems,Inc.の商標である)。
【0029】
図1Bは、いくつかの実現形態による図1Aの要素の一例となる実現形態とこれらの要素間の一例となる相互接続とのブロック図を示す。すなわち、図1Bはまた環境10を示すが、図1Bにおいて、システム16の各種要素及び当該要素間の各種相互接続が、いくつかのより具体的な実現形態によりより詳細に示される。さらに、図1Bにおいて、ユーザシステム12は、プロセッサシステム12A、メモリシステム12B、入力システム12C及び出力システム12Dを含む。プロセッサシステム12Aは、1つ以上のプロセッサの何れか適した組み合わせを含むことができる。メモリシステム12Bは、1つ以上のメモリデバイスの何れか適した組み合わせを含むことができる。入力システム12Cは、1つ以上のタッチスクリーンインタフェース、キーボード、マウス、トラックボール、スキャナ、カメラ又はネットワークとのインタフェースなどの入力デバイスの何れか適した組み合わせを含むことができる。出力システム12Dは、1つ以上のディスプレイデバイス、プリンタ又はネットワークとのインタフェースなどの出力デバイスの何れか適した組み合わせを含むことができる。
【0030】
図1Bにおいて、ネットワークインタフェース20は、HTTPアプリケーションサーバ100~100のセットとして実現される。各アプリケーションサーバ100は、ここではまた“アップサーバ”として参照され、テナントデータベース22及びその中のテナントデータ23と共に、システムデータベース24及びその中のシステムデータ25と通信し、ユーザシステム12から受信したリクエストに対してサービスを提供するよう構成される。テナントデータ23は、物理的又は論理的に構成又は分割可能な個々のテナントストレージスペース112に分割可能である。各テナントストレージスペース112内において、ユーザストレージ114及びアプリケーションメタデータ116は、同様に各ユーザについて配分できる。例えば、ユーザのMRU(Most Recently Used)アイテムのコピーはユーザストレージ114に格納可能である。同様に、テナントである組織全体のMRUアイテムのコピーは、テナントストレージスペース112に格納可能である。
【0031】
プロセススペース28は、システムプロセススペース102、個別テナントプロセススペース及びテナント管理プロセススペース110を含む。アプリケーションプラットフォーム18は、アプリケーションデベロッパのアプリケーションの作成及び管理をサポートするアプリケーションセットアップ機構38を含む。そのようなアプリケーションなどは、例えば、テナント管理プロセス110により管理される1つ以上のテナントプロセススペースとして加入者による実行のためにセーブルーチン36によって、テナントデータベース22にメタデータとして保存可能である。そのようなアプリケーションの呼び出しは、API32にプログラミング言語スタイルインタフェース拡張を提供するPL/SOQL34を用いて符号化可能である。いくつかのPL/SOQL言語の実現形態の詳細な説明は、2010年6月1日に発行されたCraig WeissmanによるMETHOD AND SYSTEM FOR ALLOWING ACCESS TO DEVELOPED APPLICATIONS VIA A MULTI-TENANT ON-DEMAND DATABASE SERVICEというタイトルの共有譲受された米国特許第7,730,478号において議論され、その全体が全ての目的のため参照によってこれに援用される。アプリケーションの呼び出しは、呼び出しを実行し、バーチャルマシーンにおけるアプリケーションとしてメタデータを実行する加入者のアプリケーションメタデータ116の抽出を管理する1つ以上のシステムプロセスによって検出可能である。
【0032】
図1Bのシステム16はまた、ユーザシステム12におけるユーザ又は開発者に対するシステム16の常駐プロセスとのユーザインタフェース(UI)30及びアプリケーションプログラミングインタフェース(API)32を含む。いくつかの他の実現形態では、環境10は、上述したものと同じ要素を有しなくてもよいし、あるいは、上述したものに代わって又は追加して他の要素を有してもよい。
【0033】
各アプリケーションサーバ100は、例えば、異なるネットワーク接続を介しそれぞれ手年とデータ23及びシステムデータ25へのアクセスを有するテナントデータベース22及びシステムデータベース24と通信可能に結合可能である。例えば、あるアプリケーションサーバ100はネットワーク14(例えば、インターネット)を介し結合可能であり、他のアプリケーションサーバ100N-1はダイレクトネットワークリンクを介し結合可能であり、他のアプリケーションサーバ100は更なる異なるネットワーク接続によって結合可能である。TCI/IPは、アプリケーションサーバ100とシステム16との間の通信に利用可能な典型的なプロトコルの具体例である。しかしながら、他のトランスポートプロトコルが利用されるネットワーク相互接続に応じてシステム16を最適化するのに利用可能であることは、当業者に明らかであろう。
【0034】
いくつかの実現形態では、各アプリケーションサーバ100は、システム16のテナントである何れかの組織に関連する何れかのユーザに対するリクエストを処理するよう構成される。任意の時点で各種理由のためサーバプールに対してアプリケーションサーバ100を追加及び削除可能であることが望ましいため、いくつかの実現形態では、特定のアプリケーションサーバ100に対するユーザ又は組織のサーバ親和性はない。このようないくつかの実現形態では、ロードバランシング機能を実現するインタフェースシステム(例えば、F5 Big-IPロードバランサ)は、アプリケーションサーバ100にリクエストを分派得するため、アプリケーションサーバ100とユーザシステム12との間で通信可能に結合される。一実現形態では、ロードバランサは、最小接続アルゴリズムを利用して、ユーザリクエストをアプリケーションサーバ100にルーティングする。ラウンドロビン及び観察されたレスポンス時間などのロードバランシングアルゴリズムの他の具体例がまた利用可能である。例えば、いくつかの具体例では、同一のユーザからの3つの連続するリクエストが、3つの異なるアプリケーションサーバ100にヒットし、異なるユーザからの3つのリクエストが、同一のアプリケーションサーバ100にヒットしうる。このようにして、例えば、システム16は、別々のユーザ及び組織の間で異なるオブジェクト、データ及びアプリケーションの格納及びアクセスをシステム16が処理するマルチテナントシステムとすることができる。
【0035】
一例となるストレージ利用ケースでは、あるテナントは、各販売員がシステム16を利用して自らの販売の側面を管理するセールスフォースを利用する企業とすることができる。ユーザは、ユーザの個人販売プロセスに全てが適用可能なコンタクトデータ、リードデータ、カスタマフォローアップデータ、パフォーマンスデータ、目的進捗データなどを維持可能である。MTS構成の具体例では、アクセス、閲覧、修正、報告、送信、計算などのためのデータ及びアプリケーションの全ては、少し多いネットワークアクセスを有するユーザシステム12によって維持及びアクセス可能であるため、ユーザは、多くの異なるユーザシステムの何れかから自らの販売努力及びサイクルを管理可能である。例えば、販売員がカスタマを訪問し、カスタマがロビーにおいてインターネットアクセスを有するとき、販売員は、カスタマがロビーに到着するのを待機しながら、当該カスタマに関する重要なアップデートを取得可能である。
【0036】
各ユーザのデータは各ユーザの雇用者に関係なく他のユーザのデータから分離して格納可能である一方、一部のデータは、テナントである所与の組織の複数のユーザ又は全てのユーザによって共有又はアクセス可能な組織全体のデータとすることができる。従って、他のデータ構造がユーザレベルにおいて管理可能である一方、テナントレベルにおいて配分されるシステム16によって管理されるいくつかのデータ構造が存在可能である。MTSは可能な競争者を含む複数のテナントをサポートできるため、MTSは、データ、アプリケーション及びアプリケーションの利用を別々に維持するセキュリティプロトコルを有することが可能である。また、多数のテナントが自らのシステムを維持するのでなくMTSにアクセスする傾向があるため、冗長性、アップタイム及びバックアップが、MTSにおいて実現可能な更なる機能である。ユーザ固有のデータ及びテナント固有のデータに加えて、システム16はまた、複数のテナント又は他のデータによって利用可能なシステムレベルデータを維持可能である。このようなシステムレベルデータは、テナント間で共有可能な業界レポート、ニュース、ポスティングなどを含むことが可能である。
【0037】
いくつかの実現形態では、ユーザシステム12(また、クライアントシステムとすることが可能である)は、システム16からのシステムレベル及びテナントレベルデータをリクエスト及びアップデートするため、アプリケーションサーバ100と通信する。このようなリクエスト及びアップデートは、1つ以上のクエリをテナントデータベース22又はシステムデータベース24に送信することを伴う可能性がある。システム16(例えば、システム16におけるアプリケーションサーバ100)は、所望の情報にアクセスするよう設計された1つ以上のSQLステートメント(例えば、1つ以上のSQLクエリ)を自動生成可能である。システムデータベース24は、データベースからリクエストされたデータにアクセスするためのクエリプランを生成可能である。“クエリプラン”という用語は、一般にデータベースシステムにおける情報にアクセスするのに利用される1つ以上の処理を参照する。
【0038】
各データベースは、一般に所定又はカスタマイズ可能なカテゴリに適合されたデータを含む、論理テーブルのセットなどのオブジェクトの集まりとして見ることができる。“テーブル”は、データオブジェクトの一表現であり、いくつかの実現形態によるオブジェクト及びカスタムオブジェクトの概念的な記述を簡単化するためここで利用されうる。“テーブル”及び“オブジェクト”はここでは互換的に利用されうることが理解されるべきである。各テーブルは、一般に閲覧可能な方式でカラム又はフィールドとして論理的に構成される1つ以上のデータカテゴリを含む。テーブルの各行又は要素は、フィールドによって規定される各カテゴリのデータのインスタンスを含みうる。例えば、CRMデータベースは、名前、住所、電話番号、ファックス番号などの基本的コンタクト情報のためのフィールドによってカスタマを記述したテーブルを含むことが可能である。他のテーブルは、カスタマ、製品、販売価格、日付などの情報のためのフィールドを含む購入注文を記述可能である。いくつかのMTS実現形態では、標準エンティティのテーブルが全てのテナントによる利用のため提供可能である。CRMデータベースアプリケーションについて、そのような標準エンティティは、それぞれが所定のフィールドを含むケース、アカウント、コンタクト、リード及び機会データオブジェクトのためのテーブルを含むことが可能である。ここで用いられる“エンティティ”という用語はまた、“オブジェクト”及び“テーブル”と互換的に利用されうる。
【0039】
いくつかのMTS実現形態では、テナントは、カスタムオブジェクトを作成及び格納することが可能とされるか、あるいは、例えば、カスタムインデックスフィールドを含む標準的オブジェクトのためのカスタムフィールドを作成することによって、標準エンティティ又はオブジェクトをカスタマイズすることが可能とされてもよい。2010年8月17日に発行されたWeissmanらによるCUSTOM ENTITIES AND FIELDS IN A MULTI-TENANT DATABASE SYSTEMというタイトルの共有譲受され、その全体が全ての目的のため参照によりここに援用される米国特許第7,779,039号は、カスタムオブジェクトを作成すると共に、マルチテナントデータベースシステムにおける標準的オブジェクトをカスタマイズするシステム及び方法を教示する。いくつかの実現形態では、例えば、全てのカスタムエンティティデータ行が、組織毎に複数の論理テーブルを含みうる単一のマルチテナント物理テーブルに格納される。複数の“テーブル”が実際に1つの大きなテーブルに格納されているか、あるいは、データが他のカスタマのデータと同じテーブルに格納されうるかが、カスタマにとって明らかである。
II.イベントストリーム処理システム
図2は、イベントストリーム処理システムを含む計算システム200を示す。計算システム200は、1つ以上のイベントパブリッシャ(例えば、イベントを生成するシステム)の計算デバイス201を含んでもよい。計算デバイス201は、図1A~1Bに記載されるようにデータベースシステムのコンポーネントの何れかを含んでもよい。順序付けされてパーティションされたイベントログクラスタ202は、システムデータベース24及び/又はテナントデータベース22など、図1A~1Bに記載されるデータベースシステムの何れかのデータストアに格納されてもよい。イベントプロセッサ203は、データストリーム処理システムのコンポーネント(例えば、Apache Stormなどのイベントストリーム処理エンジン)であってもよい。データベースポッド205~207は、テナントデータベース22など、ここに記載される何れかのデータベースのデータベースポッドを含み、イベントプロセッサ203による出力されるデータを格納するのに利用されてもよい。
【0040】
データストア204は、データベースポッド205~207に出力されるデータに関するメタデータ及び/又はイベントプロセッサにより受信される入力に関するメタデータ、イベントプロセッサ203の何れかのコンポーネントによって実行される処理に関するデータなど、又はこれらの組み合わせを格納しうる。メタデータは、イベントプロセッサ203がイベントログクラスタ202を処理する方法に関する情報であってもよい。
【0041】
イベントプロセッサ203は、1つ以上のイベントログコンシューマを含んでもよい。イベントログコンシューマは、イベントバッファにおけるイベントデータを構成するための1つ以上のバーチャルスパウトを含んでもよい。イベントストリームプロセッサは、イベントバッファにアクセスしてもよい。
【0042】
図3A~Bは、バーチャルスパウト対応のスパウトインスタンス(例えば、連携スパウト502)のライフサイクルを示すシーケンス図を示す。期間510において、連携スパウト502がインスタンス化され、イベントストリーム処理システム501のイベントストリームプロセッサがデータを生成する前であってもよい。連携スパウト502は、イベントストリーム処理システム501に配置され、その後にオープンされる。
【0043】
期間515において、連携スパウト502は、ランタイムコンフィギュレーションを実行し、1つ以上のバーチャルスパウトがインスタンス化、配置及びオープンされてもよい。バーチャルスパウト503は、作成されて新たなチャイルドスレッドの実行を開始し、ランタイムコンフィギュレーションを実行してもよい。
【0044】
期間520において、イベントストリーム処理システム501のイベントストリームプロセッサは、1つ以上のデータストアへのデータのプッシュを開始する。連携スパウト502は、全てのバーチャルスパウト(例えば、バーチャルスパウト503)にアクティブ化するよう通知する。バーチャルスパウト503は、データソース505に接続し、データの読み込みを開始し、図示されたプロセスループを実行してもよい(イベントストリームプロセッサは、連携スパウトインスタンス502のメッセージバッファからメッセージを受信したことに応答して、1つ以上のデータストアへのデータのプッシュを開始してもよい)。
【0045】
次に図3Bを参照して、他の期間525において、連携スパウト502は、更なるバーチャルスパウト504がデータソース506について必要とされていると特定する。これは、新たなテナントに対するリクエストに応答して行われてもよい。連携スパウト502は、バーチャルスパウト504をインスタンス化、配置及びオープンする。バーチャルスパウト504は作成され、新たなチャイルドスレッドの実行を開始し、ランタイムコンフィギュレーションを実行してもよい。バーチャルスパウト504は、データソース506に接続し、データの読み込みを開始し、図示されるプロセスループを実行してもよい。
【0046】
他の期間530において、連携スパウト502は、バーチャルスパウト503及び504の既存のものがもはや必要でないと特定する。連携スパウト502は、例えば、非アクティブ化するようバーチャルスパウトに通知する。バーチャルスパウト503は、データソース505からの抽出を停止する。バーチャルスパウト503は、データソース505とのそれの接続をクローズし、終了する。
【0047】
他の期間535では、イベントストリーム処理システムは、イベントストリーム処理システムをシャットダウンする。シャットダウンでは、連携スパウトは、非アクティブ化するよう残りのスパウトに通知する。バーチャルスパウト504は、データソース506からの抽出を停止する。バーチャルスパウト504は、データソース506とのそれの接続をクローズし、終了する。連携スパウト502は、イベントストリーム処理システムを終了し、及び/又はイベントストリームプロセッサはシャットダウンしてもよい。
【0048】
連携スパウトのライフサイクル段階は、以下の1つ以上を含んでもよい。
・インスタンス化-“バーチャルスパウト対応”スパウトコンポーネント(又は“連携”スパウト)が作成及び設定される。
・配置-連携スパウトが配置される。
・オープン-オープン段階中、連携スパウトは、存在する場合、何れのバーチャルスパウトインスタンスが作成される必要があるか判断する。作成対象の各バーチャルスパウトについて、連携スパウトは、新たなチャイルド処理スレッド(配置段階)内で新たなバーチャルスパウトインスタンス(インスタンス化段階)を作成する。バーチャルスパウトインスタンスは、何れかのランタイムセットアッププロセスを実行するよう設定される(オープン段階)。
・アクティブ化-アクティブ化段階中、連携スパウトは、各バーチャルスパウトインスタンスにアクティブ化するよう通知するか、それの設定されたデータソースからのデータの取り込みを開始する。連携スパウトがアクティブ化されている間、それは管理され、アクティブ化された各バーチャルスパウトは、後述されるようなメッセージライフサイクルに従う。当該段階中の何れかの時点において、連携スパウトは、更なるバーチャルスパウトが更なる又は新たなデータソースからデータを取り込むよう要求されていると動的に判断する。連携スパウトは、作成された新たなバーチャルスパウトのそれぞれについてこの同じ概略されたライフサイクルに従う。この段階中の何れかの時点において、連携スパウトは、何れかアクティブ化されたバーチャルスパウトがもはや必要とされていないと動的に判断する。それは、非アクティブ化及びクローズによって自らのライフサイクルを係属するようこれらのバーチャルスパウトに通知する。
・非アクティブ化-非アクティブ化段階中、連携スパウトは、非アクティブ化するよう全てのバーチャルスパウトインスタンスに通知する。全てのバーチャルスパウトは、各自のデータソースからのメッセージの取り込みを中止する。
・クローズ-クローズ段階中、連携スパウトは、クローズするよう全てのバーチャルスパウトインスタンスに通知する。全てのバーチャルスパウトは、何れか必要な“クリーンアップ”又は“シャットダウン”タスクを実行する。その後、全てのバーチャルスパウトは、実行を中止し、それらのチャイルド処理スレッドを終了する。連携スパウトは、自らを終了させる前に全てのバーチャルスパウトが終了するのを待機する。
【0049】
メッセージライフサイクル
連携スパウトが1つ以上の内部的なバーチャルスパウトインスタンスを作成した後、それらは、メッセージバッファへのメッセージの送信を開始する。メッセージバッファは、全てのバーチャルスパウトの間で共有され、これらのバーチャルスパウトからのメッセージがバッファに追加されることを可能にする。メッセージがメッセージバッファに追加されると、メッセージは、元のバーチャルスパウトにメッセージをリンクさせる識別子によりタグ付けされる。
【0050】
イベントストリームプロセッサ(例えば、ストリーム処理エンジン)が、次のメッセージが処理されるように連携スパウトをポーリングするとき、連携スパウトは、メッセージバッファからメッセージを抽出し、それを処理のためにストリームプロセッサに返す。
【0051】
ストリーム処理エンジンが連携スパウトにメッセージが処理を良好に完了させたと通知すると、連携スパウトは、メッセージを調べ、当該メッセージが何れのバーチャルスパウトから発信されたか判断する。連携スパウトは、その後に処理すべき適切なバーチャルスパウトにメッセージ完了通知をルーティングする。
【0052】
ストリーム処理エンジンが連携スパウトにメッセージが正しく処理できなかったと通知すると、連携スパウトは、メッセージを調べ、当該メッセージが何れのバーチャルスパウトから発信されたか判断する。連携スパウトは、その後に処理すべき適切なバーチャルスパウトにメッセージ失敗通知をルーティングする。
【0053】
図4は、単一のバーチャルスパウトを備えたイベントストリーム処理システム600を示す。イベントストリーム処理システム600は、図2のイベントストリーム処理システムを含む、ここに説明される何れかのイベントストリーム処理システムと同様であってもよい。
【0054】
単一の連携スパウト612の内部の実行は、単一のバーチャルスパウトインスタンス611である。バーチャルスパウトインスタンス611は、テナントAのSalesforce.comストリーミングAPIからのイベントを利用し、それらをメッセージに変換する。これらのメッセージは、メッセージバッファ615に追加される。連携スパウト612は、その後にメッセージバッファ615からメッセージを移動し、処理対象のイベントストリームプロセッサ620に送信する。メッセージがイベントストリームプロセッサ620によって完了としてマーク付けされているとき、それは連携スパウト612に通知する。連携スパウト612は、メッセージの発信元の適切なバーチャルスパウトインスタンス611に当該通知を送信する。メッセージがイベントストリームプロセッサ620によって失敗としてマーク付けされているとき、それは連携スパウト612に通知する。連携スパウト612は、メッセージの発信元の適切なバーチャルスパウトインスタンス611に当該通知を送信する。
【0055】
図5は、複数のバーチャルスパウトを備えたイベントストリーム処理システム700を示す。イベントストリーム処理システム700は、図2のイベントストリーム処理システムを含む、ここに説明される何れかのイベントストリーム処理システムと同様であってもよい。
【0056】
単一の連携スパウト712の内部の実行は、複数のバーチャルスパウトインスタンス711、721及び731である。各バーチャルスパウトインスタンス711、721及び731は、メッセージを生成する各自のテナントのデータソースからのデータを利用する。これらのメッセージは、メッセージバッファ715に追加される。連携スパウトインスタンス712は、その後にメッセージバッファ715からメッセージを移動し、処理対象のイベントストリームプロセッサ720に送信する。メッセージがイベントストリームプロセッサ720によって完了としてマーク付けされているとき、それは連携スパウト712に通知する。連携スパウト712は、メッセージの発信元のバーチャルスパウトインスタンス711、721及び731の適切なものに当該通知を送信する。メッセージがイベントストリームプロセッサ720によって失敗としてマーク付けされているとき、それは連携スパウト712に通知する。連携スパウト712は、メッセージの発信元のバーチャルスパウトインスタンス711、721及び731の適切なものに当該通知を送信する。
【0057】
図6は、テナントの1つのバーチャルスパウトが他のテナントのサービスを混乱させることなくクローズされるイベントストリーム処理システム800を示す。イベントストリーム処理システム800は、図2のイベントストリーム処理システムを含む、ここに説明される何れかのイベントストリーム処理システムと同様であってもよい。
【0058】
単一の連携スパウト812の内部の実行は、複数のバーチャルスパウトインスタンス811、821、831及び841である。テナントBのバーチャルスパウトインスタンス821はもはや必要でなく、“X”のマーキングによって示されるように、それは動的にシャットダウンされた。新たなバーチャルスパウトインスタンス841が、それが必要になったとき、テナントDがそれのデータソースから利用するため作成された。バーチャルスパウトインスタンス811、821、831及び841のそれぞれは、各自のテナントのデータソースからデータを利用し、そこからメッセージを生成する。これらのメッセージはメッセージバッファ815に追加される。連携スパウトインスタンス812は、その後にメッセージバッファ815からメッセージを移動し、処理対象のイベントストリームプロセッサ820に送信する。メッセージがイベントストリームプロセッサ820によって完了としてマーク付けされているとき、それは連携スパウト812に通知する。連携スパウト812は、メッセージの発信元のバーチャルスパウト811、821、831及び841の適切なものに当該通知を送信する。メッセージがイベントストリームプロセッサ820によって失敗としてマーク付けされているとき、それは連携スパウト812に通知する。連携スパウト812は、メッセージの発信元のバーチャルスパウト811、821、831及び841の適切なものに当該通知を送信する。
III.イベントストリーム処理システムにおけるサイドライニング
アプリケーションシステム(Salesforce Pardotなど)は、データストリーム処理システム(例えば、Apache Storm)を多用して、順序付けされた時系列イベントログ(例えば、Apache Kafka)から利用する。イベント処理システムは、ログを利用し、ログのオフセットを用いて処理されたメッセージを追跡する。アプリケーションシステムは、それのテナントの全てからのイベントを単一のログにプッシュする。しかしながら、インフラストラクチャメンテナンス(カスタマデータベースは作業を必要とする)又はテナント接続性(例えば、Salesforce org oauthトークンが満了になる)などの時間がある。これらの時間中、このテナントに関連するイベントについて、データベースの呼び出しは、イベント処理システムによる試みは不成功となり、テナントのデータのデータ損失を生じさせうる。
【0059】
マルチテナントコミットログを読み込むとき、他のテナントのイベントを処理し続けながら(例えば、所与のテナントの処理を延期する)、ある期間に特定のテナントのデータを失うことなくログから当該テナントの処理イベントをスキップすることが望ましい。部分的な解決策は、例えば、テナント毎に1つのトピックなど、更なるトピックを作成することである。しかしながら、この部分的な解決策は、多数のテナントを良好にはスケーリングしない(一部のデータベースシステムでは、トピックの数が約200を超えると、パフォーマンスに影響が生じうる)。
【0060】
データストリーム処理システムは、サイドライニングを実行するための命令を含んでもよい。サイドライニングは、所与のフィルタ基準によって、処理を延期するためのリクエストが行われると追跡し、その後、処理を延期させた状況が変わると、処理を再開することを含む。
【0061】
このシステムは、これらのメンテナンスの時間をフィルタリング基準のセットとして扱い、それらがトリガされると、スパウトは当該所与のフィルタ基準について順序付けされた時系列イベントログに対するオフセットを追跡する。フィルタ基準が適用されている間、一致するログから流れる何れのメッセージも、イベントプロセッサの更なる下流には発信されない。スパウトがサイドライニングを中止するようトリガされると、フィルタはトピックのメインフローから削除され、新たなスレッド又はバーチャルスパウトが、サイドラインリクエストの元のフィルタ基準のネゲーションに一致するオフセットの間のメッセージを利用するためスピンアップ(spin up)される。サイドラインからのメッセージは、その後にメインフローからのメッセージの残りと共にイベントプロセッサに発信される。
【0062】
いくつかのイベントストリーム処理システムは、サイドライニングを実行するのに用いられる所定のトリガ及びフィルタリングセマンティックを含んでもよい。サイドラインシステムは、イベントストリームプロセッサから離れる選択されたデータフローの全てのセマンティックを処理するデータストリームの取り込み(例えば、Kafkaスパウト、Stormスパウトなどのスパウト)の実現形態におけるシームレスなドロップであってもよい。
【0063】
図7A~Cは、アクティブにサイドライニングしないとき、サイドライニング中及びサイドライニング停止後のイベントストリーム処理システムの異なる状態をそれぞれ示す。イベントストリーム処理システムは、図2のイベントストリーム処理システムを含む、ここに説明される何れかのイベントストリーム処理システムと同様であってもよい。具体例では、イベントストリーム処理システムは、1つ以上のイベントストリームプロセッサによって利用されるイベントデータを格納するためのイベントバッファと、複数のデータストリームを生成するデータストリームプロセッサとを含み、各データストリームは複数のイベントの異なるサブセットに基づき、ストリームはイベントバッファに格納されているイベントデータをまとめて構成し、1つ以上のストリームプロセッサのイベントストリームプロセッサはイベントデータの一部を利用し、当該一部は複数のストリームに対応する。
【0064】
トリガ951は、サイドライニングが行われる条件を規定する。一例では、トリガ951は、ポッド状態950に関連する。ポッドは、メンテナンス又は他の理由のためオフラインとなる(例えば、データベースポッド205~207の1つ)。いくつかの具体例におけるトリガ951は、サイドライニングがポッド状態の変更に応答して行われることを指定する。他の例では、トリガ951は、フィルタリングが行われる何れか選択された条件を示す。
【0065】
トリガ951は、他の具体例では、データベースポッド1~3などのデータベースシステムコンポーネントの可用性に関連しない、フィルタリングが開始される何れかの条件に関するものであってもよい。フィルタリングは、例えば、カスタマリクエスト及び/又は順序付けされたイベントログに関連するクエリに基づくものとすることができる。
【0066】
スパウトは、処理機構のチェーンの第1の部分であってもよい(AがBに移り、BがCに移るなど)。スパウトは、イベントストリームプロセッサが処理可能な形式でデータソースを取得する責任がありうる。スパウト内において、第1の段階は、データソースから読み取る責任がある(例えば、データソースの生データを利用する)。“非アクティブなサイドライニング”状態におけるバーチャルスパウトは、第1のバーチャルスパウト(例えば、ファイアホース(firehose)バーチャルスパウト)であってもよい。
【0067】
図7Bをここで参照して、ウィンドウ985の間、フィルタ基準が適用される。フィルタリング基準は、何れのデータが第1のバーチャルスパウトに移るか制御する。第1のバーチャルスパウトは、ウィンドウ985のグレイアウトされたイベントをスキップする。フィルタリング基準は、選択されるアカウントであってもよい。ポッド(pod)が下がる例では(メンテナンス又は他の理由のため)、選択されるアカウントは、当該ポッドに関するアカウントであってもよい(図では、ポッド1に関するアカウントはフィルタリング基準である)。
【0068】
図7Cをここで参照して、サイドライニングが停止すると、第2のバーチャルスパウトがスピンアップされる。第2のバーチャルスパウトは、ウィンドウ985のイベントをまた受信するコンシューマを有してもよい。フィルタリング基準(例えば、この場合、ポッド1のみ)のネゲーションは、第2のバーチャルスパウトへのデータフィードに適用される。この状態では、両方のバーチャルスパウトが、データを同じイベントバッファに提供する。従って、図示される具体例では、第2のバーチャルスパウトは、ウィンドウ985の期間中にポッド1に関するイベントにイベント番号を提供する。
【0069】
ポッド停止の例では、イベントストリームプロセッサは、停止中に動作し続けるが、それは、停止しているポッドに関するイベントを受信せず、また、ウィンドウ期間中にダウンしているポッドに対するデータベース呼び出しを行わない(データベース呼び出しがウィンドウ期間中に行われた場合、データ損失が生じうる)。“スキップ”されたイベントは、第2のバーチャルスパウトに以降において提供され(ウィンドウ後)、イベントストリームプロセッサは、第1のポッドがバックアップされる期間においてそれのデータベース呼び出しを行うようにしてもよい(データ損失が回避されうる)。
【0070】
イベントストリームプロセッサは、あたかも単一のスパウトがあるかのように、イベントバッファのデータに対して動作してもよい。しかしながら、何れかの数のバーチャルスパウトが存在可能である。インタフェースが、更に指定されたフィルタ基準に基づき何れかの数の更なるスパウトを確立するため提供されてもよい。更なるバーチャルスパウトは、各自のフィルタリング基準について各自のウィンドウにおいてスピンアップされる。イベントストリームプロセッサは、複数のスパウトがあるという知識を必要とせず、従って、従来のイベントストリームプロセッサは、図7A~7Bのバーチャルスパウトと共に利用されてもよい。
【0071】
図8A~8Bは、図2及び/又は7A~7Cのイベントストリーム処理システムを含む、ここに説明される何れかのイベントストリーム処理システムによって実行されうるプロセスを示す。丸印991、992及び993は、図示されたプロセスについて図8A図8Bに続くことを示す。
【0072】
具体例
1つ以上のデータソースからデータを取り込み、データをイベントストリームプロセッサの無限のストリームに変換するストリーム処理システムであって、第1の時点に配置される第1の連携スパウトインスタンスであって、1つ以上の第2のスパウトインスタンスをインスタンス化し、第1の時点より以降の第2の時点で1つ以上の第2のスパウトインスタンスを配置する第1の連携スパウトインスタンスを有し、1つ以上の第2のスパウトインスタンスは、1つ以上のデータソースにそれぞれ接続し、1つ以上のデータソースの各自のものからデータの各自の部分を取り込み、データの取り込まれた部分に基づきメッセージを出力し、イベントストリームプロセッサの無限のストリームは、メッセージに基づくシステムである。
【0073】
具体例2は、具体例1又は他の何れかの具体例の主題を含み、出力されたメッセージを受信するメッセージバッファを更に有し、無限のストリームは、バッファから出力される。
【0074】
具体例3は、具体例1~2の何れか又は他の何れかの具体例の主題を含み、第1の連携スパウトインスタンスは、1つ以上の第3のスパウトインスタンスをインスタンス化し、第2の時点より以降の第3の時点で1つ以上の第3のスパウトインスタンスを配置し、1つ以上の第3のスパウトインスタンスは、1つ以上の更なるデータソースにそれぞれ接続し、1つ以上の更なるデータソースの各自のものから更なるデータの各自の部分を取り込み、更なるデータの取り込まれた部分に基づきメッセージを出力し、イベントストリームプロセッサの無限のストリームは、メッセージと更なるメッセージとに基づく。
【0075】
具体例4は、具体例1~3の何れか又は他の何れかの具体例の主題を含み、データソースは、時系列の順序付けされたイベントログを含む。
【0076】
具体例5は、具体例1~4の何れか又は他の何れかの具体例の主題を含み、データソースは、時系列の順序付けされたイベントログを含み、更なるデータソースは、更なる時系列の順序付けされたイベントログを含む。
【0077】
具体例6は、具体例1~5の何れか又は他の何れかの具体例の主題を含み、更なる時系列の順序付けされたイベントログは、時系列の順序付けされたイベントログのスタート時間後に始まる。
【0078】
具体例7は、具体例1~6の何れか又は他の何れかの具体例の主題を含み、第1の連携スパウトインスタンスは更に、イベントストリームプロセッサからメッセージを受信し、メッセージのコンテンツに基づき1つ以上の第2のスパウトインスタンスと1つ以上の第3のスパウトインスタンスとの間にメッセージを分配する。
【0079】
具体例8は、具体例1~7の何れか又は他の何れかの具体例の主題を含み、メッセージは、無限のストリームを処理したことに応答して、イベントストリームプロセッサによって生成されたメッセージ完了通知とメッセージ失敗通知とを含む。
【0080】
具体例9は、具体例1~8の何れか又は他の何れかの具体例の主題を含み、メッセージは、イベントストリームプロセッサの単一の出力インタフェースを介し受信される。
【0081】
具体例10は、具体例1~9の何れか又は他の何れかの具体例の主題を含み、第1の連携スパウトインスタンスは、1つ以上の第2のスパウトインスタンスの個別のものを選択し、1つ以上の第2のスパウトインスタンスの個別のものに非アクティブ化するよう通知し、1つ以上の第2のスパウトインスタンスの選択された個別のものをクローズする。
【0082】
具体例11は、1つ以上のデータソースからデータを取り込み、データをイベントストリームプロセッサの無限のストリームに変換する方法であって、第1の時点で第1の連携スパウトインスタンスを配置するステップと、第1の連携スパウトインスタンスを配置した後、第1の連携スパウトインスタンスを利用して、1つ以上の第2のスパウトインスタンスをインスタンス化し、第1の時点より以降の第2の時点で1つ以上の第2のスパウトインスタンスを配置するステップと、1つ以上のデータソースに接続し、1つ以上の第2のスパウトインスタンスをそれぞれ利用して、1つ以上のデータソースからデータの各自の部分を取り込むステップと、データの取り込まれた部分に基づき、1つ以上の第2のスパウトインスタンスからメッセージを出力するステップとを有し、イベントストリームプロセッサの無限のストリームは、前記メッセージに基づく方法である。
【0083】
具体例12は、具体例11の何れか又は他の何れかの具体例の主題を含み、メッセージを単一のバッファに出力するステップを更に有し、無限のストリームは、バッファから出力される。
【0084】
具体例13は、具体例11~12の何れか又は他の何れかの具体例の主題を含み、第1の連携スパウトインスタンスを配置した後、1つ以上の第3のスパウトインスタンスをインスタンス化し、第2の時点より以降の第3の時点で1つ以上の第3のスパウトインスタンスを配置するステップと、1つ以上の更なるデータソースに接続し、1つ以上の第3のスパウトインスタンスをそれぞれ利用して、1つ以上の更なるデータソースから更なるデータの各自の部分を取り込むステップと、更なるデータの取り込まれた部分に基づき、1つ以上の第3のスパウトインスタンスからメッセージを出力するステップとを更に有し、イベントストリームプロセッサの無限のストリームは、メッセージと更なるメッセージとに基づく。
【0085】
具体例14は、具体例11~13の何れか又は他の何れかの具体例の主題を含み、データソースは、時系列の順序付けされたイベントログを含む。
【0086】
具体例15は、具体例11~14の何れか又は他の何れかの具体例の主題を含み、データソースは、時系列の順序付けされたイベントログを含み、更なるデータソースは、更なる時系列の順序付けされたイベントログを含む。
【0087】
具体例16は、具体例11~15の何れか又は他の何れかの具体例の主題を含み、更なる時系列の順序付けされたイベントログは、時系列の順序付けされたイベントログのスタート時間後に始まる。
【0088】
具体例17は、具体例11~16の何れか又は他の何れかの具体例の主題を含み、第1の連携スパウトインスタンスにおいてイベントストリームプロセッサからメッセージを受信するステップと、メッセージのコンテンツに基づき、1つ以上の第2のスパウトインスタンスと1つ以上の第3のスパウトインスタンスとの間でメッセージを分配するステップとを更に有する。
【0089】
具体例18は、具体例11~17の何れか又は他の何れかの具体例の主題を含み、メッセージは、無限のストリームを処理したことに応答して、イベントストリームプロセッサによって生成されたメッセージ完了通知とメッセージ失敗通知とを含む。
【0090】
具体例19は、具体例11~18の何れか又は他の何れかの具体例の主題を含み、メッセージは、イベントストリームプロセッサの単一の出力インタフェースを介し受信される。
【0091】
具体例20は、具体例11~19の何れか又は他の何れかの具体例の主題を含み、連携スパウトインスタンスがオープンである間、クローズ対象の1つ以上の第2のスパウトインスタンスの個別のものを選択するステップと、1つ以上の第2のスパウトインスタンスの個別のものに非アクティブ化するよう通知するステップと、第1の連携スパウトインスタンスによってイベントストリームプロセッサとのインタフェースを維持しながら、1つ以上の第2のスパウトインスタンスの個別のものをクローズするステップとを更に有する。
【0092】
具体例21は、具体例1~6の何れか又は他の何れかの具体例の主題を含み、1つ以上のイベントストリームプロセッサにより利用されるイベントデータを格納するイベントバッファと、複数のデータストリームを生成するデータストリームプロセッサとを有するイベントストリーム処理システムであって、各データストリームは、複数のイベントの異なるサブセットに基づき、これらのストリームは、イベントバッファに格納されているイベントデータをまとめて構成し、1つ以上のストリームプロセッサのイベントストリームプロセッサは、複数のストリームに対応するイベントデータの部分を利用するシステムである。
【0093】
具体例22は、具体例21の何れか又は他の何れかの具体例の主題を含み、データストリームプロセッサは、選択された期間中に順序付けされたイベントログの一部に1つ以上のフィルタリング基準を適用し、複数のストリームの第1のストリームを構成するため、複数のイベントのサブセットの対応するものを特定し、データストリームプロセッサは、選択された期間の終了後、順序付けされたイベントログの同一の部分に1つ以上のフィルタリング基準のネゲーションを適用し、複数のストリームの異なる第2のストリームを構成するため、複数のイベントのサブセットの対応する異なるものを特定する。
【0094】
具体例23は、具体例21~22の何れか又は他の何れかの具体例の主題を含み、期間は、1つ以上のイベントストリームプロセッサによって生成されるデータを格納する複数のポッドのポッドの利用不可期間に対応する。
【0095】
具体例24は、具体例21~23の何れか又は他の何れかの具体例の主題を含み、1つ以上のフィルタリング基準を利用して順序付けされたイベントログの部分の情報のフィルタリングは、順序付けされたイベントログの情報のサブセットを第1のストリームの構成中にスキップさせる。
【0096】
具体例25は、具体例21~24の何れか又は他の何れかの具体例の主題を含み、1つ以上のフィルタリング基準のネゲーションを利用して順序付けされたイベントログの部分の情報のフィルタリングは、第2のデータストリームプロセッサに異なる第2の情報の構成中に情報のサブセットを除き、順序付けされたイベントログの部分の全ての情報をスキップさせる。
【0097】
具体例26は、具体例21~25の何れか又は他の何れかの具体例の主題を含み、データストリームプロセッサはスパウトを含み、各ストリームは、スパウトの複数のバーチャルスパウトの異なるバーチャルスパウトから生じる。
【0098】
具体例27は、イベントストリーム処理システムを利用する方法であって、イベントバッファに1つ以上のイベントストリームプロセッサにより利用されるイベントデータを格納するステップと、複数のデータストリームを生成するステップとを有し、各データストリームは、複数のイベントの異なるサブセットに基づき、これらのストリームは、イベントバッファに格納されているイベントデータをまとめて構成し、1つ以上のストリームプロセッサのイベントストリームプロセッサは、複数のストリームに対応するイベントデータの部分を利用する方法である。
【0099】
具体例28は、具体例27の何れか又は他の何れかの具体例の主題を含み、選択された期間中に順序付けされたイベントログの一部に1つ以上のフィルタリング基準を適用し、複数のストリームの第1のストリームを構成するため、複数のイベントのサブセットの対応するものを特定するステップと、選択された期間の終了後、順序付けされたイベントログの同一の部分に1つ以上のフィルタリング基準のネゲーションを適用し、複数のストリームの異なる第2のストリームを構成するため、複数のイベントのサブセットの対応する異なるものを特定するステップとを含む。
【0100】
具体例29は、具体例27~28の何れか又は他の何れかの具体例の主題を含み、期間は、1つ以上のイベントストリームプロセッサによって生成されるデータを格納する複数のポッドのポッドの利用不可期間に対応する。
【0101】
具体例30は、他の何れかの具体例の主題を含み、1つ以上のフィルタリング基準を利用して順序付けされたイベントログの部分の情報のフィルタリングは、順序付けされたイベントログの情報のサブセットを第1のストリームの構成中にスキップさせる。
【0102】
具体例31は、具体例27~30の何れか又は他の何れかの具体例の主題を含み、1つ以上のフィルタリング基準のネゲーションを利用して順序付けされたイベントログの部分の情報のフィルタリングは、異なる第2の情報の構成中に情報のサブセットを除き、順序付けされたイベントログの部分の全ての情報をスキップさせる。
【0103】
具体例32は、具体例27~31の何れか又は他の何れかの具体例の主題を含み、各ストリームは、イベントストリームプロセッサが利用するスパウトの複数のバーチャルスパウトの異なるバーチャルスパウトから生じる。
【0104】
具体例33は、具体例1~10の何れか又は他の何れかの具体例の主題を含み、1つ以上の第2のスパウトインスタンスは、複数のスパウトインスタンスを含み、複数のスパウトインスタンスの第1のスパウトインスタンスは、選択された期間について、データの取り込まれた部分に1つ以上のフィルタリング基準を適用するよう構成され、メッセージの第1のサブセットは、1つ以上のフィルタリング基準の適用に応答して、複数のスパウトインスタンスの第1のスパウトインスタンスによって生成され、複数のスパウトインスタンスの第2のスパウトインスタンスは、選択された期間の終了後、1つ以上のフィルタリング基準のネゲーションをデータの同一の取り込まれた部分に適用するよう構成され、メッセージの異なる第2のサブセットは、1つ以上のフィルタリング基準のネゲーションの適用に応答して、複数のスパウトインスタンスの第2のスパウトインスタンスによって生成される。
【0105】
具体例34は、具体例1~10又は33の何れか又は他の何れかの具体例の主題を含み、選択された期間は、イベントストリームプロセッサによって生成されたデータを格納するためのストレージデバイスの利用不可期間に対応する。
【0106】
具体例35は、1つ以上のデータソースからデータを取り込み、データをイベントストリームプロセッサの無限のストリームに変換するストリーム処理システムであって、第1の時点に配置される第1の連携スパウトインスタンスであって、第2のスパウトインスタンスと第3のスパウトインスタンスとをインスタンス化する第1の連携スパウトインスタンスを有し、第1の連携スパウトインスタンスは、第2及び第3のスパウトインスタンスを順次配置し、第2のスパウトインスタンスは、第1の時点より以降の第2の時点で配置され、第3のスパウトインスタンスは、第2の時点より以降の第3の時点で配置され、第2及び第3のスパウトインスタンスはそれぞれ、1つ以上のデータソースからのデータの同一の部分を取り込み、第1のメッセージと第2のメッセージとをそれぞれ出力し、イベントストリームプロセッサの無限のストリームは、第1及び第2のメッセージに基づくシステムである。
【0107】
具体例36は、具体例35の何れか又は他の何れかの具体例の主題を含み、第2のスパウトインスタンスは、1つ以上のデータソースからのデータの部分に第1のフィルタリング基準を適用するよう構成され、第3のスパウトインスタンスは、1つ以上のデータソースからのデータの部分に第1のフィルタリング基準と異なる第2のフィルタリング基準を適用するよう構成される。
【0108】
具体例37は、具体例35~36の何れか又は他の何れかの具体例の主題を含み、第2のフィルタリング基準は、第1のフィルタリング基準のネゲーションを含む。
【0109】
ここに開示された実現形態の特定の態様の具体的詳細は、開示された実現形態の精神及び範囲から逸脱することなく、何れか適した方法で組み合わされてもよい。しかしながら、他の実現形態は、個別の各態様に関連する特定の実現形態又はこれら個別の態様の特定の組み合わせに関するものであってもよい。
【0110】
さらに、開示された具体例はしばしば、オンデマンドデータベースサービス環境が、複数のテナントをサポート可能なオンデマンドデータベースサービスのためのフロントエンドを提供するアプリケーションサーバを有するデータベースシステムにおいて実現される実現形態を参照してここで説明されるが、本実現形態は、マルチテナントデータベース又はアプリケーションサーバ上の配置に限定されない。実現形態は、請求される実現形態の範囲から逸脱することなく、他のデータベースアーキテクチャ、すなわち、ORACLE(登録商標)、IBMによるDB2(登録商標)などを用いて実施されてもよい。
【0111】
開示された実現形態の一部は、制御ロジックの形態を含む、ハードウェア、ソフトウェア、ファームウェアの各種タイプ又はこれらの組み合わせの形態で、当該ハードウェア又はソフトウェアをモジュール又は統合方式で利用して実現可能であることがまた、理解されるべきである。他のやり方又は方法が、ハードウェア及びハードウェアとソフトウェアとの組み合わせを用いて可能である。さらに、本願において説明されるソフトウェアコンポーネント又は機能の何れも、例えば、既存又はオブジェクト指向技術を利用して、Java、C++、Perlなどの何れか適したコンピュータ言語を利用して、1つ以上のプロセッサによって実行されるソフトウェアコードとして実現可能である。ソフトウェアコードは、物理的な非一時的コンピュータ可読媒体上のコンピュータ又はプロセッサにより実行可能な命令又はコマンドとして格納可能である。適した媒体の具体例は、ランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)、ハードドライブ又はフロッピー(登録商標)ディスクなどの磁気媒体、コンパクトディスク(CD)又はDVDなどの光媒体、フラッシュメモリなど、又はこのようなストレージ若しくは伝送デバイスの何れかの組み合わせを含む。
【0112】
ソフトウェア/プログラムコードにより符号化されるコンピュータ可読媒体は、互換的デバイスと一緒にパッケージ化されるか、あるいは、他のデバイスから別々に提供されてもよい(例えば、インターネットダウンロードを介し)。このようなコンピュータ可読媒体は、単一の計算デバイス又はコンピュータシステム全体に常駐され、システム又はネットワーク内の他のコンピュータ可読媒体間にあってもよい。コンピュータシステム又は他の計算デバイスは、ここに述べられた結果の何れかをユーザに提供するためのモニタ、プリンタ又は他の適したディスプレイを含んでもよい。
【0113】
開示された技術の原理が適用される多数の可能な実施例を鑑み、図示された実施例は単なる好適な具体例であり、開示の範囲を限定するものとしてとられるべきでないことが認識されるべきである。本発明として請求されるものは、添付した請求項の範囲及び精神の範囲内である。


図1A
図1B
図2
図3A
図3B
図4
図5
図6
図7A
図7B
図7C
図8A
図8B