特許 6378356 イベント処理システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6378356

(24)【登録日】2018年8月3日

(45)【発行日】2018年8月22日

(54)【発明の名称】イベント処理システム

(51)【国際特許分類】

   G06F 12/00 20060101AFI20180813BHJP

   G06F 9/50 20060101ALI20180813BHJP

   G06F 17/30 20060101ALI20180813BHJP

【ＦＩ】

   G06F12/00 513J

   G06F9/50 150D

   G06F17/30 110C

   G06F17/30 415

【請求項の数】12

【全頁数】16

(21)【出願番号】特願2016-559816(P2016-559816)

(86)(22)【出願日】2014年3月31日

(65)【公表番号】特表2017-514216(P2017-514216A)

(43)【公表日】2017年6月1日

(86)【国際出願番号】EP2014056425

(87)【国際公開番号】WO2015149830

(87)【国際公開日】20151008

【審査請求日】2016年11月7日

(73)【特許権者】

【識別番号】503433420

【氏名又は名称】華為技術有限公司

【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】レヴィ，エリエゼル

(72)【発明者】

【氏名】アヴィズール，アハロン

(72)【発明者】

【氏名】ブラウン，ルーカス

(72)【発明者】

【氏名】エッテール，トマス

(72)【発明者】

【氏名】ギャスパリ，ジョルジオ

(72)【発明者】

【氏名】カウフマン，マルティン

(72)【発明者】

【氏名】コスマン，ドナルド

(72)【発明者】

【氏名】ウィドメール，ダニエル

【審査官】 田中 啓介

(56)【参考文献】

【文献】 国際公開第２０１２／０４６３１６（ＷＯ，Ａ１）

【文献】 国際公開第２０１３／１４５３１０（ＷＯ，Ａ１）

【文献】 米国特許出願公開第２０１２／０２９１０４９（ＵＳ，Ａ１）

【文献】 特開２０１０−２０４８８０（ＪＰ，Ａ）

【文献】 特開２００７−１６４７９４（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００９／０１０６１８９（ＵＳ，Ａ１）

【文献】 西澤 晋，大量のデータをリアルタイムで監視して処理する 複合イベント処理ＣＥＰ，ＩＴアーキテクト，日本，２００９年 ５月２８日，Ｖｏｌ．２３

【文献】 勝沼 聡，ストリームデータ処理の分散並列化実行におけるマージ処理コスト削減方式，第２回データ工学と情報マネジメントに関するフォーラム−ＤＥＩＭ ２０１０−論文集，日本，２０１０年 ５月２５日

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ９／４５５−９／５４

Ｇ０６Ｆ１２／００、１７／３０

(57)【特許請求の範囲】

【請求項1】

データベースシステムで動作するイベントのストリームを処理するよう構成されるイベント処理システムであって、前記イベント処理システムは、イベント負荷平衡ユニットと、複数のイベント計算ノードと、前記複数のイベント計算ノードに対応し前記複数のイベント計算ノードと別個の複数のイベント状態ストアと、を含み、
前記イベント負荷平衡ユニットは、イベント負荷平衡基準に従って、イベントの前記ストリームを前記複数のイベント計算ノードへルーティングするよう構成され、
前記複数のイベント状態ストアは、対応するイベント計算ノードによるイベントの処理に関連する状態変数を格納するよう構成され、
前記複数のイベント計算ノードは、前記イベント負荷平衡ユニットから受信した前記イベントを処理し、前記イベントの処理に関連する状態変数を変化し、前記変化した状態変数に基づき、該イベント計算ノードに対応するイベント状態ストアに格納された前記状態変数を更新するよう構成される、
イベント処理システム。

【請求項2】

クエリ負荷平衡ユニットと、複数のクエリ処理ノードと、を更に有し、
前記クエリ負荷平衡ユニットは、クエリ負荷平衡基準に従って、前記複数のクエリ処理ノードへ、クエリのストリームをルーティングするよう構成され、
前記複数のクエリ処理ノードは、前記クエリ負荷平衡ユニットから受信した前記クエリを処理するよう構成される、
請求項１に記載のイベント処理システム。

【請求項3】

前記クエリ負荷平衡ユニットは、各々のクエリを、１つのクエリ処理ノードへ転送するよう構成される、請求項２に記載のイベント処理システム。

【請求項4】

前記複数のクエリ処理ノードのうちの１つのクエリ処理ノードは、前記クエリ負荷平衡ユニットから受信した前記クエリを処理するために、前記複数のイベント状態ストアのうちの少なくとも１つのイベント状態ストアにアクセスするよう構成される、請求項２又は３に記載のイベント処理システム。

【請求項5】

前記クエリ処理ノードは、前記クエリを処理するために、更なるデータ、特に前記データベースシステムの顧客マスタデータにアクセスするよう構成される、請求項４に記載のイベント処理システム。

【請求項6】

前記複数のクエリ処理ノードは、リアルタイム解析のためにアドホッククエリを扱うよう構成される、請求項２乃至５のいずれか一項に記載のイベント処理システム。

