知財求人 - 知財ポータルサイト「IP Force」
▶ セールスフォース ドット コム インコーポレイティッドの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-11-25
(45)【発行日】2022-12-05
(54)【発明の名称】イベントストリーム処理システム
(51)【国際特許分類】
G06F 9/50 20060101AFI20221128BHJP
【ＦＩ】
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)【参考文献】
【文献】国際公開第２０１７／０５８７３４（ＷＯ，Ａ１）
【文献】米国特許出願公開第２０１５／００３２７３８（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ ９／５０
(57)【特許請求の範囲】
【請求項1】
１つ以上のデータソースからデータを取り込み、前記データをイベントストリームプロセッサの無限のストリームに変換するストリーム処理システムであって、第１の時点に配置される第１の連携スパウトインスタンスであって、１つ以上の第２のスパウトインスタンスをインスタンス化し、前記第１の時点より以降の第２の時点で前記１つ以上の第２のスパウトインスタンスを配置する第１の連携スパウトインスタンスを有し、
前記１つ以上の第２のスパウトインスタンスは、
前記１つ以上のデータソースにそれぞれ接続し、前記１つ以上のデータソースの各自のものから前記データの各自の部分を取り込み、
前記データの取り込まれた部分に基づきメッセージを出力し、
前記イベントストリームプロセッサの無限のストリームは、前記メッセージに基づくシステム。
【請求項2】
前記出力されたメッセージを受信するメッセージバッファを更に有し、前記無限のストリームは、前記メッセージバッファから出力される、請求項１記載のシステム。
【請求項3】
前記第１の連携スパウトインスタンスは、１つ以上の第３のスパウトインスタンスをインスタンス化し、前記第２の時点より以降の第３の時点に前記１つ以上の第３のスパウトインスタンスを配置し、前記１つ以上の第３のスパウトインスタンスは、
１つ以上の更なるデータソースにそれぞれ接続し、前記１つ以上の更なるデータソースの各自のものから更なるデータの各自の部分を取り込み、
前記更なるデータの取り込まれた部分に基づきメッセージを出力し、
前記イベントストリームプロセッサの無限のストリームは、前記メッセージと前記更なるメッセージとに基づく、請求項１記載のシステム。
【請求項4】
前記データソースは、時系列の順序付けされたイベントログを含む、請求項１記載のシステム。
【請求項5】
前記データソースは、時系列の順序付けされたイベントログを含み、前記更なるデータソースは、更なる時系列の順序付けされたイベントログを含む、請求項３記載のシステム。
【請求項6】
前記更なる時系列の順序付けされたイベントログは、前記時系列の順序付けされたイベントログのスタート時間後に始まる、請求項５記載のシステム。
【請求項7】
前記第１の連携スパウトインスタンスは更に、前記イベントストリームプロセッサからメッセージを受信し、前記メッセージのコンテンツに基づき前記１つ以上の第２のスパウトインスタンスと前記１つ以上の第３のスパウトインスタンスとの間に前記メッセージを分配する、請求項３記載のシステム。
【請求項8】
前記メッセージは、前記無限のストリームを処理したことに応答して、前記イベントストリームプロセッサによって生成されたメッセージ完了通知とメッセージ失敗通知とを含む、請求項７記載のシステム。
【請求項9】
前記メッセージは、前記イベントストリームプロセッサの単一の出力インタフェースを介し受信される、請求項８記載のシステム。
【請求項10】
前記第１の連携スパウトインスタンスは、前記１つ以上の第２のスパウトインスタンスの個別のものを選択し、前記１つ以上の第２のスパウトインスタンスの個別のものに非アクティブ化するよう通知し、前記１つ以上の第２のスパウトインスタンスの選択された個別のものをクローズする、請求項１記載のシステム。
【請求項11】
前記１つ以上の第２のスパウトインスタンスは、複数のスパウトインスタンスを含み、前記複数のスパウトインスタンスの第１のスパウトインスタンスは、選択された期間について、前記データの取り込まれた部分のイベントログに１つ以上のフィルタリング基準を適用するよう構成され、
前記メッセージの第１のサブセットは、前記１つ以上のフィルタリング基準の適用に応答して、前記複数のスパウトインスタンスの第１のスパウトインスタンスによって生成され、
前記複数のスパウトインスタンスの第２のスパウトインスタンスは、前記選択された期間の終了後、前記１つ以上のフィルタリング基準のネゲーションを前記イベントログに適用するよう構成され、
前記メッセージの異なる第２のサブセットは、前記１つ以上のフィルタリング基準のネゲーションの適用に応答して、前記複数のスパウトインスタンスの第２のスパウトインスタンスによって生成される、請求項１記載のシステム。
【請求項12】
前記選択された期間は、前記イベントストリームプロセッサによって生成されたデータを格納するためのストレージデバイスの利用不可期間に対応する、請求項１１記載のシステム。
【請求項13】
１つ以上のデータソースからデータを取り込み、前記データをイベントストリームプロセッサの無限のストリームに変換するストリーム処理システムであって、第１の時点に配置される第１の連携スパウトインスタンスであって、第２のスパウトインスタンスと第３のスパウトインスタンスとをインスタンス化する第１の連携スパウトインスタンスを有し、
前記第１の連携スパウトインスタンスは、前記第２及び第３のスパウトインスタンスを順次配置し、前記第２のスパウトインスタンスは、前記第１の時点より以降の第２の時点で配置され、前記第３のスパウトインスタンスは、前記第２の時点より以降の第３の時点で配置され、
前記第２及び第３のスパウトインスタンスはそれぞれ、前記１つ以上のデータソースから同じイベントログを取り込み、第１のメッセージと第２のメッセージとをそれぞれ出力し、
前記イベントストリームプロセッサの無限のストリームは、前記第１及び第２のメッセージに基づくシステム。
【請求項14】
前記第２のスパウトインスタンスは、前記イベントログに第１のフィルタリング基準を適用するよう構成され、前記第３のスパウトインスタンスは、前記イベントログに第１のフィルタリング基準と異なる第２のフィルタリング基準を適用するよう構成される、請求項１３記載のシステム。
【請求項15】
前記第２のフィルタリング基準は、前記第１のフィルタリング基準のネゲーションを含む、請求項１４記載のシステム。
【請求項16】
１つ以上のデータソースからデータを取り込み、前記データをイベントストリームプロセッサの無限のストリームに変換する方法であって、第１の時点で第１の連携スパウトインスタンスを配置するステップと、
前記第１の連携スパウトインスタンスを配置した後、前記第１の連携スパウトインスタンスを利用して、１つ以上の第２のスパウトインスタンスをインスタンス化し、前記第１の時点より以降の第２の時点で前記１つ以上の第２のスパウトインスタンスを配置するステップと、
前記１つ以上のデータソースに接続し、前記１つ以上の第２のスパウトインスタンスをそれぞれ利用して、前記１つ以上のデータソースから前記データの各自の部分を取り込むステップと、
前記データの取り込まれた部分に基づき、前記１つ以上の第２のスパウトインスタンスからメッセージを出力するステップと、
を有し、
前記イベントストリームプロセッサの無限のストリームは、前記メッセージに基づく方法。
【請求項17】
前記メッセージを単一のバッファに出力するステップを更に有し、前記無限のストリームは、前記バッファから出力される、請求項１６記載の方法。
【請求項18】
前記第１の連携スパウトインスタンスを配置した後、１つ以上の第３のスパウトインスタンスをインスタンス化し、前記第２の時点より以降の第３の時点で前記１つ以上の第３のスパウトインスタンスを配置するステップと、１つ以上の更なるデータソースに接続し、前記１つ以上の第３のスパウトインスタンスをそれぞれ利用して、前記１つ以上の更なるデータソースから更なるデータの各自の部分を取り込むステップと、
前記更なるデータの取り込まれた部分に基づき、前記１つ以上の第３のスパウトインスタンスからメッセージを出力するステップと、
を更に有し、
前記イベントストリームプロセッサの無限のストリームは、前記メッセージと前記更なるメッセージとに基づく、請求項１６記載の方法。
【請求項19】
前記データソースは、時系列の順序付けされたイベントログを含む、請求項１６記載の方法。
【請求項20】
前記データソースは、時系列の順序付けされたイベントログを含み、前記更なるデータソースは、更なる時系列の順序付けされたイベントログを含む、請求項１８記載の方法。
【請求項21】
前記更なる時系列の順序付けされたイベントログは、前記時系列の順序付けされたイベントログのスタート時間後に始まる、請求項２０記載の方法。
【請求項22】
前記第１の連携スパウトインスタンスにおいて前記イベントストリームプロセッサからメッセージを受信するステップと、前記メッセージのコンテンツに基づき、前記１つ以上の第２のスパウトインスタンスと前記１つ以上の第３のスパウトインスタンスとの間で前記メッセージを分配するステップと、
を更に有する、請求項１８記載の方法。
【請求項23】
前記メッセージは、前記無限のストリームを処理したことに応答して、前記イベントストリームプロセッサによって生成されたメッセージ完了通知とメッセージ失敗通知とを含む、請求項２２記載の方法。
【請求項24】
前記メッセージは、前記イベントストリームプロセッサの単一の出力インタフェースを介し受信される、請求項２３記載の方法。
【請求項25】
前記第１の連携スパウトインスタンスがオープンである間、クローズ対象の前記１つ以上の第２のスパウトインスタンスの個別のものを選択するステップと、前記１つ以上の第２のスパウトインスタンスの個別のものに非アクティブ化するよう通知するステップと、
前記第１の連携スパウトインスタンスによって前記イベントストリームプロセッサとのインタフェースを維持しながら、前記１つ以上の第２のスパウトインスタンスの個別のものをクローズするステップと、
を更に有する、請求項１６記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
［優先権］
本出願は、それぞれが参照によってその全体がここに援用される、２０１７年５月２日に出願された米国仮出願第６２／５００，２５８号（整理番号８６６５－００９５）及び２０１７年９月６日に出願された米国仮出願第６２／５５４，８６０号の利益を主張する。
［著作権表示］
本特許文献の開示の一部は、著作権保護を受ける題材を含む。著作権所有者は、それが米国特許商標庁の特許ファイル又はレコードに現れるとき、特許文献又は特許開示の何れかの者によるファクシミリ複製に対して異議を有さないが、そうでない場合、全ての著作権を留保する。
［技術分野］
１つ以上の実現形態は、一般に計算システムに関し、一部の実施例は、バーチャルスパウト（ｖｉｒｔｕａｌ ｓｐｏｕｔ）を利用するイベントストリーム処理システムに関し、一部の実施例では、バーチャルスパウトはサイドライニング（ｓｉｄｅｌｉｎｉｎｇ）を利用しうる。
本出願は、それぞれが参照によってその全体がここに援用される、２０１７年５月２日に出願された米国仮出願第６２／５００，２５８号（整理番号８６６５－００９５）及び２０１７年９月６日に出願された米国仮出願第６２／５５４，８６０号の利益を主張する。
［著作権表示］
本特許文献の開示の一部は、著作権保護を受ける題材を含む。著作権所有者は、それが米国特許商標庁の特許ファイル又はレコードに現れるとき、特許文献又は特許開示の何れかの者によるファクシミリ複製に対して異議を有さないが、そうでない場合、全ての著作権を留保する。
［技術分野］
１つ以上の実現形態は、一般に計算システムに関し、一部の実施例は、バーチャルスパウト（ｖｉｒｔｕａｌ ｓｐｏｕｔ）を利用するイベントストリーム処理システムに関し、一部の実施例では、バーチャルスパウトはサイドライニング（ｓｉｄｅｌｉｎｉｎｇ）を利用しうる。
【背景技術】
【0002】
アプリケーションシステム（Ｓａｌｅｓｆｏｒｃｅ Ｐａｒｄｏｔなど）は、イベントストリーム処理システム（例えば、Ａｐａｃｈｅ Ｓｔｏｒｍ）を多用して、順序付けされた時系列イベントログ（例えば、Ａｐａｃｈｅ Ｋａｆｋａ）から消費する。イベントストリーム処理システム内において、スパウトはソースからデータを取り入れ、当該データをイベントストリームプロセッサが処理可能な無限のストリームに変換する。
【0003】
一部のシステムでは、スパウトはイベントストリーム処理システムが配置された時点で一度作成される。そのようなスパウトは、データストリーム処理システムが再配置されるまで、静的で不変なままである。
【0004】
単一のスパウトにより配置されたシステムでは、当該単一のスパウトは、マルチテナントシステムにおける単一のテナントなどのソースからデータを消費する。スパウトは、イベントストリームプロセッサからの完了及び失敗したメッセージ通知を処理すると共に、イベントストリームプロセッサへのメッセージの発信を処理する。スパウトは、固定され、テナントのデータストアとのみ通信可能である。
【0005】
一部のイベントストリーム処理システムは、複数のスパウトを含む。そのようなシステムでは、複数のテナントの各テナントについて別々のスパウトが存在しうる。そのようなスパウトは、トポロジ配置時に規定され、その後の何れかの時点でも追加又は削除されないかもしれない。新たなテナントがサインアップされると、トポロジが停止され、規定された新たなスパウトにより再配置されるまで、テナントのデータソースにサービス提供するため、更なる新たなスパウトコンポーネントを作成することはできない。テナントのサービス中断の可能性などの複数の理由のため、再配置は望ましくない。
【図面の簡単な説明】
【0006】
含まれる図面は例示的な目的のためであり、開示される発明のシステム、装置、方法及びコンピュータ可読記憶媒体のための可能な構成及び処理の具体例を提供するのに利用される。これらの図面は、開示される実現形態の精神及び範囲から逸脱することなく、当業者により行いうる形式及び詳細の変更を限定するものでない。
【図1A】いくつかの実現形態によるオンデマンドデータベースサービスが利用可能な一例となる環境のブロック図を示す。
【図2】イベントストリーム処理システムを含む計算システム２００を示す。
【図3A】バーチャルスパウト対応スパウトインスタンスのライフサイクルを示すシーケンス図を示す。
【図3B】バーチャルスパウト対応スパウトインスタンスのライフサイクルを示すシーケンス図を示す。
【図4】単一のバーチャルスパウトを備えたイベントストリーム処理システムを示す。
【図5】複数のバーチャルスパウトを備えたイベントストリーム処理システムを示す。
【図6】テナントの１つのバーチャルスパウトが他のテナントのサービスを混乱させることなくクローズされるイベントストリーム処理システムを示す。
【発明を実施するための形態】
【0007】
開示される実現形態によるシステム、装置、コンピュータ可読記憶媒体及び方法の具体例が本セクションにおいて説明される。これらの具体例は、コンテクストを追加し、開示される実現形態の理解を支援するためだけに提供されている。従って、開示される実現形態は提供される具体的詳細の一部又は全てなく実施されうることは、当業者に自明であろう。他の例では、“ブロック”としてここで参照される特定のプロセス又は方法の処理は、開示される実現形態を不要に不明瞭にすることを回避するため詳細には説明されていない。他の実現形態及び適用もまた可能であり、以下の具体例は範囲又は設定において明確な又は限定するものとしてとられるべきでない。
【0008】
以下の詳細な説明では、例示によって特定の実現形態が示され、本説明の一部を構成する添付図面が参照される。これらの開示された実現形態は、当業者が実現形態を実施することを可能にするのに十分詳細に説明されるが、他の実現形態が利用されてもよく、それらの精神及び範囲から逸脱することなく開示された実現形態に変更が可能であるように、これらの具体例は限定的でないことが理解されるべきである。例えば、ここに図示及び説明される方法のブロックは、他の一部の実現形態において示される順序において必ずしも実行される必要はない。さらに、他の一部の実現形態では、開示される方法は説明されるより多くの又はより少ないブロックを含みうる。他の具体例として、別々のブロックとしてここに説明される一部のブロックは、他のいくつかの実現形態では組み合わせされてもよい。他方、単一のブロックとしてここに説明されうるものは、他のいくつかの実現形態では複数のブロックにおいて実現されうる。さらに、接続詞“又は”は、特段の断りがない場合、必要に応じて内包的な意味と意図され、すなわち、“Ａ，Ｂ又はＣ”というフレーズは、“Ａ”、“Ｂ”、“Ｃ”、“Ａ及びＢ”、“Ｂ及びＣ”、“Ａ及びＣ”並びに“Ａ，Ｂ及びＣ”の可能性を含むことが意図される。
【0009】
いくつかのイベントストリーム処理システムにおけるいくつかのスパウトは、以下のライフサイクル段階を受けうる。
・インスタンス化－これは、イベント処理システムの実行前に行われる。スパウトは、規定、作成及び設定されうる。システム内の全てのコンポーネントは、ライフサイクルのこの段階において規定されうる。この段階が完了した後、更なるコンポーネントは作成されないか、あるいは、システムから削除されない。
・配置－スパウトコンポーネントは、他の全てのコンポーネント共にＡｐａｃｈｅ Ｓｔｏｒｍクラスタに配置されてもよい。
・オープン－スパウトを含むイベント処理システムにおけるコンポーネントの全てには、配置されたシステムに関する情報が与えられ、何れか必要なランタイムコンフィギュレーションを実行するよう指示される。
・アクティブ化－イベント処理システムにおけるスパウトコンポーネントは、“スタート”するよう通知される。各スパウトは、それの外部データソースに接続し、イベント処理システムへのデータの取り込みを開始する。スパウトコンポーネントによって生成されるメッセージは、以下のライフサイクル段階を有しうる。
○次のメッセージ－イベント処理システムは、次のメッセージがスパウトからの処理のためシステムに取り込まれることを要求する。
○アクノリッジメント－イベント処理システムは、処理のためシステムに送信した特定のメッセージの処理が成功したことをスパウトコンポーネントに通知する。
○フェイル－イベント処理システムは、処理のためシステムに送信した特定のメッセージの処理が成功しなかったことをスパウトコンポーネントに通知する。
・非アクティブ化－典型的には、イベント処理システムのシャットダウン前に、全てのスパウトはイベント処理システムへのデータの取り込みを中止するよう指示される。
・クローズ－全てのスパウトコンポーネントは、何れか必要な“クリーンアップ”又は“シャットダウン”タスクを実行し、その後に実行を中止する。
・インスタンス化－これは、イベント処理システムの実行前に行われる。スパウトは、規定、作成及び設定されうる。システム内の全てのコンポーネントは、ライフサイクルのこの段階において規定されうる。この段階が完了した後、更なるコンポーネントは作成されないか、あるいは、システムから削除されない。
・配置－スパウトコンポーネントは、他の全てのコンポーネント共にＡｐａｃｈｅ Ｓｔｏｒｍクラスタに配置されてもよい。
・オープン－スパウトを含むイベント処理システムにおけるコンポーネントの全てには、配置されたシステムに関する情報が与えられ、何れか必要なランタイムコンフィギュレーションを実行するよう指示される。
・アクティブ化－イベント処理システムにおけるスパウトコンポーネントは、“スタート”するよう通知される。各スパウトは、それの外部データソースに接続し、イベント処理システムへのデータの取り込みを開始する。スパウトコンポーネントによって生成されるメッセージは、以下のライフサイクル段階を有しうる。
○次のメッセージ－イベント処理システムは、次のメッセージがスパウトからの処理のためシステムに取り込まれることを要求する。
○アクノリッジメント－イベント処理システムは、処理のためシステムに送信した特定のメッセージの処理が成功したことをスパウトコンポーネントに通知する。
○フェイル－イベント処理システムは、処理のためシステムに送信した特定のメッセージの処理が成功しなかったことをスパウトコンポーネントに通知する。
・非アクティブ化－典型的には、イベント処理システムのシャットダウン前に、全てのスパウトはイベント処理システムへのデータの取り込みを中止するよう指示される。
・クローズ－全てのスパウトコンポーネントは、何れか必要な“クリーンアップ”又は“シャットダウン”タスクを実行し、その後に実行を中止する。
【0010】
ここに説明及び参照されるいくつかの実現形態は、バーチャルスパウトを含むイベントストリーム処理システムのためのシステム、装置、コンピュータにより実現される方法及びコンピュータ可読記憶媒体に関する。
【0011】
バーチャルスパウトを利用する実施例は、単一の固定的な“連携”スパウトコンポーネント内で１つ以上の“スパウト”を実行する。連携スパウトのインスタンスは、配置時に単一の固定的なスパウトコンポーネントとして自らをストリーム処理エンジンに提供する。連携スパウトは、いくつかの実施例では、それらが要求されるとき、新たなバーチャルスパウトのインスタンスを内部的に動的に作成する。さらに、いくつかの実施例では、連携スパウトは、それらがもはや必要とされないとき、バーチャルスパウトのインスタンスをシャットダウンする。連携スパウトのインスタンスは、全ての内部的なバーチャルスパウトのインスタンスのスパウトライフサイクルを管理する。連携スパウトのインスタンスはまた、メッセージライフサイクルに関してストリーム処理エンジンとそれの内部的に管理されたバーチャルスパウトのインスタンスとの間の全ての通信を管理する。
【0012】
Ｐａｒｄｏｔカスタマは、典型的には、それにリンクされたＳａｌｅｓｆｏｒｃｅ．ｃｏｍアカウントを有する。Ｐａｒｄｏｔが新たなカスタマを毎日サインオンするとき、彼らのＳａｌｅｓｆｏｒｃｅ．ｃｏｍアカウントから彼らのＰａｒｄｏｔアカウントにデータをストリーミングする必要がある。Ｐａｒｄｏｔが新たなカスタマをサインアップする毎に、新たなスパウトインスタンスを作成し、ストームトポロジーを再配置することは、実現可能でないかもしれない（新たなカスタマのサインアップの頻度のため）。バーチャルスパウトを利用する実施例では、連携スパウトは、新たなカスタマをモニタし、新たなバーチャルスパウトのインスタンスを作成／開始する。同様に、カスタマがＰａｒｄｏｔによる彼らのアカウントを終了させるとき、連携スパウトはこれを検出し、カスタマの対応するバーチャルスパウトのインスタンスをシャットダウンする。
【0013】
一部の実施例は、１つ以上のデータソースからデータを取り込み、データをイベントストリームプロセッサの無限のストリームに変換するためのストリーム処理システムを含む。ストリーム処理システムは、第１の時点に配置された第１の連携スパウトインスタンスを含み、当該第１の連携スパウトインスタンスは１つ以上の第２のスパウトインスタンスをインスタンス化し、第１の時点より以降の第２の時点で１つ以上の第２のスパウトインスタンスを配置する。
【0014】
１つ以上の第２のスパウトインスタンスのそれぞれは、１つ以上のデータソースにそれぞれ接続し、各自のデータ部分を１つ以上のデータソースの各自のものから取り込むよう構成される。１つ以上の第２のスパウトインスタンスは、データの取り込まれた部分に基づきメッセージを出力する。イベントストリームプロセッサの無限のストリームは、メッセージに基づくものであってもよい。
【0015】
そのような実施例では、データソースに関連する動的な変更がサポートされる。例えば、新たなデータソースが必要とされるか（いくつかの実施例では新たなテナントのため、あるいは、他の何れかの理由のため）、あるいは、既存のデータソースがもはや必要とされない場合、新たなバーチャルスパウトが作成可能であるか、あるいは、既存のスパウトが他のデータソースの処理を混乱させることなく完了可能である（例えば、新たなデータソース又はクローズされたデータソースに関連しないテナントに対するサービスを混乱させることなく）。
【0016】
いくつかの実施例では、イベントストリーム処理システムは、必須ではないが、１つ以上の第２のスパウトインスタンスを利用してサイドライニングを実行する。これらの実施例では、第１及び第２のスパウトインスタンスのそれぞれは、異なる時点におけるソースデータの同一部分を取り込む。
【0017】
サイドライニングを利用する１つの具体例は、１つ以上のデータソースからデータを取り込み、当該データをイベントストリームプロセッサのための無限のストリームに変換するストリーム処理システムである。ストリーム処理システムは、第１の時点で配置された第１の連携スパウトインスタンスを含んでもよく、第１の連携スパウトインスタンスは第２のスパウトインスタンス及び第３のスパウトインスタンスをインスタンス化し、第１の連携スパウトインスタンスは第２及び第３のスパウトインスタンスを順次配置し、第２のスパウトインスタンスは第１の時点より以降の第２の時点で配置され、第３のスパウトインスタンスは第２の時点より以降の第３の時点で配置され、第２及び第３のスパウトインスタンスはそれぞれ１つ以上のデータソースから同一のデータ部分を取り込み、それぞれ第１のメッセージ及び第２のメッセージを出力し、イベントストリームプロセッサの無限のストリームは第１及び第２のメッセージに基づく。第２のスパウトインスタンスは１つ以上のデータソースからのデータ部分に対して第１のフィルタリング基準を適用するよう構成され、第３のスパウトインスタンスは１つ以上のデータソースからのデータ部分に対して第１のフィルタリング基準と異なる第２のフィルタリング基準を適用するよう構成される。第２のフィルタリング基準は第１のフィルタリング基準のネゲーションを含む。
Ｉ．一例となるシステムの概略
図１Ａは、いくつかの実現形態によるオンデマンドデータベースサービスが利用可能な環境１０の具体例のブロック図を示す。環境１０は、ユーザシステム１２、ネットワーク１４、データベースシステム１６（また、“クラウドベースシステム”としてここでは参照される）、プロセッサシステム１７、アプリケーションプラットフォーム１８、ネットワークインタフェース２０、テナントデータ２３を格納するためのテナントデータベース２２、システムデータ２５を格納するためのシステムデータベース２４、システム１６の各種機能を実現するためのプログラムコード２６及びアプリケーションホストサービスの一部としてアプリケーションを実行するなど、データベースシステムプロセス及びテナント固有プロセスを実行するためのプロセススペース２８を含む。いくつかの他の実現形態では、環境１０は、これらのコンポーネント又はシステムの全てを有しなくてもよいし、あるいは、上述したものの代わりに又は加えて他のコンポーネント又はシステムを有してもよい。
Ｉ．一例となるシステムの概略
図１Ａは、いくつかの実現形態によるオンデマンドデータベースサービスが利用可能な環境１０の具体例のブロック図を示す。環境１０は、ユーザシステム１２、ネットワーク１４、データベースシステム１６（また、“クラウドベースシステム”としてここでは参照される）、プロセッサシステム１７、アプリケーションプラットフォーム１８、ネットワークインタフェース２０、テナントデータ２３を格納するためのテナントデータベース２２、システムデータ２５を格納するためのシステムデータベース２４、システム１６の各種機能を実現するためのプログラムコード２６及びアプリケーションホストサービスの一部としてアプリケーションを実行するなど、データベースシステムプロセス及びテナント固有プロセスを実行するためのプロセススペース２８を含む。いくつかの他の実現形態では、環境１０は、これらのコンポーネント又はシステムの全てを有しなくてもよいし、あるいは、上述したものの代わりに又は加えて他のコンポーネント又はシステムを有してもよい。
【0018】
いくつかの実現形態では、環境１０はオンデマンドデータベースサービスが存在する環境である。システム１６を用いて実現可能なものなどのオンデマンドデータベースサービスは、システム１６を所有、維持又はアクセスを提供する企業の外部のユーザに利用可能とされるサービスである。上述したように、このようなユーザは、一般にシステム１６の構築又は維持に関与する必要はない。代わりに、システム１６によって提供されるリソースは、ユーザがシステム１６によって提供されるサービスを必要とするとき、このようなユーザの利用のために、すなわち、ユーザの要求に応じて利用可能とされてもよい。いくつかのオンデマンドデータベースサービスは、マルチテナントデータベースシステム（ＭＴＳ）を形成するため、１つ以上のテナントからの情報を共通のデータベースイメージのテーブルに格納可能である。“マルチテナントデータベースシステム”という用語は、データベースシステムのハードウェア及びソフトウェアの各種要素が１つ以上のカスタマ又はテナントによって共有されうるシステムを参照可能である。例えば、所与のアプリケーションサーバは、潜在的にはるかに多数のカスタマのためのフィードアイテムなどリクエストを同時に処理しうる。データベースイメージは、１つ以上のデータベースオブジェクトを含みうる。リレーショナルデータベースマネージメントシステム（ＲＤＢＭＳ）又は等価なものが、データベースオブジェクトに対する情報の格納及び抽出を実行可能である。
【0019】
アプリケーションプラットフォーム１８は、システム１６のハードウェア又はソフトウェアインフラストラクチャなど、システム１６のアプリケーションが実行可能なフレームワークとすることができる。いくつかの実現形態では、アプリケーションプラットフォーム１８は、オンデマンドデータベースサービスのプロバイダ、ユーザシステム１２を介しオンデマンドデータベースサービスにアクセスするユーザ又はユーザシステム１２を介しオンデマンドデータベースサービスにアクセスするサードパーティアプリケーションデベロッパによって開発される１つ以上のアプリケーションの作成、管理及び実行を可能にする。
【0020】
いくつかの実現形態では、システム１６は、ウェブベースカスタマ関係マネージメント（ＣＲＭ）システムを実現する。例えば、そのようないくつかの実現形態では、システム１６は、ユーザシステム１２との間で関連するデータ、コード、フォーム、レンダリング可能なウェブページ及びドキュメント並びに他の情報を提供するため、ＣＲＭソフトウェアアプリケーションを実現及び実行し、データベースシステムとの間で関連するデータ、オブジェクト及びウェブページコンテンツを格納及び抽出するよう構成されるアプリケーションサーバを含む。いくつかのＭＴＳ実現形態では、複数のテナントのデータは、テナントデータベース２２の同一の物理データベースオブジェクトに格納されうる。いくつかのそのような実現形態では、テナントデータはテナントデータベース２２の記憶媒体に構成され、これにより、あるテナントのデータが他のテナントのものから論理的に分離され続け、データが明示的に共有されていない場合、あるテナントは他のテナントのデータにアクセスできない。システム１６はまた、ＣＲＭアプリケーション以外又は加えてアプリケーションを実現する。例えば、システム１６は、ＣＲＭアプリケーションを含む複数のホストされた（標準的及びカスタム）アプリケーションへのアクセスをテナントに提供できる。ＣＲＭを含んでもよいし、あるいは含まなくてもよいユーザ（又はサードパーティデベロッパ）アプリケーションは、アプリケーションプラットフォーム１８によってサポートされうる。アプリケーションプラットフォーム１８は、１つ以上のデータベースオブジェクトへのアプリケーションの作成及び格納と、システム１６のプロセススペースにおける１つ以上のバーチャルマシーンのアプリケーションの実行とを管理する。
【0021】
いくつかの実現形態によると、各システム１６は、システム１６のテナントとしてユーザシステム１２によるアクセスをサポートするよう、ウェブページ、フォーム、アプリケーション、データ及び目ディコンテンツをユーザ（クライアント）システム１２に提供するよう構成される。また、システム１６は、データが共有されない場合、各テナントのデータを分離して維持するためのセキュリティ機構を提供する。複数のＭＴＳが利用される場合、それらは、互いに近接して配置されてもよいし（例えば、単一の建物又はキャンパスに配置されたサーバファームに）、あるいは、それらは互いに遠隔地に配置されてもよい（例えば、都市Ａに配置された１つ以上のサーバ及び都市Ｂに配置された１つ以上のサーバ）。ここで利用されるように、各ＭＴＳは、１つ以上の地理的位置にわたって又は論理的に分散される１つ以上の論理的又は物理的に接続されたサーバを含みうる。さらに、“サーバ”という用語は、処理ハードウェア及びプロセススペースを含む計算デバイス又はシステム、メモリデバイス又はデータベースなどの関連する記憶媒体、及びいくつかの例では当該技術において周知であるようなデータベースアプリケーション（例えば、ＯＯＤＢＭＳ又はＲＤＢＭＳ）を参照することが意図される。また、“サーバシステム”及び“サーバ”はここではしばしば互換的に利用されることが理解されるべきである。同様に、ここで説明されるデータベースオブジェクトは、単一のデータベース、分散されたデータベース、分散データベースの集まり、冗長オンライン又はオフラインバックアップ又は他の冗長性を備えたデータベースなどの一部として実現可能であり、分散されたデータベース又はストレージネットワーク及び関連する処理インテリジェンスを含みうる。
【0022】
ネットワーク１４は、互いに通信するシステム又はデバイスの何れかのネットワーク又はネットワークの組み合わせとすることが可能であるか、あるいは、含むことが可能である。例えば、ネットワーク１４は、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、電話網、無線ネットワーク、セルラネットワーク、ポイント・ツー・ポイントネットワーク、スターネットワーク、トークンリングネットワーク、ハブネットワーク又は他の適切なコンフィギュレーションの何れか１つ又は何れかの組み合わせとすることが可能であるか、あるいは、含むことが可能である。ネットワーク１４は、“インターネット”（大文字“Ｉ”による）としてしばしば参照されるネットワークのグローバルインターネットワークなど、ＴＣＰ／ＩＰ（Ｔｒａｎｓｆｅｒ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ ａｎｄ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークを含むことが可能である。インターネットは、ここでは具体例の多くにおいて利用される。しかしながら、ＴＣＰ／ＩＰは頻繁に実装されるプロトコルであるが、開示される実現形態が利用可能なネットワークはそれに限定されないことが理解されるべきである。
【0023】
ユーザシステム１２は、ＴＣＰ／ＩＰ及びＨＴＴＰ、ＦＴＰ、ＡＦＳ、ＷＡＰなどの通信するための上位のネットワークレベルにおける他の一般的なインターネットプロトコルを利用してシステム１６と通信可能である。ＨＴＴＰが利用される具体例では、各ユーザシステム１２は、“ウェブブラウザ”として一般的に参照されるＨＴＴＰクライアント又はシステム１６のＨＴＴＰサーバとの間でＨＴＴＰ信号を送受信するための単なる“ブラウザ”を含むことができる。このようなＨＴＴＰサーバは、システム１６とネットワーク１４との間の単なるネットワークインタフェース２０として実現可能であるが、他の技術はこれらの技術に加えて又は代わりに利用可能である。いくつかの実現形態では、システム１６とネットワーク１４との間のネットワークインタフェース２０は、ロードをバランスさせ、複数のサーバを介し入力されるＨＴＴＰリクエストを均等に分配するためのラウンドロビンＨＴＴＰリクエストディストリビュータなどのロード共有機能を含む。ＭＴＳ実現形態では、各サーバはＭＴＳデータへのアクセスを有することが可能であるが、他の代わりのコンフィギュレーションが代わりに利用されてもよい。
【0024】
ユーザシステム１２は、データベースシステム１６にアクセスするため、ユーザにより利用可能な何れかの計算デバイス又は他のデータ処理装置若しくはシステムとして実現可能である。例えば、ユーザシステム１２の何れかは、デスクトップコンピュータ、ワークステーション、ラップトップコンピュータ、タブレットコンピュータ、携帯計算デバイス、携帯電話（例えば、“スマートフォン”）又は他の何れかのＷｉ－Ｆｉ対応デバイス、無線アクセスプロトコル（ＷＡＰ）対応デバイス又はインターネット若しくは他のネットワークと直接的又は間接的にインタフェース可能な他の計算デバイスとすることができる。“ユーザシステム”及び“計算デバイス”という用語は、ここでは互いに及び“コンピュータ”という用語と交互に利用される。上述されるように、各ユーザシステム１２は、例えば、ユーザシステム１２のユーザ（例えば、システム１６により提供されるオンデマンドサービスの加入者）がネットワーク１４を介しシステム１６から利用可能な情報、ページ及びアプリケーションにアクセス、処理及び閲覧することを可能にする、ＷｅｂＫｉｔプラットフォーム、ＭｉｃｒｏｓｏｆｔのＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅブラウザ、ＡｐｐｌｅのＳａｆａｒｉ、ＧｏｏｇｌｅのＣｈｒｏｍｅ、Ｏｐｅｒａのブラウザ又はＭｏｚｉｌｌａのＦｉｒｅｆｏｘブラウザなどに基づくウェブブラウザなどのウェブブラウジング（又は単に“ブラウジング”）プログラムなどのＨＴＴＰクライアントを典型的に実行する。
【0025】
各ユーザシステム１２はまた、典型的には、システム１６又は他のシステム若しくはサーバによって提供されるページ、フォーム、アプリケーション及び他の情報に関連して、ユーザシステム１２のディスプレイ（例えば、他の可能性のうち、モニタスクリーン、液晶ディスプレイ（ＬＣＤ）、発光ダイオード（ＬＥＤ）ディスプレイ）上のブラウザによって提供されるグラフィカルユーザインタフェース（ＧＵＩ）とやりとりするため、キーボード、マウス、トラックボール、タッチパッド、タッチスクリーン、ペン又はスタイラスなどの１つ以上のユーザ入力デバイスを含む。例えば、ユーザインタフェースデバイスは、システム１６によってホストされるデータ及びアプリケーションにアクセスし、格納されているデータに対してサーチを実行し、ユーザがユーザに提示される各種ＧＵＩページとやりとりすることを可能にするのに利用可能である。上述されるように、イントラネット、エクストラネット、バーチャルプライベートネットワーク（ＶＰＮ）、非ＴＣＰ／ＩＰベースネットワーク、何れかのＬＡＮ若しくはＷＡＮなどの他のネットワークが、インターネットの代わりに又は加えて利用可能であるが、実現形態はインターネットによる利用に適している。
【0026】
ユーザシステム１２のユーザは、各自の能力において異なりうるものであり、特定のユーザシステム１２の能力は、ユーザシステムの現在のユーザについてのパーミッション（パーミッションレベル）によって完全に決定可能である。例えば、販売員が特定のユーザシステム１２を利用してシステム１６とやりとりしている場合、当該ユーザシステムは、販売員に割り当てられた能力を有することができる。しかしながら、管理者がユーザシステム１２を利用してシステム１６とやりとりしている間、ユーザシステムは、当該管理者に割り当てられた能力を有することができる。階層的ロールモデルが利用される場合、あるパーミッションレベルのユーザは、下位のパーミッションレベルのユーザによりアクセス可能なアプリケーション、データ及びデータベース情報にアクセス可能であるが、上位のパーミッションレベルのユーザによりアクセス可能な特定のアプリケーション、データベース情報及びデータへのアクセスを有しないかもしれない。従って、異なるユーザは、一般にユーザ各自のセキュリティ又はパーミッションレベル（また、“権限”として参照される）に応じて、アプリケーション及びデータベース情報にアクセス及び修正することに関して、異なる能力を有することになる。
【0027】
いくつかの実現形態によると、各ユーザシステム１２及びそれのコンポーネントの一部又は全ては、Ｉｎｔｅｌ Ｐｅｎｔｉｕｍ（登録商標）プロセッサなどの中央処理ユニット（ＣＰＵ）を用いて実行されるコンピュータコードを含む、ブラウザなどのアプリケーションを用いてオペレータにより設定可能である。同様に、システム１６（及び複数存在する場合、ＭＴＳの更なるインスタンス）及びそれのコンポーネントの全ては、Ｉｎｔｅｌ Ｐｅｎｔｉｕｍ（登録商標）プロセッサなどを含みうるＣＰＵ又は複数のＣＰＵを含むよう実現されうるプロセッサシステム１７を用いて実行されるコンピュータコードを含むアプリケーションを用いてオペレータにより設定可能とすることができる。
【0028】
システム１６は、ここに説明されるプロセスの実現形態の一部を実行するようサーバ又は他の計算システム（又は当該サーバ又は計算システムの集まり）をプログラムするよう実行可能又は利用される非一時的な命令を格納して有形のコンピュータ可読媒体を含む。例えば、コンピュータプログラムコード２６は、ここに説明されるようなウェブページ、アプリケーション及び他のデータ及びメディアコンテンツを相互通信及び処理するようシステム１６を動作及び設定するための命令を実現可能である。いくつかの実現形態では、コンピュータコード２６は、ハードディスク上にダウンロード及び格納可能であるが、プログラムコード全体又はその一部はまた、ＲＯＭ又はＲＡＭなどの周知な他の何れかの揮発性若しくは不揮発性記憶媒体に格納可能であるか、あるいは、フロッピーディスク、光ディスク、デジタル多用途ディスク（ＤＶＤ）、コンパクトディスク（ＣＤ）、マイクロドライバ及び光磁気ディスクを含む何れかのタイプの回転媒体、磁気若しくは光カード、ナノシステム（分子メモリＩＣを含む）又は命令若しくはデータを格納するのに適した他の何れかのタイプのコンピュータ可読媒体又はデバイスなど、プログラムコードを格納可能な何れかの媒体上で提供可能である。さらに、プログラムコード全体又はその一部は、例えば、周知であるインターネットを介し又は他のサーバから伝送媒体上のソフトウェアソースから送信及びダウンロードされてもよいし、あるいは、周知である何れかの通信媒体及びプロトコル（例えば、ＴＣＰ／ＩＰ、ＨＴＴＰ、ＨＴＴＰＳ、イーサネットＴＭなど）を用いて周知である他の何れか既存のネットワーク接続（例えば、エクストラネット、ＶＰＮ、ＬＡＮなど）を介し送信されてもよい。また、開示された実現形態のためのコンピュータコードは、例えば、Ｃ、Ｃ＋＋、ＨＴＭＬ、他の何れかのマークアップ言語、ＪａｖａＴＭ、ＪａｖａＳｃｒｉｐｔＴＭ、ＡｃｔｉｖｅＸ、ＶＢＳｃｒｉｐｔなどの他の何れかのスクリプト言語など、サーバ又は他の計算システム上で実行可能な何れかのプログラミング言語において実現可能であり、周知である他の多数のプログラミング言語が利用されうる（ＪａｖａＴＭは、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．の商標である）。
【0029】
図１Ｂは、いくつかの実現形態による図１Ａの要素の一例となる実現形態とこれらの要素間の一例となる相互接続とのブロック図を示す。すなわち、図１Ｂはまた環境１０を示すが、図１Ｂにおいて、システム１６の各種要素及び当該要素間の各種相互接続が、いくつかのより具体的な実現形態によりより詳細に示される。さらに、図１Ｂにおいて、ユーザシステム１２は、プロセッサシステム１２Ａ、メモリシステム１２Ｂ、入力システム１２Ｃ及び出力システム１２Ｄを含む。プロセッサシステム１２Ａは、１つ以上のプロセッサの何れか適した組み合わせを含むことができる。メモリシステム１２Ｂは、１つ以上のメモリデバイスの何れか適した組み合わせを含むことができる。入力システム１２Ｃは、１つ以上のタッチスクリーンインタフェース、キーボード、マウス、トラックボール、スキャナ、カメラ又はネットワークとのインタフェースなどの入力デバイスの何れか適した組み合わせを含むことができる。出力システム１２Ｄは、１つ以上のディスプレイデバイス、プリンタ又はネットワークとのインタフェースなどの出力デバイスの何れか適した組み合わせを含むことができる。
【0030】
図１Ｂにおいて、ネットワークインタフェース２０は、ＨＴＴＰアプリケーションサーバ１００１～１００Ｎのセットとして実現される。各アプリケーションサーバ１００は、ここではまた“アップサーバ”として参照され、テナントデータベース２２及びその中のテナントデータ２３と共に、システムデータベース２４及びその中のシステムデータ２５と通信し、ユーザシステム１２から受信したリクエストに対してサービスを提供するよう構成される。テナントデータ２３は、物理的又は論理的に構成又は分割可能な個々のテナントストレージスペース１１２に分割可能である。各テナントストレージスペース１１２内において、ユーザストレージ１１４及びアプリケーションメタデータ１１６は、同様に各ユーザについて配分できる。例えば、ユーザのＭＲＵ（Ｍｏｓｔ Ｒｅｃｅｎｔｌｙ Ｕｓｅｄ）アイテムのコピーはユーザストレージ１１４に格納可能である。同様に、テナントである組織全体のＭＲＵアイテムのコピーは、テナントストレージスペース１１２に格納可能である。
【0031】
プロセススペース２８は、システムプロセススペース１０２、個別テナントプロセススペース及びテナント管理プロセススペース１１０を含む。アプリケーションプラットフォーム１８は、アプリケーションデベロッパのアプリケーションの作成及び管理をサポートするアプリケーションセットアップ機構３８を含む。そのようなアプリケーションなどは、例えば、テナント管理プロセス１１０により管理される１つ以上のテナントプロセススペースとして加入者による実行のためにセーブルーチン３６によって、テナントデータベース２２にメタデータとして保存可能である。そのようなアプリケーションの呼び出しは、ＡＰＩ３２にプログラミング言語スタイルインタフェース拡張を提供するＰＬ／ＳＯＱＬ３４を用いて符号化可能である。いくつかのＰＬ／ＳＯＱＬ言語の実現形態の詳細な説明は、２０１０年６月１日に発行されたＣｒａｉｇ ＷｅｉｓｓｍａｎによるＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＡＬＬＯＷＩＮＧ ＡＣＣＥＳＳ ＴＯ ＤＥＶＥＬＯＰＥＤ ＡＰＰＬＩＣＡＴＩＯＮＳ ＶＩＡ Ａ ＭＵＬＴＩ－ＴＥＮＡＮＴ ＯＮ－ＤＥＭＡＮＤ ＤＡＴＡＢＡＳＥ ＳＥＲＶＩＣＥというタイトルの共有譲受された米国特許第７，７３０，４７８号において議論され、その全体が全ての目的のため参照によってこれに援用される。アプリケーションの呼び出しは、呼び出しを実行し、バーチャルマシーンにおけるアプリケーションとしてメタデータを実行する加入者のアプリケーションメタデータ１１６の抽出を管理する１つ以上のシステムプロセスによって検出可能である。
【0032】
図１Ｂのシステム１６はまた、ユーザシステム１２におけるユーザ又は開発者に対するシステム１６の常駐プロセスとのユーザインタフェース（ＵＩ）３０及びアプリケーションプログラミングインタフェース（ＡＰＩ）３２を含む。いくつかの他の実現形態では、環境１０は、上述したものと同じ要素を有しなくてもよいし、あるいは、上述したものに代わって又は追加して他の要素を有してもよい。
【0033】
各アプリケーションサーバ１００は、例えば、異なるネットワーク接続を介しそれぞれ手年とデータ２３及びシステムデータ２５へのアクセスを有するテナントデータベース２２及びシステムデータベース２４と通信可能に結合可能である。例えば、あるアプリケーションサーバ１００１はネットワーク１４（例えば、インターネット）を介し結合可能であり、他のアプリケーションサーバ１００Ｎ－１はダイレクトネットワークリンクを介し結合可能であり、他のアプリケーションサーバ１００Ｎは更なる異なるネットワーク接続によって結合可能である。ＴＣＩ／ＩＰは、アプリケーションサーバ１００とシステム１６との間の通信に利用可能な典型的なプロトコルの具体例である。しかしながら、他のトランスポートプロトコルが利用されるネットワーク相互接続に応じてシステム１６を最適化するのに利用可能であることは、当業者に明らかであろう。
【0034】
いくつかの実現形態では、各アプリケーションサーバ１００は、システム１６のテナントである何れかの組織に関連する何れかのユーザに対するリクエストを処理するよう構成される。任意の時点で各種理由のためサーバプールに対してアプリケーションサーバ１００を追加及び削除可能であることが望ましいため、いくつかの実現形態では、特定のアプリケーションサーバ１００に対するユーザ又は組織のサーバ親和性はない。このようないくつかの実現形態では、ロードバランシング機能を実現するインタフェースシステム（例えば、Ｆ５ Ｂｉｇ－ＩＰロードバランサ）は、アプリケーションサーバ１００にリクエストを分派得するため、アプリケーションサーバ１００とユーザシステム１２との間で通信可能に結合される。一実現形態では、ロードバランサは、最小接続アルゴリズムを利用して、ユーザリクエストをアプリケーションサーバ１００にルーティングする。ラウンドロビン及び観察されたレスポンス時間などのロードバランシングアルゴリズムの他の具体例がまた利用可能である。例えば、いくつかの具体例では、同一のユーザからの３つの連続するリクエストが、３つの異なるアプリケーションサーバ１００にヒットし、異なるユーザからの３つのリクエストが、同一のアプリケーションサーバ１００にヒットしうる。このようにして、例えば、システム１６は、別々のユーザ及び組織の間で異なるオブジェクト、データ及びアプリケーションの格納及びアクセスをシステム１６が処理するマルチテナントシステムとすることができる。
【0035】
一例となるストレージ利用ケースでは、あるテナントは、各販売員がシステム１６を利用して自らの販売の側面を管理するセールスフォースを利用する企業とすることができる。ユーザは、ユーザの個人販売プロセスに全てが適用可能なコンタクトデータ、リードデータ、カスタマフォローアップデータ、パフォーマンスデータ、目的進捗データなどを維持可能である。ＭＴＳ構成の具体例では、アクセス、閲覧、修正、報告、送信、計算などのためのデータ及びアプリケーションの全ては、少し多いネットワークアクセスを有するユーザシステム１２によって維持及びアクセス可能であるため、ユーザは、多くの異なるユーザシステムの何れかから自らの販売努力及びサイクルを管理可能である。例えば、販売員がカスタマを訪問し、カスタマがロビーにおいてインターネットアクセスを有するとき、販売員は、カスタマがロビーに到着するのを待機しながら、当該カスタマに関する重要なアップデートを取得可能である。
【0036】
各ユーザのデータは各ユーザの雇用者に関係なく他のユーザのデータから分離して格納可能である一方、一部のデータは、テナントである所与の組織の複数のユーザ又は全てのユーザによって共有又はアクセス可能な組織全体のデータとすることができる。従って、他のデータ構造がユーザレベルにおいて管理可能である一方、テナントレベルにおいて配分されるシステム１６によって管理されるいくつかのデータ構造が存在可能である。ＭＴＳは可能な競争者を含む複数のテナントをサポートできるため、ＭＴＳは、データ、アプリケーション及びアプリケーションの利用を別々に維持するセキュリティプロトコルを有することが可能である。また、多数のテナントが自らのシステムを維持するのでなくＭＴＳにアクセスする傾向があるため、冗長性、アップタイム及びバックアップが、ＭＴＳにおいて実現可能な更なる機能である。ユーザ固有のデータ及びテナント固有のデータに加えて、システム１６はまた、複数のテナント又は他のデータによって利用可能なシステムレベルデータを維持可能である。このようなシステムレベルデータは、テナント間で共有可能な業界レポート、ニュース、ポスティングなどを含むことが可能である。
【0037】
いくつかの実現形態では、ユーザシステム１２（また、クライアントシステムとすることが可能である）は、システム１６からのシステムレベル及びテナントレベルデータをリクエスト及びアップデートするため、アプリケーションサーバ１００と通信する。このようなリクエスト及びアップデートは、１つ以上のクエリをテナントデータベース２２又はシステムデータベース２４に送信することを伴う可能性がある。システム１６（例えば、システム１６におけるアプリケーションサーバ１００）は、所望の情報にアクセスするよう設計された１つ以上のＳＱＬステートメント（例えば、１つ以上のＳＱＬクエリ）を自動生成可能である。システムデータベース２４は、データベースからリクエストされたデータにアクセスするためのクエリプランを生成可能である。“クエリプラン”という用語は、一般にデータベースシステムにおける情報にアクセスするのに利用される１つ以上の処理を参照する。
【0038】
各データベースは、一般に所定又はカスタマイズ可能なカテゴリに適合されたデータを含む、論理テーブルのセットなどのオブジェクトの集まりとして見ることができる。“テーブル”は、データオブジェクトの一表現であり、いくつかの実現形態によるオブジェクト及びカスタムオブジェクトの概念的な記述を簡単化するためここで利用されうる。“テーブル”及び“オブジェクト”はここでは互換的に利用されうることが理解されるべきである。各テーブルは、一般に閲覧可能な方式でカラム又はフィールドとして論理的に構成される１つ以上のデータカテゴリを含む。テーブルの各行又は要素は、フィールドによって規定される各カテゴリのデータのインスタンスを含みうる。例えば、ＣＲＭデータベースは、名前、住所、電話番号、ファックス番号などの基本的コンタクト情報のためのフィールドによってカスタマを記述したテーブルを含むことが可能である。他のテーブルは、カスタマ、製品、販売価格、日付などの情報のためのフィールドを含む購入注文を記述可能である。いくつかのＭＴＳ実現形態では、標準エンティティのテーブルが全てのテナントによる利用のため提供可能である。ＣＲＭデータベースアプリケーションについて、そのような標準エンティティは、それぞれが所定のフィールドを含むケース、アカウント、コンタクト、リード及び機会データオブジェクトのためのテーブルを含むことが可能である。ここで用いられる“エンティティ”という用語はまた、“オブジェクト”及び“テーブル”と互換的に利用されうる。
【0039】
いくつかのＭＴＳ実現形態では、テナントは、カスタムオブジェクトを作成及び格納することが可能とされるか、あるいは、例えば、カスタムインデックスフィールドを含む標準的オブジェクトのためのカスタムフィールドを作成することによって、標準エンティティ又はオブジェクトをカスタマイズすることが可能とされてもよい。２０１０年８月１７日に発行されたＷｅｉｓｓｍａｎらによるＣＵＳＴＯＭ ＥＮＴＩＴＩＥＳ ＡＮＤ ＦＩＥＬＤＳ ＩＮ Ａ ＭＵＬＴＩ－ＴＥＮＡＮＴ ＤＡＴＡＢＡＳＥ ＳＹＳＴＥＭというタイトルの共有譲受され、その全体が全ての目的のため参照によりここに援用される米国特許第７，７７９，０３９号は、カスタムオブジェクトを作成すると共に、マルチテナントデータベースシステムにおける標準的オブジェクトをカスタマイズするシステム及び方法を教示する。いくつかの実現形態では、例えば、全てのカスタムエンティティデータ行が、組織毎に複数の論理テーブルを含みうる単一のマルチテナント物理テーブルに格納される。複数の“テーブル”が実際に１つの大きなテーブルに格納されているか、あるいは、データが他のカスタマのデータと同じテーブルに格納されうるかが、カスタマにとって明らかである。
ＩＩ．イベントストリーム処理システム
図２は、イベントストリーム処理システムを含む計算システム２００を示す。計算システム２００は、１つ以上のイベントパブリッシャ（例えば、イベントを生成するシステム）の計算デバイス２０１を含んでもよい。計算デバイス２０１は、図１Ａ～１Ｂに記載されるようにデータベースシステムのコンポーネントの何れかを含んでもよい。順序付けされてパーティションされたイベントログクラスタ２０２は、システムデータベース２４及び／又はテナントデータベース２２など、図１Ａ～１Ｂに記載されるデータベースシステムの何れかのデータストアに格納されてもよい。イベントプロセッサ２０３は、データストリーム処理システムのコンポーネント（例えば、Ａｐａｃｈｅ Ｓｔｏｒｍなどのイベントストリーム処理エンジン）であってもよい。データベースポッド２０５～２０７は、テナントデータベース２２など、ここに記載される何れかのデータベースのデータベースポッドを含み、イベントプロセッサ２０３による出力されるデータを格納するのに利用されてもよい。
ＩＩ．イベントストリーム処理システム
図２は、イベントストリーム処理システムを含む計算システム２００を示す。計算システム２００は、１つ以上のイベントパブリッシャ（例えば、イベントを生成するシステム）の計算デバイス２０１を含んでもよい。計算デバイス２０１は、図１Ａ～１Ｂに記載されるようにデータベースシステムのコンポーネントの何れかを含んでもよい。順序付けされてパーティションされたイベントログクラスタ２０２は、システムデータベース２４及び／又はテナントデータベース２２など、図１Ａ～１Ｂに記載されるデータベースシステムの何れかのデータストアに格納されてもよい。イベントプロセッサ２０３は、データストリーム処理システムのコンポーネント（例えば、Ａｐａｃｈｅ Ｓｔｏｒｍなどのイベントストリーム処理エンジン）であってもよい。データベースポッド２０５～２０７は、テナントデータベース２２など、ここに記載される何れかのデータベースのデータベースポッドを含み、イベントプロセッサ２０３による出力されるデータを格納するのに利用されてもよい。
【0040】
データストア２０４は、データベースポッド２０５～２０７に出力されるデータに関するメタデータ及び／又はイベントプロセッサにより受信される入力に関するメタデータ、イベントプロセッサ２０３の何れかのコンポーネントによって実行される処理に関するデータなど、又はこれらの組み合わせを格納しうる。メタデータは、イベントプロセッサ２０３がイベントログクラスタ２０２を処理する方法に関する情報であってもよい。
【0041】
イベントプロセッサ２０３は、１つ以上のイベントログコンシューマを含んでもよい。イベントログコンシューマは、イベントバッファにおけるイベントデータを構成するための１つ以上のバーチャルスパウトを含んでもよい。イベントストリームプロセッサは、イベントバッファにアクセスしてもよい。
【0042】
図３Ａ～Ｂは、バーチャルスパウト対応のスパウトインスタンス（例えば、連携スパウト５０２）のライフサイクルを示すシーケンス図を示す。期間５１０において、連携スパウト５０２がインスタンス化され、イベントストリーム処理システム５０１のイベントストリームプロセッサがデータを生成する前であってもよい。連携スパウト５０２は、イベントストリーム処理システム５０１に配置され、その後にオープンされる。
【0043】
期間５１５において、連携スパウト５０２は、ランタイムコンフィギュレーションを実行し、１つ以上のバーチャルスパウトがインスタンス化、配置及びオープンされてもよい。バーチャルスパウト５０３は、作成されて新たなチャイルドスレッドの実行を開始し、ランタイムコンフィギュレーションを実行してもよい。
【0044】
期間５２０において、イベントストリーム処理システム５０１のイベントストリームプロセッサは、１つ以上のデータストアへのデータのプッシュを開始する。連携スパウト５０２は、全てのバーチャルスパウト（例えば、バーチャルスパウト５０３）にアクティブ化するよう通知する。バーチャルスパウト５０３は、データソース５０５に接続し、データの読み込みを開始し、図示されたプロセスループを実行してもよい（イベントストリームプロセッサは、連携スパウトインスタンス５０２のメッセージバッファからメッセージを受信したことに応答して、１つ以上のデータストアへのデータのプッシュを開始してもよい）。
【0045】
次に図３Ｂを参照して、他の期間５２５において、連携スパウト５０２は、更なるバーチャルスパウト５０４がデータソース５０６について必要とされていると特定する。これは、新たなテナントに対するリクエストに応答して行われてもよい。連携スパウト５０２は、バーチャルスパウト５０４をインスタンス化、配置及びオープンする。バーチャルスパウト５０４は作成され、新たなチャイルドスレッドの実行を開始し、ランタイムコンフィギュレーションを実行してもよい。バーチャルスパウト５０４は、データソース５０６に接続し、データの読み込みを開始し、図示されるプロセスループを実行してもよい。
【0046】
他の期間５３０において、連携スパウト５０２は、バーチャルスパウト５０３及び５０４の既存のものがもはや必要でないと特定する。連携スパウト５０２は、例えば、非アクティブ化するようバーチャルスパウトに通知する。バーチャルスパウト５０３は、データソース５０５からの抽出を停止する。バーチャルスパウト５０３は、データソース５０５とのそれの接続をクローズし、終了する。
【0047】
他の期間５３５では、イベントストリーム処理システムは、イベントストリーム処理システムをシャットダウンする。シャットダウンでは、連携スパウトは、非アクティブ化するよう残りのスパウトに通知する。バーチャルスパウト５０４は、データソース５０６からの抽出を停止する。バーチャルスパウト５０４は、データソース５０６とのそれの接続をクローズし、終了する。連携スパウト５０２は、イベントストリーム処理システムを終了し、及び／又はイベントストリームプロセッサはシャットダウンしてもよい。
【0048】
連携スパウトのライフサイクル段階は、以下の１つ以上を含んでもよい。
・インスタンス化－“バーチャルスパウト対応”スパウトコンポーネント（又は“連携”スパウト）が作成及び設定される。
・配置－連携スパウトが配置される。
・オープン－オープン段階中、連携スパウトは、存在する場合、何れのバーチャルスパウトインスタンスが作成される必要があるか判断する。作成対象の各バーチャルスパウトについて、連携スパウトは、新たなチャイルド処理スレッド（配置段階）内で新たなバーチャルスパウトインスタンス（インスタンス化段階）を作成する。バーチャルスパウトインスタンスは、何れかのランタイムセットアッププロセスを実行するよう設定される（オープン段階）。
・アクティブ化－アクティブ化段階中、連携スパウトは、各バーチャルスパウトインスタンスにアクティブ化するよう通知するか、それの設定されたデータソースからのデータの取り込みを開始する。連携スパウトがアクティブ化されている間、それは管理され、アクティブ化された各バーチャルスパウトは、後述されるようなメッセージライフサイクルに従う。当該段階中の何れかの時点において、連携スパウトは、更なるバーチャルスパウトが更なる又は新たなデータソースからデータを取り込むよう要求されていると動的に判断する。連携スパウトは、作成された新たなバーチャルスパウトのそれぞれについてこの同じ概略されたライフサイクルに従う。この段階中の何れかの時点において、連携スパウトは、何れかアクティブ化されたバーチャルスパウトがもはや必要とされていないと動的に判断する。それは、非アクティブ化及びクローズによって自らのライフサイクルを係属するようこれらのバーチャルスパウトに通知する。
・非アクティブ化－非アクティブ化段階中、連携スパウトは、非アクティブ化するよう全てのバーチャルスパウトインスタンスに通知する。全てのバーチャルスパウトは、各自のデータソースからのメッセージの取り込みを中止する。
・クローズ－クローズ段階中、連携スパウトは、クローズするよう全てのバーチャルスパウトインスタンスに通知する。全てのバーチャルスパウトは、何れか必要な“クリーンアップ”又は“シャットダウン”タスクを実行する。その後、全てのバーチャルスパウトは、実行を中止し、それらのチャイルド処理スレッドを終了する。連携スパウトは、自らを終了させる前に全てのバーチャルスパウトが終了するのを待機する。
・インスタンス化－“バーチャルスパウト対応”スパウトコンポーネント（又は“連携”スパウト）が作成及び設定される。
・配置－連携スパウトが配置される。
・オープン－オープン段階中、連携スパウトは、存在する場合、何れのバーチャルスパウトインスタンスが作成される必要があるか判断する。作成対象の各バーチャルスパウトについて、連携スパウトは、新たなチャイルド処理スレッド（配置段階）内で新たなバーチャルスパウトインスタンス（インスタンス化段階）を作成する。バーチャルスパウトインスタンスは、何れかのランタイムセットアッププロセスを実行するよう設定される（オープン段階）。
・アクティブ化－アクティブ化段階中、連携スパウトは、各バーチャルスパウトインスタンスにアクティブ化するよう通知するか、それの設定されたデータソースからのデータの取り込みを開始する。連携スパウトがアクティブ化されている間、それは管理され、アクティブ化された各バーチャルスパウトは、後述されるようなメッセージライフサイクルに従う。当該段階中の何れかの時点において、連携スパウトは、更なるバーチャルスパウトが更なる又は新たなデータソースからデータを取り込むよう要求されていると動的に判断する。連携スパウトは、作成された新たなバーチャルスパウトのそれぞれについてこの同じ概略されたライフサイクルに従う。この段階中の何れかの時点において、連携スパウトは、何れかアクティブ化されたバーチャルスパウトがもはや必要とされていないと動的に判断する。それは、非アクティブ化及びクローズによって自らのライフサイクルを係属するようこれらのバーチャルスパウトに通知する。
・非アクティブ化－非アクティブ化段階中、連携スパウトは、非アクティブ化するよう全てのバーチャルスパウトインスタンスに通知する。全てのバーチャルスパウトは、各自のデータソースからのメッセージの取り込みを中止する。
・クローズ－クローズ段階中、連携スパウトは、クローズするよう全てのバーチャルスパウトインスタンスに通知する。全てのバーチャルスパウトは、何れか必要な“クリーンアップ”又は“シャットダウン”タスクを実行する。その後、全てのバーチャルスパウトは、実行を中止し、それらのチャイルド処理スレッドを終了する。連携スパウトは、自らを終了させる前に全てのバーチャルスパウトが終了するのを待機する。
【0049】
メッセージライフサイクル
連携スパウトが１つ以上の内部的なバーチャルスパウトインスタンスを作成した後、それらは、メッセージバッファへのメッセージの送信を開始する。メッセージバッファは、全てのバーチャルスパウトの間で共有され、これらのバーチャルスパウトからのメッセージがバッファに追加されることを可能にする。メッセージがメッセージバッファに追加されると、メッセージは、元のバーチャルスパウトにメッセージをリンクさせる識別子によりタグ付けされる。
連携スパウトが１つ以上の内部的なバーチャルスパウトインスタンスを作成した後、それらは、メッセージバッファへのメッセージの送信を開始する。メッセージバッファは、全てのバーチャルスパウトの間で共有され、これらのバーチャルスパウトからのメッセージがバッファに追加されることを可能にする。メッセージがメッセージバッファに追加されると、メッセージは、元のバーチャルスパウトにメッセージをリンクさせる識別子によりタグ付けされる。
【0050】
イベントストリームプロセッサ（例えば、ストリーム処理エンジン）が、次のメッセージが処理されるように連携スパウトをポーリングするとき、連携スパウトは、メッセージバッファからメッセージを抽出し、それを処理のためにストリームプロセッサに返す。
【0051】
ストリーム処理エンジンが連携スパウトにメッセージが処理を良好に完了させたと通知すると、連携スパウトは、メッセージを調べ、当該メッセージが何れのバーチャルスパウトから発信されたか判断する。連携スパウトは、その後に処理すべき適切なバーチャルスパウトにメッセージ完了通知をルーティングする。
【0052】
ストリーム処理エンジンが連携スパウトにメッセージが正しく処理できなかったと通知すると、連携スパウトは、メッセージを調べ、当該メッセージが何れのバーチャルスパウトから発信されたか判断する。連携スパウトは、その後に処理すべき適切なバーチャルスパウトにメッセージ失敗通知をルーティングする。
【0053】
図４は、単一のバーチャルスパウトを備えたイベントストリーム処理システム６００を示す。イベントストリーム処理システム６００は、図２のイベントストリーム処理システムを含む、ここに説明される何れかのイベントストリーム処理システムと同様であってもよい。
【0054】
単一の連携スパウト６１２の内部の実行は、単一のバーチャルスパウトインスタンス６１１である。バーチャルスパウトインスタンス６１１は、テナントＡのＳａｌｅｓｆｏｒｃｅ．ｃｏｍストリーミングＡＰＩからのイベントを利用し、それらをメッセージに変換する。これらのメッセージは、メッセージバッファ６１５に追加される。連携スパウト６１２は、その後にメッセージバッファ６１５からメッセージを移動し、処理対象のイベントストリームプロセッサ６２０に送信する。メッセージがイベントストリームプロセッサ６２０によって完了としてマーク付けされているとき、それは連携スパウト６１２に通知する。連携スパウト６１２は、メッセージの発信元の適切なバーチャルスパウトインスタンス６１１に当該通知を送信する。メッセージがイベントストリームプロセッサ６２０によって失敗としてマーク付けされているとき、それは連携スパウト６１２に通知する。連携スパウト６１２は、メッセージの発信元の適切なバーチャルスパウトインスタンス６１１に当該通知を送信する。
【0055】
図５は、複数のバーチャルスパウトを備えたイベントストリーム処理システム７００を示す。イベントストリーム処理システム７００は、図２のイベントストリーム処理システムを含む、ここに説明される何れかのイベントストリーム処理システムと同様であってもよい。
【0056】
単一の連携スパウト７１２の内部の実行は、複数のバーチャルスパウトインスタンス７１１、７２１及び７３１である。各バーチャルスパウトインスタンス７１１、７２１及び７３１は、メッセージを生成する各自のテナントのデータソースからのデータを利用する。これらのメッセージは、メッセージバッファ７１５に追加される。連携スパウトインスタンス７１２は、その後にメッセージバッファ７１５からメッセージを移動し、処理対象のイベントストリームプロセッサ７２０に送信する。メッセージがイベントストリームプロセッサ７２０によって完了としてマーク付けされているとき、それは連携スパウト７１２に通知する。連携スパウト７１２は、メッセージの発信元のバーチャルスパウトインスタンス７１１、７２１及び７３１の適切なものに当該通知を送信する。メッセージがイベントストリームプロセッサ７２０によって失敗としてマーク付けされているとき、それは連携スパウト７１２に通知する。連携スパウト７１２は、メッセージの発信元のバーチャルスパウトインスタンス７１１、７２１及び７３１の適切なものに当該通知を送信する。
【0057】
図６は、テナントの１つのバーチャルスパウトが他のテナントのサービスを混乱させることなくクローズされるイベントストリーム処理システム８００を示す。イベントストリーム処理システム８００は、図２のイベントストリーム処理システムを含む、ここに説明される何れかのイベントストリーム処理システムと同様であってもよい。
【0058】
単一の連携スパウト８１２の内部の実行は、複数のバーチャルスパウトインスタンス８１１、８２１、８３１及び８４１である。テナントＢのバーチャルスパウトインスタンス８２１はもはや必要でなく、“Ｘ”のマーキングによって示されるように、それは動的にシャットダウンされた。新たなバーチャルスパウトインスタンス８４１が、それが必要になったとき、テナントＤがそれのデータソースから利用するため作成された。バーチャルスパウトインスタンス８１１、８２１、８３１及び８４１のそれぞれは、各自のテナントのデータソースからデータを利用し、そこからメッセージを生成する。これらのメッセージはメッセージバッファ８１５に追加される。連携スパウトインスタンス８１２は、その後にメッセージバッファ８１５からメッセージを移動し、処理対象のイベントストリームプロセッサ８２０に送信する。メッセージがイベントストリームプロセッサ８２０によって完了としてマーク付けされているとき、それは連携スパウト８１２に通知する。連携スパウト８１２は、メッセージの発信元のバーチャルスパウト８１１、８２１、８３１及び８４１の適切なものに当該通知を送信する。メッセージがイベントストリームプロセッサ８２０によって失敗としてマーク付けされているとき、それは連携スパウト８１２に通知する。連携スパウト８１２は、メッセージの発信元のバーチャルスパウト８１１、８２１、８３１及び８４１の適切なものに当該通知を送信する。
ＩＩＩ．イベントストリーム処理システムにおけるサイドライニング
アプリケーションシステム（Ｓａｌｅｓｆｏｒｃｅ Ｐａｒｄｏｔなど）は、データストリーム処理システム（例えば、Ａｐａｃｈｅ Ｓｔｏｒｍ）を多用して、順序付けされた時系列イベントログ（例えば、Ａｐａｃｈｅ Ｋａｆｋａ）から利用する。イベント処理システムは、ログを利用し、ログのオフセットを用いて処理されたメッセージを追跡する。アプリケーションシステムは、それのテナントの全てからのイベントを単一のログにプッシュする。しかしながら、インフラストラクチャメンテナンス（カスタマデータベースは作業を必要とする）又はテナント接続性（例えば、Ｓａｌｅｓｆｏｒｃｅ ｏｒｇ ｏａｕｔｈトークンが満了になる）などの時間がある。これらの時間中、このテナントに関連するイベントについて、データベースの呼び出しは、イベント処理システムによる試みは不成功となり、テナントのデータのデータ損失を生じさせうる。
ＩＩＩ．イベントストリーム処理システムにおけるサイドライニング
アプリケーションシステム（Ｓａｌｅｓｆｏｒｃｅ Ｐａｒｄｏｔなど）は、データストリーム処理システム（例えば、Ａｐａｃｈｅ Ｓｔｏｒｍ）を多用して、順序付けされた時系列イベントログ（例えば、Ａｐａｃｈｅ Ｋａｆｋａ）から利用する。イベント処理システムは、ログを利用し、ログのオフセットを用いて処理されたメッセージを追跡する。アプリケーションシステムは、それのテナントの全てからのイベントを単一のログにプッシュする。しかしながら、インフラストラクチャメンテナンス（カスタマデータベースは作業を必要とする）又はテナント接続性（例えば、Ｓａｌｅｓｆｏｒｃｅ ｏｒｇ ｏａｕｔｈトークンが満了になる）などの時間がある。これらの時間中、このテナントに関連するイベントについて、データベースの呼び出しは、イベント処理システムによる試みは不成功となり、テナントのデータのデータ損失を生じさせうる。
【0059】
マルチテナントコミットログを読み込むとき、他のテナントのイベントを処理し続けながら（例えば、所与のテナントの処理を延期する）、ある期間に特定のテナントのデータを失うことなくログから当該テナントの処理イベントをスキップすることが望ましい。部分的な解決策は、例えば、テナント毎に１つのトピックなど、更なるトピックを作成することである。しかしながら、この部分的な解決策は、多数のテナントを良好にはスケーリングしない（一部のデータベースシステムでは、トピックの数が約２００を超えると、パフォーマンスに影響が生じうる）。
【0060】
データストリーム処理システムは、サイドライニングを実行するための命令を含んでもよい。サイドライニングは、所与のフィルタ基準によって、処理を延期するためのリクエストが行われると追跡し、その後、処理を延期させた状況が変わると、処理を再開することを含む。
【0061】
このシステムは、これらのメンテナンスの時間をフィルタリング基準のセットとして扱い、それらがトリガされると、スパウトは当該所与のフィルタ基準について順序付けされた時系列イベントログに対するオフセットを追跡する。フィルタ基準が適用されている間、一致するログから流れる何れのメッセージも、イベントプロセッサの更なる下流には発信されない。スパウトがサイドライニングを中止するようトリガされると、フィルタはトピックのメインフローから削除され、新たなスレッド又はバーチャルスパウトが、サイドラインリクエストの元のフィルタ基準のネゲーションに一致するオフセットの間のメッセージを利用するためスピンアップ（ｓｐｉｎ ｕｐ）される。サイドラインからのメッセージは、その後にメインフローからのメッセージの残りと共にイベントプロセッサに発信される。
【0062】
いくつかのイベントストリーム処理システムは、サイドライニングを実行するのに用いられる所定のトリガ及びフィルタリングセマンティックを含んでもよい。サイドラインシステムは、イベントストリームプロセッサから離れる選択されたデータフローの全てのセマンティックを処理するデータストリームの取り込み（例えば、Ｋａｆｋａスパウト、Ｓｔｏｒｍスパウトなどのスパウト）の実現形態におけるシームレスなドロップであってもよい。
【0063】
図７Ａ～Ｃは、アクティブにサイドライニングしないとき、サイドライニング中及びサイドライニング停止後のイベントストリーム処理システムの異なる状態をそれぞれ示す。イベントストリーム処理システムは、図２のイベントストリーム処理システムを含む、ここに説明される何れかのイベントストリーム処理システムと同様であってもよい。具体例では、イベントストリーム処理システムは、１つ以上のイベントストリームプロセッサによって利用されるイベントデータを格納するためのイベントバッファと、複数のデータストリームを生成するデータストリームプロセッサとを含み、各データストリームは複数のイベントの異なるサブセットに基づき、ストリームはイベントバッファに格納されているイベントデータをまとめて構成し、１つ以上のストリームプロセッサのイベントストリームプロセッサはイベントデータの一部を利用し、当該一部は複数のストリームに対応する。
【0064】
トリガ９５１は、サイドライニングが行われる条件を規定する。一例では、トリガ９５１は、ポッド状態９５０に関連する。ポッドは、メンテナンス又は他の理由のためオフラインとなる（例えば、データベースポッド２０５～２０７の１つ）。いくつかの具体例におけるトリガ９５１は、サイドライニングがポッド状態の変更に応答して行われることを指定する。他の例では、トリガ９５１は、フィルタリングが行われる何れか選択された条件を示す。
【0065】
トリガ９５１は、他の具体例では、データベースポッド１～３などのデータベースシステムコンポーネントの可用性に関連しない、フィルタリングが開始される何れかの条件に関するものであってもよい。フィルタリングは、例えば、カスタマリクエスト及び／又は順序付けされたイベントログに関連するクエリに基づくものとすることができる。
【0066】
スパウトは、処理機構のチェーンの第１の部分であってもよい（ＡがＢに移り、ＢがＣに移るなど）。スパウトは、イベントストリームプロセッサが処理可能な形式でデータソースを取得する責任がありうる。スパウト内において、第１の段階は、データソースから読み取る責任がある（例えば、データソースの生データを利用する）。“非アクティブなサイドライニング”状態におけるバーチャルスパウトは、第１のバーチャルスパウト（例えば、ファイアホース（ｆｉｒｅｈｏｓｅ）バーチャルスパウト）であってもよい。
【0067】
図７Ｂをここで参照して、ウィンドウ９８５の間、フィルタ基準が適用される。フィルタリング基準は、何れのデータが第１のバーチャルスパウトに移るか制御する。第１のバーチャルスパウトは、ウィンドウ９８５のグレイアウトされたイベントをスキップする。フィルタリング基準は、選択されるアカウントであってもよい。ポッド（ｐｏｄ）が下がる例では（メンテナンス又は他の理由のため）、選択されるアカウントは、当該ポッドに関するアカウントであってもよい（図では、ポッド１に関するアカウントはフィルタリング基準である）。
【0068】
図７Ｃをここで参照して、サイドライニングが停止すると、第２のバーチャルスパウトがスピンアップされる。第２のバーチャルスパウトは、ウィンドウ９８５のイベントをまた受信するコンシューマを有してもよい。フィルタリング基準（例えば、この場合、ポッド１のみ）のネゲーションは、第２のバーチャルスパウトへのデータフィードに適用される。この状態では、両方のバーチャルスパウトが、データを同じイベントバッファに提供する。従って、図示される具体例では、第２のバーチャルスパウトは、ウィンドウ９８５の期間中にポッド１に関するイベントにイベント番号を提供する。
【0069】
ポッド停止の例では、イベントストリームプロセッサは、停止中に動作し続けるが、それは、停止しているポッドに関するイベントを受信せず、また、ウィンドウ期間中にダウンしているポッドに対するデータベース呼び出しを行わない（データベース呼び出しがウィンドウ期間中に行われた場合、データ損失が生じうる）。“スキップ”されたイベントは、第２のバーチャルスパウトに以降において提供され（ウィンドウ後）、イベントストリームプロセッサは、第１のポッドがバックアップされる期間においてそれのデータベース呼び出しを行うようにしてもよい（データ損失が回避されうる）。
【0070】
イベントストリームプロセッサは、あたかも単一のスパウトがあるかのように、イベントバッファのデータに対して動作してもよい。しかしながら、何れかの数のバーチャルスパウトが存在可能である。インタフェースが、更に指定されたフィルタ基準に基づき何れかの数の更なるスパウトを確立するため提供されてもよい。更なるバーチャルスパウトは、各自のフィルタリング基準について各自のウィンドウにおいてスピンアップされる。イベントストリームプロセッサは、複数のスパウトがあるという知識を必要とせず、従って、従来のイベントストリームプロセッサは、図７Ａ～７Ｂのバーチャルスパウトと共に利用されてもよい。
【0071】
図８Ａ～８Ｂは、図２及び／又は７Ａ～７Ｃのイベントストリーム処理システムを含む、ここに説明される何れかのイベントストリーム処理システムによって実行されうるプロセスを示す。丸印９９１、９９２及び９９３は、図示されたプロセスについて図８Ａが図８Ｂに続くことを示す。
【0072】
具体例
１つ以上のデータソースからデータを取り込み、データをイベントストリームプロセッサの無限のストリームに変換するストリーム処理システムであって、第１の時点に配置される第１の連携スパウトインスタンスであって、１つ以上の第２のスパウトインスタンスをインスタンス化し、第１の時点より以降の第２の時点で１つ以上の第２のスパウトインスタンスを配置する第１の連携スパウトインスタンスを有し、１つ以上の第２のスパウトインスタンスは、１つ以上のデータソースにそれぞれ接続し、１つ以上のデータソースの各自のものからデータの各自の部分を取り込み、データの取り込まれた部分に基づきメッセージを出力し、イベントストリームプロセッサの無限のストリームは、メッセージに基づくシステムである。
１つ以上のデータソースからデータを取り込み、データをイベントストリームプロセッサの無限のストリームに変換するストリーム処理システムであって、第１の時点に配置される第１の連携スパウトインスタンスであって、１つ以上の第２のスパウトインスタンスをインスタンス化し、第１の時点より以降の第２の時点で１つ以上の第２のスパウトインスタンスを配置する第１の連携スパウトインスタンスを有し、１つ以上の第２のスパウトインスタンスは、１つ以上のデータソースにそれぞれ接続し、１つ以上のデータソースの各自のものからデータの各自の部分を取り込み、データの取り込まれた部分に基づきメッセージを出力し、イベントストリームプロセッサの無限のストリームは、メッセージに基づくシステムである。
【0073】
具体例２は、具体例１又は他の何れかの具体例の主題を含み、出力されたメッセージを受信するメッセージバッファを更に有し、無限のストリームは、バッファから出力される。
【0074】
具体例３は、具体例１～２の何れか又は他の何れかの具体例の主題を含み、第１の連携スパウトインスタンスは、１つ以上の第３のスパウトインスタンスをインスタンス化し、第２の時点より以降の第３の時点で１つ以上の第３のスパウトインスタンスを配置し、１つ以上の第３のスパウトインスタンスは、１つ以上の更なるデータソースにそれぞれ接続し、１つ以上の更なるデータソースの各自のものから更なるデータの各自の部分を取り込み、更なるデータの取り込まれた部分に基づきメッセージを出力し、イベントストリームプロセッサの無限のストリームは、メッセージと更なるメッセージとに基づく。
【0075】
具体例４は、具体例１～３の何れか又は他の何れかの具体例の主題を含み、データソースは、時系列の順序付けされたイベントログを含む。
【0076】
具体例５は、具体例１～４の何れか又は他の何れかの具体例の主題を含み、データソースは、時系列の順序付けされたイベントログを含み、更なるデータソースは、更なる時系列の順序付けされたイベントログを含む。
【0077】
具体例６は、具体例１～５の何れか又は他の何れかの具体例の主題を含み、更なる時系列の順序付けされたイベントログは、時系列の順序付けされたイベントログのスタート時間後に始まる。
【0078】
具体例７は、具体例１～６の何れか又は他の何れかの具体例の主題を含み、第１の連携スパウトインスタンスは更に、イベントストリームプロセッサからメッセージを受信し、メッセージのコンテンツに基づき１つ以上の第２のスパウトインスタンスと１つ以上の第３のスパウトインスタンスとの間にメッセージを分配する。
【0079】
具体例８は、具体例１～７の何れか又は他の何れかの具体例の主題を含み、メッセージは、無限のストリームを処理したことに応答して、イベントストリームプロセッサによって生成されたメッセージ完了通知とメッセージ失敗通知とを含む。
【0080】
具体例９は、具体例１～８の何れか又は他の何れかの具体例の主題を含み、メッセージは、イベントストリームプロセッサの単一の出力インタフェースを介し受信される。
【0081】
具体例１０は、具体例１～９の何れか又は他の何れかの具体例の主題を含み、第１の連携スパウトインスタンスは、１つ以上の第２のスパウトインスタンスの個別のものを選択し、１つ以上の第２のスパウトインスタンスの個別のものに非アクティブ化するよう通知し、１つ以上の第２のスパウトインスタンスの選択された個別のものをクローズする。
【0082】
具体例１１は、１つ以上のデータソースからデータを取り込み、データをイベントストリームプロセッサの無限のストリームに変換する方法であって、第１の時点で第１の連携スパウトインスタンスを配置するステップと、第１の連携スパウトインスタンスを配置した後、第１の連携スパウトインスタンスを利用して、１つ以上の第２のスパウトインスタンスをインスタンス化し、第１の時点より以降の第２の時点で１つ以上の第２のスパウトインスタンスを配置するステップと、１つ以上のデータソースに接続し、１つ以上の第２のスパウトインスタンスをそれぞれ利用して、１つ以上のデータソースからデータの各自の部分を取り込むステップと、データの取り込まれた部分に基づき、１つ以上の第２のスパウトインスタンスからメッセージを出力するステップとを有し、イベントストリームプロセッサの無限のストリームは、前記メッセージに基づく方法である。
【0083】
具体例１２は、具体例１１の何れか又は他の何れかの具体例の主題を含み、メッセージを単一のバッファに出力するステップを更に有し、無限のストリームは、バッファから出力される。
【0084】
具体例１３は、具体例１１～１２の何れか又は他の何れかの具体例の主題を含み、第１の連携スパウトインスタンスを配置した後、１つ以上の第３のスパウトインスタンスをインスタンス化し、第２の時点より以降の第３の時点で１つ以上の第３のスパウトインスタンスを配置するステップと、１つ以上の更なるデータソースに接続し、１つ以上の第３のスパウトインスタンスをそれぞれ利用して、１つ以上の更なるデータソースから更なるデータの各自の部分を取り込むステップと、更なるデータの取り込まれた部分に基づき、１つ以上の第３のスパウトインスタンスからメッセージを出力するステップとを更に有し、イベントストリームプロセッサの無限のストリームは、メッセージと更なるメッセージとに基づく。
【0085】
具体例１４は、具体例１１～１３の何れか又は他の何れかの具体例の主題を含み、データソースは、時系列の順序付けされたイベントログを含む。
【0086】
具体例１５は、具体例１１～１４の何れか又は他の何れかの具体例の主題を含み、データソースは、時系列の順序付けされたイベントログを含み、更なるデータソースは、更なる時系列の順序付けされたイベントログを含む。
【0087】
具体例１６は、具体例１１～１５の何れか又は他の何れかの具体例の主題を含み、更なる時系列の順序付けされたイベントログは、時系列の順序付けされたイベントログのスタート時間後に始まる。
【0088】
具体例１７は、具体例１１～１６の何れか又は他の何れかの具体例の主題を含み、第１の連携スパウトインスタンスにおいてイベントストリームプロセッサからメッセージを受信するステップと、メッセージのコンテンツに基づき、１つ以上の第２のスパウトインスタンスと１つ以上の第３のスパウトインスタンスとの間でメッセージを分配するステップとを更に有する。
【0089】
具体例１８は、具体例１１～１７の何れか又は他の何れかの具体例の主題を含み、メッセージは、無限のストリームを処理したことに応答して、イベントストリームプロセッサによって生成されたメッセージ完了通知とメッセージ失敗通知とを含む。
【0090】
具体例１９は、具体例１１～１８の何れか又は他の何れかの具体例の主題を含み、メッセージは、イベントストリームプロセッサの単一の出力インタフェースを介し受信される。
【0091】
具体例２０は、具体例１１～１９の何れか又は他の何れかの具体例の主題を含み、連携スパウトインスタンスがオープンである間、クローズ対象の１つ以上の第２のスパウトインスタンスの個別のものを選択するステップと、１つ以上の第２のスパウトインスタンスの個別のものに非アクティブ化するよう通知するステップと、第１の連携スパウトインスタンスによってイベントストリームプロセッサとのインタフェースを維持しながら、１つ以上の第２のスパウトインスタンスの個別のものをクローズするステップとを更に有する。
【0092】
具体例２１は、具体例１～６の何れか又は他の何れかの具体例の主題を含み、１つ以上のイベントストリームプロセッサにより利用されるイベントデータを格納するイベントバッファと、複数のデータストリームを生成するデータストリームプロセッサとを有するイベントストリーム処理システムであって、各データストリームは、複数のイベントの異なるサブセットに基づき、これらのストリームは、イベントバッファに格納されているイベントデータをまとめて構成し、１つ以上のストリームプロセッサのイベントストリームプロセッサは、複数のストリームに対応するイベントデータの部分を利用するシステムである。
【0093】
具体例２２は、具体例２１の何れか又は他の何れかの具体例の主題を含み、データストリームプロセッサは、選択された期間中に順序付けされたイベントログの一部に１つ以上のフィルタリング基準を適用し、複数のストリームの第１のストリームを構成するため、複数のイベントのサブセットの対応するものを特定し、データストリームプロセッサは、選択された期間の終了後、順序付けされたイベントログの同一の部分に１つ以上のフィルタリング基準のネゲーションを適用し、複数のストリームの異なる第２のストリームを構成するため、複数のイベントのサブセットの対応する異なるものを特定する。
【0094】
具体例２３は、具体例２１～２２の何れか又は他の何れかの具体例の主題を含み、期間は、１つ以上のイベントストリームプロセッサによって生成されるデータを格納する複数のポッドのポッドの利用不可期間に対応する。
【0095】
具体例２４は、具体例２１～２３の何れか又は他の何れかの具体例の主題を含み、１つ以上のフィルタリング基準を利用して順序付けされたイベントログの部分の情報のフィルタリングは、順序付けされたイベントログの情報のサブセットを第１のストリームの構成中にスキップさせる。
【0096】
具体例２５は、具体例２１～２４の何れか又は他の何れかの具体例の主題を含み、１つ以上のフィルタリング基準のネゲーションを利用して順序付けされたイベントログの部分の情報のフィルタリングは、第２のデータストリームプロセッサに異なる第２の情報の構成中に情報のサブセットを除き、順序付けされたイベントログの部分の全ての情報をスキップさせる。
【0097】
具体例２６は、具体例２１～２５の何れか又は他の何れかの具体例の主題を含み、データストリームプロセッサはスパウトを含み、各ストリームは、スパウトの複数のバーチャルスパウトの異なるバーチャルスパウトから生じる。
【0098】
具体例２７は、イベントストリーム処理システムを利用する方法であって、イベントバッファに１つ以上のイベントストリームプロセッサにより利用されるイベントデータを格納するステップと、複数のデータストリームを生成するステップとを有し、各データストリームは、複数のイベントの異なるサブセットに基づき、これらのストリームは、イベントバッファに格納されているイベントデータをまとめて構成し、１つ以上のストリームプロセッサのイベントストリームプロセッサは、複数のストリームに対応するイベントデータの部分を利用する方法である。
【0099】
具体例２８は、具体例２７の何れか又は他の何れかの具体例の主題を含み、選択された期間中に順序付けされたイベントログの一部に１つ以上のフィルタリング基準を適用し、複数のストリームの第１のストリームを構成するため、複数のイベントのサブセットの対応するものを特定するステップと、選択された期間の終了後、順序付けされたイベントログの同一の部分に１つ以上のフィルタリング基準のネゲーションを適用し、複数のストリームの異なる第２のストリームを構成するため、複数のイベントのサブセットの対応する異なるものを特定するステップとを含む。
【0100】
具体例２９は、具体例２７～２８の何れか又は他の何れかの具体例の主題を含み、期間は、１つ以上のイベントストリームプロセッサによって生成されるデータを格納する複数のポッドのポッドの利用不可期間に対応する。
【0101】
具体例３０は、他の何れかの具体例の主題を含み、１つ以上のフィルタリング基準を利用して順序付けされたイベントログの部分の情報のフィルタリングは、順序付けされたイベントログの情報のサブセットを第１のストリームの構成中にスキップさせる。
【0102】
具体例３１は、具体例２７～３０の何れか又は他の何れかの具体例の主題を含み、１つ以上のフィルタリング基準のネゲーションを利用して順序付けされたイベントログの部分の情報のフィルタリングは、異なる第２の情報の構成中に情報のサブセットを除き、順序付けされたイベントログの部分の全ての情報をスキップさせる。
【0103】
具体例３２は、具体例２７～３１の何れか又は他の何れかの具体例の主題を含み、各ストリームは、イベントストリームプロセッサが利用するスパウトの複数のバーチャルスパウトの異なるバーチャルスパウトから生じる。
【0104】
具体例３３は、具体例１～１０の何れか又は他の何れかの具体例の主題を含み、１つ以上の第２のスパウトインスタンスは、複数のスパウトインスタンスを含み、複数のスパウトインスタンスの第１のスパウトインスタンスは、選択された期間について、データの取り込まれた部分に１つ以上のフィルタリング基準を適用するよう構成され、メッセージの第１のサブセットは、１つ以上のフィルタリング基準の適用に応答して、複数のスパウトインスタンスの第１のスパウトインスタンスによって生成され、複数のスパウトインスタンスの第２のスパウトインスタンスは、選択された期間の終了後、１つ以上のフィルタリング基準のネゲーションをデータの同一の取り込まれた部分に適用するよう構成され、メッセージの異なる第２のサブセットは、１つ以上のフィルタリング基準のネゲーションの適用に応答して、複数のスパウトインスタンスの第２のスパウトインスタンスによって生成される。
【0105】
具体例３４は、具体例１～１０又は３３の何れか又は他の何れかの具体例の主題を含み、選択された期間は、イベントストリームプロセッサによって生成されたデータを格納するためのストレージデバイスの利用不可期間に対応する。
【0106】
具体例３５は、１つ以上のデータソースからデータを取り込み、データをイベントストリームプロセッサの無限のストリームに変換するストリーム処理システムであって、第１の時点に配置される第１の連携スパウトインスタンスであって、第２のスパウトインスタンスと第３のスパウトインスタンスとをインスタンス化する第１の連携スパウトインスタンスを有し、第１の連携スパウトインスタンスは、第２及び第３のスパウトインスタンスを順次配置し、第２のスパウトインスタンスは、第１の時点より以降の第２の時点で配置され、第３のスパウトインスタンスは、第２の時点より以降の第３の時点で配置され、第２及び第３のスパウトインスタンスはそれぞれ、１つ以上のデータソースからのデータの同一の部分を取り込み、第１のメッセージと第２のメッセージとをそれぞれ出力し、イベントストリームプロセッサの無限のストリームは、第１及び第２のメッセージに基づくシステムである。
【0107】
具体例３６は、具体例３５の何れか又は他の何れかの具体例の主題を含み、第２のスパウトインスタンスは、１つ以上のデータソースからのデータの部分に第１のフィルタリング基準を適用するよう構成され、第３のスパウトインスタンスは、１つ以上のデータソースからのデータの部分に第１のフィルタリング基準と異なる第２のフィルタリング基準を適用するよう構成される。
【0108】
具体例３７は、具体例３５～３６の何れか又は他の何れかの具体例の主題を含み、第２のフィルタリング基準は、第１のフィルタリング基準のネゲーションを含む。
【0109】
ここに開示された実現形態の特定の態様の具体的詳細は、開示された実現形態の精神及び範囲から逸脱することなく、何れか適した方法で組み合わされてもよい。しかしながら、他の実現形態は、個別の各態様に関連する特定の実現形態又はこれら個別の態様の特定の組み合わせに関するものであってもよい。
【0110】
さらに、開示された具体例はしばしば、オンデマンドデータベースサービス環境が、複数のテナントをサポート可能なオンデマンドデータベースサービスのためのフロントエンドを提供するアプリケーションサーバを有するデータベースシステムにおいて実現される実現形態を参照してここで説明されるが、本実現形態は、マルチテナントデータベース又はアプリケーションサーバ上の配置に限定されない。実現形態は、請求される実現形態の範囲から逸脱することなく、他のデータベースアーキテクチャ、すなわち、ＯＲＡＣＬＥ（登録商標）、ＩＢＭによるＤＢ２（登録商標）などを用いて実施されてもよい。
【0111】
開示された実現形態の一部は、制御ロジックの形態を含む、ハードウェア、ソフトウェア、ファームウェアの各種タイプ又はこれらの組み合わせの形態で、当該ハードウェア又はソフトウェアをモジュール又は統合方式で利用して実現可能であることがまた、理解されるべきである。他のやり方又は方法が、ハードウェア及びハードウェアとソフトウェアとの組み合わせを用いて可能である。さらに、本願において説明されるソフトウェアコンポーネント又は機能の何れも、例えば、既存又はオブジェクト指向技術を利用して、Ｊａｖａ、Ｃ＋＋、Ｐｅｒｌなどの何れか適したコンピュータ言語を利用して、１つ以上のプロセッサによって実行されるソフトウェアコードとして実現可能である。ソフトウェアコードは、物理的な非一時的コンピュータ可読媒体上のコンピュータ又はプロセッサにより実行可能な命令又はコマンドとして格納可能である。適した媒体の具体例は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードドライブ又はフロッピー（登録商標）ディスクなどの磁気媒体、コンパクトディスク（ＣＤ）又はＤＶＤなどの光媒体、フラッシュメモリなど、又はこのようなストレージ若しくは伝送デバイスの何れかの組み合わせを含む。
【0112】
ソフトウェア／プログラムコードにより符号化されるコンピュータ可読媒体は、互換的デバイスと一緒にパッケージ化されるか、あるいは、他のデバイスから別々に提供されてもよい（例えば、インターネットダウンロードを介し）。このようなコンピュータ可読媒体は、単一の計算デバイス又はコンピュータシステム全体に常駐され、システム又はネットワーク内の他のコンピュータ可読媒体間にあってもよい。コンピュータシステム又は他の計算デバイスは、ここに述べられた結果の何れかをユーザに提供するためのモニタ、プリンタ又は他の適したディスプレイを含んでもよい。
【0113】
開示された技術の原理が適用される多数の可能な実施例を鑑み、図示された実施例は単なる好適な具体例であり、開示の範囲を限定するものとしてとられるべきでないことが認識されるべきである。本発明として請求されるものは、添付した請求項の範囲及び精神の範囲内である。
【図1A】
【図1B】
【図2】
【図3A】
【図3B】
【図4】
【図5】
【図6】
【図7A】
【図7B】
【図7C】
【図8A】
【図8B】