JP6404892B2 - データベースシステムおよびデータ処理方法 - Google Patents

Description

本発明の実施形態は、データベースシステムおよびデータ処理方法に関する。

分散データベース技術においては、複数のサーバー装置が、それぞれ記憶手段を備えている。そして、その記憶手段上のデータが更新される際には、適宜、それら複数のサーバー間で記憶されているデータを同期させることにより、データの整合性を維持している。通常、それら複数のサーバー装置のうち、特定の一つのサーバー装置がマスターサーバー装置として機能し、他のサーバー装置はスレーブサーバー装置として機能する。そして、クライアント装置側からデータの更新を要求された場合、まずマスターサーバー装置上のデータを更新し、所定のタイミングでその更新がスレーブサーバー装置にも反映される。このマスターサーバー装置におけるデータの変更をスレーブサーバー装置側にも反映させることを、レプリケーションと呼ぶ。

レプリケーションには、大別して２種類の方式が存在する。それらは、非同期レプリケーションと同期レプリケーションである。

非同期レプリケーションにおいては、クライアント装置からマスターサーバー装置にデータ更新の要求があった場合、マスターサーバー装置は、マスターサーバー装置上のデータを更新した後、すぐにクライアント装置へのレスポンスを返す。マスターサーバー装置は、クライアント装置へのレスポンスを返した後で、更新データをスレーブ装置側に送信する。非同期レプリケーションは、スレーブサーバー装置でのデータの書き込み完了を待たずにレスポンスを返すため高速であるというメリットがある反面、障害時にデータを損失してしまい、マスター側とスレーブ側とでデータが一致しなくなるというリスクがある。また、非同期レプリケーションは、ある一時点において、マスター側とスレーブ側とでデータがずれている（同期していない）というデメリットもある。

同期レプリケーションにおいては、クライアント装置からマスターサーバー装置にデータ更新の要求があった場合、マスターサーバー装置は、スレーブサーバー装置側でもデータの更新が完了するのを待ってからクライアント装置へのレスポンスを返す。同期レプリケーションは、マスター側とスレーブ側とで常にデータの同期が取れているというメリットがある反面、クライアントへの応答が遅いというデメリットもある。また、コミットメントの単位でマスター側とスレーブ側との同期を行うため、同期に要する時間もより多くかかるというデメリットもある。

つまり、非同期レプリケーションにおいては、レプリケーションするデータがたまってしまうという問題がある。また、同期レプリケーションにおいては、個々のデータ更新において余計に時間がかかるため、クライアント装置側から見た性能に問題が生じ得るという問題がある。

これらの問題を解決するため、従来技術では、マスターサーバー装置側でのデータ更新頻度に基づいて、半同期レプリケーションと非同期レプリケーションとを切り替えることを行う。この方式では、マスターサーバー装置側からスレーブサーバー装置側にデータを送信する際に、スレーブサーバー装置側から応答を受け取らずにマスターサーバー装置が継続動作するため、完全な同期レプリケーションではない。
この従来技術では、マスターサーバー装置側でのデータ更新頻度のみに基づいて半同期レプリケーションと非同期レプリケーションとを切り替えいるため、スレーブ装置側の負荷やネットワークの負荷は考慮されないという問題がある。また、スレーブサーバー装置がマスターサーバー装置への応答を行わないため、同期が完全ではないという問題がある。

また、他の従来技術では、マスターサーバー装置側での実行結果により、マスターサーバー装置側からスレーブサーバー装置側に、物理ログを転送する方法と論理ログを転送する方法を切り替えている。ここで、物理ログを転送する方式は、変更されたデータそのものをログとして記録する方式である。また、論理ログを転送する方式は、データベースをどのように更新したかを示す情報（典型的には、実行されたＳＱＬ文）をログとして記録する方式である。なお、ＳＱＬは「ストラクチャードクエリー言語（Structured Query Language）」の略である。
この従来技術では、マスターサーバー装置側でデータ更新型の重いクエリーを実行したとき、スレーブサーバー装置側での同期完了に時間がかかり過ぎるという問題がある。この問題について、次に具体的に説明する。

マスターサーバー装置側とスレーブサーバー装置側でのデータのずれを所定範囲内におさえるために、同期間隔の時間が設定される。この同期間隔をＴ_ＩＮＴとする。マスターサーバー装置側で時刻Ｔ_０から（Ｔ_０＋Ｔ_ＩＮＴ）までの間に実行されたデータ更新は、スレーブサーバー装置側においても時刻（Ｔ_０＋２・Ｔ_ＩＮＴ）までには完了することが望ましい。このように、分散データベースシステムとして、スレーブ装置側にデータが反映されるための遅延の目標が設定されていることにより、データベースを利用するアプリケーションでの性能設計が容易になる。しかしながら、データ更新型の重いクエリーがデータベースシステムに要求された場合、そのクエリーの実行自体にＴ_ＩＮＴ以上の時間を要する場合がある。従来技術では、マスターサーバー装置側でその重いクエリーの実行を完了してからスレーブサーバー装置側に当該クエリーの実行を命令する。すると、マスターサーバー装置側でのクエリー実行完了時からスレーブサーバー装置側でのクエリー実行完了時までに、Ｔ_ＩＮＴ以上の時間がかかり、つまり、上記の遅延の目標が達成されないという問題が生じ得る。

特開２００６−３１８０２０号公報 特開２０１３−２１８６３５号公報

本発明が解決しようとする課題は、データ更新型の重いクエリーを実行する際にも、マスターからスレーブへのデータ反映の遅延を所定の目標遅延時間内に抑えることができるデータベースシステムおよびデータ処理方法を提供することである。

実施形態のデータベースシステムは、マスターサーバー装置と、スレーブサーバー装置とを持つ。
マスターサーバー装置は、マスター側記憶部と、マスター側要求変換部と、マスター側命令実行部と、マスター側レプリケーション実行部とを持つ。マスター側記憶部は、データを記憶する。マスター側要求変換部は、要求されるクエリーを受信し、受信した前記クエリーが通常のクエリーであるか重いクエリーであるかを判定する。マスター側命令実行部は、前記マスター側要求変換部が受信した前記クエリーを実行して前記マスター側記憶部に記憶されている前記データを処理するとともに、前記クエリーの実行結果を前記スレーブサーバー装置側にレプリケーションするためのレプリケーションデータを生成する。マスター側レプリケーション実行部は、前記マスター側命令実行部によって生成された前記レプリケーションデータを前記スレーブサーバー装置側に転送する。
スレーブサーバー装置は、スレーブ側記憶部と、スレーブ側レプリケーション実行部とを持つ。スレーブ側記憶部は、前記マスター側記憶部が記憶する前記データのレプリケーションを記憶する。スレーブ側レプリケーション実行部は、前記マスター側レプリケーション実行部から転送された前記レプリケーションデータに基づき、前記スレーブ側記憶部に記憶された前記データのレプリケーションを更新する。
そして、マスター側レプリケーション実行部は、前記マスター側要求変換部が通常のクエリーであると判定した前記クエリーに関する前記レプリケーションデータを、マスター側命令実行部が当該クエリーの実行を完了した後に前記スレーブサーバー装置側に転送するとともに、前記マスター側要求変換部が重いクエリーであると判定した前記クエリーに関する前記レプリケーションデータを、マスター側命令実行部が当該クエリーの実行を完了したか否かに関わらず前記スレーブサーバー装置側に転送する。