【請求項7】

前記複数のイベント状態ストアは、分散型の主メモリに基づくキー値ストアを有する、請求項１乃至６のいずれか一項に記載のイベント処理システム。

【請求項8】

前記イベント負荷平衡ユニットは、前記複数のイベント計算ノードのうちの１つのイベント計算ノードが、前記イベントの特定の部分集合を扱い、前記イベントの前記特定の部分集合について全てのルールを処理できるように、前記イベントをルーティングするよう構成される、請求項１乃至７のいずれか一項に記載のイベント処理システム。

【請求項9】

前記イベント負荷平衡ユニットは、全てのイベント計算ノードが全てのイベント及びルールの部分集合を扱えるように、イベント複製及びルール区分に基づき、前記イベントをルーティングするよう構成される、請求項１乃至７のいずれか一項に記載のイベント処理システム。

【請求項10】

前記イベント負荷平衡ユニットは、前記複数のイベント計算ノードのうちの１つのイベント計算ノードが空き容量を有するときイベントを扱うことができるように、前記イベントのラウンドロビン区分及びルールの複製に基づき、前記イベントをルーティングするよう構成される、請求項１乃至７のいずれか一項に記載のイベント処理システム。

【請求項11】

イベント処理システムの作動方法であって、前記イベント処理システムは、イベント負荷平衡ユニットと、複数のイベント計算ノードと、前記複数のイベント計算ノードに対応し前記複数のイベント計算ノードと別個の複数のイベント状態ストアと、を含み、前記作動方法は、
前記イベント負荷平衡ユニットが、イベント負荷平衡基準に従って、イベントのストリームを、複数のイベント計算ノードへルーティングするステップと、
前記複数のイベント計算ノードが、前記イベント計算ノードによるイベントの処理に関連する状態変数を、前記イベント計算ノードに対応するイベント状態ストアに格納するステップと、
前記複数のイベント計算ノードが、受信したイベントを処理し、前記イベントの前記処理に関連する状態変数を変化し、前記変化した状態変数に基づき、該イベント計算ノードに対応するイベント状態ストアに格納された前記状態変数を更新するステップと、
を含む方法。

【請求項12】

コンピュータプログラムであって、コンピュータに、
イベント負荷平衡基準に従いイベントのストリームを複数のイベント計算ノードにルーティングさせ、
前記複数のイベント計算ノードによるイベントの処理に関連する状態変数を、前記複数のイベント計算ノードに対応し前記イベント計算ノードと別個の複数のイベント状態ストアに格納させ、
前記複数のイベント計算ノードにおいて受信したイベントを処理させ、前記イベントの前記処理に関連する状態変数を変化させ、及び前記変化した状態変数に基づき、該イベント計算ノードに対応するイベント状態ストアに格納された前記状態変数を更新させる、
コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、イベント処理システム、及びイベント処理のための方法に関する。本開示は、さらに、データベース管理システム（database management system、ＤＢＭＳ）、特にＳＱＬ（構造化クエリ言語、Structured Query Language）を用いるＤＢＭＳのリアルタイム解析と結合されたスケーラブルストリーム処理に関する。

【背景技術】

【0002】

大規模データ処理では、３つの重要な特長である、大容量の処理状態を把握できるイベント処理、複雑な宣言型クエリ（例えば、ＳＱＬクエリ）、つまり多数のクエリ及びイベントを伴うリアルタイム解析、並びに、負荷及びデータベースの大きさのスケーラビリティは、多くのアプリケーションにとって重要である。一例として、電気通信オペレータは、毎秒、最大何百万もの呼レコードをキャプチャし処理し、複雑なアドホッククエリにより自身の顧客の行動の分析のサポートを提供する必要がある場合がある。従来のデータベース技術は、これらの３つの特徴のうちの多くても２つしか解決できない。さらに具体的には、２つのシステムクラスがある。（ａ）データストリーム管理システム（Data Stream Management System、ＤＳＭＳ）、及び（ｂ）データベース管理システム（Database Management System、ＤＢＭＳ）である。ＤＳＭＳは、複雑なイベント処理に良好に適するが、リアルタイム解析をサポートしない。最も高度なＤＭＢＳは、（良くても）リアルタイム解析をサポートするが、複雑なイベント処理に良好に適合しない。両方の種類のシステムは、限られたスケーラビリティを有する場合が多い。

【0003】

データストリーム管理システム（ＤＳＭＳ）の目的は、別個のイベントの高帯域幅ストリームをリアルタイムに追跡することである。従来のシステムは、ＳｔｒｅａｍＳＱＬのようなＳＱＬクエリ言語の拡張を用いて、宣言型インタフェースを提供する。ＳｔｒｅａｍＳＱＬを用いて、アプリケーション開発者は、入力イベントストリームにある可能な複雑なパターンを指定するルール（連続クエリとしても言及される）を定める。入力イベントストリームがこのようなパターンを呈するときは常に、ルールが発火し、イベントストリームとしてアプリケーションにより消費される結果を生成する。

