特表 2024-521886 マルチテナントシステムのための、ソースに適応したデータ取出し

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-06-04

(54)【発明の名称】マルチテナントシステムのための、ソースに適応したデータ取出し

(51)【国際特許分類】

   G06Q 10/02 20120101AFI20240528BHJP

【ＦＩ】

G06Q10/02

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023574245

(86)(22)【出願日】2022-05-23

(85)【翻訳文提出日】2024-01-17

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

(87)【国際公開番号】W WO2022253607

(87)【国際公開日】2022-12-08

(31)【優先権主張番号】17/335,616

(32)【優先日】2021-06-01

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

(71)【出願人】

【識別番号】509228994

【氏名又は名称】アマデウス エス．アー．エス．

【氏名又は名称原語表記】ＡＭＡＤＥＵＳ Ｓ．Ａ．Ｓ．

【住所又は居所原語表記】４８５ Ｒｏｕｔｅ ｄｕ Ｐｉｎ Ｍｏｎｔａｒｄ，Ｓｏｐｈｉａ Ａｎｔｉｐｏｌｉｓ，Ｆ－０６４１０ Ｂｉｏｔ，Ｆｒａｎｃｅ

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】ラドゥ－コンスタンタン・ステファネスク

(72)【発明者】

【氏名】ジェフリー・ペ・デュケット

(72)【発明者】

【氏名】ミカエル・ケニー

(72)【発明者】

【氏名】アダム・エドゥアール・ビュンジェール

【テーマコード（参考）】

5L010

【Ｆターム（参考）】

5L010AA03

(57)【要約】

方法は、統合コンピューティングデバイスにおいて、レコード識別子を有する複数のソースデータレコードを維持したソースコンピューティングデバイスに対応するスケジューリングパラメータを維持することと、ソースコンピューティングデバイスから複数の修正指示子を受信することであって、各修正指示子が、ソースコンピューティングデバイスにおいてソースデータレコードの修正に応答して生成され、そのソースデータレコードのレコード識別子を含む、受信することと、複数の修正指示子をリポジトリ内に記憶することと、スケジューリングパラメータに従って、ソースコンピューティングデバイスから複数のソースデータレコードのサブセットを定期的に取得することであって、リポジトリから複数の修正指示子を取り出すこと、取り出した複数の修正指示子からの複数のレコード識別子を含むバルクレコード要求を生成すること、バルクレコード要求をソースコンピューティングデバイスに送信すること、およびバルクレコード要求の送信に応答して、ソースコンピューティングデバイスから複数のソースデータレコードのサブセットを受信することによって行われる、取得することとを含む。

【特許請求の範囲】

【請求項1】

統合コンピューティングデバイスにおいて、それぞれのレコード識別子を有する複数のソースデータレコードを維持したソースコンピューティングデバイスに対応するスケジューリングパラメータを維持するステップと、
前記統合コンピューティングデバイスにおいて、前記ソースコンピューティングデバイスから複数の修正指示子を受信するステップであって、各修正指示子が、前記ソースコンピューティングデバイスにおいてソースデータレコードの修正に応答して生成され、前記ソースデータレコードの前記レコード識別子を含む、ステップと、
前記複数の修正指示子をリポジトリ内に記憶するステップと、
前記スケジューリングパラメータに従って、前記ソースコンピューティングデバイスから前記複数のソースデータレコードのサブセットを定期的に取得するステップであって、
前記リポジトリから前記複数の修正指示子を取り出すステップ、
前記取り出した複数の修正指示子からの前記複数のレコード識別子を含むバルクレコード要求を生成するステップ、
前記バルクレコード要求を前記ソースコンピューティングデバイスに送信するステップ、および
前記バルクレコード要求の送信に応答して、前記ソースコンピューティングデバイスから複数のソースデータレコードの前記サブセットを受信するステップ
によって行われる、ステップと
を含む、方法。

【請求項2】

複数のソースデータレコードの前記サブセットを受信した後で、複数のソースデータレコードの前記サブセットを中央ソースデータリポジトリ内に記憶するステップ
をさらに含む、請求項1に記載の方法。

【請求項3】

複数のソースデータレコードの前記サブセットを受信した後で、複数のソースデータレコードの前記サブセットを、さらなる処理のためにマルチテナントサブシステムに公開するステップ
をさらに含む、請求項1に記載の方法。

【請求項4】

前記複数の修正指示子を取り出した後で、前記リポジトリから前記複数の修正指示子を取り除くステップ
をさらに含む、請求項1に記載の方法。

【請求項5】

ソースデータレコードのそれぞれに対応するセットをそれぞれが維持した複数のソースコンピューティングデバイスのそれぞれについて、別個のスケジューリングパラメータを維持するステップと、
各ソースコンピューティングデバイスから複数の修正指示子を受信し、各修正指示子を前記リポジトリ内に、前記対応するソースコンピューティングデバイスの識別子と関連付けて記憶するステップと
をさらに含む、請求項1に記載の方法。

【請求項6】

前記複数の修正指示子が、それぞれのソースデバイス識別子を含む、請求項5に記載の方法。

【請求項7】

前記複数のソースコンピューティングデバイスのそれぞれについての前記取得するステップ、前記取り出すステップ、前記生成するステップ、および前記送信するステップを、前記それぞれのスケジューリングパラメータに従って反復するステップ
をさらに含む、請求項5に記載の方法。

【請求項8】