第１の実施形態のデータベースシステムの概略機能構成を示すブロック図。 第１の実施形態のマスターサーバー装置の通常時の動作のシーケンスを示す概略図。 第１の実施形態のマスターサーバー装置において、重いクエリーが発生したときの動作のシーケンスを示す概略図。 第１の実施形態のデータベースシステムに更新型の重いクエリーの実行が要求されたときの処理の流れの例を示す概略図。 第１の実施形態のデータベースシステムに更新型の重いクエリーの実行が要求されたときの処理の別の例を示す概略図。 第１の実施形態のデータベースシステムに、複数の更新型の重いクエリーの実行が同時期に要求されたときの処理の別の例を示す概略図。 第１の実施形態のデータベースシステムに、複数の更新型の重いクエリーの実行が同時期に要求されたときの処理の別の例（スレーブ側の並列実行）を示す概略図。 第１の実施形態のマスターサーバー装置側でのクエリーの実行と、マスターサーバー装置からスレーブサーバー装置に対して同期時に送信されるデータとを示す概略図。 第１の実施形態において、マスターサーバー装置側から送信されるデータを受信したスレーブサーバー装置側での処理例の概要を示す概略図。 第１の実施形態において、マスターサーバー装置側から送信されるデータを受信したスレーブサーバー装置側での、別の処理例の概要を示す概略図。

以下、実施形態のデータベースシステムおよびデータ処理方法を、図面を参照して説明する。

図１は、本実施形態によるデータベースシステムの概略機能構成を示すブロック図である。図示するように、データベースシステム１は、マスターサーバー装置２と、スレーブサーバー装置３と、を含んで構成される。
なお、同図では、スレーブサーバー装置３が１台のみ存在する場合を示しているが、スレーブサーバー装置３が複数台存在する構成として、データベースシステム１を構成するようにしてもよい。

データベースシステム１は、このように複数のサーバー装置で構成される分散データベースシステムである。一例として、データベースシステム１は、リレーショナル形式のデータベースである。ただし、データベースシステム１が、他の形態のデータベース（例えば、ＸＭＬデータベースやオブジェクト指向データベース等）であってもよい。なお、ＸＭＬは、「Extensible Markup Language」（拡張マークアップ言語）の略である。以下では、データベースシステム１がリレーショナルデータベースである場合を説明するが、本実施形態の技術は、他の形態のデータベースにも適用可能である。

データベースシステム１は、マスター／スレーブ式の分散データベースシステムである。マスターサーバー装置２は、マスターデータベースの機能を備える。また、スレーブサーバー装置３は、スレーブデータベースの機能を備える。マスターサーバー装置２は、分散データベースシステムにおける主たるデータを内部に保持し、管理する。一方、スレーブサーバー装置３は、分散データベースシステムにおける従たるデータを内部に保持し、管理する。

データベースシステム１は、マスター／スレーブレプリケーション（複製）を行うことにより、マスターサーバー装置２とスレーブサーバー装置３との間でデータを同期させる。つまり、データベースシステム１がデータベースへの書き込み要求を受けたとき、マスターサーバー装置２側だけではなく、スレーブサーバー装置３側にもデータを書き込む。これにより、スレーブサーバー装置３は、マスターサーバー装置２のバックアップとして機能することが可能となる。つまり、故障等の理由によってマスターサーバー装置２が機能しなくなったときに、スレーブサーバー装置３がマスターに昇格してサービスを引き継ぐことが可能となる。また、読み出しのみのクエリーについては、スレーブサーバー装置３でも行うようにすることで、サーバー全体としての負荷を分散させることが可能となる。

クライアント装置は、マスターサーバー装置２またはスレーブサーバー装置３に対してＳＱＬ文を送り、クエリーを実行させ、クエリーの実行結果を受け取る。マスターサーバー装置２は、データの更新を行うクエリー（ＳＱＬのＩｎｓｅｒｔ文やＵｐｄａｔｅ文やＤｅｌｅｔｅ文）を含み、あらゆる種類のクエリーを受け取って実行することができる。一方、スレーブサーバー装置３は、前述の通り読み出しのみ（ｒｅａｄ−ｏｎｌｙ）のクエリー（ＳＱＬのＳｅｌｅｃｔ文等）を受け取って実行することができる。クライアント装置は、クエリーの種類に応じて適宜接続先のサーバー装置（マスターサーバー装置２またはスレーブサーバー装置３）を選択する。あるいは、データベースシステム１のフロントエンドに位置するミドルウェア機能が、クエリーの種類に応じて、クライアント装置からのクエリーを、マスターサーバー装置２またはスレーブサーバー装置３のいずれか適切な側に振り分けるようにしてもよい。
なお、図示するように、マスターサーバー装置２に接続されるクライアント装置を、クライアント装置１０２とする。また、スレーブサーバー装置３に接続されるクライアント装置を、クライアント装置１０３とする。

本実施形態では、マスター／スレーブレプリケーションとして、非同期レプリケーションの方式を用いる。つまり、データ更新を伴うクエリーが要求されたとき、マスターサーバー装置２は、マスターサーバー装置２側でのデータ更新が完了すると、スレーブサーバー装置３側でのデータ更新の完了を待たずに、クライアント装置へのレスポンスを返す。マスターサーバー装置２からスレーブサーバー装置３へのデータの送信は、その後で行われる。例えば、一定時間ごとにマスターサーバー装置２からスレーブサーバー装置３へのデータ送信を行ったり、データベースシステム１の負荷が低いときに一定時間ごとにマスターサーバー装置２からスレーブサーバー装置３へのデータ送信を行ったりする。なお、マスターサーバー装置２とスレーブサーバー装置３との間でのデータ更新のタイミングのずれを所定の範囲内に抑えるため、同期遅延時間が適宜設定される。データベースシステム１においては、この同期遅延時間を超える更新タイミングのずれが生じないようにすることが、性能目標の一つである。

