JP2015535995A - データの保存および取得の方法およびシステム - Google Patents

データの保存および取得の方法およびシステム Download PDF

Info

Publication number
JP2015535995A
JP2015535995A JP2015533468A JP2015533468A JP2015535995A JP 2015535995 A JP2015535995 A JP 2015535995A JP 2015533468 A JP2015533468 A JP 2015533468A JP 2015533468 A JP2015533468 A JP 2015533468A JP 2015535995 A JP2015535995 A JP 2015535995A
Authority
JP
Japan
Prior art keywords
data
cache
database
software application
queried
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2015533468A
Other languages
English (en)
Other versions
JP6511394B2 (ja
Inventor
ジーン−チャールズ リダウティ,
ジーン−チャールズ リダウティ,
ジョエル シンガー,
ジョエル シンガー,
フロレン バラ,
フロレン バラ,
プルドン,フロリアン
ロマン ブートループ,
ロマン ブートループ,
コリン ピトラット,
コリン ピトラット,
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Amadeus SAS
Original Assignee
Amadeus SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/628,517 external-priority patent/US9037801B2/en
Priority claimed from EP12368027.4A external-priority patent/EP2713284B1/en
Application filed by Amadeus SAS filed Critical Amadeus SAS
Publication of JP2015535995A publication Critical patent/JP2015535995A/ja
Application granted granted Critical
Publication of JP6511394B2 publication Critical patent/JP6511394B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2379Updates performed during online database operations; commit processing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • G06F16/24552Database cache management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/275Synchronous replication

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

ソフウェアアプリケーションと、データベースシステムと、複数のキャッシュノードとを備えたデータストレージ方法及びシステムに関する。ソフトウェアアプリケーションは独自にデータベースシステムと第1の専用インターフェースで接続し、キャッシュノードと第2の専用インターフェースで接続する。特徴は:ソフトウェアアプリケーションは、クエリされたデータを用いてユーザリクエストを処理する。クエリされたデータがデータベースに存在する場合は、ソフトウェアアプリケーションはクエリされたデータを用いてユーザリクエストを処理し、キャッシュノードにクエリされたデータを送信し、クエリされたデータをキャッシュノードに追加するように指示を送信する。データベース内で見つからない場合は、データが存在しないことを示す情報をキャッシュに追加する。起動後のキャッシュノードの入力を大幅に早めることができる。【選択図】図1

Description

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

Claims (15)

  1. データをデータストレージシステム(100)に保存し、データを前記データストレージシステム(100)から取得する方法であって、前記データストレージシステム(100)は、ソフトウェアアプリケーション(10)と、1または複数のデータベースシステム(20)と、複数のキャッシュノード(30)とを備え、前記ソフトウェアアプリケーションはユーザリクエストを受信するように構成され、前記ユーザリクエストは少なくとも1つのデータの読み込みまたはデータの1つの書き込みを要求し、前記ソフトウェアアプリケーションはさらに、読み込みクエリまたは書き込みクエリを前記データストレージシステム(100)に送信して、前記ユーザリクエストを処理するように構成され、前記方法は、前記ソフトウェアアプリケーションが独自に前記1または複数のデータベースシステムおよび前記複数のキャッシュノード(30)と接続することと、前記方法が、少なくとも1つのデータプロセッサを備える前記ソフトウェアアプリケーションが実施する以下のステップを備えることを特徴とし、前記ステップは、
    少なくとも1つのデータの読み込みを要求するユーザリクエストを受信すると、前記ソフトウェアアプリケーション(10)は読み込みクエリのみ(210)を前記複数のキャッシュノード(30)に送信するステップと、
    前記ソフトウェアアプリケーション(10)がクエリされたデータを少なくとも1つのキャッシュノード(30)から、前記読み込みクエリに応答して受信する場合は、前記ソフトウェアアプリケーション(10)は、前記クエリされたデータを用いて前記ユーザリクエストを処理するステップと、
    前記ソフトウェアアプリケーション(10)が損失(220)をすべてのキャッシュノード(30)から、前記読み込みクエリに応答して受信する場合は、前記ソフトウェアアプリケーション(10)は前記1または複数のデータベースシステム(20)を取り出し(230)、前記クエリされたデータを前記1または複数のデータベースシステム(20)から取得すると、前記ソフトウェアアプリケーション(10)は前記クエリされたデータを用いて、前記ユーザリクエストを処理し、少なくとも1つのキャッシュノード(30)に、前記クエリされたデータと、前記クエリされたデータを前記少なくとも1つのキャッシュノード(30)に追加する(250)ように指示を送信するステップであり、
    少なくとも1つのデータの書き込みを要求するユーザリクエストを受信すると、前記ソフトウェアアプリケーション(10)は書き込みの指示を前記1または複数のデータベースシステム(20)に送信し、また、同時に書き込みの指示を前記複数のキャッシュノード(30)に送信し、それによって、前記複数のキャッシュノード(30)を前記データストレージシステム(100)の各損失された読み込みクエリおよび各書き込みクエリに投入する、
    方法。
  2. 書き込みクエリは、前記データベースシステム(20)のデータの追加、更新および削除のうち少なくとも1つを備える、請求項1に記載の方法。
  3. 前記ソフトウェアアプリケーション(10)は、前記クエリされたデータを前記少なくとも1つのキャッシュノードに追加することが無事終了したことに関する肯定応答(260)を受信する、請求項1〜2のうちいずれか1項に記載の方法。
  4. データの書き込み(410)が前記同一のクエリされたデータを前記1または複数のデータベースシステムから同時に取得する間に発生する場合は、前記クエリされたデータを前記少なくとも1つのキャッシュノードに後で追加(252)することは中断され、否定応答(262)が前記ソフトウェアアプリケーション(10)に戻され、それによって、前記ソフトウェアアプリケーションが前記書き込まれたデータを代わりに(420)用いることができる、請求項1〜3のうちいずれか1項に記載の方法。
  5. データを前記1または複数のデータベースシステム(20)に書き込むための指示を送信し、前記複数のキャッシュノード(30)に同時に書き込むための指示を送信すると、
    前記1または複数のデータベースシステムから、前記書き込みを適用する現在保存されているデータを取得(510)し、前記現在保存されているデータをロックするステップと、
    前記1または複数のデータベースシステムに、保存すべき新規データを書き込む(530)ステップと、
    ソフトウェアアプリケーション(10)にキャッシュバッファを書き込み(540)、保存すべき前記新規データを一時的に保持するステップと、
    前記少なくとも1つのキャッシュノードに保存すべき前記新規データを転送し、設定する(552)ステップと、
    前記トランザクションを前記1または複数のデータベースシステムにコミットする(554)ステップと、
    が実施される、請求項1〜4のうちいずれか1項に記載の方法。
  6. 前記コミットが失敗すると、前記アプリケーションソフトウェア(10)は指示を前記少なくとも1つのキャッシュノードに送信し、前もって設定された前記新規データを削除する、請求項5に記載の方法。
  7. 前記クエリされたデータが前記1または複数のデータベースシステムまたは前記複数のキャッシュノード(30)のいずれにもない場合は、
    前記1または複数のデータベースシステム(20)を取り出した(30)後、損失(640)が前記ソフトウェアアプリケーションに、前記クエリされたデータの代わりに戻され、
    前記ソフトウェアアプリケーション(10)は少なくとも1つのキャッシュノード(30)に不在のデータ(650)を送信し、前記不在のデータ(650)は前記少なくとも1つのキャッシュノード(30)に前記対応するクエリされたデータのために追加され、前記不在のデータはすべての次の読み込みクエリに対して直ちに利用可能(270)となり、
    それによって、前記ソフトウェアアプリケーション(10)が、前記損失しているクエリされたデータを取得するために、前記1または複数のデータベース(10)をさらに取り出すことを回避する、請求項1〜6のうちいずれか1項に記載の方法。
  8. 前記ソフトウェアアプリケーション(10)は独自に前記1または複数のデータベースシステム(20)と第1の専用インターフェース(12)で接続し、前記複数のキャッシュノード(30)と第2の専用インターフェース(14)で接続する、請求項1〜7のうちいずれか1項に記載の方法。
  9. 前記キャッシュノードおよび前記データベースの前記データモデルは一貫しており、それによって、キャッシュノードおよびデータベースのデータにアクセスするために、正確に同一の処理キーが得られる、請求項1〜8のうちいずれか1項に記載の方法。
  10. データが存在するときは、同一のデータが前記データベースおよび少なくとも1つのキャッシュノードに保存され、またはキャッシュおよびデータベースの前記同一のデータの前記処理の前記一貫性を保証するような方法で保存される、請求項1〜9のうちいずれか1項に記載の方法。
  11. ソフトウェアプログラム指示を含有するコンピュータプログラム製品であって、前記ソフトウェアプログラム指示を少なくとも1つのデータプロセッサによって実行する場合は、請求項1〜10のいずれか1つに記載の前記方法を実行することを含む、操作の実施につながる、プログラム。
  12. 1または複数のデータベースシステム(20)と、少なくとも1つのキャッシュノード(30)と、少なくとも1つのデータプロセッサと、ソフトウェアアプリケーション(10)とを備えるデータストレージシステム(100)であって、前記ソフトウェアアプリケーションを前記少なくとも1つのデータプロセッサによって実行することは、請求項1〜10のいずれか1つに記載の前記方法を実行することを含む操作の実施につながり、前記1または複数のデータベースシステム(20)および前記少なくとも1つのキャッシュノード(30)は、独自に前記ソフトウェアアプリケーション(10)によって起動される、システム。
  13. 前記キャッシュノードの数およびストレージリソースは、前記すべてのデータベースシステムの内容を保持するように適応される、請求項12に記載のデータストレージシステム(100)。
  14. 請求項12および13のいずれか1つに記載のデータストレージシステム(100)であって、前記データベースシステム(20)の一部のデータは、2以上のキャッシュノード(30)に保存される、システム。
  15. 旅行プロバイダの在庫は、請求項12〜14のうちいずれか1項に記載のデータストレージシステムを備える、在庫。
JP2015533468A 2012-09-27 2013-09-04 データの保存および取得の方法およびシステム Active JP6511394B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US13/628,517 US9037801B2 (en) 2012-09-27 2012-09-27 Method and system of storing and retrieving data
US13/628,517 2012-09-27
EP12368027.4 2012-09-27
EP12368027.4A EP2713284B1 (en) 2012-09-27 2012-09-27 Method and system of storing and retrieving data
PCT/EP2013/002655 WO2014048540A1 (en) 2012-09-27 2013-09-04 Method and system of storing and retrieving data

Publications (2)

Publication Number Publication Date
JP2015535995A true JP2015535995A (ja) 2015-12-17
JP6511394B2 JP6511394B2 (ja) 2019-05-15

Family

ID=49150900

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015533468A Active JP6511394B2 (ja) 2012-09-27 2013-09-04 データの保存および取得の方法およびシステム

Country Status (8)

Country Link
JP (1) JP6511394B2 (ja)
KR (1) KR101690288B1 (ja)
CN (1) CN104662539B (ja)
AU (1) AU2013324689B2 (ja)
CA (1) CA2882498C (ja)
IN (1) IN2015DN01332A (ja)
SG (1) SG11201501650WA (ja)
WO (1) WO2014048540A1 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106846802B (zh) * 2017-02-09 2021-01-05 陕西公路交通科技开发咨询公司 一种高速路数据处理方法及装置
KR102415155B1 (ko) 2018-05-11 2022-06-29 삼성에스디에스 주식회사 데이터 검색 장치 및 방법
FR3081238A1 (fr) * 2018-05-17 2019-11-22 Amadeus S.A.S. Mise en memoire cache de base de donnees
FR3092920B1 (fr) * 2019-02-14 2022-04-01 Amadeus Traitement d’interrogations de base de données complexes
CN111125138B (zh) * 2019-12-26 2023-08-25 深圳前海环融联易信息科技服务有限公司 一种轮询查询数据的方法、装置、计算机设备及存储介质
SG10202008564PA (en) * 2020-09-03 2021-12-30 Grabtaxi Holdings Pte Ltd Data Base System and Method for Maintaining a Data Base
CN116521969B (zh) * 2023-02-28 2023-12-29 华为云计算技术有限公司 一种数据检索方法、服务端、系统及相关设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08147201A (ja) * 1994-11-18 1996-06-07 Nippon Telegr & Teleph Corp <Ntt> トラヒックデータキャッシュ方法
JP2009193440A (ja) * 2008-02-15 2009-08-27 Nec Corp キャッシュシステム、サーバおよび端末
US20100180208A1 (en) * 2009-01-15 2010-07-15 Kasten Christopher J Server side data cache system
JP2010524083A (ja) * 2007-03-30 2010-07-15 マイクロソフト コーポレーション 共有・カスタマイズ可能なマルチテナントデータのメモリ内キャッシング

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6256710B1 (en) * 1995-04-28 2001-07-03 Apple Computer, Inc. Cache management during cache inhibited transactions for increasing cache efficiency
US6067550A (en) * 1997-03-10 2000-05-23 Microsoft Corporation Database computer system with application recovery and dependency handling write cache
US6609126B1 (en) * 2000-11-15 2003-08-19 Appfluent Technology, Inc. System and method for routing database requests to a database and a cache
US7434000B1 (en) * 2004-06-30 2008-10-07 Sun Microsystems, Inc. Handling duplicate cache misses in a multithreaded/multi-core processor
US7415487B2 (en) * 2004-12-17 2008-08-19 Amazon Technologies, Inc. Apparatus and method for data warehousing
EP1962195A4 (en) * 2005-12-02 2009-01-21 Ibm SYSTEM FOR IMPROVING ACCESS EFFICIENCY TO A DATABASE AND METHOD THEREFOR
US20090204583A1 (en) * 2006-06-08 2009-08-13 International Business Machines Corporation Method for providing access to data stored in a database to an application
US7711657B1 (en) * 2006-06-26 2010-05-04 Hewlett-Packard Development Company, L.P. Resource-reservation pricing structures based on expected ability to deliver
CN102103523A (zh) * 2009-12-22 2011-06-22 国际商业机器公司 锁分配控制的方法和装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08147201A (ja) * 1994-11-18 1996-06-07 Nippon Telegr & Teleph Corp <Ntt> トラヒックデータキャッシュ方法
JP2010524083A (ja) * 2007-03-30 2010-07-15 マイクロソフト コーポレーション 共有・カスタマイズ可能なマルチテナントデータのメモリ内キャッシング
JP2009193440A (ja) * 2008-02-15 2009-08-27 Nec Corp キャッシュシステム、サーバおよび端末
US20100180208A1 (en) * 2009-01-15 2010-07-15 Kasten Christopher J Server side data cache system

Also Published As

Publication number Publication date
CA2882498A1 (en) 2014-04-03
IN2015DN01332A (ja) 2015-07-03
SG11201501650WA (en) 2015-04-29
CN104662539B (zh) 2018-02-23
CA2882498C (en) 2020-11-17
KR101690288B1 (ko) 2016-12-28
AU2013324689B2 (en) 2016-07-07
CN104662539A (zh) 2015-05-27
JP6511394B2 (ja) 2019-05-15
WO2014048540A1 (en) 2014-04-03
AU2013324689A1 (en) 2015-04-09
KR20150075407A (ko) 2015-07-03

Similar Documents

Publication Publication Date Title
US9037801B2 (en) Method and system of storing and retrieving data
JP6511394B2 (ja) データの保存および取得の方法およびシステム
US10831720B2 (en) Cloud storage distributed file system
JP6165729B2 (ja) クライアント/サーバシステムの分散した複製コンテンツの強一貫性を維持するための方法およびシステム
US10817498B2 (en) Distributed transactions in cloud storage with hierarchical namespace
JP5841177B2 (ja) マルチサーバ予約システムにおける同期化メカニズムのための方法及びシステム
US20190370362A1 (en) Multi-protocol cloud storage for big data and analytics
US10817536B2 (en) Transferring connections in a multiple deployment database
US11010267B2 (en) Method and system for automatic maintenance of standby databases for non-logged workloads
WO2020009737A1 (en) Data replication and data failover in database systems
US9990225B2 (en) Relaxing transaction serializability with statement-based data replication
JP5193056B2 (ja) 無線装置の最新データを維持するための方法及びシステム
US10025710B2 (en) Pattern for integrating primary and secondary data stores in a sharded data domain
US10749955B2 (en) Online cache migration in a distributed caching system using a hybrid migration process
US10191936B2 (en) Two-tier storage protocol for committing changes in a storage system
CN113010549B (zh) 基于异地多活系统的数据处理方法、相关设备及存储介质
JP6833516B2 (ja) 分散データグリッドにおける分散データ構造をサポートするためのシステムおよび方法
SG192163A1 (en) System and method for session synchronization with independent external systems
US20190065327A1 (en) Efficient versioned object management
EP2713284B1 (en) Method and system of storing and retrieving data
JP2001265635A (ja) Sql文によるデータベース更新方法
JP2015064804A (ja) 無効リンクの発生を抑止するデータ管理システムおよび記憶装置

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20151014

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160606

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170531

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170626

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20170926

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171102

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180402

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20180702

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181002

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190311

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190408

R150 Certificate of patent or registration of utility model

Ref document number: 6511394

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250