【0004】

この機能を実行するために、ＤＳＭＳは、ルールを評価するために必要な、場合によっては膨大な数の状態変数を維持しなければならない。原理的に、各々のイベントの到着により、ＤＳＭＳは、関連状態変数を更新し、新しい大域状態が所定のルールをトリガすることを要求するか否かを調べなければならない。関連する計算は、新しい値の計算及びこれらの状態変数の更新を意味し、一方で、関連する記憶は、新しい値の頻繁な計算がリアルタイムに行えるよう、状態変数の維持を意味する。

【0005】

最新のＤＳＭＳは、標準的な単一のマシンで、最大で毎秒数十万ものイベント、及び数百ものルールを処理できる。それらは、多数の最適化を適用することにより、これを行う。最も具体的には、それらは、特に所与のルールセットに対して状態変数の管理を内部的に最適化する。マシンの数に対応するために、これらのシステムは、イベントストリームを複製し、異なるマシンで異なるルールを処理する。つまり、それらは、データを複製し、負荷を分配する。これらのシステムは、「Brian Babcock, Shivnath Babu, Mayur Datar, Rajeev Motwani, Jennifer Widom: Models and Issues in Data Stream Systems. PODS ２００２: １−１６」によるStreamプロジェクト、「Sailesh Krishnamurthy, Sirish Chandrasekaran, Owen Cooper, Amol Deshpande, Michael J. Franklin, Joseph M. Hellerstein, Wei Hong, Samuel Madden, Frederick Reiss, Mehul A. Shah: TelegraphCQ: An Architectural Status Report. IEEE Data Eng. Bull. ２６(１): １１−１８ (２００３)」によるTelegraphプロジェクト、及び「Hari Balakrishnan, Magdalena Balazinska, Donald Carney, Ugur Cetintemel, Mitch Cherniack, Christian Convey, Eduardo F. Galvez, Jon Salz, Michael Stonebraker, Nesime Tatbul, Richard Tibbetts, Stanley B. Zdonik: Retrospective on Aurora. VLDB J. １３(４): ３７０−３８３ (２００４)」及び「Daniel J. Abadi, Yanif Ahmad, Magdalena Balazinska, Ugur Cetintemel, Mitch Cherniack, Jeong−Hyon Hwang, Wolfgang Lindner, Anurag Maskey, Alex Rasin, Esther Ryvkina, Nesime Tatbul, Ying Xing, Stanley B. Zdonik: The Design of the Borealis Stream Processing Engine. CIDR ２００５: ２７７−２８９」によるAurora/Borealisプロジェクト、の環境で行われた研究に基づく。

【0006】

最新のＤＳＭＳの設計は、それらが設計された特定のアプリケーションに対してそれを良好に機能させるが、リアルタイム解析をサポートするためにそれらを不適切にする。全ての状態変数をカプセル化し、ルール専用に状態変数の記憶を調整することにより、データに対する任意のアドホッククエリを処理することが事実上不可能になる。結果として、最新のＤＳＭＳのいずれも、充分なリアルタイム解析能力を有しない。「複製データ−分配負荷」の原理は、これらのシステムのスケーラビリティを制限する。データレートが単一のマシンの能力を超えて増大する場合、これらのシステムは、もはや負荷に耐えられない。

【0007】

最新のＤＳＭＳのスケーラビリティ問題を克服するために、「Daniel Peng, Frank Dabek: Large−scale Incremental Processing Using Distributed Transactions and Notifications. OSDI ２０１０: ２５１−２６４」によるPercolatorシステムが「Google」社の独自仕様システムとして開発された。Percolatorシステムは、配信されるスケーラブルなストリーム及び複雑なイベント処理のための柔軟なプログラミングの枠組みを提供する。Percolatorにより、アプリケーション開発者は、より良いデータスケーラビリティを達成するために「分配データ−分配負荷」モデルに従うことを選択できる。しかしながら、Percolatorは、ルール及び連続クエリをサポートするために任意の宣言型メカニズムを提供しない。さらに、Percolatorは、リアルタイム解析の任意のサポートを提供しない。大部分のPercolator設計原理に従い、「www.storm−project.net」によるStormシステムが、「Twitter」社によるオープンソースシステムとして開発された。

【0008】