なお、レプリケーションを行う方式の一例として、マスターサーバー装置２からスレーブサーバー装置３に、ＷＡＬログを転送する。なお、ＷＡＬは、「Write Ahead Logging」（ログ先行書き込み）の略である。ＷＡＬログは、物理ログと論理ログの２つに分類される。物理ログは、変更を行ったデータそのもの（変更されたページそのもののデータや、変更したレコードのデータとページを特定する情報とページ内におけるレコード位置を特定する情報の組み合わせなど）を、保持するログである。一方、論理ログは、データベースをどのように変更したかを表す情報を保持するログである。論理ログの典型例としては、実行されたＳＱＬ文をログとして記録する。スレーブサーバー装置３側では、受け取ったＷＡＬログ（物理ログまたは論理ログ）を用いて、データを更新する。

次に各装置の詳細な機能構成について説明する。
図１に示すように、マスターサーバー装置２は、要求変換部２１（マスター側要求変換部）と、命令実行部２２（マスター側命令実行部）と、レプリケーションデータ保持部２３と、記憶部２４（マスター側記憶部）と、レプリケーション実行部２５と、を含んで構成される。これらの各機能は、電子回路を用いて実現される。また、情報を記憶するために、適宜、半導体メモリーや磁気ハードディスク等の情報記憶手段を用いる。なお、コンピュータープログラムを用いて上記各部の少なくとも一部を実現するようにしてもよい。

要求変換部２１は、クライアント装置１０２から送られるＳＱＬ文によるデータアクセス要求（クエリー）を受けとり、その要求を命令実行部２２が実行可能な形式の命令に変換する。また、要求変換部２１は、クライアント装置１０２からのＳＱＬ文を受け取った際に、そのＳＱＬ文と、その時点でのデータベースの状態とを解析し、そのクエリーを実行するために要する時間コストを見積もる。ここで、データベースの状態とは、データベース上の各テーブルのデータ量や、各テーブルがどのキーによるインデックスを有しているかといった情報などである。なお、クエリーを実行するために要する時間コストを見積もる技術自体は、既存の技術である。また、要求変換部２１は、見積もった時間コストと所定の閾値とに基づいて、そのクエリーが通常クエリーであるか、重いクエリーであるかを判別する。そして要求変換部２１は、その判別結果に応じた処理を、命令実行部２２に実行させる。
つまり、要求変換部２１は、要求されるクエリーを受信し、受信したクエリーが通常のクエリーであるか重いクエリーであるかを判定する。
要求変換部２１は、命令実行部２２における処理が完了すると、クライアント装置１０２にレスポンスを返す。

なお、重いクエリーの典型例は、条件節（Ｗｈｅｒｅ節）を含まずある程度以上のサイズのテーブルの全レコードを更新する全件Ｕｐｄａｔｅや、同じく条件節を含まずある程度以上のサイズのテーブルの全レコードを削除する全件Ｄｅｌｅｔｅである。また、多数のレコードをあるテーブルから読み込んで、他のテーブルに挿入するＳｅｌｅｃｔ Ｉｎｓｅｒｔも、重いクエリーの典型例である。

命令実行部２２は、要求変換部２１によってＳＱＬ文から変換された命令を実行する機能を有する。その命令は、マスターサーバー装置２の記憶部２４が保持するデータを参照したり更新したりするものである。また、命令実行部２２は、レプリケーション実行部２５に、レプリケーションの処理を命令する。具体的には、命令実行部２２は、要求変換部２１における判別結果（通常のクエリーであるか、重いクエリーであるか）により、異なるレプリケーションのしかたをレプリケーション実行部２５に実行させる。通常のクエリーの場合には、命令実行部２２は、レプリケーションデータ保持部２３内のレプリケーションデータリストにレプリケーションデータを書き込み、レプリケーション実行部２５に通常の非同期レプリケーションを実行させる。一方、重いクエリーの場合には、命令実行部２２は、レプリケーションデータ保持部２３内のレプリケーションデータリストにレプリケーションデータを書き込み、レプリケーション実行部２５にスレーブサーバー装置との同期処理をすぐに実行させる。
つまり、命令実行部２２は、要求変換部２１が受信したクエリーを実行して記憶部２４に記憶されているデータを処理（参照や更新）するとともに、クエリーの実行結果をスレーブサーバー装置３側にレプリケーションするためのレプリケーションデータを生成する。
そして、命令実行部２２は、命令された処理の完了後に、要求変換部２１にレスポンスを返す。

また、本実施形態では、命令実行部２２は、要求変換部２１が通常のクエリーであると判定したクエリーに関して、クエリーの実行結果であるデータの物理ログをレプリケーションデータとして生成し、要求変換部２１が重いクエリーであると判定したクエリーに関して、クエリーそのものを前記レプリケーションデータとして生成する。これにより、通常のクエリーについてはスレーブ側でのレプリケーション実行効率を優先させることができる。また、重いクエリーについては大量のレプリケーションデータの転送を避ける、即ち、レプリケーションデータの転送コスト（時間、通信量）の低下を優先させることができる。

レプリケーションデータ保持部２３は、レプリケーションデータリストを保持する。レプリケーションデータリストは、先入先出（ＦＩＦＯ）方式のリストであり、複数のレプリケーションデータを含む。命令実行部２２がレプリケーションデータリストへの書き込みを行う。また、レプリケーション実行部２５が、レプリケーションデータリストからレプリケーションデータを読み出すとともに、読み出して処理済みのデータを削除する。
レプリケーションデータは、個々のクエリーに対応するものである。レプリケーションデータは、クエリーの実行結果であるデータの物理ログ、またはクエリーそのもののデータ（論理ログ）のいずれかの形態を取り得る。これらのいずれの形態であっても、レプリケーションデータは、クエリーによるデータ更新の結果を再現することができる情報である。

また、レプリケーションデータ保持部２３は、コミットデータリストをも保持する。コミットデータリストは、複数のコミットデータを含む。コミットデータは、データの更新をコミット（commitment）する処理に対応する。データベースの更新を行う際、マスターサーバー装置２とスレーブサーバー装置３との間で、物理的にはデータの内容が異なる状況が生じ得る。しかし、コミットデータに基づいてコミット制御（コミットしたりロールバックしたり）することにより、マスターサーバー装置２とスレーブサーバー装置３との間でのデータの整合を図ることができる。

記憶部２４は、データベースシステムに含まれるテーブルのデータや、索引のデータや、各種の管理のためのデータを記憶するものである。