前記スケジューリングパラメータが要求頻度を含み、前記方法が、前記統合コンピューティングデバイスにおいて、
前記バルクレコード要求の送出に応答して、前記要求に対応するタイムスタンプを記憶するステップ
をさらに含む、請求項1に記載の方法。

【請求項9】

前記バルクレコード要求を生成するステップが、前記取り出した複数の修正指示子からの重複レコード識別子を検出し、取り除くステップを含む、請求項1に記載の方法。

【請求項10】

それぞれのレコード識別子を有する複数のソースデータレコードを維持したソースコンピューティングデバイスに対応するスケジューリングパラメータを記憶するメモリと、
通信インターフェースと、
前記メモリおよび前記通信インターフェースと結合されたプロセッサであって、
前記通信インターフェースを介して前記ソースコンピューティングデバイスから複数の修正指示子を受信することであって、各修正指示子が、前記ソースコンピューティングデバイスにおいてソースデータレコードの修正に応答して生成され、前記ソースデータレコードの前記レコード識別子を含む、受信すること、
前記複数の修正指示子を前記メモリのリポジトリ内に記憶すること、
前記スケジューリングパラメータに従って、前記ソースコンピューティングデバイスから前記複数のソースデータレコードのサブセットを定期的に取得することであって、前記プロセッサが、前記サブセットを定期的に取得するために、
前記リポジトリから前記複数の修正指示子を取り出すこと、
前記取り出した複数の修正指示子からの前記複数のレコード識別子を含むバルクレコード要求を生成すること、
前記バルクレコード要求を前記ソースコンピューティングデバイスに送信すること、および
前記バルクレコード要求の送信に応答して、前記ソースコンピューティングデバイスから複数のソースデータレコードの前記サブセットを受信すること
を行うように構成される、取得すること
を行うように構成された、プロセッサと
を備える、コンピューティングデバイス。

【請求項11】

前記プロセッサが、
複数のソースデータレコードの前記サブセットを受信した後で、複数のソースデータレコードの前記サブセットを中央ソースデータリポジトリ内に記憶すること
を行うようにさらに構成される、請求項10に記載のコンピューティングデバイス。

【請求項12】

前記プロセッサが、
複数のソースデータレコードの前記サブセットを受信した後で、複数のソースデータレコードの前記サブセットを、さらなる処理のためにマルチテナントサブシステムに公開すること
を行うようにさらに構成される、請求項10に記載のコンピューティングデバイス。

【請求項13】

前記プロセッサが、
前記複数の修正指示子を取り出した後で、前記リポジトリから前記複数の修正指示子を取り除くこと
を行うようにさらに構成される、請求項10に記載のコンピューティングデバイス。

【請求項14】

前記プロセッサが、
ソースデータレコードのそれぞれに対応するセットをそれぞれが維持した複数のソースコンピューティングデバイスのそれぞれについて、別個のスケジューリングパラメータを維持すること、および
各ソースコンピューティングデバイスから複数の修正指示子を受信し、各修正指示子を前記リポジトリ内に、前記対応するソースコンピューティングデバイスの識別子と関連付けて記憶すること
を行うようにさらに構成される、請求項10に記載のコンピューティングデバイス。

【請求項15】

前記複数の修正指示子が、それぞれのソースデバイス識別子を含む、請求項14に記載のコンピューティングデバイス。

【請求項16】

前記プロセッサが、
前記複数のソースコンピューティングデバイスのそれぞれについての前記取得すること、前記取り出すこと、前記生成すること、および前記送信することを、前記それぞれのスケジューリングパラメータに従って反復すること
を行うようにさらに構成される、請求項14に記載のコンピューティングデバイス。

【請求項17】

前記スケジューリングパラメータが要求頻度を含み、前記プロセッサが、
前記バルクレコード要求の送出に応答して、前記要求に対応するタイムスタンプを記憶すること
を行うようにさらに構成される、請求項10に記載のコンピューティングデバイス。

【請求項18】

前記プロセッサが、
前記バルクレコード要求を生成するために、前記取り出した複数の修正指示子からの重複レコード識別子を検出し、取り除くこと
を行うようにさらに構成される、請求項10に記載のコンピューティングデバイス。

【請求項19】

統合コンピューティングデバイスのプロセッサによって実行可能な命令を記憶した非一時的コンピュータ可読媒体であって、前記命令が、
それぞれのレコード識別子を有する複数のソースデータレコードを維持したソースコンピューティングデバイスに対応するスケジューリングパラメータを維持することと、
前記ソースコンピューティングデバイスから複数の修正指示子を受信することであって、各修正指示子が、前記ソースコンピューティングデバイスにおいてソースデータレコードの修正に応答して生成され、前記ソースデータレコードのレコード識別子を含む、受信することと、
前記複数の修正指示子をリポジトリ内に記憶することと、
前記スケジューリングパラメータに従って、前記ソースコンピューティングデバイスから前記複数のソースデータレコードのサブセットを定期的に取得することであって、
前記リポジトリから前記複数の修正指示子を取り出すこと、
前記取り出した複数の修正指示子からの複数のレコード識別子を含むバルクレコード要求を生成すること、
前記バルクレコード要求を前記ソースコンピューティングデバイスに送信すること、および
前記バルクレコード要求の送信に応答して、前記ソースコンピューティングデバイスから複数のソースデータレコードの前記サブセットを受信すること
によって行われる、取得することと
を行うためのものである、非一時的コンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本明細書は一般に、データ処理システムに関し、具体的には、マルチテナントデータ処理システムのための、ソースに適応したデータ取出し機構に関する。