ＤＳＭＳの代替として、論理的には、イベントストリームを処理し及びアドホックリアルタイム解析クエリを実行するために、最新のＤＢＭＳを使用することが可能である。このアプローチでは、各々のイベントは、トランザクションとしてＤＭＢＳにポストされる。アドホッククエリは、次に、同じＤＭＢＳにより実行され得る。「Per−Ake Larson, Mike Zwilling, Kevin Farlee: The Hekaton Memory−Optimized OLTP Engine. IEEE Data Eng. Bull. ３６(２): ３４−４０ (２０１３)」による「Hekaton」のような最新の主メモリデータベースシステムは、単一のマシンで毎秒数十万もの（イベントを挿入するような）単純トランザクションを処理できる。さらに、それらは、幾つかのノードに渡りデータを分配することによりスケール可能である。しかしながら、それらのアドホッククエリのサポートは、このようなハイエンドトランザクション処理システムの内部データ構造がデータイングレスのための多数の小さなトランザクションを処理するために専用に調整されているので、再び限られている。さらに、これらのシステムは、標準的に、幾つかのマシンに格納されるデータを巻き込むクエリのサポートを提供しない。さらに悪いことに、これらのシステムは、ルール及び連続クエリの処理のサポートを全く提供しない。再び、この欠陥は、それらのアーキテクチャに固有であり、「Michael Stonebraker: Technical perspective − One size fits all: an idea whose time has come and gone. Commun. ACM ５１(１２): ７６ (２００８)」により記載されるようなＤＳＭＳの開発の初めの段階で主要な動機であった。良くても、これらのシステムは、特定のイベントが生じるとき発火する、所謂トリガをサポートするが（「] Jennifer Widom, Stefano Ceri: Introduction to Active Database Systems. Active Database Systems: Triggers and Rules For Advanced Database Processing １９９６: １−４１」を参照）、このようなトリガは、複雑なイベント処理アプリケーションのルールの中に標準的に見られる複雑なパターンを検出することができない。

【発明の概要】

【0009】

本発明の目的は、大容量の処理状態を把握できるイベント処理、複雑な宣言型クエリを有するリアルタイム解析、並びに、負荷及びデータベースサイズのスケーラビリティを提供する改善されたイベント処理のための技術を提供することである。

【0010】

この目的は、独立請求項の特徴により達成される。さらに実装形態は、従属請求項、説明及び図面から明らかである。

【0011】

以下に記載されるような本発明は、イベント処理のロジック及び状態と、解析行列（ＡＭ）としての状態の構造化との分離、並びに、リアルタイム解析の目的で分離した状態に対するクエリ処理能力の追加の可能性という、改善したイベント処理システムを提供するための２つのキーポイントがあるという基本観測に基づく。

【0012】

ストリーム処理システムの状態及びロジックは結合されないので、体系的にスケールアウト（scale−out）方法でシステムをスケールすることが可能である。ＡＭの更新がキーにより行うことができ、ＡＭがキーにより区分できるので、スケールアウトは、比較的単純且つ合理化されている。さらに、無状態ロジック及びルールインデックスは、スケールのために複製されても良い。従来のＤＳＭＳは、結果として生じるスケーラビリティを実証できない。同様に、記憶レイヤは、データのサイズ及び／又は負荷要件と別個にスケールできる。

【0013】

（分散型キー値ストアとは反対に）ストリーム処理サブシステムの状態は、主記憶データベースシステムの中に維持される場合、リアルタイム解析の要件を満たす新鮮なデータに対するクエリ処理のために使用できる。いずれの場合にも、リアルタイム解析レイヤは、ストリーム処理レイヤと同様に負荷と共にスケールしても良く、増大する又は減少する負荷を扱うために、ノードは、任意の時点で追加され及び削除されても良い。

【0014】

以下では、特定の専用記憶装置にイベント処理の状態を維持するために、解析行列（Analytics Matrix、ＡＭ）と呼ばれるメカニズムが記載される。具体的には、状態変数が、分散型の主メモリに基づくキー値ストアに格納されても良い。さらに、複雑なイベント処理のためのルール及び連続クエリを扱うために、処理ノードの別個のティアが記載される。さらに、リアルタイム解析のためのアドホッククエリを扱うために、処理ノードの更なる別個のティアが記載される。

【0015】

本発明を詳細に説明するために、以下の用語、略語及び注釈が用いられる。
ＡＭ：解析行列（Analytics Matrix）
ＤＢＭＳ：データベース管理システム（database management system）
ＤＳＭＳ：データストリーム管理システム（data stream management system）
ＳＱＬ：構造化クエリ言語（Structured Query Language）
ＳＥＰ：ストリーム及びイベント処理システム（Stream and Event Processing System）
ＲＴＡ：リアルタイム解析システム（real−time analytics system）
ＡＩＭ：インモーション解析（Analytics in Motion）
ＥＴＬ：抽出、変換、ロード（Extract, Transform, Load）
ＣＲＭ：顧客関係管理（Customer Relationship Management）

【0016】

データベース管理システム（ＤＢＭＳ）は、データをキャプチャし解析するために、ユーザ、他のアプリケーション、及びデータベース自体と相互作用する特別に設計されたアプリケーションである。汎用データベース管理システム（ＤＢＭＳ）は、データベースの定義、生成、クエリ、更新、及び管理を可能にするために設計されたソフトウェアシステムである。異なるＤＢＭＳは、単一のアプリケーションを１より多いデータベースと共に機能させるために、ＳＱＬ及びＯＤＢＣ又はＪＤＢＣのような標準を用いることにより相互運用できる。

【0017】