レプリケーション実行部２５は、レプリケーションデータ保持部２３からレプリケーションデータリストを読み出し、レプリケーションを実行する。通常時においては、レプリケーションデータ保持部２３は、レプリケーションデータリスト内のコミットデータを随時チェックし、レプリケーションを実行する。要求変換部２１が重いクエリーを受け取ったと判断した場合には、レプリケーション実行部２５は、コミットデータリストにあるデータをすべてコミットしてから、それらのコミットメントが完了してから重いクエリーのレプリケーションを実行する。
つまり、レプリケーション実行部２５は、命令実行部２２によって生成されたレプリケーションデータをスレーブサーバー装置３側に転送する。このレプリケーションデータの転送により、マスターサーバー装置２側でのクエリー（データ更新）の完全な情報が、スレーブサーバー装置３側に伝わる。
また、レプリケーション実行部２５は、要求変換部２１が通常のクエリーであると判定したクエリーに関するレプリケーションデータを、命令実行部２２が当該クエリーの実行を完了した後にスレーブサーバー装置３側に転送するとともに、要求変換部２１が重いクエリーであると判定したクエリーに関するレプリケーションデータを、命令実行部２２が当該クエリーの実行を完了したか否かに関わらずスレーブサーバー装置３側に転送する。これにより、スレーブサーバー装置３側での重いクエリーの実行の遅延時間を減らすことができる。

また、スレーブサーバー装置３は、要求変換部３１と、命令実行部３２と、記憶部３４（スレーブ側記憶部）と、レプリケーション実行部３５（スレーブ側レプリケーション実行部）と、を含んで構成される。これらの各機能も、マスターサーバー装置２のそれらと同様に、電子回路を用いて実現される。また、情報を記憶するために、適宜、半導体メモリーや磁気ハードディスク等の情報記憶手段を用いる。なお、コンピュータープログラムを用いて上記各部の少なくとも一部を実現するようにしてもよい。

要求変換部３１は、クライアント装置１０３から送られるＳＱＬ文によるデータアクセス要求（クエリー）を受けとり、その要求を命令実行部３２が実行可能な形式の命令に変換する。なお、前述の通り、要求変換部３１がクライアント装置１０３から受け取るクエリーは、データの読出しのみ（ＳＱＬのＳｅｌｅｃｔ文等）のクエリーである。
要求変換部３１は、命令実行部３２における処理が完了すると、クライアント装置１０３にレスポンスを返す。

命令実行部３２は、要求変換部３１によってＳＱＬ文から変換された命令を実行する機能を有する。その命令は、スレーブサーバー装置３の記憶部３４が保持するデータを参照するものである。
命令実行部３２は、命令された処理の完了後に、要求変換部３１にレスポンスを返す。

記憶部３４は、データベースシステムに含まれるテーブルのデータや、索引のデータや、各種の管理のためのデータを記憶するものである。基本的に、記憶部３４が保持するテーブルのデータは、マスターサーバー装置２側からレプリケーションされるデータである。つまり、レプリケーション実行部３５が、マスターサーバー装置２側から受け取ったレプリケーションデータに基づき、記憶部３４を更新する。
つまり、記憶部３４は、マスターサーバー装置２側の記憶部２４が記憶するデータのレプリケーションを記憶する。

レプリケーション実行部３５は、マスター側からのレプリケーションを実行する。つまり、レプリケーション実行部３５は、レプリケーション実行部２５から受け取ったレプリケーションデータに基づいて、記憶部３４上のデータを更新する。なお、ここで言う「更新」は、ＳＱＬのＵｐｄａｔｅ文やＩｎｓｅｒｔ文やＤｅｌｅｔｅ文に対応するデータ処理である。つまり、レプリケーション実行部３５は、マスターサーバー装置２側のレプリケーション実行部２５から転送されたレプリケーションデータに基づき、記憶部３４に記憶されたデータのレプリケーションを更新する。

また、レプリケーション実行部３５は、重いクエリーであると判定されたクエリーに関してクエリーそのものをレプリケーションデータとしてマスターサーバー装置２側のレプリケーション実行部２５から受信した場合には、通常のクエリーであると判定されたクエリーに関してレプリケーション実行部２５から受信済みであった物理ログに基づくデータのレプリケーションの更新をすべて実行した後で、当該重いクエリーであると判定されたクエリーに基づくデータのレプリケーションの更新を実行する。これにより、データ更新の際のデータの整合性が維持される。

また、レプリケーション実行部３５は、複数のクエリーに対応するレプリケーションデータを時系列に並べて管理するとともに、この時系列にしたがってレプリケーションデータに基づくデータの更新を実行する。これにより、データ更新の際のデータの整合性が維持される。

また、レプリケーション実行部３５は、重いクエリーであると判定されたクエリーに対応するレプリケーションデータに基づくデータのレプリケーションの更新が完了するまでは、当該重いクエリーに後続する他のクエリーに対応するレプリケーションデータに基づくデータのレプリケーションの更新の処理を待機する。これにより、データ更新の際のデータの整合性が維持される。

次に、図２および図３を参照しながら、マスターサーバー装置２の、通常時の動作および重いクエリーが発生したときの動作についてそれぞれ説明する。

図２は、マスターサーバー装置２の通常時の動作のシーケンスを示す概略図である。以下、番号順に、このシーケンスを説明する。
（１）まず要求変換部２１がクライアント装置側からクエリー（ＳＱＬ）を受け取る。そして、要求変換部２１は、クエリーの実行コスト（時間コスト）を見積り、通常クエリーであるか重いクエリーであるかを判定する。本図のケースでは、通常クエリーである場合を説明する。したがって、要求変換部２１は、以下の処理において、通常の非同期レプリケーションを実行させる。
（２）次に、命令実行部２２は、要求変換部２１からの命令に基づき、レプリケーションデータ保持部２３が保持するレプリケーションデータリストに、データを追加する。そして、命令実行部２２は、要求変換部２１から指示されたクエリーの処理を実行する。
（３）レプリケーション実行部２５は、要求変換部２１および命令実行部２２の処理と並行して、レプリケーションデータリスト内のコミットデータリストを随時チェックし、コミットデータを取り出して、スレーブサーバー装置３側へのレプリケーションを実行する。

図３は、マスターサーバー装置２において、重いクエリーが発生したときの動作のシーケンスを示す概略図である。以下、番号順に、このシーケンスを説明する。
（１）まず要求変換部２１がクライアント装置側からクエリー（ＳＱＬ）を受け取る。そして、要求変換部２１は、クエリーの実行コスト（時間コスト）を見積り、通常クエリーであるか重いクエリーであるかを判定する。本図のケースでは、重いクエリーである場合を説明する。この場合、要求変換部２１は、レプリケーション実行部２５がすぐにレプリケーションを実行するよう、命令実行部２２に指示する。
（２）次に、命令実行部２２は、レプリケーション実行部２５に、上記の重いクエリーまでを含めた同期をすぐに実行するように命令する。そして、命令実行部２２は、要求変換部２１から指示されたクエリー（重いクエリー）の処理を実行する。
（３）レプリケーション実行部２５は、コミットデータリスト内のすべてのデータのレプリケーションを実行する。即ち、レプリケーション実行部２５は、それらのデータをすべてコミットする。そして、その完了後に、レプリケーション実行部２５は、上記の重いクエリーをスレーブサーバー装置３側でも実行するよう、スレーブサーバー装置３側に送信する。
なお、転送されたクエリーは、スレーブサーバー装置３側で実行される。