【背景技術】

【0002】

データ処理システムは、クラウドベースのアプリケーションとして実装することができる。例えば、アプリケーションプロバイダは、所与のクラウドベースのアプリケーションのそれぞれのデプロイメントを、そのクラウドベースのアプリケーションのいくつかのオペレータのそれぞれについて実装することができる。換言すれば、各デプロイメントは、対応するオペレータのデータのみを収容したシングルテナントシステムとして構成される。クラウドベースのアプリケーションの各デプロイメントには、他のデプロイメントからの別個の計算リソース(例えば処理ハードウェア)を割り当てることもでき、またクラウドベースのアプリケーションの各デプロイメントは、性能要件および使用パターンが全く異なることがある。

【0003】

上記の構成は、所与のオペレータに合わせて比較的容易にスケーリングすることができるが、複数の別個のデプロイメントからのデータ(すなわち複数のオペレータに対応するデータ)の入手を利用するアプリケーションおよび/またはデータストレージの実装は、基礎をなすオペレータ固有のデプロイメントの性能に悪影響を及ぼすことがあり、かつ/または規模が大きくコストのかかるマイグレーションアクティビティを必要とすることがある。

【発明の概要】

【課題を解決するための手段】

【0004】

本明細書の一態様は、統合コンピューティングデバイスにおいて、それぞれに対応するレコード識別子を有する複数のソースデータレコードを維持したソースコンピューティングデバイスに対応するスケジューリングパラメータを維持するステップと、統合コンピューティングデバイスにおいて、ソースコンピューティングデバイスから複数の修正指示子を受信するステップであって、各修正指示子が、ソースコンピューティングデバイスにおいてソースデータレコードの修正に応答して生成され、そのソースデータレコードのレコード識別子を含む、ステップと、複数の修正指示子をリポジトリ内に記憶するステップと、スケジューリングパラメータに従って、ソースコンピューティングデバイスから複数のソースデータレコードのサブセットを定期的に取得するステップであって、リポジトリから修正指示子を取り出すステップ、取り出した複数の修正指示子からの複数のレコード識別子を含むバルクレコード要求を生成するステップ、バルクレコード要求をソースコンピューティングデバイスに送信するステップ、およびバルクレコード要求の送信に応答して、ソースコンピューティングデバイスから複数のソースデータレコードのサブセットを受信するステップによって行われる、ステップとを含む、方法を提供する。

【0005】

本明細書の別の態様は、それぞれに対応するレコード識別子を有する複数のソースデータレコードを維持したソースコンピューティングデバイスに対応するスケジューリングパラメータを記憶するメモリと、通信インターフェースと、メモリおよび通信インターフェースと結合されたプロセッサであって、通信インターフェースを介してソースコンピューティングデバイスから複数の修正指示子を受信することであって、各修正指示子が、ソースコンピューティングデバイスにおいてソースデータレコードの修正に応答して生成され、そのソースデータレコードのレコード識別子を含む、受信すること、複数の修正指示子をメモリのリポジトリ内に記憶すること、スケジューリングパラメータに従って、ソースコンピューティングデバイスから複数のソースデータレコードのサブセットを定期的に取得することであって、プロセッサが、サブセットを定期的に取得するために、リポジトリから複数の修正指示子を取り出すこと、取り出した複数の修正指示子からの複数のレコード識別子を含むバルクレコード要求を生成すること、バルクレコード要求をソースコンピューティングデバイスに送信すること、およびバルクレコード要求の送信に応答して、ソースコンピューティングデバイスから複数のソースデータレコードのサブセットを受信することを行うように構成される、取得することを行うように構成された、プロセッサとを備える、コンピューティングデバイスを提供する。

【0006】

本明細書のさらなる一態様は、統合コンピューティングデバイスのプロセッサによって実行可能な命令を記憶した非一時的コンピュータ可読媒体であって、命令が、それぞれに対応するレコード識別子を有する複数のソースデータレコードを維持したソースコンピューティングデバイスに対応するスケジューリングパラメータを維持することと、ソースコンピューティングデバイスから複数の修正指示子を受信することであって、各修正指示子が、ソースコンピューティングデバイスにおいてソースデータレコードの修正に応答して生成され、そのソースデータレコードのレコード識別子を含む、受信することと、複数の修正指示子をリポジトリ内に記憶することと、スケジューリングパラメータに従って、ソースコンピューティングデバイスから複数のソースデータレコードのサブセットを定期的に取得することであって、リポジトリから複数の修正指示子を取り出すこと、取り出した複数の修正指示子からの複数のレコード識別子を含むバルクレコード要求を生成すること、バルクレコード要求をソースコンピューティングデバイスに送信すること、およびバルクレコード要求の送信に応答して、ソースコンピューティングデバイスから複数のソースデータレコードのサブセットを受信することによって行われる、取得することとを行うためのものである、非一時的コンピュータ可読媒体を提供する。

【0007】

実施形態については、添付の図を参照して説明する。

【図面の簡単な説明】

【0008】

【図1】ソースに適応したデータ取出しのためのシステムの図である。

【図2A】図1の統合サブシステムのいくつかの内部コンポーネントの図である。

【図2B】図1のソースサブシステムのいくつかの内部コンポーネントの図である。