データストリーム管理システム（ＤＳＭＳ）は、連続データストリームを管理するためのコンピュータプログラムである。ＤＳＭＳは、データベース管理システム（ＤＢＭＳ）と同様であるが、従来のデータベースの中の静的データのために設計されている。ＤＳＭＳは、必要な情報がクエリを用いて表現され得るように、フレキシブルクエリ処理も提供する。しかしながら、ＤＢＭＳと対照的に、ＤＳＭＳは、１回だけ実行されるのではなく恒久的にインストールされる連続クエリを実行する。したがって、クエリは、明示的にアンインストールされるまで、連続的に実行される。大部分のＤＳＭＳはデータ駆動型であるので、連続クエリは、新しいデータがシステムに到着する限り、新しい結果を生成する。この基本概念は、複雑なイベント処理と類似している。したがって、両方の技術は部分的に融合される。

【0018】

イベント処理、イベント計算
イベント処理は、発生する事態（イベント）に関する情報（データ）のストリームを追跡し及び解析し（処理し）、それらから結果を導出する方法である。複雑なイベント処理（Complex event processing）又はＣＥＰは、より複雑な状況を示唆するイベント又はパターンを推測するために、複数のソースからのデータを結合するイベント処理である。複雑なイベント処理の目標は、（好機又は危険な兆候のような）有意義なイベントを識別し、それらに可能な限り迅速に応答することである。

【0019】

ＳＱＬ（構造化クエリ言語、Structured Query Language）は、関係性データベース管理システム（relational database management system、ＲＤＢＭＳ）に保持されるデータを管理するために設計された特定用途プログラミング言語である。
元来、関係代数及びタプル関係演算に基づき、ＳＱＬは、データ定義言語及びデータ操作言語で構成される。ＳＱＬの範囲は、データ挿入、クエリ、更新及び削除、方式生成及び変更、並びにデータアクセス制御を含む。

【0020】

InfiniBandは、高性能コンピューティング及びエンタープライズデータセンタで使用されるスイッチ型ファブリックコンピュータネットワーク通信リンクである。その特徴は、高スループット、短い待ち時間、サービス品質及びフェイルオーバを有し、スケーラブルであるように設計される。InfiniBandアーキテクチャ仕様は、プロセッサノードと記憶装置のような高性能Ｉ／Ｏノードとの間の接続を定める。

【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】

本発明の更なる実施形態は、以下の図面に関して説明される。

【図1】一実装形式によるイベント処理システム１００を示すブロック図を示す。

【図2】一実装形式によるイベント処理の方法２００を示すブロック図を示す。

【発明を実施するための形態】

【0057】

以下の詳細な説明では、その一部を形成する添付の図面が参照される。添付の図面は本開示が実施され得る説明のための特定の態様として示される。他の態様が利用されてもよく、構造的又は論理的変化が本開示の範囲から逸脱することなく行われても良いことが理解される。したがって、以下の詳細な説明は限定的意味と考えられるのではなく、本開示の範囲は添付の特許請求の範囲によって定められる。

【0058】

本願明細書に記載の装置及び方法は、イベント計算ノード及びイベント状態ストアに基づいても良い。記載の方法に関連して付されるコメントは、方法を実行するよう構成される対応する装置又はシステムについてもまた真であり、逆も同様であることが理解される。例えば、特定の方法ステップが記載される場合、対応する装置は、記載の方法ステップを実行するユニットを、このようなユニットが明示的に記載され又は図に示されない場合でも、有しても良い。さらに、特に断りのない限り、本願明細書に記載の種々の例示的な態様の特徴は、互いに結合されても良いことが理解される。

【0059】

本願明細書に記載の方法及び装置は、データベース管理システム、特にＳＱＬを用いるＤＢＭＳに、実装されても良い。記載の装置及びシステムは、集積回路及び／又は受動素子を含んでも良く、種々の技術に従い製造されても良い。例えば、回路は、論理集積回路、アナログ集積回路、根号信号集積回路、光回路、メモリ回路、及び／又は集積受動素子、として設計されても良い。

【0060】

図１は、一実装形式によるイベント処理システム１００を示すブロック図を示す。イベント処理システム１００は、データベースシステムで動作するストリーム１０１のストリームを処理しても良い。イベント処理システム１００は、イベント負荷平衡ユニット１０３と、複数のイベント計算ノード１０５ａ、１０５ｂ、１０５ｃと、イベント計算ノード１０５ａ、１０５ｂ、１０５ｃと別個の複数のイベント状態ストア１０９ａ、１０９ｂ、１０９ｃと、を有しても良い。イベント負荷平衡ユニット１０３は、イベント負荷平衡基準に従って、イベント１０１のストリームを、複数のイベント計算ノード１０５ａ、１０５ｂ、１０５ｃへルーティングしても良い。複数のイベント状態ストア１０９ａ、１０９ｂ、１０９ｃは、イベント処理の状態を維持するために、複数のイベント計算ノード１０５ａ、１０５ｂ、１０５ｃの状態を格納しても良い。複数のイベント計算ノード１０５ａ、１０５ｂ、１０５ｃは、イベント負荷平衡ユニット１０３から受信したイベント１０１を処理し、イベントの処理に従いそれらの状態を変更し、及びそれらの変化した状態に基づき、複数のイベント状態ストア１０９ａ、１０９ｂ、１０９ｃを更新しても良い。