以上説明したように、図３に示した処理では、マスターサーバー装置２側での重いクエリーの完了を待たずに、並行して、スレーブサーバー装置３側で同一のクエリーの実行を開始させる。言い換えれば、マスターサーバー装置２上での実行の前に、スレーブサーバー装置３側にもクエリーを転送する。これにより、マスターサーバー装置２側でのクエリーの完了と、スレーブサーバー装置３側でのクエリーの完了との時間差を、所定の時間内とすることが可能となる。ただし、未同期のコミットデータとの間の不整合を回避するために、現在残っている（溜まっている）コミットデータをすべて適用した後、重いクエリーをマスターサーバー装置２側からスレーブサーバー装置３側に転送するようにしている。
このような処理により、重いクエリーに関しても、非同期レプリケーションによる同期を所定の目標遅延時間内に完了させることが可能となる。つまり、システム全体のレイテンシーおよびスループットを改善することが可能となる。

次に、データベースシステム１の動作例を説明する。

図４は、データベースシステム１に更新型の重いクエリーの実行が要求されたときの処理の流れの例を示す概略図である。同図において、横軸は時間軸である。また、同図では縦の破線で同期間隔を区切って示している。同期間隔の長さはＴ_ＩＮＴである。つまり、時刻Ｔ１、Ｔ２、Ｔ３、Ｔ４、Ｔ５に関して、Ｔ２−Ｔ１＝Ｔ３−Ｔ２＝Ｔ４−Ｔ３＝Ｔ５−Ｔ４＝Ｔ_ＩＮＴである。
同図の処理例では、時刻Ｔ１とＴ２の間に、クライアント装置側からＵｐｄａｔｅ文のクエリーの実行が要求される。マスターサーバー装置２内の要求変換部２１は、このＵｐｄａｔｅ文を解析することによってこのクエリーの実行時間を見積り、このクエリーが重いクエリーであると判断する。すると、マスターサーバー装置２は、自装置内でそのクエリーの実行が完了する前に、そのクエリーをスレーブサーバー装置３側にも転送する。そして、時刻Ｔ１とＴ２の間に、マスターサーバー装置２側とスレーブサーバー装置３側との両方で、それぞれ、そのクエリーの実行が開始される。図中では、クエリー実行時間と記載した矢印で、そのクエリーの実行にかかる時間を示している。実際には、クエリー実行時間の長さは、Ｔ_ＩＮＴよりも少し長い。そして、時刻Ｔ２とＴ３の間で、マスターサーバー装置２側およびスレーブサーバー装置３側のそれぞれにおいて、Ｕｐｄａｔｅクエリーの実行が終了する。なお、マスターサーバー装置２側でそのＵｐｄａｔｅクエリーの実行が終了した時点で、クライアント装置に対するレスポンスが返される。そして、マスターサーバー装置２とスレーブサーバー装置３との間で同期を行う。

図４に例示したように、データベースシステム１は、重いクエリーであると判断した場合に、マスターサーバー装置側でのクエリーの完了を待たずに、スレーブサーバー装置側でもそのクエリーを実行させる。これにより、クエリー実行時間が同期間隔Ｔ_ＩＮＴよりも長い場合にも、マスターサーバー装置２におけるクエリー終了時刻とスレーブサーバー装置３におけるクエリー終了時刻と差を、Ｔ_ＩＮＴ以下にすることが可能である。

図５は、データベースシステム１に更新型の重いクエリーの実行が要求されたときの処理の流れの別の例を示す概略図である。同図に示す例では、重いと判定されるクエリーをマスターサーバー装置２側からスレーブサーバー装置３側に転送する前に、未転送のコミット済データを先にスレーブサーバー装置３側に転送する。なお、同期間隔の長さＴ_ＩＮＴと時刻Ｔ１、Ｔ２、Ｔ３、Ｔ４、Ｔ５との関係は、図４で説明した場合と同様であり、Ｔ２−Ｔ１＝Ｔ３−Ｔ２＝Ｔ４−Ｔ３＝Ｔ５−Ｔ４＝Ｔ_ＩＮＴである。

同図において、マスターサーバー装置２側の左端部分に描かれている２本の下向き矢印（太枠に囲まれている「その他のコミット済データ」）は、マスターサーバー装置２側でのコミット済データである。このコミット済データは、その時点ではまだスレーブサーバー装置３側に転送されていない。そして、同図に示すケースでは、このタイミングでクライアント装置からＵｐｄａｔｅクエリーの実行を要求され、要求変換部２１によってそのクエリーが重いクエリーであると判定される。すると、マスターサーバー装置２のレプリケーション実行部２５は、コミットデータリストをチェックし、コミット済データのレプリケーションを実行する。このようにして未転送であった更新データの同期をまず実行する。その後、マスターサーバー装置２は、重いクエリーをスレーブサーバー装置３側に転送する。また、マスターサーバー装置２側とスレーブサーバー装置３側の両方で、それぞれ、そのクエリーを実行する。その後の処理の流れは、図４で説明した処理と同様である。

図５に例示したように、重いクエリーをマスターサーバー装置２側からスレーブサーバー装置３側に転送する前に、その時点で残っているコミット済データを先にスレーブサーバー装置３側に転送することで、データの整合性が維持される。

図６は、データベースシステム１に、複数の更新型の重いクエリーの実行が同時期に（近いタイミングで）要求されたときの処理の流れの別の例を示す概略図である。同図においても、同期間隔の長さＴ_ＩＮＴと時刻Ｔ１、Ｔ２、Ｔ３、Ｔ４、Ｔ５との関係は、Ｔ２−Ｔ１＝Ｔ３−Ｔ２＝Ｔ４−Ｔ３＝Ｔ５−Ｔ４＝Ｔ_ＩＮＴである。同図に示す例では、時刻Ｔ１とＴ２の間に、２つのクエリーの実行要求がクライアント装置からマスターサーバー装置２に送られている。なお、これら２つのクエリーの実行要求は、同一のクライアント装置から送られるものであってもよいし、別々のクライアント装置から送られるものであってもよい。これら２つのクエリーの各々は、マスターサーバー装置２上の要求変換部２１で重いクエリーであると判定されると、マスターサーバー装置２上での実行の完了を待たずにスレーブサーバー装置３に転送される。そして、スレーブサーバー装置３上では、これら転送されてきた２つのクエリーは、直列に実行される。また、マスターサーバー装置２上で、２つのクエリーのうちの後のほうのクエリーの実行が完了した後、マスターサーバー装置２は、スレーブサーバー装置３に対して同期を指示する。これを受けたスレーブサーバー装置３は、スレーブサーバー装置３での後のほうのクエリーの実行が完了した後、スレーブサーバー装置３側での同期処理を行う。

