(57)【特許請求の範囲】
【請求項１】
データをデータストレージシステム（１００）に保存し、データを前記データストレージシステム（１００）から取得する方法であって、前記データストレージシステム（１００）は、ソフトウェアアプリケーション（１０）と、１または複数のデータベースシステム（２０）と、複数のキャッシュノード（３０）とを備え、前記ソフトウェアアプリケーションはユーザリクエストを受信するように構成され、前記ユーザリクエストは少なくとも１つのデータの読み込みまたはデータの１つの書き込みを要求し、前記ソフトウェアアプリケーションはさらに、読み込みクエリまたは書き込みクエリを前記複数のキャッシュノード（３０）に送信して、前記ユーザリクエストを処理するように構成され、前記方法は、前記ソフトウェアアプリケーションが独自に前記１または複数のデータベースシステムおよび前記複数のキャッシュノード（３０）と接続することと、前記方法が、少なくとも１つのデータプロセッサを備える前記ソフトウェアアプリケーションが実施する以下のステップを備えることを特徴とし、前記ステップは、
少なくとも１つのデータの読み込みを要求するユーザリクエストを受信すると、前記ソフトウェアアプリケーション（１０）は読み込みクエリのみ（２１０）を前記複数のキャッシュノード（３０）に送信するステップと、
前記ソフトウェアアプリケーション（１０）がクエリされたデータを少なくとも１つのキャッシュノード（３０）から、前記読み込みクエリに応答して受信する場合は、前記ソフトウェアアプリケーション（１０）は、前記クエリされたデータを用いて前記ユーザリクエストを処理するステップと、
前記ソフトウェアアプリケーション（１０）が損失（２２０）をすべてのキャッシュノード（３０）から、前記読み込みクエリに応答して受信する場合は、前記ソフトウェアアプリケーション（１０）は前記１または複数のデータベースシステム（２０）からデータを取り出し（２３０）、前記クエリされたデータを前記１または複数のデータベースシステム（２０）から取得すると、前記ソフトウェアアプリケーション（１０）は前記クエリされたデータを用いて、前記ユーザリクエストを処理し、少なくとも１つのキャッシュノード（３０）に、前記クエリされたデータと、前記クエリされたデータを前記少なくとも１つのキャッシュノード（３０）に追加する（２５０）ための指示とを送信するステップであり、
少なくとも１つのデータの書き込みを要求するユーザリクエストを受信すると、前記ソフトウェアアプリケーション（１０）は書き込みの指示を前記１または複数のデータベースシステム（２０）に送信し、また、同時に書き込みの指示を前記複数のキャッシュノード（３０）に送信し、それによって、前記データストレージシステム（１００）の各損失された読み込みクエリおよび各書き込みクエリにおいて、前記複数のキャッシュノード（３０）にデータを追加し、
前記キャッシュノードの数およびストレージリソースは、前記すべてのデータベースシステムの内容を保持するように適応される、
方法。
【請求項２】
書き込みクエリは、前記データベースシステム（２０）のデータの追加、更新および削除のうち少なくとも１つを備える、請求項１に記載の方法。
【請求項３】
前記ソフトウェアアプリケーション（１０）は、前記クエリされたデータを前記少なくとも１つのキャッシュノードに追加することが無事終了したことに関する肯定応答（２６０）を受信する、請求項１〜２のうちいずれか１項に記載の方法。
【請求項４】
データの書き込み（４１０）が同一のクエリされたデータを前記１または複数のデータベースシステムから同時に取得する間に発生する場合は、前記クエリされたデータを前記少なくとも１つのキャッシュノードに後で追加（２５２）することは中断され、否定応答（２６２）が前記ソフトウェアアプリケーション（１０）に戻され、それによって、前記ソフトウェアアプリケーションが前記書き込まれたデータを代わりに（４２０）用いることができる、請求項１〜３のうちいずれか１項に記載の方法。
【請求項５】
データを前記１または複数のデータベースシステム（２０）に書き込むための指示を送信し、前記複数のキャッシュノード（３０）に同時に書き込むための指示を送信すると、
前記１または複数のデータベースシステムから、前記書き込みを適用する現在保存されているデータを取得（５１０）し、前記現在保存されているデータをロックするステップと、
前記１または複数のデータベースシステムに、保存すべき新規データを書き込む（５３０）ステップと、
ソフトウェアアプリケーション（１０）にキャッシュバッファを書き込み（５４０）、保存すべき前記新規データを一時的に保持するステップと、
前記少なくとも１つのキャッシュノードに保存すべき前記新規データを転送し、設定する（５５２）ステップと、
トランザクションを前記１または複数のデータベースシステムにコミットする（５５４）ステップと、
が実施される、請求項１〜４のうちいずれか１項に記載の方法。
【請求項６】
前記コミットが失敗すると、前記ソフトウェアアプリケーション（１０）は指示を前記少なくとも１つのキャッシュノードに送信し、前もって設定された前記新規データを削除する、請求項５に記載の方法。
【請求項７】
前記クエリされたデータが前記１または複数のデータベースシステムまたは前記複数のキャッシュノード（３０）のいずれにもない場合は、
前記１または複数のデータベースシステム（２０）からデータを取り出した（３０）後、損失（６４０）が前記ソフトウェアアプリケーションに、前記クエリされたデータの代わりに戻され、
前記ソフトウェアアプリケーション（１０）は少なくとも１つのキャッシュノード（３０）に不在のデータ（６５０）を送信し、前記不在のデータ（６５０）は前記少なくとも１つのキャッシュノード（３０）に前記クエリされたデータのために追加され、前記不在のデータはすべての次の読み込みクエリに対して直ちに利用可能（２７０）となり、
それによって、前記ソフトウェアアプリケーション（１０）が、前記損失しているクエリされたデータを取得するために、前記１または複数のデータベースシステム（２０）からデータをさらに取り出すことを回避する、請求項１〜６のうちいずれか１項に記載の方法。
【請求項８】
前記ソフトウェアアプリケーション（１０）は独自に前記１または複数のデータベースシステム（２０）と第１の専用インターフェース（１２）で接続し、前記複数のキャッシュノード（３０）と第２の専用インターフェース（１４）で接続する、請求項１〜７のうちいずれか１項に記載の方法。
【請求項９】
前記キャッシュノードおよび前記データベースシステムのデータモデルは一貫しており、それによって、キャッシュノードおよびデータベースシステムのデータにアクセスするために、正確に同一の処理キーが得られる、請求項１〜８のうちいずれか１項に記載の方法。
【請求項１０】
データが存在するときは、同一のデータが前記データベースシステムおよび少なくとも１つのキャッシュノードに保存され、またはキャッシュおよびデータベースシステムの前記同一のデータの前記処理の一貫性を保証するような方法で保存される、請求項１〜９のうちいずれか１項に記載の方法。
【請求項１１】
ソフトウェアプログラム指示を含有するコンピュータプログラム製品であって、前記ソフトウェアプログラム指示を少なくとも１つのデータプロセッサによって実行する場合は、請求項１〜１０のいずれか１つに記載の前記方法を実行することを含む、操作の実施につながる、プログラム。
【請求項１２】
１または複数のデータベースシステム（２０）と、少なくとも１つのキャッシュノード（３０）と、少なくとも１つのデータプロセッサと、ソフトウェアアプリケーション（１０）とを備えるデータストレージシステム（１００）であって、前記ソフトウェアアプリケーションを前記少なくとも１つのデータプロセッサによって実行することは、請求項１〜１０のいずれか１つに記載の前記方法を実行することを含む操作の実施につながり、前記１または複数のデータベースシステム（２０）および前記少なくとも１つのキャッシュノード（３０）は、独自に前記ソフトウェアアプリケーション（１０）によって起動される、システム。
【請求項１３】
請求項１２に記載のデータストレージシステム（１００）であって、前記データベースシステム（２０）の一部のデータは、２以上のキャッシュノード（３０）に保存される、システム。
【請求項１４】
請求項１２または１３に記載のデータストレージシステムを備える旅行プロバイダの在庫管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、物品およびサービスの大手プロバイダが、自社製品全体の提供および利用可能性のレベルを管理するために用いる種類のデータマネジメントシステムに関する。より具体的には、本発明は、データストレージのリモートユーザからのハイレベルなクエリに対して、遅延なく、またはわずかな遅延のみで答えることができ、データストレージ管理の結果として、内容を常に更新するトランザクションの完了には影響を与えないシステムに関する。
【背景技術】
【０００２】
内部接続したすべての世界では、すべての物品およびサービスの大手プロバイダは、製品およびサービスの提供の特性、仕様およびコストを保持する大規模なデータベースシステムを今までに築いてきた。データベースマネジメントシステム（ＤＢＭＳ）制御下で操作されると、おそらく世界中から、大勢のオンラインの顧客が内容に同時にアクセスできるようになる。オンラインの顧客には、このように、データベースにクエリ、特定のオンラインソフトウェアアプリケーションを用いて商業トランザクションを完了する機会が提供される。特定のオンラインソフトウェアアプリケーションによって、オンラインの顧客は様々な製品およびサービスを予約し、購入する。
【０００３】
航空業界では、このような非常に巨大なデータベースの例として、航空会社の在庫を記載したデータベースがあげられる。このようなデータベースを用いて、所与の航空会社が操業する実際の座席数、予約の現状と共に、保有飛行機の構成をリアルタイムに追跡する。
【０００４】
より具体的には、航空会社の在庫は通常、利用可能な座席があるすべての航空便を含有し、一般に、サービスクラス（たとえばファースト、ビジネスまたはエコノミークラス）および異なる値段および予約条件が適用される多くの予約クラスに区別されている。在庫マネジメントの中心となる機能の１つは在庫管理である。在庫管理は、個々の予約クラスの販売を開始および終了することによって、様々な予約クラスにおける利用可能な座席数を操作する。運賃見積もりシステムに保存されている運賃と予約条件を組み合わせて、各販売座席の料金が決定する。ほとんどの場合、在庫管理は航空会社のレベニューマネジメントシステムと接続し、需要の変化に応じて、提供する予約クラスを恒久的に最適化することをサポートする。ユーザは、ディスプレイおよびグラフィカルユーザインターフェースを有する利用可能性を示すアプリケーションを通じて、航空会社の在庫にアクセスする。利用可能性を示すアプリケーションは、具体的な都市までの様々な予約クラスにおいて利用可能な座席と組み合わせて、提供されるすべての航空便を含有する。
【０００５】
航空会社在庫データベースは通常は、航空会社が管理する。航空会社在庫データベースは、旅行サービスを旅行業界の多くの関係者に提供する企業によっても設定される。旅行業界には、航空会社、伝統的な旅行代理店およびあらゆる種類の他のオンライン旅行サービスプロバイダも含まれる。このような企業には、たとえば、スペインのマドリッドに本店を持つ欧州の旅行サービスプロバイダであるＡＭＡＤＥＵＳがある。在庫管理の中には、直接航空会社が管理し、グローバルディストリビューションシステム（ＧＤＳ）または中央予約システム（ＣＲＳ）と接続するものもある。
【０００６】
この環境では、これらのデータベースの利用は、問い合わせまたは読み込みクエリのレベルが年を追って、大幅に増加してきたことが特徴としてあげられる。実際に、トランザクションのうち、データベースが処理しなければならないオンライン予約率は非常に高くなっている。したがって、旅行サービスプロバイダは、コンピュータ化された必要なリソースを配置し、増え続けるオンラインの顧客が効率的にデータベースに問い合わせ、迅速な答えを得ることができると同時に、予約の完了と、航空会社の場合は旅客への座席の販売の結果として、データベースの更新が同時に進行できるという状況に対処しなければならない。
【０００７】
このようなデータベースを実装するために利用可能であり、広く使用されている大規模なデータベースシステムは、Ｏｒａｃｌｅのように数社の専門企業から提供されている。Ｏｒａｃｌｅは、アメリカ合衆国、カリフォルニア州、レッドウッドショアに本社を持ち、データベース管理システムの開発を専門としている。ただし、標準的なＤＢＭＳだけでは、物品およびサービスの大手サービスプロバイダが、何万もの潜在的な顧客に同時に提供しなくてはならないこともある受容に必要なレベルを処理できない。この目的を実現するために、何らかの方法で、ユーザからの無数のクエリを直接受けないように、データベースを保護しなくてはならない。
【０００８】
したがって、データベースの内容をキャッシュ化するための多くの解決法が開発されてきた。キャッシュは、アプリケーション階層に位置するアプリケーションキャッシュであってもよく、アプリケーションがデータベースから前もって取得したデータを基本的に再利用する。これは、データベースの内容がその間更新されているかもしれないため、ユーザの別の問い合わせに応答して提供されるデータの品質の問題がすぐに生じる。これは、データベースが常に更新され、高品質のデータを必要とする一部のアプリケーションではかなり問題となることが分かっている。たとえば、航空会社の在庫に関連するアプリケーションの場合は、データが最新であることが、顧客に提供される座席販売の可能性および料金に直接影響を与えるため、データの品質が問題となる。
【０００９】
したがって、この種類のキャッシュによって提供されるデータの品質があまり重要ではない場合を除き、また、他の何よりも有益であると考えられない限り、この種類のアプリケーションキャッシュは、データベースとキャッシュの間で高機能の機構を実装することを要求する。それによって、データベースで更新されるとき、以前に取得したデータの無効化および／または交換が可能になり、したがって、アプリケーションキャッシュおよびデータベースの内容が実際に一貫するように維持される。キャッシュはデータベースとアプリケーションとの間のパスに挿入されることが多いため、キャッシュは常にまず、アプリケーションによってクエリされる。クエリされたデータがキャッシュに存在しない場合は、データベースから取得され、アプリケーションに提供される前にキャッシュに取り込まれる。これらのすべての解決法は、キャッシュおよびデータベースが密接に結合することが要求され、お互いを認識する必要があるという共通点がある。結果として、サービスプロバイダがより多くのコンピュータリソースを配備して、トラフィックの増加を処理し、システムの性能を維持しながら、より多くの顧客にサービスを提供しなければならないとき、これらの解決法は容易には拡張可能ではない。
【００１０】
ただし、特定の解決法によって、かなり良好な拡張性が可能となり、キャッシュとデータベース間の一定の独立性が可能となることが、「データベースリクエストをデータベースおよびキャッシュにルーティングするシステムおよび方法」という特許文献１に記載されている。開示されている解決法では、データベースおよびキャッシュは、アプリケーションの制御下のみで個別に起動されることによって、ある程度独立している。ただし、キャッシュは読み込みクエリに答えるためにのみ用いられ、更新はアプリケーションによって、データベースでのみ実施される。したがって、データベースへの変更をキャッシュに反映するために、特許文献１は、キャッシュを更新する複製部品がデータベースに含有されることを記載している。
【００１１】
前述のすべてのキャッシュに関する解決法は、重大な作業負荷をデータベースに追加する一方、キャッシュおよびデータベースは常に一貫性があることを保証されず、データベースは様々なキャッシュを認識しなければならない。これによって、新規のキャッシュを追加するときに、特定の操作をデータベースで実施することが必要となり、したがって拡張性は容易に実現できない。前述のように、特許文献１はデータベースマネジメントシステムが外部の部品を組み込むことを要求する。これは標準的なＤＢＭＳの利用に、実際には適合しない。
【００１２】
したがって、本発明の目的として、高トラフィックおよび高拡張性が可能となる一方、ユーザに適切なデータ品質を提供することができる、データベースを備えたコンピュータ化されたデータシステムを記載する。
【００１３】
本発明の別の目的、特徴および有利点は、以下の記載を添付図を参照しながら検証することによって、当業者には明らかとなろう。任意の追加の有利点が本明細書に組み込まれることが意図される。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】米国特許第６,６０９,１２６号
【発明の概要】
【００１５】
本発明の実施形態によれば、前述の問題および他の問題は克服され、他の有利点が実現される。
【００１６】
本発明の第１の態様は、データをデータストレージシステムに保存し、データをデータストレージシステムから取得する方法を提供する。データストレージシステムは、ソフトウェアアプリケーションと、１または複数のデータベースシステムと、複数のキャッシュノードとを備える。ソフトウェアアプリケーションはユーザリクエストを受信するように構成され、ユーザリクエストは少なくとも１つのデータの読み込みまたはデータの１つの書き込みを要求し、ソフトウェアアプリケーションはさらに、読み込みクエリまたは書き込みクエリをデータストレージシステムに送信して、ユーザリクエストを処理するように構成される。方法は、ソフトウェアアプリケーションが独自に１または複数のデータベースシステムおよび複数のキャッシュノードと接続することと、方法が、少なくとも１つのデータプロセッサを備えるソフトウェアアプリケーションが実施する以下のステップを備えることを特徴とする。
つまり、少なくとも１つのデータの読み込みを要求するユーザリクエストを受信すると、ソフトウェアアプリケーションは、読み込みクエリのみを複数のキャッシュノードに送信する。好ましくは、ソフトウェアアプリケーションがクエリされたデータ（つまり、取得されたデータ）を少なくとも１つのキャッシュノードから、読み込みクエリに応答して受信する場合は、ソフトウェアアプリケーションは、クエリされたデータを用いてユーザリクエストを処理する。好ましくは、ソフトウェアアプリケーションが損失をすべてのキャッシュノードから読み込みクエリに応答して受信する場合は、それによって、データがキャッシュノードで発見されなかったことを意味し、ソフトウェアアプリケーションは１または複数のデータベースシステムを取り出す。クエリされたデータがデータベースに存在する場合は、１または複数のデータベースシステムからクエリされたデータを取得すると、ソフトウェアアプリケーションはクエリされたデータを用いて、ユーザリクエストを処理し、少なくとも１つのキャッシュノードにクエリされたデータを送信し、クエリされたデータを少なくとも１つのキャッシュノードに追加するように指示を送信する。
【００１７】
好ましい実施形態によると、少なくとも１つのデータの書き込みを要求するユーザリクエストを受信すると、ソフトウェアアプリケーションは書き込みの指示を１または複数のデータベースシステムに送信し、また、同時に書き込みの指示を複数のキャッシュノードに送信し、それによって、複数のキャッシュノードをデータストレージシステムの各損失された読み込みクエリおよび各書き込みクエリに投入する。各データはしたがって複数のキャッシュノードのうち少なくとも１つのキャッシュノードと１または複数のデータベースシステムに同一に保存されており、それによって、データベースシステムと複数のキャッシュノードが常に完全に同期化されていることを保証する。
【００１８】
したがって、本発明は、複数のキャッシュから完全に独立したデータベースを持つことが可能となり、キャッシュを更新するために、データベースに一体化された複製の部品に関与する既知の解決法とは反対に、複数のキャッシュノードを備える。既知の解決法では、データベースおよびキャッシュは、完全に独立しているとは言えず、ストレージシステム全体の拡張性が制限され、特定のデータベースが必要となる。
【００１９】
完全に独立し、互いを認識していないデータベースおよびキャッシュを備えるコンピュータ化データシステムによって、したがって、トラフィックの増加を処理することが必要なとき、より多くのコンピュータおよびストレージ収容能力を導入するだけで、制限のない拡張性を持つデータシステムが可能となる。
【００２０】
さらに、高拡張性は機器のコストを抑えながら実現可能である。具体的には、本発明は標準的なデータベースおよびＤＢＭＳで実装することができる。本発明はまた、維持コストを削減することができる。具体的には、ストレージリソースの増加はデータベース上で何も操作する必要がない。
【００２１】
ソフトウェアアプリケーションは、データベースのデータの更新およびキャッシュの投入を担当する。これは、データベースの書き込みを反映すること、またはデータベースには存在するが、まだキャッシュにはないクエリされたデータを追加することによって行われる。そのためエンドユーザには、高品質データつまり最新のデータが提供される。さらに、キャッシュは迅速に投入されるため、新規のキャッシュノードをシステムに追加するとすぐに、スループットが増加する。
【００２２】
さらに、本発明は、正確かつ顧客に合わせた返答をユーザに提供することができる。
【００２３】
非限定的な実施形態によれば、書き込みクエリは、データベースシステムのデータの追加、更新および削除のうち少なくとも１つを備える。
【００２４】
任意には、本発明による方法は、以下の条件的特徴およびステップのいずれか１つを備えていてもよい。
【００２５】
キャッシュおよびデータベースのデータモデルは同一であってもよいが、厳格に同一である必要はない。唯一の要件は一貫していることであり、それによってキャッシュおよびデータベースの記録にアクセスするために、正確に同一の処理キーを得ることができる。キーはまた、書き込み操作の一貫性のためにデータベースの記録をロックすることができる。したがって、データの記録は、存在するときは、データベースおよびキャッシュに同一に保存されているか、またはキャッシュおよびデータベースの同一のデータの処理の一貫性を保証するような方法で保存される。たとえば、キャッシュデータモデルはデータベースモデルに対して適応されてもよく、データの取得を早める。それによって、２つのエンティティの間で処理が完全に一貫している間、キャッシュのアクセス時間は改善される。
【００２６】
非限定的な実施形態によれば、キャッシュノードのデータモデルは同一の１または複数のデータベースのデータモデルと同一である。各キャッシュノードの各データはデータベースシステムに同一に保存されている。データベースシステムの各データは、各キャッシュノードに同一に保存されている。
【００２７】
１または複数のデータベースシステムへの書き込み指示はソフトウェアアプリケーションから１または複数のデータベースシステムに送信される。
【００２８】
複数のキャッシュノードに同時に書き込む指示は、ソフトウェアアプリケーションから複数のキャッシュノードに送信される。
【００２９】
１つの単一ソフトウェアアプリケーションはデータベースシステムおよびキャッシュノードにアクセスする。
【００３０】
データストレージシステムは、１つの単一データベースシステムを備える。
【００３１】
キャッシュはキャッシュノードを備え、非永続的な各データストレージ手段を備える。
【００３２】
ソフトウェアアプリケーションは、クエリされたデータを少なくとも１つのキャッシュノードに追加することが無事に完了した時に肯定応答（positive acknowledgement）を受信する。
【００３３】
データの書き込みが起きるとき、同一のクエリされたデータは同時に１または複数のデータベースから取得され、次に後続してクエリされたデータを少なくとも１つのキャッシュノードに追加することは中断され、否定応答(negative acknowledgement)がソフトウェアアプリケーションに返される。それによって、ソフトウェアアプリケーションは代わりに書き込まれたデータを用いることができる。
【００３４】
１または複数のデータベースシステムに書き込む指示を送信し、複数のキャッシュノードに同時に書き込む指示を送信すると、以下のステップが実施される。
１または複数のデータベースシステムから、書き込みを適用する現在保存されているデータを取得し、１または複数のデータベースシステムにロックするステップと、
保存すべき新規データをソフトウェアアプリケーションで処理し、１または複数のデータベースシステムに書き込むステップと、
ソフトウェアアプリケーションにキャッシュバッファを書き込み、一時的に保存すべき新規データを保持するステップと、
少なくとも１つのキャッシュノードに保存すべき新規データを転送し、トランザクションを１または複数のデータベースシステムにコミットするステップ。
【００３５】
本発明では、キャッシュノードまたはキャッシュはキャッシュバッファとは異なる。キャッシュバッファは、書き込み中に一時的にデータを保存する。いかなるデータも、ユーザリクエストに応答して、キャッシュバッファからは取得されない。キャッシュバッファは書き込み処理専用である。
【００３６】
コミットが失敗すると、次に、アプリケーションソフトウェアは指示を送信して、少なくとも１つのキャッシュノードに以前設定した新規データを削除させる。
【００３７】
新規データを含有する少なくとも１つのキャッシュノードは、その内容から新規データを削除する。複数のキャッシュノードが新規データを含有する場合は、その複数のすべてのキャッシュノードは新規データを削除する。
【００３８】
ソフトウェアアプリケーションは、どのキャッシュノードまたは複数のキャッシュノードのうちどのキャッシュノードに、データを追加する指示または送信するデータを更新または削除する指示を出すかを決定する。
【００３９】
決定は負荷均衡を考慮する。
【００４０】
クエリされたデータが１または複数のデータベースシステムまたは少なくとも１つのキャッシュノードのいずれにもない場合は、
１または複数のデータベースシステムを取り出した後、損失がソフトウェアアプリケーションに、クエリされたデータの代わりに返され、
ソフトウェアアプリケーションは少なくとも１つのキャッシュノードに不在のデータを送信し、不在のデータは少なくとも１つのキャッシュノードに対応するクエリされたデータのために追加され、不在のデータはすべての次の読み込みクエリに対して直ちに利用可能となり、
それによって、ソフトウェアアプリケーションが、損失しているクエリされたデータを取得するために、１または複数のデータベースをさらに取り出すことを回避する。
【００４１】
エンドユーザがリクエストし、最終的にデータベースで発見されないデータは、次に「損失しているデータ」としてキャッシュに保存される。それによって、キャッシュの次に問い合わせに対しては、ユーザがリクエストしたデータはキャッシュにもデータベースにもないという情報を直ちに返すことができる。これによって、データベースへのさらなる問い合わせがデータベースシステムをスローダウンさせないようにする。
【００４２】
非限定的な実施形態によれば、各データはヘッダと関連し、記録を形成する。ヘッダはデータベースシステムで内容が損失しているかどうかを示す。したがって、記録のヘッダを読み込むだけで、データベースシステムを取り出す価値があるかどうかを知ることができる。
【００４３】
別の実施形態によれば、キャッシュノードはデータに関連する特定の値を保存する。この特定の値はデータがデータベースに存在しないことを示す。
【００４４】
ソフトウェアアプリケーションは独自に１または複数のデータベースシステムと第１の専用インターフェースで接続し、少なくとも１つのキャッシュノードと第２の専用インターフェースで接続する。
【００４５】
データモデルは、データベースおよびキャッシュに直接マッピング可能であるように選択される。
【００４６】
データの各セットは機能エンティティによってグループ分けされ、キーによってインデックスが付けられる。これによって、内容がある程度異なっているとしても、データベースおよびキャッシュノード両方のキーのおかげで、一式のデータに直ちにアクセス可能となる。
【００４７】
データは、フライト−日付によってグループ分けされ、フライト−日付キーによって特定される。
【００４８】
ソフトウェアアプリケーションは旅行プロバイダの在庫のソフトウェアアプリケーションである。
【００４９】
ソフトウェアアプリケーション、データベースシステムおよびキャッシュノードは旅行プロバイダの在庫に含まれる。
【００５０】
通常、旅行プロバイダは航空会社である。
【００５１】
ソフトウェアアプリケーションで受信するユーザリクエストは、旅行代理店、オンライン旅行代理店、オンラインの顧客のうち少なくとも１つから送信される。
【００５２】
キャッシュノードのデータモデルおよびデータベースは一貫性を持ち、それによって、まさしく同一の処理キーを得て、キャッシュノードおよびデータベースのデータにアクセスする。
【００５３】
データが存在する場合は、データはデータベースおよび少なくとも１つのキャッシュノードに同一に保存されているか、キャッシュおよびデータベースの同一のデータの処理の一貫性を保証するような方法で保存されている。
【００５４】
本発明の別の態様では、コンピュータ−プログラム製品または非一時的コンピュータ−は、読み込み可能媒体であり、ソフトウェアプログラム指示を含有する。ソフトウェアプログラム指示を少なくとも１つのデータプロセッサによって実行することは、前述の方法の実行を含む操作性能につながる。
【００５５】
代表的な実施形態はまた、保存データをデータストレージシステムに保存し、データをデータストレージシステムから取得する方法を含有する。データストレージシステムは、ソフトウェアアプリケーション、１または複数のデータベースシステムおよび複数のキャッシュノードを備える。ソフトウェアアプリケーションは、少なくとも１つのデータの読み込みまたはデータの１つの書き込みを要求するユーザリクエストを受信するように構成される。ソフトウェアアプリケーションはさらに、読み込みクエリおよび書き込みクエリをデータストレージシステムに送信して、ユーザリクエストを処理するように構成される。本方法は、ソフトウェアアプリケーションが独自に１または複数のデータベースシステムおよび複数のキャッシュノードと接続することと、本方法が、少なくとも１つのデータプロセッサを備えるソフトウェアアプリケーションが実施する以下のステップを備えることを特徴とする。
少なくとも１つのデータの読み込みを要求するユーザリクエストを受信すると、ソフトウェアアプリケーションは、読み込みクエリのみを複数のキャッシュノードに送信する。
ソフトウェアアプリケーションがクエリされたデータ（つまり、取得されたデータ）を少なくとも１つのキャッシュノードから受信する場合は、ソフトウェアアプリケーションは、クエリされたデータを用いてユーザリクエストを処理する。
ソフトウェアアプリケーションが損失をすべてのキャッシュノードから、読み込みクエリに応答して受信する場合は、ソフトウェアアプリケーションは１または複数のデータベースシステムを取り出し、クエリされたデータがデータベースシステムに存在する場合は、クエリされたデータを１または複数のデータベースシステムから取得した後で、ソフトウェアアプリケーションはクエリされたデータを用いてユーザリクエストを処理し、少なくとも１つのキャッシュノードにクエリされたデータを送信し、クエリされたデータを少なくとも１つのキャッシュノードに追加する指示を送信する。データベース内で見つからない場合は、データが存在しないことを示す情報をキャッシュに追加する。
各データは複数のキャッシュノードのうち少なくとも１つのキャッシュノードおよび１または複数のデータベースシステムに同一に保存されているか、またはキャッシュおよびデータベースの同一のデータの処理の一貫性を保証するような方法で保存される。
【００５６】
任意だが、有利には、少なくとも１つのデータの書き込みを要求するユーザリクエストを受信すると、ソフトウェアアプリケーションは、１または複数のデータベースシステムに書き込みの指示を送信し、クエリのみを複数のキャッシュノードに送信する。１または複数のデータベースシステムは、データストレージシステムの各損失された読み込みクエリおよび各書き込みクエリの複数のキャッシュノードを投入する指示も送信する。
【００５７】
本発明の別の態様では、航空会社の在庫のデータストレージシステムにデータを保存する方法と、データストレージシステムからデータを取得する方法とが提供される。データストレージシステムは、ソフトウェアアプリケーションと、１または複数のデータベースシステムと、複数のキャッシュノードとを備える。ソフトウェアアプリケーションは、少なくとも以下のうちの１つを要求するユーザリクエストを受信するように構成される。少なくとも１つのフライトに関する利用可能性を知るためにデータを読み込むことと、少なくとも１つのフライトに関する利用可能性を修正するためにデータに書き込むことである。ソフトウェアアプリケーションはさらに、読み込みクエリおよび書き込みクエリをデータストレージシステムに送信して、ユーザリクエストを処理するように構成される。本方法は、ソフトウェアアプリケーションは独自に１または複数のデータベースシステムおよび複数のキャッシュノードと接続することと、方法が少なくとも１つのデータプロセッサを備えるソフトウェアアプリケーションが実施する以下のステップを備えることを特徴とする。
少なくとも１つのフライトに関する利用可能性を知るためにデータを読み込むことを要求するユーザリクエストを受信すると、ソフトウェアアプリケーションは読み込みクエリのみを複数のキャッシュノードに送信する。
ソフトウェアアプリケーションがクエリされたデータ（つまり取得されたデータ）を少なくとも１つのキャッシュノードから受信する場合は、クエリされたデータを用いてユーザリクエストを処理する。
ソフトウェアアプリケーションがすべてのキャッシュノードから損失を受信する場合は、ソフトウェアアプリケーションは１または複数のデータベースシステムを読み出す。クエリされたデータがデータベースシステムにある場合は、クエリされたデータを１または複数のデータベースシステムから取得後、ソフトウェアアプリケーションはクエリされたデータを用いて、ユーザリクエストを処理し、クエリされたデータを少なくとも１つのキャッシュノードに送信し、クエリされたデータを少なくとも１つのキャッシュノードに追加する指示を送信する。
各データは、複数のキャッシュノードのうち少なくとも１つのキャッシュノードおよび１または複数のデータベースシステムに同一に保存されている。
【００５８】
任意ではあるが、有利には、少なくとも１つのフライトに関する利用可能性を修正するために、少なくとも書き込みを要求するユーザリクエストは、座席購入、座席キャンセル、座席変更のいずれかを要求するユーザリクエストである。
【００５９】
本発明の別の態様では、本発明はデータストレージシステムを提供する。データストレージシステムは、１または複数のデータベースシステムと、少なくとも１つのキャッシュノードと、少なくとも１つのデータプロセッサと、ソフトウェアアプリケーションとを備える。ソフトウェアアプリケーションを少なくとも１つのデータプロセッサで実行すると、前述の方法の任意の１つの実行を含む操作能力につながる。１または複数のデータベースシステムおよび少なくとも１つのキャッシュノードは独自にソフトウェアアプリケーションによって駆動されるように構成される。
【００６０】
有利には、キャッシュノードの数およびソフトウェアアプリケーションを実行するためのコンピュータ化手段の処理動力が適応され、ソフトウェアアプリケーションのすべてのエンドユーザが作成した集約したピークトラフィックに合致する。
【００６１】
任意には、本発明によるデータストレージシステムは、以下の任意の特徴およびステップのうちいずれか１つを備えていてもよい。
【００６２】
キャッシュノードの数およびストレージリソースを適応し、すべてのデータベースシステム内容を保持する。
【００６３】
データベースシステムの一部のデータは、２以上のキャッシュノードに保存される。
【００６４】
すべてのデータベースのシステムの内容が少なくとも１つのキャッシュノードにソフトウェアアプリケーションによって転送された場合は、少なくとも１つのキャッシュノードのヒット率クエリは最終的には１００％に到達する。
【００６５】
本発明の別の態様では、本発明のデータストレージシステムを備える旅行プロバイダの在庫を提供する。
【図面の簡単な説明】
【００６６】
【図１】本発明によるデータストレージシステムを示す。
【図２】エンドユーザがリクエストし、まだキャッシュに存在しないデータをアプリケーションで最終的には取得するプロセスを例示する。
【図３】アプリケーションからデータベースおよびキャッシュに同時に書き込むプロセスを記載する。
【図４】同時書き込み操作が発生する具体的な事例において、キャッシュデータをデータベースから取得するプロセスを例示する。
【図５】アプリケーションによってデータベースおよびキャッシュに同時に書き込みが実施されるデータのタイミングの詳細をさらに示す。
【図６】リクエストされたデータがキャッシュにもデータベースにも存在しない事例を例示する。
【図７】データベースの書き込みおよびキャッシュが削除される事例を例示する。
【発明を実施するための形態】
【００６７】
以下の本発明の詳細な説明は、添付図を参照する。説明には代表的な実施形態を含むが、その他の実施形態も可能であり、本発明の精神および範囲から逸脱することなく、記載した実施形態を変更することもある。
【００６８】
図１は本発明によるデータストレージシステム１００を説明する。そのソフトウェアアプリケーション１０は独自に、一方では、データベースシステム２０に接続し、他方では、キャッシュとも称されるキャッシュシステムに接続し、１または複数のキャッシュノード３０を備える。
【００６９】
以下で記載する本発明のデータベースキャッシュシステムは、特定のものであることは注目に値する。それは主に、データベースの内容全体が最終的には一式のキャッシュノードに転送されるためである。このキャッシュノードは、すべての読み込まれるトラフィックを保護するフロントエンド処理層として動作する。キャッシュノードが読み込まれるトラフィックを保護しない場合は、読み込まれるトラフィックはデータベースシステム２０に到達してしまうため、データストレージシステム１００の性能が大幅に改善される。十分な数のキャッシュノードを次に展開して、トラフィック全体をサポートし、データベースの内容全体を共に処理する。したがって、システムが立ち上がり、かなりの長期間稼働していた場合は、バックエンドデータベースに含有されるすべてのデータエンティティは、最終的には一式のキャッシュノードに転送されるか、キャッシュノードに存在する。それによって、すべての読み込みクエリはキャッシュノードによって取り扱われるため、もはやキャッシュの損失は起こらない。データベースの書き込みは、キャッシュおよびデータベースにおいて、体系的に実施される。そのため、キャッシュおよびデータベース内容は常に、一貫性を持つ。以下で記載するデータストレージシステムが、このように高速フロントエンド保存および処理システムをデータの格納庫として用いる場合であっても、キャッシュという用語は本発明の以下の説明で用いられる。
【００７０】
データストレージシステム１００は、データ処理システムでよく使われる伝統的なツリー階層アーキテクチャを取る。中間階層１２０はソフトウェアアプリケーション１０階層であり、ソフトウェアアプリケーション１０階層から、サービスプロバイダのプロプライエタリソフトウェアアプリケーション１０が実行される。以前ＧＤＳで用いられていた例では、これは通常、航空会社の保有飛行機のすべての予約および座席の予約を管理することを目的とする、任意の航空会社の在庫管理アプリケーションである。
【００７１】
クライアント階層１３０は、アプリケーション１０の遠隔ユーザ４０のすべてからなる。前述の航空会社在庫のように、サービスプロバイダが設定する旅行アプリケーションの事例では、エンドユーザは通常、伝統的な旅行代理店の旅行代理人である。また、エンドユーザには個人もいる。個人は任意の多くの利用可能な旅行ウェブサイトまたはオンライン旅行代理店を使用し、そこから旅行の依頼をだし、場合によってはオンラインで飛行機を使う旅行を予約する。
【００７２】
下階層はストレージ階層１１０であり、データベースシステム２０を備える。本発明はサービスプロバイダが用いるデータベースシステムについて考慮しない。市販の標準的なデータベースマネジメントシステム（ＤＢＭＳ）に基づくことがほとんどであるが、プロプライエタリデータベースシステムであってもよい。どちらのデータベースシステムをサービスプロバイダが用いるとしても、十分な量のハードウェアおよびソフトウェアリソースから実装され、サービスプロバイダのすべてのデータを保持し、処理する。図１では、データストレージシステム１００を実装するために必要なすべてのハードウェアリソースは、符号１０１で全体的に言及する個々のコンピュータのようなマシンとして示される。永続的で、不揮発性のストレージは各個々のコンピュータおよび、必要な場合は、別のデータディスク１０２から利用可能と考えられ、たとえば恒久的にデータベースの内容を保持する。
【００７３】
本発明のデータストレージシステムは、ストレージ階層１１０および中間階層１２０を備える。
【００７４】
本発明では、「ユーザリクエスト」または「リクエスト」という用語は、ユーザ４０からの要望を指し、アプリケーション１０まで到達する。ユーザは、旅行者または旅行代理人などの個人であってもよく、リクエストを送信するコンピュータ化されたシステムであってもよい。
【００７５】
本発明では、「データクエリ」または「クエリ」という用語は、アプリケーション１０からキャッシュノード３０まで、および／またはデータベースシステム２０まで送信される要望を指す。クエリは読み込みクエリまたは書き込みクエリであってもよい。
【００７６】
読み込みクエリは、少なくともキャッシュノードから得る指示を含み、またはデータベースシステムからデータを読み込む指示を含む。通常、データをデータベースシステムから取得する行為は、「読み込む」と示され、キャッシュノードからデータを取得する行為は「得る」と示される。クエリされたデータは少なくとも、少なくとも部分的に、ユーザリクエストを実現するために得る、または読み込まねばならないデータである。
【００７７】
書き込みクエリは、データを追加し、更新／設定し、または削除する指示を含む。通常、データベースシステムからのデータを修正するための行為は、「更新する」と表され、キャッシュノードからのデータを修正するための行為は、「設定する」と表される。
【００７８】
したがって、以下の発明では、アプリケーション１０はユーザリクエストを受信し、データクエリを送信する。これらのクエリは読み込みクエリまたは書き込みクエリである。
【００７９】
どちらのシステムを実際に用いるにしても、本発明はデータベース２０がサービスプロバイダの最終的なデータリポジトリであると推定する。データベース２０は次に、好ましくはＡＣＩＤ（原子性、一貫性、独立性および永続性）の特性一式を守り、したがって、データベーストランザクションが、原子性、一貫性、独立性および永続性に関して確実に処理されることを保証する。
【００８０】
従来技術で既知の前述したデータベースシステムに関して、本発明のソフトウェアアプリケーション１０は、このように独立して、専用インターフェース１２を通じてデータベース２０に、直接接続したままである。したがって、データベースシステムの動作は、ソフトウェアアプリケーション１０との専用インターフェース１４を独自に持つ、１または複数のキャッシュノード３０によってまったく影響されない。本発明の以下の説明でさらに論じるように、データベースが処理しなければならない必須のトランザクションのみをデータベースに送信するかは、ソフトウェアアプリケーション１０次第である。つまり、新規の予約が完了し、一般に、たとえば、キャンセルが発生するなどのために、予約の何らかの状況を変化しなければならない結果として、データベースの内容が恒久的に更新される場合などである。
【００８１】
したがって、キャッシュノード３０のいずれもデータベースシステム２０と接続しない。メッセージ、指示またはデータはまったく、データベースシステムとキャッシュノード３０との間で交換されない。
【００８２】
データストレージシステム１００では、ソフトウェアアプリケーション１０が処理するすべてのトラフィックは、次に、専用キャッシュソフトウェアアプリケーション１０のインターフェース１４を通じてサポートされる。図１に示すように、キャッシュは機能的にデータベースなどのストレージ階層に配置される。インターフェース１４および１または複数のキャッシュノード３０は、どのようなスループットが目標であっても、ソフトウェアアプリケーション１０の階層１２０で、およびキャッシュノードのためにストレージ階層１１０で、期待するスループットに見合う十分なハードウェアおよびソフトウェアリソースを提供し、展開することのみによって、データストレージシステム１００のすべてのトラフィックを処理できると想定される。したがって、多くのデータを処理することは、多くの計算および保存リソースをリソースに追加することによってのみ実現できる。このようにすると、システムの拡張性は、目標とするスループット、つまりそのコスト、電力損失および占有面積を実現するために展開する必要がある、コンピュータプラットフォームの数以外の構造的考慮によって限定されない。
【００８３】
前述の拡張性を効率的にするために、データストレージシステム１００は、キャッシュおよびデータベースで内容が一貫しているグローバルなキー／値データモデルに基づく。そのため、同じキーを用いて両方を取り出すことができる。データモデルは、このように、データベースおよびキャッシュに直接マッピング可能であるように選択される。特に、データの各セットは機能エンティティによってグループ分けされ、共通の一意キーによってインデックスが付けられる。これによって、内容がある程度異なっているとしても、データベースおよびキャッシュ両方の一意キーから全体的にすぐにアクセス可能となる。上記のように動作するためのデータモデルの唯一の要件は以下の通りである。
−キャッシュ内で更新されるべきデータの上位集合をロックするための更新前の能力。
−所与の更新によって影響を受ける、データベース内のすべてのキャッシュキーを更新するために推測する可能性。
【００８４】
旅行業界分野での典型的な例は以下の表の通りである。
【００８５】
【表１】
0006511394.tif 000002
式中、
（＊）Ｏ＆Ｄ＝出発地と目的地
（＊＊）区間はフライトの一部である。たとえば、ニース（ＮＣＥ）からニューヨーク（ＮＹＣ）まで、パリ（ＣＤＧ）での途中降機があるフライトを例に取る。このフライトには２つの区間がある。ＮＣＥ−ＣＤＧおよびＣＤＧ−ＮＹＣまでである（フライトが３つのＯ＆Ｄを有することに注意されたい。Ｏ＆Ｄ：ＮＣＥ−ＣＤＧ、ＮＣＥ−ＮＹＣおよびＣＤＧ−ＮＹＣである。）
【００８６】
前述の例では、スケジュール情報は関連するデータベースに保存される。「母」表はフライト−日付の一次キーを有する。「子」表のうち１つは、区間−日付一次キーを有する。一部の書き込み（たとえば更新）は、フライトレベルで行われ、他の書き込みは区間レベルで行われる。フライトレベルでロックすることは両方の事例で行われる。これを用いて、フライトおよびフライトのすべての区間においていかなる修正も行われないようにする。ロックは区間−日付レベルでは設定することはできない。なぜなら、フライトの更新は、次にすべての区間を更新し、同時更新につながることもありえるためである。
【００８７】
したがって、データベースおよびキャッシュのデータモデルは、まったく同一でない場合は、一貫性がなければならない。それによって、データベース記録がロックされることを許可しながら、キャッシュおよびデータベースの記録にアクセスするために同一の記号キーを導くことができる。
【００８８】
図１に示すアーキテクチャは、スループット全体をサポートし、またおよびキャッシュデータ一貫性のマネジメントを大幅に単純化する分散キャッシュとして、単一層クライアント側として構成されるキャッシュを用いる。クライアント側分散キャッシュを有することは、キャッシュを構成する様々なキャッシュノード３０の間のデータ分散が既知であり、ソフトウェアアプリケーション１０階層でクライアント側で計算されることを意味する。結果として、すべてのキャッシュノード３０は、したがって、完全に独立し、システムの拡張性は実際に潜在的には無制限である。ただし、実際に、ストレージ階層に新規のキャッシュノード３０を追加して処理動力をさらに得ることは、ノード間でのデータの分散もバランスが取れている場合にのみ、実現可能である。分散が実際にバランスが取れるようにするためには、データは分散キープロパティに基づいて分散される。たとえば、フライトに関するデータはフライト番号に基づいて分散される。利用可能なキャッシュノードの数または分散パラメータが変化することよって、分散の変化をもたらす修正は、たとえば、また、正常な再分散手順によってサポートされる。この手順では、キャッシュシステム全体をオンラインに維持し、再分散が起きている間、公称条件で動作する。この目的のため、２つのキャッシュ構成に対する一時的な複式供給については、本発明の以下の説明で後述する。
【００８９】
本発明のデータストレージシステム１００は、キャッシュとデータベース間にいかなる同期機構も必要としない。キャッシュはソフトウェアアプリケーション１０によって明示的に用いられる。つまり、たとえば、データベースまたはキャッシュが書き込まれなければならないとき、同一のユーザリクエストの間に、２つのデータソース、つまり、データベースまたはキャッシュのどちらか１つを用いるか、または両方を用いるかを決めるのはソフトウェアアプリケーション１０階層である。この手法の直接的な結果として、データベースがまったくキャッシュの存在に気づかず、本発明のデータ構造のキャッシュの存在または不在によって影響を受けない。逆も明らかに真である。キャッシュは完全にデータベースから切り離される。こうして、両方の構造は完全に、必要に応じて独自に進化する。
【００９０】
キャッシュ内のデータ書き込みは、無効ポリシーを用いないことに留意が必要である。すべての書き込みはデータを直ちにキャッシュと交換する結果となる。データベース全体の内容が最終的にはキャッシュにマッピングされ、すべての利用可能なキャッシュノード３０に分散され、非常に高レベルの同時書き込みが発生する場合であっても、ヒット率は１００％となる。
【００９１】
キャッシュデータは常に、有効であると考えることができ、有効性を確認するための追加のプロセスが必要ない。実際に、すべてのキャッシュは、失われた値をデータベースからキャッシュに追加するトリガを見逃す。これは最終的に行われ、したがって、データエンティティごとに１回のみ取り出して取得されるデータベースに対して最低限の負荷となるようにする。これは、キャッシュが動作可能となるとき、たとえば、キャッシュノード３０追加後にシステムを起動した後、故障またはキャッシュノード３０の後、メインテナンス操作の後に起きることが多い。本発明は、分散キャッシュノード３０内にデータベースの内容全体を受容する十分な余地があることを前提としている。
【００９２】
エンドユーザがリクエストしたデータがデータベース内にないこともキャッシュに記録される。エンドユーザがリクエストしたデータがキャッシュに発見できず、データベースからの取得できない場合は、データ不在がキャッシュに記録され、次回キャッシュがクエリを受けるとき、データベースの負荷を制限するために、対応するデータをデータベースから取り出す試みは行われない。
【００９３】
図１に記載するアーキテクチャは、キー−値方式を取れる任意の種類のデータに拡張可能である。また、キー−値方式を取れる任意のプロセスに適用可能である。具体的には、フライトの利用可能性を確認するように考案される任意のプロセスに適用可能である。
【００９４】
以下の図は、データベースとキャッシュとの間で、そのキャッシュを取得するためにソフトウェアアプリケーション１０が実行する操作を説明する。キャッシュは、最終的にはソフトウェアアプリケーション１０が生成するトラフィック全体をサポートし、すべてのユーザリクエストに対応する。
【００９５】
前述のように、システムのキャッシュ部分は、かなり単純であり、基本的なリモートキー／値プロトコルを提供する１または複数の独立したコンピュータからなる。キャッシュ上の３つの基本的な操作が次のように規定される。つまり、ソフトウェアアプリケーション１０にキャッシュを更新させること、キャッシュをデータベースから入力させること、およびデータをキャッシュから取得させることである。
設定（キー、値）：キーに関連する値を無条件に更新する。
追加（キー、値）：キーに関連する値がキャッシュにまだない場合は、追加する。
取得（キー）：キーに関連する値をキャッシュから返す。
本発明は、期待するレベルの性能が実現される限り、ソフトウェアアプリケーション１０によって実装される方法に関していかなる想定もしない。有利には、バルク操作が規定される。バルク操作によって、複数の基本的な操作を一緒に送信し、処理できるようになる。
【００９６】
システムの主要部分はソフトウェアアプリケーション１０階層にあり、キャッシュノード３０すべてにわたってデータ分散を制御する。キー／値データは、キャッシュを構成するノード間で分散する。すべてのノードにわたってできるだけ均一に分散できるように、キーのプロパティを抽出して、対応するキャッシュノード３０を次の計算式で計算する。
ノード_数＝数としてキー_プロパティ_MODULOノード数
【００９７】
フライトに関するデータはプロパティを用いる。連続したフライト番号が通常同一のプロパティを有するフライトに用いられる。この事例では、フライト番号は分散の基礎として直接用いられる。
【００９８】
フライトの出発地と目的地（Ｏ＆Ｄ）に基づくフライトに関するデータに対して、ハッシュ値は単独のＯ＆Ｄキーで計算される。
【００９９】
前述のように、すべての利用可能なノード上で、データ分散のバランスを取ることは、制限のない拡張性を実現するために実際に重要である。
【０１００】
図２および図３は、キャッシュにデータが入力される方法およびソフトウェアアプリケーション１０の制御のみで、キャッシュがデータベースの内容と一貫性を保つ方法を示す。
【０１０１】
図２はプロセスを記載する。プロセスは、最終的にはソフトウェアアプリケーション１０でエンドユーザがリクエストし、キャッシュにまだ存在しないデータを取得することを許可する。この状況がよく起こるのは、たとえば、システムの起動後にキャッシュにデータが入力されるときであり、または新規のノードを挿入したか除去し、キャッシュノード３０の内容のバランスを再び取ることが進行中である場合などである。
【０１０２】
ソフトウェアアプリケーション１０がユーザリクエストに応える必要があるとき、キャッシュはまず、「取得」操作２１０を通じて読み込まれる。航空会社の在庫データベースの例では、これは、たとえば、データベースのエンドユーザが発する多数のユーザリクエストの１つに答えることである。ユーザリクエストは、特定の日付、特定のクラスなどで具体的なフライトの座席が利用可能かどうかを判別するために行われる。対応するデータがキャッシュにない場合は、つまり、一般的に、対応するデータが以前の読み込みによって、まだキャッシュに取り入れられていない場合は、キャッシュは次に「損失」２２０をソフトウェアアプリケーション１０に返す。そうでない場合は、情報は、「取得」操作を送信するソフトウェアアプリケーション１０にキャッシュから単に返送されることは明らかである。ソフトウェアアプリケーション１０は、したがってエンドユーザのユーザリクエストを実行することができる。最終的には、ソフトウェアアプリケーション１０は、クエリされたデータを追加のデータと集約し、エンドユーザからのリクエストに応じて返送する。追加のデータは通常は、ユーザリクエストを実行するために必ず取得されることもある別のデータである。たとえば、一部のデータはキャッシュノードから得ることができるが、同一のユーザリクエストを実行するために必要な別のデータも他のキャッシュノードから取得し、および／またはデータベースシステム２０から読み込まねばならない。
【０１０３】
クエリされたデータがキャッシュにはないという情報を受信すると、ソフトウェアアプリケーション１０は、データベースに「読み込む」操作２３０で問い合わせる。損失情報は次に２４０でソフトウェアアプリケーション１０に返送される。データベースからのデータの読み込みは、前述したように、データベース専用インターフェース１２で行われる。これは、ソフトウェアアプリケーション１０から、対応するクエリを本発明のデータストレージシステム１００が用いるデータベースマネジメントシステム（ＤＢＭＳ）に発行することによって行われる。
【０１０４】
データベースからキャッシュにないデータを受信すると、ソフトウェアアプリケーション１０は次に、「追加」操作２５０を実施して、データをキャッシュに保存する。この時点以降、キャッシュが動作可能であり、再構成されない限り、データはキャッシュ内に存在する２７０。この操作が終了すると、肯定応答（ＯＫ）２６０がソフトウェアアプリケーション１０に返送される。
【０１０５】
このプロセスは、データベースおよびキャッシュノード３０同一に保存される、または一貫性を持つ任意の所与のデータに対してキャッシュが更新され、動作している間に１回のみ行われることに留意したい。これは、データがソフトウェアアプリケーション１０によってリクエストされたが、キャッシュにまだ存在していないときにまず起こる。この後、たとえば、航空会社座席が販売されて、データベースの内容を変更する必要がある場合は、対応するデータが更新されることもある。この事例では、後述するように、ソフトウェアアプリケーション１０は、キャッシュおよびデータベースの両方を更新するため、図２のプロセスを再実行する必要はまったくない。
【０１０６】
図３は、ソフトウェアアプリケーション１０から同時にデータベースおよびキャッシュを更新するプロセスを記載する。
【０１０７】
一貫したデータベースおよびキャッシュ内容を維持するために、ソフトウェアアプリケーション１０は常にキャッシュおよびデータベースの両方を更新する。キャッシュの更新は次に、前述の通り「設定」操作３１０で行われる。同時に、データベースの「更新」３０５は仕様しているＤＢＭＳのクエリ言語を用いて実施される。アプリケーションによってデータベースに対して操作がコミットされた後、更新３２０は効率的である。
【０１０８】
より具体的には、更新がデータベースで行われているときには、設定は行われないが、コミットが行われているときには設定が行われる。アプリケーションによって、データはコミットが終わるまで、メモリに設定されたままとなる。更新３０５と設定３１０との間に多数のステップがあることもある。ただし、設定３１０およびコミット３２０は続いて実施されるように意図される。
【０１０９】
安定状態では、つまりシステムが起動されて、長期間稼働した後で、データベースのすべての内容をすべてのキャッシュノード３０にわたって最終的に取り入れて、分散する。次に、更新操作、つまり内容更新、挿入および削除は、データベースインターフェース上で実施する必要があるが唯一の操作である。このため、データベース負荷が大幅に減少する。削除操作の場合は、図７に記載するキャッシュ内で対応するデータの無効化をトリガする。
【０１１０】
また、本発明のキャッシュは、図３のプロセスはキャッシュに書き込むために実行すべき任意の具体的な条件を想定していないため、読み込みおよび書き込み操作の両方から入力されることに留意しなければならない。これによって、キャッシュ入力のために読み込みのみを用いるシステムと比較して、起動後のキャッシュノード３０の入力を大幅に早めることができる。これは可能であり、このように単純に行われる。前述したように、データベースおよびキャッシュが保存するデータエンティティは、両方とも更新され続ける。データベースおよびキャッシュの内容が一般に大きく異なる他のキャッシュソリューションでは更新はされ続けない。これは、キャッシュストレージ要件を最小にしようとするためであり、またはソフトウェアアプリケーション１０に提供されるキャッシュデータエンティティが様々な部分のデータベースから抽出されたデータを解体して構成されているためである。
【０１１１】
図４は、図２のプロセスを記載する。具体的には、データベースの同時書き込み（たとえば更新）がソフトウェアアプリケーション１０からリクエストされ、したがってその実行に干渉する事例である。
【０１１２】
図２に記載した方式と同様に、プロセスはデータをキャッシュから「取得」する２１０から開始する。その後「損失」２２０が続き、損失しているデータをデータベースから取り出すこと２３０をトリガする。ただし、損失しているデータは通常は、ソフトウェアアプリケーション１０に戻される２４０。同一のデータに対する書き込みクエリ４１０もまた、ソフトウェアアプリケーション１０から受信される。書き込みは図３に説明するように行われる。キャッシュ内で、「設定」操作３１０およびデータベース内で「更新」操作３０５を用いて書き込みは行われる。「設定」がキャッシュに対して発行され、データベースにおいて、「コミット」３２０が送信されるとき、対応するデータは、直ちに利用可能４２０となる。設定がトリガされる前に、アプリケーションはデータをメモリに保持する（「メモリ内に設定」）。
【０１１３】
次に、この具体的な事例では、キャッシュ内容は以下の「追加」２５０によってさらに更新されてはならない。これは損失しているデータをデータベースから取り出す２３０行為の結果であり、データベースはその間に更新されているためである。「追加」２５２は次に、実際に中断される。否定応答（ＫＯ）２６２が戻され、ソフトウェアアプリケーション１０にキャッシュの更新が「追加」操作によって実際には行われていないことを通知する。
【０１１４】
したがって、キャッシュをデータベースに読み取ったデータで更新するために、本発明は追加コマンドを用いる。それによって、データをデータベースにロックせずに、データをキャッシュに送信することができる。実際に、データを追加しようとするときに、データがまだキャッシュにない場合は、効率的に追加される。更新プロセスによって、その間更新されていた場合は、追加は失敗するが、予想されていることである。更新プロセスはデータベース上にロックを持ち、このキーに対して更新する優先順位を持つ。したがって、これがキャッシュに留まることは通常のことである。
【０１１５】
本発明のこれらの特徴によって、特に、データベースシステムおよびキャッシュは、お互いの性能に対してロックもできず、影響を与えることもできないため、更新プロセスと非常にスムーズに一体化することが可能となる。同時に、データは１度しかデータベースで読み取られないため、データベースに対する負荷は最大限低くなる。
【０１１６】
図５は、ソフトウェアアプリケーション１０によってデータベースおよびキャッシュで同時に実施されるデータ更新のタイミングをさらに詳細に記載する。
【０１１７】
ソフトウェアアプリケーション１０は、対応するクエリ５１０をデータベースに発行して、現在保存されている値を取得することによって、更新トランザクションを開始する。同時に、同時更新が別のソフトウェアアプリケーション１０から行われないように、データベースマネジメントシステム（ＤＢＭＳ）は、現在保存されている値をロックする。ソフトウェアアプリケーション階層内で、データはソフトウェアアプリケーション１０によって処理される。データがＤＢＭＳによって、更新される用意ができると５３０、バッファキャッシュ５４０の更新がソフトウェアアプリケーション１０でも実施され、キャッシュに転送され保存されるべき新規データを保持する。
【０１１８】
次に、ソフトウェアアプリケーション１０は、変更５５０をコミットすることができ、変更５５０はキャッシュ５５２で「設定」操作で直ちに実施され、また、データベース５５４にコミットされる。このように、新規データは、実際にデータベースにコミットされ、利用可能５５８となるより少し前５５６にキャッシュで利用可能となることに気づくであろう。参照５５６は、データベースシステム２０ではまだ利用できないときに、更新が行われて、エンドユーザがキャッシュで利用可能となる時間枠を示す。
【０１１９】
たとえば、ハードウェアおよび／またはソフトウェアの故障など何らかの理由で、コミットするが通常通り終了しなかった場合は、以前のキャッシュへの書き込み操作、つまり「設定」操作５５２はロールバックされるため、キャッシュ内容は変更されない。したがって、コミットが失敗すると、「コミットＫＯ」５６０がアプリケーションに送られ、次に削除５６２をキャッシュに対して発行し、追加されたデータを削除する。その結果として、その期間５６４内に、誤った値が、キャッシュに存在することになる。
【０１２０】
したがってデータベースに関連せず最高性能の、影響の大きいデータ品質がキャッシュに提供される。更新はキャッシュに、ライトアヘッドコミットを用いて「コミット依頼」データで伝達される。相違する制約がキャッシュされたデータに禁じられている場合は、データベースと比較して、キャッシュ内のデータを「悪くても」前もって形成するが、具体的には、非常に高コストな通常の２段階のコミットアーキテクチャを用いずに、任意の追加のコストは発生しない。このような品質は、利用可能リクエストのためのデータ品質要件を満たし、最終的なクライアントの観点からの優位点としても考えられえる。
【０１２１】
図６は、クエリされたデータがキャッシュにもデータベースにもない事例を記載する。これは、データベースが保持していない情報をエンドユーザがリクエストしている場合を扱う。
【０１２２】
このような状況が発生すると、データベースへのさらなる問い合わせを避けるために、対応するデータ不在もキャッシュに記録される。すると、次回キャッシュがソフトウェアアプリケーション１０から問い合わせを受けるとき、クエリされたデータがデータベースに不在であるという情報が直接キャッシュ自体によって提供され、したがってさらにデータベース負荷が減少する。
【０１２３】
プロセスは図２に記載のものと類似している。キャッシュに対して発行された「取得」操作２１０が「損失」２２０を返答すると、データベースの対応するデータの読み込み２３０もまた、ソフトウェアアプリケーション１０にデータベース「損失」６４０を返答する。次に、データ不在がキャッシュに追加される６５０。データと同様に、データ不在はキャッシュで直ちに利用可能２７０になり、キャッシュは応答２６０をソフトウェアアプリケーション１０に返答する。
【０１２４】
非限定的な実施形態によれば、各データはヘッダと関連し、記録を形成する。ヘッダはデータベースシステム２０で内容が損失しているかどうかを示す。したがって、記録のヘッダを読み込むだけで、データベースシステムを取り出す価値があるかどうかを知ることができる。代替的実施形態によれば、キャッシュノードはデータに関連する特定の値を保存する。この特定の値はデータがデータベースに存在しないことを示す。したがって、記録の値を読み込むだけで、データベースシステムを取り出す価値があるかどうかを知ることができる。
【０１２５】
図７は、図３で前述した事例を例示する。この事例では、アプリケーションからの特定の更新操作がデータ７０５をデータベースから削除する。この操作は図３で説明するように全体的に実施されるが、削除されたデータは実際にはキャッシュから削除されず、「データ不在」として表示することによって示される。削除がアプリケーションによってデータベースコミットされる３２０と、対応する情報は特定の「設定」操作３１０でキャッシュに保存される。「データ不在」は直ちに利用可能３３０となる。したがって、前述したように、キャッシュが後ほど問い合わせを受ける場合は、リクエストされたデータはもはやキャッシュにもデータベースにもないという情報を直接提供することができる。
【０１２６】
以下では、たとえば、トラフィック増加に対応するために、本発明のデータベースシステムの構成を修正することが必要となる事例を論じる。図１に示すシステム構成を拡張するために、さらに多くのキャッシュストレージ収容能力を提供し、さらに多数の処理ノードに増加するトラフィックを分散するために、追加のキャッシュノードを追加しなければならない。ただし、多数のノードを用いて、一般にいうと、アクティブノードの数を変更しなければならないときはいつも、ノードで一意にデータに取り組むキーを再計算して、実際にすべてのトラフィックが均等に新規の完全なノードの組にわたって広がることができるようにしなければならない。
【０１２７】
本発明は、データベースおよびキャッシュから同一に保存され、取得されるデータエンティティからの計算キーの任意の具体的な方法を想定していない。ほとんどの場合、特定のアプリケーションによって処理されるデータの種類に応じて、一部のハッシュ機能を用いて、次にノードの数のモジューロを取ってさらに計算することによって、ノード処理をハッシュされたキーから単に引き出す。したがって、ノードの数が変更されると、違う結果が特定のデータエンティティを取得するために得られる。特定のデータエンティティは、新規の構成の違うノードで探す必要があるかもしれない。構成の更新はではなく、データベースシステムは完全に動作可能である間に透過的に実施されなければならないという事実から問題が発生する。すべてのキャッシュクライアントが同時に新規の構成を意識するわけではない。これは、データの一部の書き込みが、新規の構成に基づいて行いえるが、他の書き込みは古い構成を用いえることを意味する。結果として、キャッシュとデータベースとの間でデータセットが一貫しないことになりえる。
【０１２８】
本発明は、「複式供給」と呼ばれる手順を可能にすることでこの問題を処理する。複式供給とは、キャッシュに通常用いられる構成に追加して、１つの追加構成を維持するため、「複式供給」と呼ばれる。追加の構成はデフォルトではないが、構成変更時に起動可能である。起動されると、すべての書き込み操作は標準的な構成および複式構成の両方に送信される。生存時間（ＴＴＬ）はキャッシュの各アイテムに関連するプロパティである。名称が示唆するように、生存時間は、アイテムが有効である期間に対応する。生存時間が切れると、アイテムをもはやキャッシュから取得することができず、データが損失したかのように、キャッシュ損失につながる。これは、標準的な構成に１つ、複式構成に１つ等、構成によって設定可能である。生存時間が設定しないと、アイテムは失効しない。
【０１２９】
複式構成の起動もまた原子性ではないため、短い生存時間でまず起動されなければならない。複式供給構成が完全に起動されると、生存時間を削除することができる。生存時間が失効すると１度のみ、標準的な構成および複式構成を交換することができる。構成変更が終了すると、複式供給を停止することができる。構成が伝搬されているステップの間（複式の起動／停止）、一部の「無効」データは書き込まれるが、読み込まれていない場所でのみ書き込まれる。このように、手順は以下の通りである。
−短いＴＴＬを持つ複式供給構成の作成。
−複式構成の起動、その伝搬を待機。
−複式供給構成から短いＴＴＬを削除。
−標準的構成と複式供給構成との交換。伝搬を待機。
−複式の停止。
【０１３０】
システム上の任意の変更をオンラインで行うことができる手順一式を以下に記載する。
【０１３１】
提案されたアーキテクチャは、すべてのシステムが後でキャッシュなしでは適切に動作しない立場にならないような拡張性を提供する。このようは状況に対処するために、本発明の実施形態によれば、すべての維持操作はオンラインで行われるように意図され、最大でも１つのノード（またはトラフィックの等しい割合）を同時に（たとえばキャッシュノードアップグレードまたは１つずつ交換、複式供給機構を用いて実施されるグローバルなキャッシュ変更）行い、データベースへの影響を少なくする。
−キャッシュノードアップグレードまたは交換は１つずつ行われる。システムは、好ましくは、データベースを用いてこのノードがホストすべきであったデータを取得する。
−グローバルなキャッシュ変更は、通常、複数のキャッシュノードの追加または削除または変更であり、グローバルなディストリビューションの大幅な変更を引き起こし、前段落で述べたように複式供給機構を用いて実施される。
【０１３２】
前述した記載から、本発明がデータをキャッシュとデータベースとの間で一貫性を保つことができることは明らかである。これは、厳密にはＡＣＩＤに遵守していないが、高度に拡張可能であり、データベースには影響を与えず、１００％のヒット率を可能にし、何よりも、完全にデータ品質のニーズを満たす機構のおかげである。さらに、本発明によって、キャッシュは、高度に動的データとなり、つまり、キャッシュの負荷が減る効果の恩恵を得ながら、通常は、一元化データごとに１秒あたり数十の書き込みが可能となる。
【図１】
0006511394.tif 000003
【図２】
0006511394.tif 000004
【図３】
0006511394.tif 000005
【図４】
0006511394.tif 000006
【図５】
0006511394.tif 000007
【図６】
0006511394.tif 000008
【図７】
0006511394.tif 000009