【0061】

イベント処理システム１００は、クエリ負荷平衡ユニット１１５と、複数のクエリ処理ノード１１３ａ、１１３ｂ、１１３ｃと、を更に有しても良い。クエリ負荷平衡ユニット１１５は、クエリ負荷平衡基準に従って、クエリ１１７のストリームを、複数のクエリ処理ノード１１３ａ、１１３ｂ、１１３ｃへルーティングしても良い。複数のクエリ処理ノード１１３ａ、１１３ｂ、１１３ｃは、クエリ負荷平衡ユニット１１５から受信したクエリ１１７を処理しても良い。

【0062】

一例では、クエリ負荷平衡ユニット１１５は、各々のクエリ１１７を、正確に１つのクエリ処理ノード１１３ａ、１１３ｂ、１１３ｃへ転送しても良い。一例では、クエリ処理ノード１１３ａ、１１３ｂ、１１３ｃは、クエリ負荷平衡ユニット１１５から受信したクエリ１１７を処理するために、複数のイベント状態ストア１０９ａ、１０９ｂ、１０９ｃのうちの少なくとも１つのイベント状態ストアにアクセスしても良い。一例では、クエリ処理ノード１１３ａ、１１３ｂ、１１３ｃは、クエリ１１７を処理するために、更なるデータ、特にデータベースシステムの顧客マスタデータにアクセスしても良い。一例では、複数のクエリ処理ノード１１３ａ、１１３ｂ、１１３ｃは、リアルタイム解析のためにアドホッククエリを扱っても良い。一例では、複数のイベント状態ストア１０９ａ、１０９ｂ、１０９ｃは、分散型の主メモリに基づくキー値ストアを有しても良い。一例では、複数のイベント計算ノード１０５ａ、１０５ｂ、１０５ｃは、リアルタイムで同時のイベント処理と一緒の複雑なイベント処理のために、ルール及び連続クエリを扱っても良い。一例では、イベント負荷平衡ユニット１０３は、特に顧客キーに基づくアプリケーションの定める区分と、ルール複製と、に基づき、イベント１０１をルーティングしても良い。一例では、イベント負荷平衡ユニット１０３は、複数のイベント計算ノード１０５ａ、１０５ｂ、１０５ｃのうちの１つのイベント計算ノードが、イベント１０１の特定の部分集合を扱い、イベント１０１の特定の部分集合について全てのルールを処理できるように、イベント１０１をルーティングしても良い。一例では、イベント負荷平衡ユニット１０３は、全てのイベント計算ノード１０５ａ、１０５ｂ、１０５ｃが全てのイベント１０１及びルールの部分集合を扱えるように、イベント複製及びルール区分に基づき、イベント１０１をルーティングしても良い。一例では、イベント負荷平衡ユニット１０３は、複数のイベント計算ノード１０５ａ、１０５ｂ、１０５ｃのうちの１つのイベント計算ノードが空き容量を有するときイベント１０１を扱えるように、イベント１０１のラウンドロビン区分及びルールの複製に基づき、イベント１０１をルーティングしても良い。一例では、イベント負荷平衡ユニット１０３は、イベント１０１の区分及び複製とルールとに基づき、複数のイベント計算ノード１０５ａ、１０５ｂ、１０５ｃを通じて、イベント１０１をルーティングしても良い。

【0063】

図１は、全体アーキテクチャを示す。イベント計算ノード１０５ａ、１０５ｂ、１０５ｃを含む上部ティアは、複雑なイベント計算に専用であっても良い。以後、イベント負荷平衡ユニット１０３として表記される負荷バランサは、イベント１０１のストリームを入力として取り入れ、以後、イベント計算ノード１０５ａ、１０５ｂ、１０５ｃとして表記される処理ノードへイベント１０１をルーティングしても良い。このレイヤにおける処理ノード１０５ａ、１０５ｂ、１０５ｃは、複雑なイベント処理のためのルールを処理しても良く、状態変数の新しい状態を計算しても良い。それらは、中間ティアユニット１０７ａ、１０７ｂ、１０７ｃに格納されたＡＭ（解析行列、analytics matrix）を更新しても良い。以後、クエリ処理ノード１１３ａ、１１３ｂ、１１３ｃとして表記される下部ティアは、リアルタイム解析のためにアドホッククエリを処理するために専用であっても良い。再び、以後、クエリ負荷平衡ユニット１１５として表記される、アドホッククエリ１１７のストリームを入力として取り入れても良く、このティアにおいて正確に１つの処理ノード１１３ａ、１１３ｂ、１１３ｃへアドホッククエリ１１７を転送しても良い負荷バランサがある。この処理ノード１１３ａ、１１３ｂ、１１３ｃは、次に、このクエリ１１７を処理しても良く、それにより、ＡＭ１０９ａ、１０９ｂ、１０９ｃに、場合によっては他の次元のデータ、例えば顧客マスタデータにアクセスする。一実装形式では、高性能のために、空間的、分散型クエリ処理技術が、ＡＭ１０９ａ、１０９ｂ、１０９ｃにおけるアドホッククエリの実行のために使用されても良い。