図６に例示したように、複数の重いクエリーがマスターサーバー装置２側で同時期に発生した場合でも、スレーブサーバー装置３上でのクエリーの実行の遅延を所定範囲内に抑えるとともに、データの整合性を維持できる。

図７は、データベースシステム１に、複数の更新型の重いクエリーの実行が同時期に（近いタイミングで）要求されたときの処理の流れの別の例を示す概略図である。同図においても、同期間隔の長さＴ_ＩＮＴと時刻Ｔ１、Ｔ２、Ｔ３、Ｔ４、Ｔ５との関係は、Ｔ２−Ｔ１＝Ｔ３−Ｔ２＝Ｔ４−Ｔ３＝Ｔ５−Ｔ４＝Ｔ_ＩＮＴである。同図に示す例では、時刻Ｔ１とＴ２の間に、２つのクエリーの実行要求がクライアント装置からマスターサーバー装置２に送られている。なお、これら２つのクエリーの実行要求は、同一のクライアント装置から送られるものであってもよいし、別々のクライアント装置から送られるものであってもよい。これら２つのクエリーの各々は、マスターサーバー装置２上の要求変換部２１で重いクエリーであると判定されると、マスターサーバー装置２上での実行の完了を待たずにスレーブサーバー装置３に転送される。そして、本図の場合には、スレーブサーバー装置３上では、これら転送されてきた２つのクエリーは、並列に実行される。なお、更新型の２つのクエリーが互いにデータ資源（データベースで管理されているデータ）について競合しない場合には、これら２つのクエリーを並列に実行することができる。例えば、２つのクエリーの各々が排他制御の目的で更新対象のテーブルをロックしてから処理を実行する場合、これら２つのテーブルが別の２つのテーブルを更新対象とする限りにおいて、これら２つのクエリーを並列に実行できる。また、例えば、２つのクエリーの各々が排他制御の目的で更新対象のデータを行単位でロックしてから処理を実行する場合、同一の行がロック対象となっていない限り、これら２つのクエリーを並列に実行できる。
そして、また、マスターサーバー装置２上で、２つのクエリーのうちの後のほうのクエリーの実行が完了した後、マスターサーバー装置２は、スレーブサーバー装置３に対して同期を指示する。これを受けたスレーブサーバー装置３は、スレーブサーバー装置３での後のほうのクエリーの実行が完了した後、スレーブサーバー装置３側での同期処理を行う。なお、図７に示す例では、マスターサーバー装置２上で実行された後のほうのクエリーの処理よりも、転送先であるスレーブサーバー装置３上で実行されたそのクエリーの処理のほうが先に完了している。

図７に例示したように、複数の重いクエリーがマスターサーバー装置２側で同時期に発生し、それらのクエリーをスレーブサーバー装置３上で並列して実行する場合でも、スレーブサーバー装置３側の遅延を所定範囲内に抑えることができる。また、データの整合性を維持できる。

次に、図８，図９，図１０を参照しながら、スレーブサーバー装置３側での整合性確保についてさらに説明する。

図８は、マスターサーバー装置２側でのクエリーの実行と、マスターサーバー装置２からスレーブサーバー装置３に対して同期時に送信されるデータとを示す概略図である。同図において、横方向が時間軸であり、左側が古い時刻、右側が新しい時刻である。同期間隔の長さＴ_ＩＮＴと時刻Ｔ１、Ｔ２、Ｔ３との関係は、Ｔ２−Ｔ１＝Ｔ３−Ｔ２＝Ｔ_ＩＮＴである。図示する例において、クエリー２は、テーブル１を更新するためのクエリーである。また、クエリー１とクエリー３とクエリー４とは、テーブル２を更新するためのクエリーである。クエリー１とクエリー３とクエリー４は、同一のテーブルを更新するクエリーであり、直列に実行される。そして、テーブル１のみを更新するクエリーとテーブル２のみを更新するクエリーとは、並列に実行させることが可能である。そして、クエリー１とクエリー２とは、要求変換部２１によって重いクエリーと判定されたクエリーである。また、クエリー３とクエリー４とは、要求変換部２１によって通常のクエリーと判定されたクエリーである。既に述べたとおり、重いクエリーに関しては、マスターサーバー装置２側での処理完了を待たずに、スレーブサーバー装置３へのクエリーの転送が行われる。

そして、図示する例では、クエリー１は、Ｔ１より前に開始され、Ｔ２とＴ３との間に完了する。クエリー２は、Ｔ１とＴ２との間に開始され、Ｔ２とＴ３との間に完了する。クエリー３は、Ｔ２とＴ３との間に開始され且つ完了する。クエリー４もまた、Ｔ２とＴ３との間に開始され且つ完了する。なお、クエリー２の処理が完了するのは、クエリー４の処理開始後且つクエリー４の処理完了前である。

同期時にマスターサーバー装置２がスレーブサーバー装置３に対して送信するデータは、マスターサーバー装置２側とスレーブサーバー装置３側とで、更新順序に関する整合性を保証するように順番付けが行われる。即ち、図示するように、旧い側から順に、クエリー１の完了を表すデータ、クエリー３のＷＡＬログ、クエリー２の完了を表すデータ、クエリー４のＷＡＬログである。
つまり、重いクエリーであるクエリー１、クエリー２に関しては、コミットやロールバックが発生した場合にそのことを同期時のデータで通知する。また、通常のクエリーであるクエリー３、クエリー４に関しては、ＷＡＬログを同期時のデータとして送る。

図９は、図８の処理によってマスターサーバー装置２側から送信されるデータを受信したスレーブサーバー装置３側での処理例の概要を示す概略図である。つまり、図９に示すスレーブサーバー装置３側の処理は、図８で説明したマスターサーバー装置２側の処理に対応するものである。なお、図９において、横方向が時間軸であり、左側が古い時刻、右側が新しい時刻である。同期間隔の長さＴ_ＩＮＴと時刻Ｔ１、Ｔ２、Ｔ３、Ｔ４との関係は、Ｔ２−Ｔ１＝Ｔ３−Ｔ２＝Ｔ４−Ｔ３＝Ｔ_ＩＮＴである。