【図3】ソースに適応したデータ取出しの方法のフローチャートである。

【図4】図3の方法のブロック305および310の例示的な実施を示す図である。

【図5】図3の方法のブロック305および310のさらなる例示的な実施の様子を示す図である。

【図6】図5の方法のブロック335の例示的な１つの実施の様子を示す図である。

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

【0009】

図1は、ソースに適応したマルチテナントデータ取出しのためのシステム100を示す。システム100は、複数のソースサブシステム104を含み、そのうち3つの例104-1、104-2、および104-3が示されている。明らかとなるように、システム100の他の実装形態では、より少数の、またはより多数のソースサブシステム104を含めることができる。ソースサブシステム104は、ソースコンピューティングデバイス104または単にソース104と呼ばれることもある。各ソース104は、単一のコンピューティングデバイス上に実装することもでき、あるいはソース104を実装するように論理的に組み合わせた複数のコンピューティングデバイスを用いて分散して実装することもできる。

【0010】

各ソース104は、例えばデータベース108または他の適切なレコード記憶機構内の、複数のソースデータレコードを含む(したがって、3つの例示的なデータベース108-1、108-2、および108-3が図1に示されている)。ソースデータレコード内に含まれるデータは、大いに異なることがあり、本明細書において詳細に説明する機能に特に関連しない。例えば、ソースデータレコードは、ネットワーク通信の送達を制御するための経路指定テーブルを定めることがある。別の例では、ソースデータレコードは、ホテル予約を表すデータ、または他の製品もしくはサービスの購入を表すデータを定めることがある。

【0011】

一般に、各ソース104は、他のソース104とは別に制御される。例えば、各ソース104は、(データベース108内のソースデータレコードの性質に応じて)別個のホテルオペレータ、航空会社など、異なるエンティティによって運用することができる。したがって、各データベース108のコンテンツは一般に、他のいかなるデータベース108ともオーバーラップせず、データベース108間でのデータの交換は限定されるかまたは存在しない。換言すれば、ソース104はシングルテナントサブシステムである。

【0012】

しかし、それぞれのデータベース108内のソースデータレコードはそれにもかかわらず、互いに同じタイプのデータを含むことがある。例えば、各データベース108が、ホテル予約を定めるソースデータレコードを含むことがある。いくつかの例では、各ソース104(および対応するデータベース108)が、ホテル予約アプリケーションなど、クラウドベースのアプリケーションの別個の実装であることがある(が、上で言及したように、多種多様な他のデータタイプがやはりソース104によって取り扱われてよく、データベース108内の特定のタイプのデータは、本明細書において説明する機能に影響を及ぼさない)。上記のクラウドベースのアプリケーションは、例えば、ソース104のそれぞれの代わりに情報技術(IT)サービスプロバイダなどのエンティティによってデプロイすることができる。

【0013】

上述したクラウドベースのデプロイメントでは、所与のソース104に合わせて、例えば追加のハードウェアをそのソースに割り振ること、および/または当該のデータベース108に関連する、クラウドベースのアプリケーションの追加のインスタンスの実行を開始することによって、比較的簡単にスケーリングすることができるが、ITサービスプロバイダによるソースデータレコードの中央処理が複雑になる。ソース104は、例えば完全に一致したデータフォーマットおよび通信プロトコルを有していないことがある。さらに、例えば図1に示していない他のエンティティによって各ソース104に課される計算負荷が、ソース104間で大いに異なることがある。したがって、集中化されたマルチテナントサブシステム112内で処理するために、および/またはマルチテナントリポジトリ116内に記憶するために、各ソース104からデータを取り出そうと試みるプロセスは、データを取得しフォーマット化する上での困難に直面することがあり、またソース104に必要以上の負荷を課すこともあり、その必要以上の負荷により、ソース104の動作が途絶することがある。

【0014】

データベース108からのソースデータの少なくともいくつかの部分を利用する追加のクラウドベースのアプリケーションなどを実装する目的で、ITサービスプロバイダによって、分析レポートを生成するために、マルチテナント処理が用いられることがある。例として、図1に示す例では、マルチテナントサブシステム112は、例えばITサービスプロバイダがハードウェアデプロイメントなどを最適化する際に使用するための、データベース108内のソースデータから得られる分析データを生成するように、構成することができる。いくつかの例では、データベース108からのソースデータをマルチテナントリポジトリ116内に収集して、サブシステム112による、またはソース104を運用するエンティティが使用するためにITサービスプロバイダによってデプロイされる追加のクラウドベースのアプリケーションによる、そのようなデータの入手を可能にすることができる。

【0015】

リポジトリ116がソース104のマルチテナント表現を含むように、リポジトリ116をソース104から収集されたデータで埋められるようにするために、システム100は、システム100の残りのコンポーネントにネットワーク124(例えばローカルネットワークと広域ネットワークとの適切な組合せ)を介して接続された、統合サブシステム120(統合器120とも呼ばれる)を含む。

【0016】

統合サブシステム120は、下でより詳細に論じるように、ソースデータレコードの修正の検出物(detection)を収集するように構成される。統合サブシステム120は、そのような検出物に基づいて、各ソース104の性能にソースデータ要求が及ぼす悪影響を軽減するように調整することのできるソース固有のスケジューリングパラメータに従って、ソース104にソースデータレコードを要求するように、さらに構成される。ソースデータレコードを取り出すと、次いで統合サブシステム120は、ソースデータレコードを、さらなる処理のためにサブシステム112およびリポジトリ116の一方または両方に提供することができる。換言すれば、統合サブシステム120は、別個のシングルテナントサブシステム(ソース104)からマルチテナントサブシステム(例えばリポジトリ116)内へのデータのインポートを、シングルテナントサブシステムの動作の途絶を回避しながら可能にするという、技術的な利点をもたらす。