【0064】

ストリーム処理における負荷平衡の４つの異なる変形が実装されても良い。第１の変形では、アプリケーションの定める（例えば顧客キーによる）イベントの区分及びルールの複製が適用されても良い。つまり、ストリーム処理レイヤの処理ノードは、全てのイベントのうちの特定の部分集合を扱っても良く、イベントのこの集合について全てのルールを処理しても良い。第２の変形では、イベント複製及びルールの区分が適用されても良い。つまり、ストリーム処理レイヤの全ての処理ノードは、ルールの部分集合だけでなく、全てのイベントを扱うことができる。第３の変形では、イベントのラウンドロビン区分及びルールの複製が適用されても良い。つまり、ストリーム処理レイヤの処理ノードは、空き容量を有するときはいつでも、イベントを扱うことができる。第４の変形では、ハイブリッドソリューション、つまり、処理レイヤに渡るイベント及びルールの区分及び複製が適用されても良い。

【0065】

どの変形が最良かは、アプリケーション負荷の特性に依存する。第１及び第２の変形、並びに第４の変形の特定の場合には、状態変数は、より高い性能のために処理ノードによりキャッシュされても良い。第３の変形では、処理ノードは、各々のイベントについて、記憶レイヤから必要な状態変数を読み取っても良い。

【0066】

実験は、最新のハードウェア、例えばInfiniBandネットワークにおいて、第３の変形が非常に良好に実行できることを示した。ＡＭの正確な記憶レイアウトは、ストリーム処理における負荷平衡のために選択したオプションに依存しても良い。第１の変形では、状態変数は、顧客キーにより区分されても良く、対応するノードに格納されても良い。一方で、第２及び第３の変形では、それらは、それらを使用し得るルールと同じノードに格納されても良い。

【0067】

分散した状態変数の高性能な読み取り及び更新を達成するために、主メモリハッシング技術、例えば、「Ion Stoica, Robert Morris, David Liben−Nowell, David R. Karger, M. Frans Kaashoek, Frank Dabek, Hari Balakrishnan: Chord: a scalable peer−to−peer lookup protocol for internet applications. IEEE/ACM Trans .Netw. １１(１): １７−３２ (２００３)」及び「Antony I. T. Rowstron, Peter Druschel: Pastry: Scalable, Decentralized Object Location, and Routing for Large−Scale Peer−to−Peer Systems. Middleware ２００１: ３２９−３５０」に記載のChord and Pastryシステムにおいて提案されたようなプロトコルが使用されても良い。代替で、任意の他の主メモリデータベースシステムが使用されても良い（例えば、MicrosoftのHekaton、OracleのTimes Ten、又はSAPのHana products）。さらに、InfiniBandのような最新の短待ち時間ネットワーキング技術が使用されても良い。

【0068】

新しいクエリ処理技術は、このような分散型の主メモリ記憶システムの上位におけるアドホック、リアルタイム解析クエリを処理するために適用されても良い。ストリーム処理レイヤの処理ノードにおけるイベントの効率的な処理のために、特別なルール編集技術が適用されても良い。これらの技術は、各々の状態変数の特定のセマンティクスを考慮しても良い。例えば、幾つかの状態変数は、完全に付加的に処理されても良く、他のものは、何らかの変化履歴を追跡し続ける必要があっても良い。コンパイラは、各々の種類の状態変数を利用しても良く、それにより空間及び時間の両方を最小化する。

【0069】

イベント処理システム１００は、TelcoオペレータのＣＲＭシステムの部分であっても良いリアルタイム決定サブシステム決定システムを構成しても良い。サブシステムは、請求システムからの並列供給及びＣＲＭシステムのユーザにより提出される幾つかの異なるクエリの混合負荷を維持しても良い。サブシステムは、２つの部分に分割されても良い。第１に、ビジネスルールの高速評価に合わせられた形式でイベントを処理し格納できるストリーム及びイベント処理システム（Stream and Event Processing System、ＳＥＰ）である。第２に、より複雑な解析クエリを評価できるリアルタイム解析システム（real−time analytics system：ＲＴＡ）が使用されても良い。

【0070】

本開示で提示される新規なアプローチは、「インモーション解析（Analytics in Motion、ＡＩＭ）」とも称され、ＲＴＡがＥＴＬ（Extract, Transform, Load、抽出、変換、ロード）工程によってＳＥＰにより供給され得る伝統的なデータウェアハウジング技術に従わず、ＲＴＡにＳＥＰの記憶へ直接アクセスさせても良く、それにより解析クエリにリアルタイムに応答可能にできる。

【0071】