図９において、同期時にスレーブサーバー装置３が受信するデータは、図８で示した同期時のデータと同一である。つまり、クエリー１およびクエリー２は、マスターサーバー装置２側から転送されてきたクエリーであり、マスターサーバー装置２での処理の完了の前に、スレーブサーバー装置もこれらクエリー１およびクエリー２を実行する。なお、クエリー１およびクエリー２は、それぞれ別のテーブルに対する更新処理を行うものである。したがって、スレーブサーバー装置３は、クエリー１およびクエリー２を並列に実行させる。

そして、スレーブサーバー装置３は、同期時に受信するデータを、順次、適用していく。この同期適用の処理は、図示する例では、時刻Ｔ３からＴ４の間に行われる。なお、スレーブサーバー装置３は、これらの同期の適用の処理を直列に行う。

つまり、スレーブサーバー装置３は、まずクエリー１を確定させる（クエリー１の処理自体は時刻Ｔ２とＴ３との間に完了済み）。次に、スレーブサーバー装置３は、クエリー３のＷＡＬを適用する。次に、スレーブサーバー装置３は、まずクエリー２を確定させる（クエリー２の処理自体は時刻Ｔ２とＴ３との間に完了済み）。そしえ最後に、スレーブサーバー装置３は、クエリー４のＷＡＬを適用する。即ち、同期時のデータをマスターサーバー装置２から受信したスレーブサーバー装置３は、そのデータによって示される順序で、クエリーの処理結果を適用していく。そして、スレーブサーバー装置３側で重いクエリーの実行が完了していない場合には、その実行完了を待つ。

図１０は、図８の処理によってマスターサーバー装置２側から送信されるデータを受信したスレーブサーバー装置３側での、図９とは別の処理例の概要を示す概略図である。つまり、図１０に示すスレーブサーバー装置３側の処理は、図８で説明したマスターサーバー装置２側の処理に対応するものである。なお、図１０において、横方向が時間軸であり、左側が古い時刻、右側が新しい時刻である。同期間隔の長さＴ_ＩＮＴと時刻Ｔ１、Ｔ２、Ｔ３、Ｔ４との関係は、Ｔ２−Ｔ１＝Ｔ３−Ｔ２＝Ｔ４−Ｔ３＝Ｔ_ＩＮＴである。

図１０に示す処理の特徴は、スレーブサーバー装置３側で実行されるクエリー２の処理に時間を要するために、クエリー２よりも後に適用されるクエリー４が待たされる点である。つまり、図１０に示す例では、スレーブサーバー装置３側におけるクエリー２の処理の完了は、図９に示した場合よりも遅く、時刻Ｔ３とＴ４との間である。
つまり、スレーブサーバー装置３が同期時に受信したデータを順次適用していくとき、まずクエリー１を確定させ、次にクエリー３のＷＡＬを適用する。そして、次に、マスターサーバー装置２側から受信したデータによると、クエリー２を確定させるべきであるが、その時点ではスレーブサーバー装置３におけるクエリー２の処理が完了していない。したがって、スレーブサーバー装置３におけるクエリー２の処理が完了するまで、クエリー２を確定する処理が待たされる。これは、時刻Ｔ３とＴ４の間において「停止」と記した時間帯における待機である。そして、スレーブサーバー装置３におけるクエリー２の処理が完了すると、スレーブサーバー装置３は、クエリー２を確定させ、最後にクエリー４のＷＡＬを適用する。

上記の実施形態では、データベースシステム１がリレーショナル型のデータベースであるものとしたが、他の形態のモデルによるデータベースであってもよい。例えば、データベースシステム１が、オブジェクト指向型データベースやネットワーク型データベースやＸＭＬデータベース等であってもよい。リレーショナル型データベース以外のデータベースについては、クエリーが、ＳＱＬ以外の形態で表される場合もある。クエリーが、ＳＱＬ以外で表される場合であっても、データの読み出しのみを行うクエリーである場合と、データの書き込み（更新）を伴うクエリーである場合とがある。データの更新を伴うクエリーに関しては、上の実施形態と同様に、マスターとスレーブとの間で同期が図られる。つまり、マスター側でのデータ更新と同様に、スレーブ側でもデータ更新が行われる。そして、データベースシステムはクエリーが通常のクエリーであるか重いクエリーであるかを判別し、重いクエリーである場合には、マスターサーバー装置側でのデータ更新の完了を待たずに、そのクエリーはスレーブサーバー装置側に転送され実行される。その他の処理についても、リレーショナルデータベースの場合と同様に、レプリケーションが行われる。

以上説明した少なくともひとつの実施形態によれば、マスターサーバー装置２側のレプリケーション実行部２５は、通常のクエリーであると判定されたクエリーに関するレプリケーションデータを、マスターサーバー装置２側の命令実行部２２が当該クエリーの実行を完了した後にスレーブサーバー装置３側に転送する。また、レプリケーション実行部２５は、重いクエリーであると判定されたクエリーに関するレプリケーションデータを、命令実行部２２が当該クエリーの実行を完了したか否かに関わらずスレーブサーバー装置３側に転送する。後者の場合、マスターサーバー装置２側でのクエリーの実行が完了する前に、スレーブサーバー装置３側でもクエリーが実行される。つまり、マスターサーバー装置２側とスレーブサーバー装置３側とで、当該クエリーが並列に実行される。これにより、マスターサーバー装置２とスレーブサーバー装置３との間の同期遅延の時間を抑えることができる。つまり、重いクエリーのスレーブ側での実行遅延時間を減らすことができる。

なお、上述した実施形態におけるマスターサーバー装置やスレーブサーバー装置や端末装置の機能の少なくとも一部をコンピューターで実現するようにしても良い。その場合、これらの機能を実現するためのプログラムをコンピューター読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピューターシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピューターシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピューターシステム内部の揮発性メモリーのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１…データベースシステム、２…マスターサーバー装置、３…スレーブサーバー装置、２１…要求変換部（マスター側要求変換部）、２２…命令実行部（マスター側命令実行部）、２３…レプリケーションデータ保持部、２４…記憶部（マスター側記憶部）、２５…レプリケーション実行部（マスター側レプリケーション実行部）、３１…要求変換部、３２…命令実行部、３４…記憶部（スレーブ側記憶部）、３５…レプリケーション実行部（スレーブ側レプリケーション実行部）、１０２，１０３…クライアント装置

Claims (7)