【0017】

システム100、および特に統合器120の動作についてより詳細に論じる前に、統合器120および例示的なソース104のいくつかの内部コンポーネントについて、図2Aおよび図2Bを参照してより詳細に説明する。

【0018】

図2Aを参照すると、統合器120は、中央処理装置(CPU)などの少なくとも1つのプロセッサ200を含む。プロセッサ200は、適切な非一時的コンピュータ可読媒体(例えば、ランダムアクセスメモリ(RAM)、読出し専用メモリ(ROM)、電気的消去可能プログラマブル読出し専用メモリ(EEPROM)、フラッシュメモリ、磁気コンピュータストレージなどのうちのいずれか1つまたは複数を含む不揮発性メモリサブシステムと揮発性メモリサブシステムとの適切な組合せ)として実装されたメモリ204と相互接続されている。プロセッサ200およびメモリ204は一般に、1つまたは複数の集積回路(IC)からなる。明らかとなるように、統合器120は、単一のコンピューティングデバイスとして示されており、本明細書においてコンピューティングデバイスと呼ばれるが、分散型アーキテクチャとして実装することもできる。下の議論において統合器をコンピューティングデバイスとして呼ぶのは、単に話を簡単にするためになされるものであり、統合器120の任意の特定の特徴を具体的なアーキテクチャに限定するためになされるものではない。

【0019】

プロセッサ200は、統合器120がシステム100の他のコンピューティングデバイスとネットワーク124を介して通信することを可能にする通信インターフェース208にも相互接続されている。したがって、通信インターフェース208は、ネットワーク124を介して通信するために必要な任意のコンポーネント(例えばネットワークインターフェースコントローラ(NIC)、無線ユニットなど)を含む。通信インターフェース208の具体的なコンポーネントは、ネットワーク124の性質に基づいて選択される。統合器120は、プロセッサ200に接続された、キーボード、マウス、ディスプレイなどの入力デバイスおよび出力デバイス(図示せず)を含むこともできる。

【0020】

メモリ204は、プロセッサ200によって実行可能な、ソースデータ統合アプリケーション212を含むさまざまなアプリケーションの形態をとる、複数のコンピュータ可読プログラミング命令を記憶する。当業者には理解されるように、プロセッサ200は、アプリケーション212の命令を、アプリケーション212内に含まれる命令によって定められたさまざまなアクションを実施するために実行する。下の説明においては、プロセッサ200、より一般には統合器120は、それらのアクションを実施するように構成される、と言われる。プロセッサ200および統合器120はメモリ204内に記憶されたアプリケーションの命令の(プロセッサ200による)実行を通じてそのように構成されるということが、理解されよう。

【0021】

アプリケーション212を実行すると、統合器120が、ソース104から、ソースデータ要求に加えられた変更を示す修正指示子を受信するように構成される。修正指示子は、メモリ204内に記憶されているか、またはその他の方法でプロセッサ200にとってアクセス可能な、修正指示子リポジトリ216内に記憶される。下で論じるように、アプリケーション212を実行すると、プロセッサ200が、修正指示子リポジトリ216のコンテンツ、ならびにアプリケーション212によって定められたスケジューリングパラメータを使用して、ソース104にソースデータレコードを要求するように構成される。

【0022】

図2Bに移ると、一般的なソース104が示されている。システム100内の各ソース104は、全く同じに実装される必要はないが、各ソース104は、図2Bに示すコンポーネントを含む。ソース104は、適切な非一時的コンピュータ可読媒体(例えば不揮発性メモリサブシステムと揮発性メモリサブシステムとの適切な組合せ)として実装されたメモリ254と相互接続された、中央処理装置(CPU)などの少なくとも1つのプロセッサ250を含む。プロセッサ250およびメモリ254は一般に、1つまたは複数の集積回路(IC)からなる。統合器120に関して上で言及したように、ソース104は、いくつかの例では、分散して実装することができる。

【0023】

プロセッサ250は、ソース104がシステム100の他のコンピューティングデバイスとネットワーク124を介して通信することを可能にする通信インターフェース258にも相互接続されている。したがって、通信インターフェース258は、ネットワーク124を介して通信するために必要な任意のコンポーネント(例えばネットワークインターフェースコントローラ(NIC)、無線ユニットなど)を含む。通信インターフェース258の具体的なコンポーネントは、ネットワーク124の性質に基づいて選択される。ソース104は、プロセッサ250に接続された、キーボード、マウス、ディスプレイなどの入力デバイスおよび出力デバイス(図示せず)を含むこともできる。

【0024】

メモリ254は、プロセッサ250によって実行可能な、複数のコンピュータ可読プログラミング命令を記憶する。メモリ254内に記憶される命令は、主ソースアプリケーション262および修正検出器266を含む。主ソースアプリケーション262は、プロセッサ250を、ホテル予約または他の製品インベントリもしくはサービスインベントリの作成や維持など、ソース104の主機能を実装するように構成する。したがって、主アプリケーション262の実行は、図1に示していない他のさまざまなコンピューティングデバイスとの通信を含むことができ、またその実行は、データベース108内のソースデータレコードの(作成および削除を含む)修正を伴う。