ＳＥＰにより処理されるルールは、どの種類の製品情報が特定の述語にしたがって顧客に宣伝され得るかを決定するのを支援できる。この種のクエリの状態は、高い選択性であっても良く、集約が頻繁にあっても良い。次に、ＲＴＡクエリが説明される。例えば、サブシステムは、マーケティング担当者が販促運動を設計し判定するのを助けるよう、顧客をグループにセグメント化するためにクエリをサポートしても良い。完全なテーブルスキャン、集約、及び祭りテーブルジョインは頻繁にあっても良い。

【0072】

図２は、一実装形式によるイベント処理の方法２００を示すブロック図を示す。方法２００は、イベント負荷平衡基準に従って、イベント１０１のストリームを、複数のイベント計算ノード１０５ａ、１０５ｂ、１０５ｃへルーティングするステップ２０１を含んでも良い（図１を参照）。方法２００は、イベント処理の状態を維持する、イベント計算ノード１０５ａ、１０５ｂ、１０５ｃと別個の複数のイベント状態ストア１０９ａ、１０９ｂ、１０９ｃに、複数のイベント計算ノード１０５ａ、１０５ｂ、１０５ｃの状態を格納するステップ２０２を含んでも良い。方法２００は、複数のイベント計算ノード１０５ａ、１０５ｂ、１０５ｃにおいて、受信したイベント１０１を処理し、イベント１０１の処理に従って複数のイベント計算ノード１０５ａ、１０５ｂ、１０５ｃの状態を変化し、及び複数のイベント状態ストア１０９ａ、１０９ｂ、１０９ｃの中の複数のイベント計算ノード１０５ａ、１０５ｂ、１０５ｃの状態を更新するステップ２０３を含んでも良い。

【0073】

本願明細書に記載の方法、システム及び装置は、デジタル信号プロセッサ（ＤＳＰ）内の、マイクロコントローラ内の、又は任意の他のサイドプロセッサ内のソフトウェアとして、又は特定用途向け集積回路（ＡＳＩＣ）内のハードウェア回路として、実装できる。

【0074】

本発明は、デジタル電子回路で、又はコンピュータハードウェア、ファームウェア、ソフトウェアで、又はそれらの組合せで、例えば従来のモバイル装置の市販のハードウェアで、又は本願明細書に記載の方法を処理するために専用の新しいハードウェアで、実施することができる。

【0075】

本開示は、実行されると少なくとも１つのコンピュータに本願明細書に記載のステップ、特に図２に関して上述したような方法２００、及び図１に関して上述した技術、を実行及び計算ステップを実行させるコンピュータ実行可能コード又はコンピュータ実行可能命令を含むコンピュータプログラム製品もサポートする。このようなコンピュータプログラムプロダクトは、コンピュータによる使用のためにプログラムコードを格納する可読記憶媒体を含み得る。該プログラムコードは、イベント負荷平衡基準に従いイベントのストリームを複数のイベント計算ノードにルーティングする命令と、複数のイベント計算ノードの状態を、イベント計算ノードと別個の複数のイベント状態ストアに格納する命令と、複数のイベント計算ノードにおいて受信したイベントを処理し、イベントの処理に従って複数のイベント計算ノードの状態を変化し、及び複数のイベント状態ストアの中の複数のイベント計算ノードの状態を更新する命令と、を有しても良い。

【0076】

本開示の特定の特徴又は態様が幾つかの実装のうちの１つのみに関して開示される場合があるが、このような特徴又は態様は、任意の所与の又は特定の用途のために望ましく有利な場合には、他の実装の１又は複数の他の特徴又は態様と組み合わせられても良い。さらに、用語「含む（include）」、「有する（have）」、「伴う（with）」、又はこれらの他の変形が詳細な説明又は請求項において使用される限り、このような用語は、用語「有する（comprise）」と同様に包含を意図する。また、用語「例示的な（exemplary）」、「例えば（forexample）」、及び「例えば（e.g.）」は、最良の又は最適なではなく、単に、例として意味される。

【0077】

本願明細書では特定の態様が図示され説明されたが、本開示の範囲から逸脱することなく広範な代替の及び／又は等価な実施が示され説明された特定の態様の代用になりうることが当業者に理解されるだろう。本願は、本願明細書で議論された特定の態様の如何なる適応又は変形も包含することを意図している。

【0078】

以下の請求の範囲の中の要素は対応する符号と共に特定の順序に列挙されるが、請求項の記載が特にこれらの要素の一部又は全部を実施するための特定の順序を示さない限り、これらの要素は、必ずしも、該特定の順序で実施されることに限定されることを意図しない。

【0079】

多くの代替、変更及び変形が、上述の教示を踏まえて当業者に明らかであろう。勿論、当業者は、本願明細書の記載以外に本発明の多数の適用が存在することを直ちに理解する。本発明は１又は複数の特定の実施形態を参照して説明されたが、当業者は、本発明の範囲から逸脱することなく、それらに多くの変更が行われ得ることを理解する。したがって、添付の特許請求の範囲及びそれらの等価物の範囲内で、或いは特に本願明細書に記載されたもの以外で、本発明が実施されても良い。

【図1】

【図2】