1. マスターサーバー装置と、
   スレーブサーバー装置と、
   を備えるデータベースシステムであって、
   前記マスターサーバー装置は、
   データを記憶するマスター側記憶部と、
   要求されるクエリーを受信し、受信した前記クエリーが通常のクエリーであるか重いクエリーであるかを判定するマスター側要求変換部と、
   前記マスター側要求変換部が受信した前記クエリーを実行して前記マスター側記憶部に記憶されている前記データを処理するとともに、前記クエリーの実行結果を前記スレーブサーバー装置側にレプリケーションするためのレプリケーションデータを生成するマスター側命令実行部と、
   前記マスター側命令実行部によって生成された前記レプリケーションデータを前記スレーブサーバー装置側に転送するマスター側レプリケーション実行部と、
   を備え、
   前記スレーブサーバー装置は、
   前記マスター側記憶部が記憶する前記データのレプリケーションを記憶するスレーブ側記憶部と、
   前記マスター側レプリケーション実行部から転送された前記レプリケーションデータに基づき、前記スレーブ側記憶部に記憶された前記データのレプリケーションを更新するスレーブ側レプリケーション実行部と、
   を備え、
   前記マスター側レプリケーション実行部は、
   前記マスター側要求変換部が通常のクエリーであると判定した前記クエリーに関する前記レプリケーションデータを、マスター側命令実行部が当該クエリーの実行を完了した後に前記スレーブサーバー装置側に転送するとともに、
   前記マスター側要求変換部が重いクエリーであると判定した前記クエリーに関する前記レプリケーションデータを、マスター側命令実行部が当該クエリーの実行を完了したか否かに関わらず前記スレーブサーバー装置側に転送し、
   前記スレーブ側レプリケーション実行部は、前記マスター側要求変換部が重いクエリーであると判定した前記クエリーに関して、マスター側命令実行部での当該クエリーの実行の完了を待たずに、前記スレーブ側記憶部に記憶された前記データに対して当該クエリーを実行させるものであり、
   前記マスター側レプリケーション実行部は、重いクエリーであると判定されたクエリーに関する前記レプリケーションデータを前記スレーブサーバー装置側に転送する前に、その時点で未転送のコミット済データのレプリケーションデータを先に前記スレーブサーバー装置側に転送し、
   前記スレーブ側レプリケーション実行部は、先に転送された前記レプリケーションデータに基づいて前記スレーブ側記憶部に記憶された前記データのレプリケーションを更新して同期を実行してから、前記重いクエリーであると判定されたクエリーを実行させる、
   データベースシステム。
2. 前記マスター側命令実行部は、
   前記マスター側要求変換部が通常のクエリーであると判定した前記クエリーに関して、前記クエリーの実行結果であるデータの物理ログを前記レプリケーションデータとして生成し、
   前記マスター側要求変換部が重いクエリーであると判定した前記クエリーに関して、前記クエリーそのものを前記レプリケーションデータとして生成する、
   請求項１に記載のデータベースシステム。
3. 前記スレーブ側レプリケーション実行部は、重いクエリーであると判定された前記クエリーに関して前記クエリーそのものを前記レプリケーションデータとして前記マスター側レプリケーション実行部から受信した場合には、通常のクエリーであると判定された前記クエリーに関して前記マスター側レプリケーション実行部から受信済みであった前記物理ログに基づく前記データのレプリケーションの更新をすべて実行した後で、前記重いクエリーであると判定された前記クエリーに基づく前記データのレプリケーションの更新を実行する、
   請求項２に記載のデータベースシステム。
4. 前記スレーブ側レプリケーション実行部は、複数の前記クエリーに対応する前記レプリケーションデータを時系列に並べて管理するとともに、この時系列にしたがって前記レプリケーションデータに基づく前記データのレプリケーションの更新を実行する、
   請求項２または請求項３に記載のデータベースシステム。
5. 前記スレーブ側レプリケーション実行部は、重いクエリーであると判定された前記クエリーに対応する前記レプリケーションデータに基づくデータのレプリケーションの更新が完了するまでは、当該重いクエリーに後続する他のクエリーに対応する前記レプリケーションデータに基づくデータのレプリケーションの更新の処理を待機する、
   請求項４に記載のデータベースシステム。
6. 前記スレーブ側レプリケーション実行部は、更新型の２つのクエリーが互いにデータ資源について競合しない場合には、これら２つのクエリーを並列に実行する、
   請求項１から５までのいずれか一項に記載のデータベースシステム。
7. マスターサーバー装置と、
   スレーブサーバー装置と、
   を備えるデータベースシステムにおけるデータ処理方法であって、
   前記マスターサーバー装置は、
   データを記憶するマスター側記憶部を備えるとともに、
   要求されるクエリーを受信し、受信した前記クエリーが通常のクエリーであるか重いクエリーであるかを判定するマスター側要求変換過程と、
   前記マスター側要求変換過程が受信した前記クエリーを実行して前記マスター側記憶部に記憶されている前記データを処理するとともに、前記クエリーの実行結果を前記スレーブサーバー装置側にレプリケーションするためのレプリケーションデータを生成するマスター側命令実行過程と、
   前記マスター側命令実行過程によって生成された前記レプリケーションデータを前記スレーブサーバー装置側に転送するマスター側レプリケーション実行過程と、
   を実行し、
   前記スレーブサーバー装置は、
   前記マスター側記憶部が記憶する前記データのレプリケーションを記憶するスレーブ側記憶部を備えるとともに、
   前記マスター側レプリケーション実行過程で転送された前記レプリケーションデータに基づき、前記スレーブ側記憶部に記憶された前記データのレプリケーションを更新するスレーブ側レプリケーション実行過程、
   を実行し、
   前記マスター側レプリケーション実行過程は、
   前記マスター側要求変換過程が通常のクエリーであると判定した前記クエリーに関する前記レプリケーションデータを、マスター側命令実行過程が当該クエリーの実行を完了した後に前記スレーブサーバー装置側に転送するとともに、
   前記マスター側要求変換過程が重いクエリーであると判定した前記クエリーに関する前記レプリケーションデータを、マスター側命令実行過程が当該クエリーの実行を完了したか否かに関わらず前記スレーブサーバー装置側に転送し、
   前記スレーブ側レプリケーション実行過程は、前記マスター側要求変換過程が重いクエリーであると判定した前記クエリーに関して、マスター側命令実行過程での当該クエリーの実行の完了を待たずに、前記スレーブ側記憶部に記憶された前記データに対して当該クエリーを実行させるものであり、
   前記マスター側レプリケーション実行部は、重いクエリーであると判定されたクエリーに関する前記レプリケーションデータを前記スレーブサーバー装置側に転送する前に、その時点で未転送のコミット済データのレプリケーションデータを先に前記スレーブサーバー装置側に転送し、
   前記スレーブ側レプリケーション実行部は、先に転送された前記レプリケーションデータに基づいて前記スレーブ側記憶部に記憶された前記データのレプリケーションを更新して同期を実行してから、前記重いクエリーであると判定されたクエリーを実行させる、
   データ処理方法。

Images