【0025】

主アプリケーション262はまた、統合器120を含む他のデバイスがソースデータレコードを要求するために利用可能な、アプリケーションプログラミングインターフェース(API)を公開する。APIによってもたらされる粒度(level of granularity)は、ソース間で異なることがあるが、データベース108内のソースデータレコードに対応するレコード識別子のセットを統合器120または別のデバイスがサブミットできるようにするバルクレコード要求機能を少なくとも提供するものと仮定する。そのような要求に応答して、プロセッサ250は、識別された各レコードのコンテンツ全体を取り出し、送出するように構成される。主アプリケーション262の実行は、プロセッサ250に大幅に異なる負荷を課すことがあり、一般に、統合器120によるレコードの要求など、他の要因によってプロセッサ250に課されるアクティビティは、主アプリケーション262の適時の実行を妨げるおそれがある。

【0026】

修正検出器266を実行すると、プロセッサ250が、データベース108内の任意のソースデータレコードの修正に応答して、修正指示子を生成し、それを統合器120に送出するように構成される。次いで、統合器120がそれらの修正指示子を使用して、(特にソース104の性能が主アプリケーション262の実行に関係するときに)ソースデータレコードを求める要求がそのような性能に及ぼす影響を軽減しながら、データベース108にソースデータレコードを要求する。

【0027】

アプリケーション212、262、および266の機能は、図示のように分割される必要はない。例えば、アプリケーション212は、下で論じる機能を実施するために互いにインタラクションするように構成された、複数の別個のアプリケーションとしてデプロイすることができる。さらなる例では、アプリケーション212、262、266の一部または全てを、事前にプログラムされたハードウェア要素もしくはファームウェア要素(例えば特定用途向け集積回路(ASIC)、電気的消去可能プログラマブル読出し専用メモリ(EEPROM)など)、または他の関連コンポーネントを使用して、実装することができる。

【0028】

図3に移ると、ここでシステム100の機能についてさらに詳細に説明する。図3は、下でシステム100内でのその実施の様子と併せて論じる、ソースに適応したデータ取出しの方法300を示す。下で具体的な言及のない限り、方法300内に示されているステップは、統合器120によって実施される。

【0029】

ブロック305において、ソース104がそれぞれ、具体的にはそれぞれに対応する修正検出器アプリケーション266の実行を通じて、データベース108内のソースデータレコードの修正を検出し、修正指示子を統合器120に送信するように、構成される。したがって、ブロック305の3つのインスタンス、すなわちブロック305-1、305-2、および305-3が示されており、というのも、各ソース104は上記の機能を対応するデータベース108に関してのみ実施するためである。修正指示子は、所与のソース104によって、新規ソースデータレコードの作成、ソースデータレコードの削除、または既存のソースデータレコードに適用された更新を含む、データベース108の修正があればそれに応答して、生成される。

【0030】

各ソース104が修正指示子を統合器120にレポートする頻度は、特に限定されておらず、それらのソース104が修正指示子を同時に、または同じ頻度でレポートする必要もない。例えば、あるソース104は、レコード修正が検出されるごとに修正指示子を送出するように構成することができ、一方、別のソース104は、バッチの形で1日に2度、またはしきい値数の検出された修正に達すると、修正指示子を送出するように構成することができる。

【0031】

いずれにせよ、各修正指示子は、その修正が検出されたレコードのレコード識別子を含む。当業者には明らかとなるように、データベース108内の各レコードは、主キーなどの識別子を含む。ブロック305において送出される修正指示子は、その識別子を含むが、レコードの残りの部分は含まない。すなわち、修正指示子は、修正された任意のレコードのデータ部分を含まない。修正指示子は、ネットワーク識別子(例えばIPアドレス)など、ソース104自体の識別子を含むことができる。しかし、他の例では、統合器120が、修正指示子の受信時に、当該のソース104の識別子を推論するか、またはその他の方法で検出することができる。さらに、いくつかの例では、修正指示子は、検出された修正が行われたときを示すタイムスタンプを含むことができる。他の例では、統合器120が、修正指示子の受信時に、例えば受信時刻に基づいてタイムスタンプを付加することができる。

【0032】

ブロック310において、統合器120が、上述した修正指示子を受信するように構成される。ブロック305および310は、方法300の初めに示されているが、実際には、ブロック305および310の実施は、方法300の実施全体を通して継続することができる。すなわち、ソース104は、統合器120が方法300の残りの部分を実施しているのと並行して、引き続き修正を検出し、したがって修正指示子を統合器120に送出することができる。

【0033】

ブロック310において修正指示子を受信したことに応答して、統合器120は、修正指示子をリポジトリ216内に記憶する。したがって、リポジトリ216は、ソース104において修正されたレコードに対応するレコード識別子のセットを蓄積する。リポジトリ216は、複数のソース104からの修正指示子を含むので、各レコード識別子と関連付けてソース識別子も記憶する。ソース識別子は、修正指示子の一部分として受信することもでき、あるいはその他の方法で、統合器120によって、例えば修正指示子の送出元ネットワークアドレスに基づいて推論することもできる。

【0034】

一時的に図4に移ると、ブロック305およびブロック310の例示的な実施の様子が示されている。具体的には、ソース104における各データベース108について、レコードの例示的なセットが示されている。各レコードは、識別子(例えば「R1-3」)、および対応するデータを含む。データは、修正が検出されていない場合は白いブロックとして、修正が検出された場合は網掛けしたブロックとして示されている。したがって、ソース104-3におけるレコードR2-3およびR3-3は修正されており、ソース104-2におけるレコードR2-2も同様である。

【0035】

上述した修正の結果として、ソース104-2および104-3は、それぞれに対応するアプリケーション266の実行を通じて、修正されたレコードのレコード識別子を少なくとも含む修正指示子を統合器120に送出するように構成される。したがって、図4にやはり示すように、ブロック310において、統合器120は、レコード識別子および対応するソース識別子を受信し、リポジトリ216内に記憶する。オプションで、先に言及したように、リポジトリ216には各レコード識別子とともにタイムスタンプを記憶することもできる。ソース104-1は、この例ではいかなる修正も検出しておらず、したがって、いかなる修正指示子も統合器120に送信しない。

【0036】

図3に戻ると、ブロック315において、統合器120は、ソース104のいずれかについてスケジューリングパラメータを更新すべきかどうかを判定するように構成される。先に言及したように、統合器120は、各ソース104について別個のスケジューリングパラメータを維持する。いくつかの例では、各ソース104についてのスケジューリングパラメータは、統合器120から当該のソース104にソースデータレコードを求める要求相互間の最小期間を示す要求頻度である。他の例では、スケジューリングパラメータは、取り出すべきレコードのしきい値数(例えばしきい値を超えるまで要求が送出されないように)などを含むことができる。

【0037】

スケジューリングパラメータは、いくつかの例では、例えばソース104における修正の変化する計算負荷または計算量に対応するように、動的に更新することができる。他の例では、スケジューリングパラメータは、例えば管理者によって設定し、次いで変化しないままとすることができる。それらの例では、ブロック315および320は省略することができる。方法300の本例の実施では、ブロック315における判定をノー(negative)であると仮定し、したがって、ブロック320における更新されたスケジューリングパラメータの選択はバイパスされる。ブロック315および320の実施については、下でさらにより詳細に論じる。

【0038】

ブロック325において、統合器120は、所与のソース104にそのソース104のスケジューリングパラメータに従ってソースデータレコードを要求すべきかどうかを判定するように構成される。換言すれば、統合器120は、各ソース104について、ブロック325(ならびに方法300の後続のブロック)の別個のインスタンスを、例えば並列に実施することができる。

【0039】

ブロック325における判定は、当該のソース104のスケジューリングパラメータに基づく。例えば、ソース104-2のスケジューリングパラメータが要求頻度(例えば1時間当たり1つの要求)である場合、統合器120は、ブロック325において、その頻度と、ソース104-2に送出された一番最近の要求に対応する記憶されたタイムスタンプとに基づいて、判定を行う。一番最近の要求と現在との間で経過した時間が、スケジューリングパラメータを満たすかまたは超える(すなわち一番最近の要求が少なくとも1時間前に送出された)場合、ブロック325における判定はイエス(affirmative)である。そうでない場合、ブロック325における判定はノーである。ブロック325におけるノー判定に続いて、統合器120はブロック310に戻るが、ブロック325の、他のソース104についての他のインスタンスがイエス判定という結果になる可能性があることは、明らかであろう。

【0040】

本例では、ブロック325における判定が3つの全てのソース104についてノーであると仮定する。したがって、統合器120は、引き続きブロック310において修正指示子を収集する。図5に移ると、データベース108-3への、具体的にはレコードR1-3およびR3-3への、追加の修正が示されている。したがって、ソース104-3は、2つの追加の修正指示子を統合器120に送出し、したがってリポジトリ216が図示のように更新される。明らかとなるように、レコードR3-3は、この時点でリポジトリ216内に2回表現されている。

【0041】

再度図3を参照し、ブロック315におけるノー判定を仮定すると、統合器120は、ブロック325において、ソース104のうちのいずれかにソースデータレコードを要求すべきかどうかを判定するように構成される。ブロック325のこの実施では、ソース104-2については判定がノーであるが、ソース104-3についてはイエスであると仮定する。すなわち、より大きな要求頻度を定めたスケジューリングパラメータをソース104-3が有している可能性があり、かつ/または統合器120がソース104-2にレコードを要求したのが、ソース104-3にレコードを要求するよりも最近であっただけの可能性がある。ブロック325におけるソース104-1についての判定はノーであり、というのも、ソース104-1から修正指示子が受信されていないためである。実際、統合器120は、ブロック325の各インスタンス(すなわち各ソース104についての)を、そのソース104についてのレコード識別子をリポジトリ216が含んでいると判定したときにのみ開始することができる。

【0042】

ブロック325における判定がイエスであるとき、統合器120はブロック330に進む。ブロック330において、統合器120は、リポジトリ216から、当該のソース104に関連するいかなるレコード識別子も取り出すように構成される。例えば、ソース104-3に関して、統合器120は、リポジトリ216(そのコンテンツは図5に示す通りである)からレコード識別子R2-3、R3-3、R1-3、およびR3-3を取り出す。

【0043】

明らかとなるように、取り出した修正指示子は、重複したレコード識別子(R3-3)を含む。ソース104は、ソース104においてアプリケーション266によって課される計算負荷を低減させるために、レコード修正があればそれを統合器120に通知するにすぎないので、統合器120は、同じレコードについて複数の修正指示子を受信することがある。したがって、ブロック330において、統合器120は、同じレコードの複数のコピーをソース104に要求することを回避するために、取り出した修正指示子を、例えば重複レコード識別子を取り除くようにフィルタリングするようにも構成される。

【0044】

ブロック335において、統合器120は、ブロック330からのフィルタリングしたレコード識別子を含むバルクレコード要求を、当該のソース104に送出するように構成される。バルクレコード要求は、換言すれば、ブロック330からのフィルタリングしたレコード識別子(すなわち1つまたは複数のレコード識別子)を全て含む、単一の要求である。図6は、統合器120からソース104-3にバルクレコード要求600を送信する様子を示す。上の議論から明らかとなるように、要求600はレコード識別子R1-3、R2-3、およびR3-3を含む。それに加えて、統合器120は、要求を送出したことに応答して、ブロック330において取り出したレコード識別子をリポジトリ216から取り除く(例えば削除する)。結果として、リポジトリ216は、ソース104-2についてのただ1つの修正指示子を含む。それに加えて、統合器120は、ブロック335において要求を送出する際に、当該のソース104に対応する一番最近の要求についての前述のタイムスタンプを更新する。

【0045】

図3に戻ると、ブロック340において、統合器120は、当該のソース104から、要求したレコードを、例えばカンマ区切り値(CSV)フォーマットまたはJavaScript Object Notation(JSON)フォーマットで受信するように構成される。ブロック340において受信したレコードは、ブロック310において受信した単なるレコード識別子ではなく、ソースデータレコード全体である。ソースデータレコードを受信すると、統合器120は、ソースデータレコードを例えばソース識別子とともに、マルチテナントリポジトリ116内に記憶することができる。統合器120は、ソースデータレコードを、さらなる処理のために(例えばサブスクリプション/公開、または他の適切な機構を通じて)マルチテナントサブシステム112に提供することもできる。サブシステム112自体が、レコードを、さらなる処理のためにリポジトリ116から直接取り出すこともできる。

【0046】

したがって、時間とともに、データベース108に修正が加えられ、統合器120がデータベース108にソースデータレコードを要求するとき、マルチテナントリポジトリ116が個々のシングルテナントデータベース108の組み合わされたコンテンツを反映するようになる。ソース104の性能に悪影響を及ぼすことなく統合器120からの要求に応答することのできる各ソース104の能力に応じて、リポジトリ116内のデータは実質的にリアルタイムで更新されることが可能である。一部のソース、例えば重い負荷のかかったソースでは、普通なら統合器120からの頻繁な要求の結果として生じることのある性能劣化のおそれを軽減するために、リポジトリ116内のデータはそれほど頻繁に更新されないことが可能である。

【0047】

先に言及したように、統合器120によってブロック325において用いられるスケジューリングパラメータは、動的に更新することができる。例えば、ブロック315において、統合器120は、ソース104のうちの1つまたは複数にポーリングしてそこから性能測定基準を取り出すように構成することができる。性能測定基準は、CPU使用率レベルなどの使用率測定基準を含むことができる。他の例では、性能測定基準は、残余クエリ利用可能数(remaining query availability)を含むことができる。例えば、所与のソース104が、期間当たり、例えば1日当たり固定数の到来要求を許容することがある。したがって、そのソース104に許容された到来要求の残余数を、統合器120によって取り出し、そのソース104についてのスケジューリングパラメータを更新するために使用することができる。

【0048】

例えば、ソース104における使用率が比較的高い場合、ブロック335における要求によってそのソース104に課されるデマンドを低減させるために、統合器120においてそのソース104についての要求頻度を低減させるという結果となり得る。反対に、ソース104における使用率が比較的低い場合、要求頻度を増大させるという結果となり得る。統合器120は、例えば、使用率を1つまたは複数のしきい値と比較することができる。次いで、統合器120は、使用率がしきい値を下回る場合に要求頻度をインクリメントし、または使用率がしきい値を超える場合に要求頻度をデクリメントすることができる。さらなる例として、統合器120は、利用可能クエリの残余数をしきい値と比較し、残余クエリ利用可能数がしきい値を下回る場合に要求頻度をデクリメントする(すなわち低減させる)ことができる。

【0049】

特許請求の範囲に記載の範囲は、上記の例において記載した実施形態によって限定されるべきではなく、説明全体と整合する最も広い解釈を与えられるべきである。

【符号の説明】

【0050】

100 システム
104 ソースサブシステム、ソースコンピューティングデバイス、ソース
104-1 ソース
104-2 ソース
104-3 ソース
108 シングルテナントデータベース、データベース
108-1 データベース
108-2 データベース
108-3 データベース
112 マルチテナントサブシステム、サブシステム
116 マルチテナントリポジトリ、リポジトリ
120 統合サブシステム、統合器
124 ネットワーク
200 プロセッサ
204 メモリ
208 通信インターフェース
212 ソースデータ統合アプリケーション、アプリケーション
216 修正指示子リポジトリ、リポジトリ
250 プロセッサ
254 メモリ
258 通信インターフェース
262 主ソースアプリケーション、主アプリケーション、アプリケーション
266 修正検出器、修正検出器アプリケーション、アプリケーション
300 方法
600 バルクレコード要求、要求
R1-3 レコード、レコード識別子
R2-2 レコード
R2-3 レコード、レコード識別子
R3-3 レコード、レコード識別子

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】

【国際調査報告】