以下、本実施の形態を図面を参照して説明する。
[第1の実施の形態]
第1の実施の形態を説明する。
図1は、第1の実施の形態の情報処理装置の例を説明する図である。
第1の実施の形態の情報処理装置10は、クエリに応じてデータベース検索を行うコンピュータである。情報処理装置10は、ユーザが操作するクライアント装置でもよいし、クライアント装置または他のサーバ装置から利用されるサーバ装置でもよい。
情報処理装置10は、記憶部11および処理部12を有する。記憶部11は、RAM(Random Access Memory)などの揮発性の半導体メモリでもよいし、HDD(Hard Disk Drive)やフラッシュメモリなどの不揮発性のストレージでもよい。処理部12は、例えば、CPU(Central Processing Unit)、GPU(Graphics Processing Unit)、DSP(Digital Signal Processor)などのプロセッサである。ただし、処理部12は、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)などの特定用途の電子回路を含んでもよい。プロセッサは、RAMなどのメモリ(記憶部11でもよい)に記憶されたプログラムを実行する。複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。
記憶部11は、データベース13に対応するインデックス14を記憶する。
データベース13は、それぞれがデータ項目13a(第1のデータ項目)およびデータ項目13b(第2のデータ項目)を含む複数のレコードを記憶する。例えば、データベース13は関係データベースであり、データ項目13a,13bはテーブルのカラムであり、レコードはテーブルのタプル(行方向に並んだ一組のデータ)である。データ項目13a,13bは、主キーではないデータ項目でもよい。一例として、レコードは商品の注文を表し、データ項目13aは値段を表し、データ項目13bは数量を表す。
インデックス14は、データ項目13aに使用され得る複数の候補値それぞれに対応付けて、レコード特定情報14aおよび統計値14bを記憶する。インデックス14は、複数の候補値に対応する複数のノードを含み、それら複数のノードが木構造に接続されたツリー型インデックスであってもよい。例えば、インデックス14はB-treeでもよい。その場合、各ノードにレコード特定情報14aおよび統計値14bが登録される。
レコード特定情報14aは、データベース13に記憶された複数のレコードのうち、データ項目13aに当該候補値を含む2以上のレコードを示す。レコード特定情報14aは、該当するレコードのアドレスを列挙したものであってもよい。統計値14bは、レコード特定情報14aが示す2以上のレコードに含まれるデータ項目13bの値を統計処理して算出される数値である。統計値14bは、例えば、2以上のレコードに含まれるデータ項目13bの値の合計、最大値、最小値、平均などである。インデックス14に、候補値毎に2種類以上の統計値が登録されてもよい。
一例として、データベース13の1番目のレコードは、データ項目13a=8500、データ項目13b=100を含む。2番目のレコードは、データ項目13a=8600、データ項目13b=200を含む。3番目のレコードは、データ項目13a=8500、データ項目13b=300を含む。4番目のレコードは、データ項目13a=8600、データ項目13b=400を含む。その場合、インデックス14は、データ項目13a=8500に対応付けて、レコード特定情報14a={#1,#3}と、統計値14b=400を含む。また、インデックス14は、データ項目13a=8600に対応付けて、レコード特定情報14a={#2,#4}と、統計値14b=600を含む。なお、この例では、統計値14bはデータ項目13bの値の合計である。
処理部12は、データベース13に対するクエリ15を受け付ける。クエリ15は、情報処理装置10で実行されるアプリケーションソフトウェアが発行したものであってもよいし、他の情報処理装置から受信されたものであってもよい。また、クエリ15は、SQLなどのクエリ言語で記述された文字列であってもよい。
クエリ15は、データ項目13aの値の条件を示す検索条件を含む。検索条件は、データ項目13aの値が特定の値であることであってもよいし、データ項目13aの値が特定の範囲に属することであってもよい。また、クエリ15は、検索条件に該当するレコードのデータ項目13bの値の統計処理を要求するコマンドを含む。コマンドは、合計関数SUM、最大値関数MAX、最小値関数MIN、平均関数AVGなどの集合関数を使用してもよい。一例として、クエリ15は、データ項目13a=8500であることを検索条件とし、検索条件に該当するレコードのデータ項目13bの値の合計を要求する。クエリ15は、特定の値段をもつレコードに含まれる数量の合計を要求するものであってもよい。
処理部12は、クエリ15に応答して、インデックス14から検索条件に該当する候補値を検索し、その候補値に対応付けられた統計値14bを読み出す。このとき、処理部12は、その候補値に対応付けられたレコード特定情報14aから個々のレコードにアクセスしなくてよい。処理部12は、読み出した統計値14bを用いて、クエリ15に対する処理結果16を出力する。処理結果16は、クエリ15が要求する統計処理の結果を含む。処理結果16は、インデックス14から読み出された統計値14bそのものを含んでもよいし、インデックス14から読み出された2以上の統計値14bから算出される数値(例えば、2以上の統計値14bの合計)を含んでもよい。一例として、処理部12は、データ項目13a=8500に対応付けられた統計値14b=400をインデックス14から読み出し、読み出した統計値14b=400を含む処理結果16を出力する。
第1の実施の形態の情報処理装置10によれば、データ項目13aに使用され得る候補値を含む2以上のレコードを示すレコード特定情報14aと、それら2以上のレコードに含まれるデータ項目13bの値の統計値14bとを含むインデックス14が用意される。データ項目13aの値の条件を示す検索条件と、検索条件に該当するレコードのデータ項目13bの値の統計処理を要求するコマンドとを含むクエリ15が受信される。すると、インデックス14から、検索条件に該当する候補値に対応付けられた統計値14bが読み出される。そして、読み出された統計値14bを用いてクエリ15に対する処理結果16が出力される。これにより、インデックス14を使用すれば、検索条件に該当する個々のレコードにアクセスしてデータ項目13bの値を読み出さなくてもよく、統計処理を要求するクエリ15に対して処理結果16を効率的に生成することができる。よって、情報処理装置10の負荷を低減し、クエリ15に対する応答を高速化できる。
[第2の実施の形態]
次に、第2の実施の形態を説明する。
図2は、第2の実施の形態の情報処理システムの例を示す図である。
第2の実施の形態の情報処理システムは、株式の売買を仲介する証券取引システムである。この情報処理システムは、サーバ装置100、仲介装置210,220を含む複数の仲介装置、および、クライアント装置230,240を含む複数のクライアント装置を有する。これらの装置は、インターネットなどの広域データ通信ネットワークに接続され、広域データ通信ネットワークを介して相互に通信する。なお、サーバ装置100は、第1の実施の形態の情報処理装置10に対応する。
サーバ装置100は、証券取引所31が有するサーバコンピュータである。サーバ装置100は、仲介装置210,220などの仲介装置から、売注文または買注文を示す注文メッセージを受信する。サーバ装置100は、売注文と買注文との間のマッチングを行い、希望の条件を満たすような売注文と買注文のペアを検出して約定を成立させる。すなわち、サーバ装置100は、売注文の注文主と買注文の注文主との間で株式売買契約を成立させる。サーバ装置100は、約定が成立した売注文および買注文について、注文メッセージの送信元の仲介装置に対して約定通知メッセージを送信する。
仲介装置210は、証券会社32が有するサーバコンピュータである。仲介装置220は、証券会社33が有するサーバコンピュータである。証券会社32,33などの証券会社は、個人投資家や機関投資家などの投資家を代理して、証券取引所31での株式売買を実行する。仲介装置210,220などの仲介装置は、証券取引所31が有するサーバ装置100に対してはクライアントとして動作し、投資家が使用するクライアント装置230,240などのクライアント装置に対してはサーバとして動作する。
仲介装置210は、証券会社32の会員の投資家が使用するクライアント装置230などのクライアント装置から、株式の売注文や買注文を受け付けるインタフェースを有する。仲介装置210は、会員の投資家からの売注文や買注文に応じて、サーバ装置100に注文メッセージを送信し、サーバ装置100から約定通知メッセージを受信する。仲介装置210は、約定通知メッセージの受信状況に応じて、クライアント装置230などのクライアント装置に対して注文結果を出力する。
同様に、仲介装置220は、証券会社33の会員の投資家が使用するクライアント装置240などのクライアント装置から、株式の売注文や買注文を受け付けるインタフェースを有する。仲介装置220は、会員の投資家からの売注文や買注文に応じて、サーバ装置100に注文メッセージを送信し、サーバ装置100から約定通知メッセージを受信する。仲介装置220は、約定通知メッセージの受信状況に応じて、クライアント装置240などのクライアント装置に対して注文結果を出力する。
クライアント装置230,240は、個人投資家や機関投資家などの投資家が使用するクライアントコンピュータである。投資家は、証券会社32,33などの証券会社に依頼して株式を売買する。クライアント装置230を使用する投資家は、証券会社32の会員である。クライアント装置230は、仲介装置210に売注文や買注文を送信し、仲介装置210から約定通知を受信する。クライアント装置240を使用する投資家は、証券会社33の会員である。クライアント装置240は、仲介装置220に売注文や買注文を送信し、仲介装置220から約定通知を受信する。
図3は、サーバ装置のハードウェア例を示すブロック図である。
サーバ装置100は、CPU101、RAM102、HDD103、画像インタフェース104、入力インタフェース105、媒体リーダ106および通信インタフェース107を有する。これらのユニットはバスに接続されている。CPU101は、第1の実施の形態の処理部12に対応する。RAM102またはHDD103は、第1の実施の形態の記憶部11に対応する。仲介装置210,220およびクライアント装置230,240も、サーバ装置100と同様のハードウェアを有する。
CPU101は、プログラムの命令を実行するプロセッサである。CPU101は、HDD103に記憶されたプログラムやデータの少なくとも一部をRAM102にロードし、プログラムを実行する。なお、CPU101は複数のプロセッサコアを備えてもよく、サーバ装置100は複数のプロセッサを備えてもよい。複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。
RAM102は、CPU101が実行するプログラムやCPU101が演算に使用するデータを一時的に記憶する揮発性の半導体メモリである。なお、サーバ装置100は、RAM以外の種類のメモリを備えてもよく、複数のメモリを備えてもよい。
HDD103は、OS(Operating System)やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性ストレージである。なお、サーバ装置100は、フラッシュメモリやSSD(Solid State Drive)など他の種類のストレージを備えてもよく、複数のストレージを備えてもよい。
画像インタフェース104は、CPU101からの命令に従って、サーバ装置100に接続された表示装置111に画像を出力する。表示装置111として、CRT(Cathode Ray Tube)ディスプレイ、液晶ディスプレイ(LCD:Liquid Crystal Display)、有機EL(OEL:Organic Electro-Luminescence)ディスプレイ、プロジェクタなど、任意の種類の表示装置を使用することができる。
入力インタフェース105は、サーバ装置100に接続された入力デバイス112から入力信号を受け付ける。入力デバイス112として、マウス、タッチパネル、タッチパッド、キーボードなど、任意の種類の入力デバイスを使用することができる。また、サーバ装置100に複数種類の入力デバイスが接続されてもよい。
媒体リーダ106は、記録媒体113に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体113として、例えば、フレキシブルディスク(FD:Flexible Disk)やHDDなどの磁気ディスク、CD(Compact Disc)やDVD(Digital Versatile Disc)などの光ディスク、光磁気ディスク(MO:Magneto-Optical disk)、半導体メモリなどを使用できる。媒体リーダ106は、例えば、記録媒体113から読み取ったプログラムやデータをRAM102またはHDD103に格納する。
通信インタフェース107は、ネットワーク114に接続され、ネットワーク114を介して仲介装置210,220と通信を行う。通信インタフェース107は、スイッチやルータなどの有線通信装置に接続される有線インタフェースである。ただし、基地局やアクセスポイントなどの無線通信装置に接続される無線インタフェースであってもよい。
次に、サーバ装置100の機能について説明する。
図4は、サーバ装置の機能例を示すブロック図である。
サーバ装置100は、注文受信部121、注文キュー122、マッチング部123、データベース管理システム(DBMS)124、注文データベース125、約定データベース126、板生成部127、約定キュー128および約定送信部129を有する。
サーバ装置100が使用するデータベース管理システム124は、データをRAM102などの主記憶装置上に保持するインメモリDBMSである。ただし、データをHDD103などの補助記憶装置に保持する通常のDBMSを使用することも可能である。注文キュー122、注文データベース125、約定データベース126および約定キュー128は、例えば、RAM102の記憶領域を用いて実現される。注文受信部121、マッチング部123、データベース管理システム124、板生成部127および約定送信部129は、例えば、CPU101が実行するプログラムを用いて実現できる。
注文受信部121は、仲介装置210,220などの仲介装置から注文メッセージを受信する。注文受信部121は、受信した注文メッセージを注文キュー122に挿入する。
注文キュー122は、未処理の注文メッセージを受信順に記憶するFIFO(First In First Out)型のバッファメモリである。注文受信部121により、最新の注文メッセージが注文キュー122の末尾に挿入される。マッチング部123により、未処理の注文メッセージのうち最も古い注文メッセージが注文キュー122の先頭から取り出される。
マッチング部123は、売注文と買注文の間のマッチングを行う。具体的には、マッチング部123は、注文キュー122の先頭から注文メッセージを1つずつ取り出す。
取り出した注文メッセージが売注文を示す場合、マッチング部123は、今回の売注文と、過去に取り出した注文メッセージが示す買注文のうち未約定の買注文とを対比する。希望する条件が合う相手方の買注文が存在する場合、マッチング部123は、約定を成立させて、約定が成立した売注文と買注文のペアを示す約定通知メッセージを約定キュー128に挿入する。希望する条件が合う相手方の買注文が存在しない場合、マッチング部123は、今回の売注文を未約定の売注文として保持する。
取り出した注文メッセージが買注文を示す場合、マッチング部123は、今回の買注文と、過去に取り出した注文メッセージが示す売注文のうち未約定の売注文とを対比する。希望する条件が合う相手方の売注文が存在する場合、マッチング部123は、約定を成立させて、約定が成立した売注文と買注文のペアを示す約定通知メッセージを約定キュー128に挿入する。希望する条件が合う相手方の売注文が存在しない場合、マッチング部123は、今回の買注文を未約定の買注文として保持する。
上記の売買処理を実現するため、マッチング部123は関係データベースを利用する。マッチング部123は、関係データベースのクエリであるSQL文をデータベース管理システム124に発行し、SQL文に対する処理結果をデータベース管理システム124から取得する。マッチング部123がデータベース管理システム124に発行するSQL文には、テーブルから特定の条件のレコードを検索する検索クエリ、テーブルに新規レコードを挿入する挿入クエリ、テーブルの特定の既存レコードの値を書き換える更新クエリ、テーブルから特定のレコードを削除する削除クエリが含まれる。
データベース管理システム124は、注文データベース125および約定データベース126を管理する。データベース管理システム124は、関係データベースのクエリであるSQL文を受け付け、受け付けたSQL文に従って注文データベース125や約定データベース126に対して処理を実行する。データベース管理システム124は、処理結果をSQL文の発行元に対して出力する。データベース管理システム124が受け付けるSQL文には、検索クエリ、挿入クエリ、更新クエリおよび削除クエリが含まれる。データベース管理システム124は、マッチング部123からSQL文を受け付けることがあり、板生成部127からSQL文を受け付けることがある。
注文データベース125は、株式の銘柄毎に、未約定の売注文を示すテーブルである売注文表を記憶する。注文データベース125は、売注文表の中の特定のカラム(列)の値に基づいてレコードを高速に検索できるようにインデックスを更に記憶している。また、注文データベース125は、株式の銘柄毎に、未約定の買注文を示すテーブルである買注文表を記憶する。注文データベース125は、買注文表の中の特定のカラムの値に基づいてレコードを高速に検索できるようにインデックスを更に記憶している。
約定データベース126は、株式の銘柄毎に、約定が成立した売注文を示すテーブルである売約定表を記憶する。また、約定データベース126は、株式の銘柄毎に、約定が成立した買注文を示すテーブルである買約定表を記憶する。なお、第2の実施の形態では、主に注文データベース125のデータ処理に着目して説明する。
板生成部127は、株式の銘柄毎に、未約定の売注文と未約定の買注文の蓄積状況を示す板情報を生成する。板情報を生成するため、板生成部127は、データベース管理システム124に対して検索クエリを発行し、データベース管理システム124から売注文の数量および買注文の数量を示す処理結果を取得する。板情報は、投資家が現在の取引価格(現値)や約定が成立する可能性のある価格を把握する上で有用な情報である。板生成部127は、生成した板情報を、証券会社32,33などの証券会社に送信してもよいし、投資情報を表示する各種の情報提供システムに送信してもよい。
約定キュー128は、未送信の約定通知メッセージを生成順に記憶するFIFO型のバッファメモリである。マッチング部123により、最新の約定通知メッセージが約定キュー128の末尾に挿入される。約定送信部129により、未送信の約定通知メッセージのうち最も古い約定通知メッセージが約定キュー128の先頭から取り出される。
約定送信部129は、約定キュー128の先頭から約定通知メッセージを1つずつ取り出す。約定送信部129は、取り出した約定通知メッセージを、証券会社32,33などの証券会社のうち約定通知の宛先となる証券会社の仲介装置に対して送信する。宛先の証券会社は、約定が成立した売注文または買注文を行った証券会社である。
図5は、注文メッセージの例を示す図である。
注文メッセージ131は、注文キュー122に記憶される。注文メッセージ131は、売買種別、指値、数量、注文日時、注文番号、銘柄コードおよび依頼元の項目を有する。
売買種別は、売注文と買注文を区別するフラグである。売買種別=1は買注文を表し、売買種別=2は売注文を表す。指値は、投資家によって指定された取引単価の条件である。売注文の場合、指値は取引単価の下限であり、指値以上の売却単価での取引を要求することを示す。買注文の場合、指値は取引単価の上限であり、指値以下の買入単価での取引を要求することを示す。指値は空欄であってもよい。指値が与えられる注文が指値注文であり、指値が与えられない注文が成行注文である。指値注文は、相手注文(売注文に対する買注文、または、買注文に対する売注文)が存在しても価格条件が合わなければ約定が成立しないのに対し、成行注文は、相手注文が存在すれば約定が成立する。
数量は、1回の注文で取引したい株式の数量(株数)である。ただし、注文メッセージ131が指定する数量のうち一部の数量だけ先行して約定が成立することがある。注文日時は、注文を行った日時である。注文番号は、注文を識別する識別番号である。注文番号は昇順の整数であり、古い注文ほど小さい注文番号が付与され、新しい注文ほど大きい注文番号が付与される。注文番号は、サーバ装置100が注文メッセージ131を受信したときに、注文受信部121が注文メッセージ131に対して付与してもよい。銘柄コードは、株式の銘柄を識別する識別番号である。依頼元は、注文メッセージ131を送信した仲介装置を有する証券会社を示す文字列である。
図6は、板情報の例を示す図である。
板情報132は、注文データベース125に基づいて板生成部127により生成される。板情報132は、ある銘柄の未約定の売注文および買注文の蓄積状況を示す。板情報132は、気配値、売数量および買数量の項目を有する。
気配値は、その銘柄の株式の価格であり、売注文および買注文の指値に対応する。売数量は、ある気配値を指値とする売注文によって指定された数量を合計した合計数量である。すなわち、売数量は、指値毎に残っている売却希望数量の合計である。買数量は、ある気配値を指値とする買注文によって指定された数量を合計した合計数量である。すなわち、買数量は、指値毎に残っている買入希望数量の合計である。一例として、図6の板情報132は、9000円で21900株、8900円で69700株、8800円で1100株、8700円で5300株、8600円で200株の売注文が残っていることを示す。また、板情報132は、8500円で400株、8400円で1600株、8300円で900株、8200円で18200株の買注文が残っていることを示す。
売注文と買注文は、原則として指値に基づいてマッチングされる。新しい注文が到着すると、その注文の指値を満たす相手注文のうち、その注文にとって取引価格が有利な方から優先的に約定相手として選択される。すなわち、新しい売注文が到着すると、その売注文の指値以上の買値をもつ買注文のうち、買値が高い方から優先的に約定相手として選択される。また、新しい買注文が到着すると、その買注文の指値以下の売値をもつ売注文のうち、売値が低い方から優先的に約定相手として選択される。ただし、取引価格が同じになる複数の相手注文がある場合、注文日時が古い方から優先的に選択される。
例えば、図6の例において、8600円で100株の買注文が到着すると、8600円で200株の売注文のうち注文日時が古い方から100株の売注文が相手となって約定が成立する。これにより、8600円の売数量が100株に減少する。また、8600円で500株の買注文が到着すると、8600円で200株の売注文が相手となって約定が成立し、残りの300株の買注文は約定が成立しない。これにより、8600円の売数量が0株に減少し、8600円の買数量が300株に増加する。
また、8700円で100株の買注文が到着すると、8600円で200株の売注文のうち注文日時が古い方から100株の売注文が相手となって約定が成立する。これにより、8600円の売数量が100株に減少する。また、8700円で500株の買注文が到着すると、8600円で200株の売注文が相手となり、8700円で5300株の売注文のうち注文日時が古い方から300株の売注文が相手となって約定が成立する。これにより、8600円の売数量が0株、8700円の売数量が5000株に減少する。
また、8500円で100株の売注文が到着すると、8500円で400株の買注文のうち注文日時が古い方から100株の買注文が相手となって約定が成立する。これにより、8500円の買数量が300株に減少する。また、8500円で500株の売注文が到着すると、8500円で400株の買注文が相手となって約定が成立し、残りの100株の売注文は約定が成立しない。これにより、8500円の買数量が0株に減少し、8500円の売数量が100株に増加する。
また、8400円で100株の売注文が到着すると、8500円で400株の買注文のうち注文日時が古い方から100株の買注文が相手となって約定が成立する。これにより、8500円の買数量が300株に減少する。また、8400円で500株の売注文が到着すると、8500円で400株の買注文が相手となり、8400円で1600株の買注文のうち注文日時が古い方から100株の買注文が相手となって約定が成立する。これにより、8500円の買数量が0株、8400円の買数量が1500株に減少する。
ここで、株式取引では、株価の変動時に利益を得ることを狙って、現値を大きく超える指値の売注文や現値を大きく下回る指値の買注文を行う投資家が存在する。よって、売数量は現値から指値が大きい方に向かって広く分布し、買数量は現値から指値が小さい方に向かって広く分布する。一方で、平時の株式取引では、現値を大きく超える指値の買注文や現値を大きく下回る指値の売注文が到着することは少ない。よって、平時の株式取引では、到着した注文の約定相手を決定するにあたり、価格条件を満たす約定相手の候補は比較的少数でありデータベース検索の負荷は比較的低い。
ただし、投資家による企業価値の評価に大きな影響を与える投資情報が公開されると、パニック的な株式取引が行われる。企業価値の上昇を投資家が予測する場面では、現値を大きく超える指値の買注文が到着するようになる。また、企業価値の下落を投資家が予測する場面では、現値を大きく下回る指値の売注文が到着するようになる。よって、パニック時の株式取引では、到着した注文の約定相手を決定するにあたり、価格条件を満たす約定相手の候補が多数存在してデータベース検索の負荷が高くなる。
すなわち、現値を大きく超える指値の買注文が到着すると、現値からその買注文の指値までの間の売値をもつ多数の売注文が約定相手の候補になる。また、現値を大きく下回る指値の売注文が到着すると、現値からその売注文の指値までの間の買値をもつ多数の買注文が約定相手の候補になる。例えば、図6の例において、指値が9000円の買注文が到着すると、売値が8600円から9000円までの98200株の売注文が約定相手の候補になる。また、指値が8200円の売注文が到着すると、買値が8500円から8200円までの21100株の買注文が約定相手の候補になる。
そこで、第2の実施の形態のサーバ装置100は、後述するように、売注文表および買注文表のインデックスを工夫してデータベース検索を高速化する。
図7は、売注文表の例を示す図である。
売注文表133は、注文データベース125に記憶される。売注文表133は、ある銘柄の未約定の売注文を列挙する。売注文表133は、売値、数量、注文日時、注文番号、銘柄コードおよび依頼元の項目を有する。売注文表133に登録される1つのレコードは、注文キュー122から取り出された注文メッセージのうち売注文を示す注文メッセージ、すなわち、売買種別=2である注文メッセージに対応する。売値は、図5に示した注文メッセージ131に含まれる指値に対応する。数量、注文日時、注文番号、銘柄コードおよび依頼元は、注文メッセージ131に含まれる数量、注文日時、注文番号、銘柄コードおよび依頼元に対応する。ただし、売注文表133に登録された数量は、売注文の一部が約定成立することで注文当初の数量より減少していることがある。
一例として、売注文表133には、8600円で100株の売注文、8600円で100株の売注文が登録されている。また、売注文表133には、8700円で1000株の売注文、8700円で300株の売注文、8700円で1500株の売注文、8700円で500株の売注文、8700円で1000株の売注文が登録されている。売注文表133の数量を売値毎に合計することで、板情報132の売数量を算出することができる。8600円で200株の新たな売注文が到着した場合、約定相手の買注文が存在しないため、その新たな売注文を示すレコードが売注文表133に登録される。
図8は、買注文表の例を示す図である。
買注文表134は、注文データベース125に記憶される。買注文表134は、ある銘柄の未約定の買注文を列挙する。買注文表134は、買値、数量、注文日時、注文番号、銘柄コードおよび依頼元の項目を有する。買注文表134に登録される1つのレコードは、注文キュー122から取り出された注文メッセージのうち買注文を示す注文メッセージ、すなわち、売買種別=1である注文メッセージに対応する。買値は、図5に示した注文メッセージ131に含まれる指値に対応する。数量、注文日時、注文番号、銘柄コードおよび依頼元は、注文メッセージ131に含まれる数量、注文日時、注文番号、銘柄コードおよび依頼元に対応する。ただし、買注文表134に登録された数量は、買注文の一部が約定成立することで注文当初の数量より減少していることがある。
一例として、買注文表134には、8500円で100株の買注文、8500円で200株の買注文、8500円で100株の買注文が登録されている。また、買注文表134には、8400円で500株の買注文、8400円で100株の買注文、8400円で1000株の売注文が登録されている。また、買注文表134には、8300円で100株の買注文が登録されている。買注文表134の数量を買値毎に合計することで、板情報132の買数量を算出することができる。8500円で200株の新たな買注文が到着した場合、その新たな買注文を示すレコードが買注文表134に登録される。
なお、売注文表133からは、約定が成立した売注文を示すレコードが削除される。約定データベース126に記憶される売約定表には、約定が成立した売注文について売注文表133と同様の情報を登録することができる。また、買注文表134からは、約定が成立した買注文を示すレコードが削除される。約定データベース126に記憶される買約定表には、約定が成立した買注文について買注文表134と同様の情報を登録することができる。以下の第2の実施の形態の説明では、売注文表133および買注文表134に対するレコードの検索、挿入、更新、削除などのデータベース操作に着目し、売約定表および買約定表に対するデータベース操作については説明を省略している。
なお、処理を高速化するため、売注文表133からのレコードの削除は、実際にレコードを削除する代わりに、削除されたレコードであることを示す削除フラグをレコードに付与することで行ってもよい。売注文表133のレコードのうち削除フラグがONであるレコードは、売注文表133に存在しないものとみなされる。同様に、買注文表134からのレコードの削除は、削除されたレコードであることを示す削除フラグをレコードに付与することで行ってもよい。買注文表134のレコードのうち削除フラグがONであるレコードは、買注文表134に存在しないものとみなされる。
ところで、売注文表133のレコードを一意に識別するためのカラムである主キーは、注文番号である。注文番号は売注文の古い順に付与される昇順の整数であるため、複数のレコードを古い順にソートするためのソート基準値としても使用される。そこで、売注文表133からは、注文番号から当該注文番号をもつレコードを高速に参照できるようにするプライマリインデックスが生成される。プライマリインデックスは、注文データベース125に記憶される。また、売注文表133に対しては、売値を検索条件として用いてレコードを絞り込む検索を行うことが多い。そこで、売注文表133からは、売値から当該売値をもつレコードを高速に参照できるようにする売値インデックスが生成される。売値インデックスは、注文データベース125に記憶される。
同様に、買注文表134のレコードを一意に識別するためのカラムである主キーは、注文番号である。買注文表134からは、注文番号から当該注文番号をもつレコードを高速に参照できるようにするプライマリインデックスが生成される。プライマリインデックスは、注文データベース125に記憶される。また、買注文表134に対しては、買値を検索条件として用いてレコードを絞り込む検索を行うことが多い。そこで、買注文表134からは、買値から当該買値をもつレコードを高速に参照できるようにする買値インデックスが生成される。買値インデックスは、注文データベース125に記憶される。
ここで、売値インデックスおよび買値インデックスの構造について説明する。
図9は、インデックスのデータ構造例を示す図である。
売値インデックスおよび買値インデックスは、複数のノード(節点)が木構造に接続されたB-treeである。ただし、売値インデックスおよび買値インデックスを、B-tree以外の木構造にしてもよいし、木構造以外のデータ構造にしてもよい。また、以下の説明では、売値インデックスおよび買値インデックスを、各ノードが2つの子ノードをもつ二分木としているが、各ノードが3つ以上の子ノードをもつようにしてもよい。
ノード135は、売値インデックスまたは買値インデックスに含まれるノードの例である。ノード135は、売値または買値、レコード数、アドレスリストへのポインタ、合計数量、左子ノードへのポインタおよび右子ノードへのポインタを含む。
ノード135が売値インデックスのノードである場合、ノード135に含まれる売値は、売注文表133の売値のカラムに出現し得る数値である。レコード数は、売注文表133に登録されたレコードのうち当該売値をもつレコードの数である。アドレスリストへのポインタは、売注文表133に登録されたレコードのうち当該売値をもつレコードのアドレスを列挙したアドレスリストを指し示す。例えば、アドレスリストへのポインタは、アドレスリストの先頭にあるリスト要素135-1を指し示す。リスト要素135-1は、当該売値をもつ1番目のレコードのアドレスと、2番目のリスト要素135-2を指し示す次ポインタとを含む。リスト要素135-2は、当該売値をもつ2番目のレコードのアドレスと、3番目のリスト要素を指し示す次ポインタとを含む。このように、リスト構造によって複数のレコードのアドレスが列挙される。ただし、リスト構造に代えて配列など他のデータ構造によって複数のレコードのアドレスを列挙してもよい。
合計数量は、売注文表133に登録されたレコードのうち当該売値をもつレコードの数量を合計した数値である。後述するように、売値毎に合計数量を売値インデックスがもつことで、売注文と買注文のマッチングを高速化することができる。左子ノードへのポインタは、ノード135より小さい売値をもつ左子ノードを指し示す。右子ノードへのポインタは、ノード135より大きい売値をもつ右子ノードを指し示す。
売注文表133に対してレコードの挿入または削除が行われる毎に、そのレコードの売値に対応するノードのレコード数、アドレスリストおよび合計数量が更新される。売注文表133にレコードが挿入されると、レコード数が1だけ増加し、アドレスリストに当該レコードのアドレスが登録され、合計数量が当該レコードの数量だけ増加する。売注文表133からレコードが削除されると、レコード数が1だけ減少し、アドレスリストから当該レコードのアドレスが削除され、合計数量が当該レコードの数量だけ減少する。
ノード135が買値インデックスのノードである場合、ノード135に含まれる買値は、買注文表134の買値のカラムに出現し得る数値である。レコード数は、買注文表134に登録されたレコードのうち当該買値をもつレコードの数である。アドレスリストへのポインタは、買注文表134に登録されたレコードのうち当該買値をもつレコードのアドレスを列挙したアドレスリストを指し示す。合計数量は、買注文表134に登録されたレコードのうち当該買値をもつレコードの数量を合計した数値である。左子ノードへのポインタは、ノード135より小さい買値をもつ左子ノードを指し示す。右子ノードへのポインタは、ノード135より大きい買値をもつ右子ノードを指し示す。
買注文表134に対してレコードの挿入または削除が行われる毎に、そのレコードの買値に対応するノードのレコード数、アドレスリストおよび合計数量が更新される。買注文表134にレコードが挿入されると、レコード数が1だけ増加し、アドレスリストに当該レコードのアドレスが登録され、合計数量が当該レコードの数量だけ増加する。買注文表134からレコードが削除されると、レコード数が1だけ減少し、アドレスリストから当該レコードのアドレスが削除され、合計数量が当該レコードの数量だけ減少する。
なお、第2の実施の形態では、マッチング部123が合計数量を使用することが多いため、ノード135に合計数量を登録している。ただし、データベース管理システム124を使用するアプリケーションに応じて、ノード135に合計数量以外の統計値を登録することも可能である。例えば、SQL文では、複数のレコードから1つの値を算出する集合関数として、合計を求める関数SUMの他に、最大値を求める関数MAX、最小値を求める関数MIN、平均を求める関数AVGなどを使用できる。そこで、ノード135に、最大数量、最小数量、平均数量などを登録してもよい。また、第2の実施の形態では数量のカラムの統計値を登録しているが、他のカラムの統計値を登録してもよい。
図10は、売注文表の売値インデックスの例を示す図である。
売値インデックス136は、売注文表133から生成される。売値インデックス136は、ある銘柄の未約定の売注文を示すレコードを、売値から絞り込むことを高速化する。売値インデックス136は、ノード136-1~136-7を含む。
ノード136-1は、売値が8900円のレコードのアドレスを列挙したアドレスリストをもつと共に、列挙されたレコードの数量の合計が69700株であることを示す。ノード136-2は、売値が8700円のレコードのアドレスを列挙したアドレスリストをもつと共に、列挙されたレコードの数量の合計が5300株であることを示す。ノード136-3は、売値が9100円のレコードのアドレスを列挙したアドレスリストをもつと共に、列挙されたレコードの数量の合計が2100株であることを示す。
ノード136-4は、売値が8600円のレコードのアドレスを列挙したアドレスリストをもつと共に、列挙されたレコードの数量の合計が200株であることを示す。ノード136-5は、売値が8800円のレコードのアドレスを列挙したアドレスリストをもつと共に、列挙されたレコードの数量の合計が1100株であることを示す。ノード136-6は、売値が9000円のレコードのアドレスを列挙したアドレスリストをもつと共に、列挙されたレコードの数量の合計が21900株であることを示す。ノード136-7は、売値が9200円のレコードのアドレスを列挙したアドレスリストをもつと共に、列挙されたレコードの数量の合計が110株であることを示す。
なお、データベース管理システム124は、売値インデックス136に含まれるノードのうち所望の売値をもつノードを、二分探索によって検索する。データベース管理システム124は、まず所望の売値とルートノードがもつ売値とを比較する。所望の売値がルートノードの売値より小さい場合には左子ノードに進み、所望の売値がルートノードの売値より大きい場合には右子ノードに進む。データベース管理システム124は、所望の売値をもつノードが見つかるまで、左子ノードまたは右子ノードの探索を繰り返す。
図11は、買注文表の買値インデックスの例を示す図である。
買値インデックス137は、買注文表134から生成される。買値インデックス137は、ある銘柄の未約定の買注文を示すレコードを、買値から絞り込むことを高速化する。買値インデックス137は、ノード137-1~137-7を含む。
ノード137-1は、買値が8000円のレコードのアドレスを列挙したアドレスリストをもつと共に、列挙されたレコードの数量の合計が3100株であることを示す。ノード137-2は、買値が7700円のレコードのアドレスを列挙したアドレスリストをもつと共に、列挙されたレコードの数量の合計が7230株であることを示す。ノード137-3は、買値が8300円のレコードのアドレスを列挙したアドレスリストをもつと共に、列挙されたレコードの数量の合計が900株であることを示す。
ノード137-4は、買値が7600円のレコードのアドレスを列挙したアドレスリストをもつと共に、列挙されたレコードの数量の合計が22800株であることを示す。ノード137-5は、買値が7800円のレコードのアドレスを列挙したアドレスリストをもつと共に、列挙されたレコードの数量の合計が11000株であることを示す。ノード137-6は、買値が8100円のレコードのアドレスを列挙したアドレスリストをもつと共に、列挙されたレコードの数量の合計が6400株であることを示す。ノード137-7は、買値が8500円のレコードのアドレスを列挙したアドレスリストをもつと共に、列挙されたレコードの数量の合計が400株であることを示す。
なお、データベース管理システム124は、買値インデックス137に含まれるノードのうち所望の買値をもつノードを、二分探索によって検索する。
図12は、テーブル定義ファイルの例を示す図である。
テーブル定義ファイル138は、予め注文データベース125に記憶される。データベース管理システム124は、起動時にテーブル定義ファイル138から、売注文表133、買注文表134、売値インデックス136および買値インデックス137を生成する。
テーブル定義ファイル138は、売注文表133の構造および売値インデックス136の構造を定義したSQL文を含む。売注文表133は、整数型の売値、整数型の数量、文字列型の注文日時、整数型の注文番号、整数型の銘柄コードおよび文字列型の依頼元のカラムを含むことが定義される。また、売注文表133の注文番号が主キーであることが定義される。また、売値インデックス136は、売注文表133の売値のカラムに対して生成され、数量のカラムに合計関数SUMを適用した値をもつことが定義される。
また、テーブル定義ファイル138は、買注文表134の構造および買値インデックス137の構造を定義したSQL文を含む。買注文表134は、整数型の買値、整数型の数量、文字列型の注文日時、整数型の注文番号、整数型の銘柄コードおよび文字列型の依頼元のカラムを含むことが定義される。また、買注文表134の注文番号が主キーであることが定義される。また、買値インデックス137は、買注文表134の買値のカラムに対して生成され、数量のカラムに合計関数SUMを適用した値をもつことが定義される。
次に、マッチング部123が売注文と買注文のマッチングを行うにあたり、データベース管理システム124に対して発行される一連のSQL文について説明する。
図13は、売注文に対する第1のクエリ実行例を示す図である。
マッチング部123は、注文メッセージ141-1を注文キュー122から取り出す。注文メッセージ141-1は、8500円で500株の売注文を示す。すると、マッチング部123は、SQL文141-2をデータベース管理システム124に発行する。SQL文141-2は、買注文表134から買値が8500円以上のレコードを検索して該当レコードに含まれる数量の総和を求める検索クエリである。
データベース管理システム124は、SQL文141-2を受け付けると、買値インデックス137から買値が8500円以上のノードを検索し、該当ノードに含まれる合計数量の総和を求める。このとき、データベース管理システム124は、買注文表134にアクセスしなくてよい。データベース管理システム124は、SQL文141-2に対する処理結果141-3をマッチング部123に応答する。処理結果141-3は、SQL文141-2によって要求された数量の総和が400株であることを示す。
マッチング部123は、処理結果141-3が示す400株が、注文メッセージ141-1が示す500株以下であるため、SQL文141-2の検索条件に合う全てのレコードが約定相手になると判定する。すると、マッチング部123は、SQL文141-4をデータベース管理システム124に発行する。SQL文141-4は、買注文表134から買値が8500円以上のレコードを削除する削除クエリである。
データベース管理システム124は、SQL文141-4を受け付けると、買値インデックス137から買値が8500円以上のノードを検索し、該当ノードから買注文表134のレコードを特定する。データベース管理システム124は、特定したレコードを買注文表134から削除する。また、データベース管理システム124は、レコードの削除が反映されるように買値インデックス137を更新する。データベース管理システム124は、SQL文141-4に対する処理結果141-5をマッチング部123に応答する。処理結果141-5は、レコードの削除が成功したことを示す。
マッチング部123は、注文メッセージ141-1が示す500株のうち100株が未約定であるため、SQL文141-6をデータベース管理システム124に発行する。SQL文141-6は、売注文表133に、売値が8500円で100株の売注文を示すレコードを挿入する挿入クエリである。データベース管理システム124は、SQL文141-6を受け付けると、売注文表133にレコードを挿入し、レコードの挿入が反映されるように売値インデックス136を更新する。データベース管理システム124は、SQL文141-6に対する処理結果141-7をマッチング部123に応答する。処理結果141-7は、レコードの挿入が成功したことを示す。これにより、注文メッセージ141-1が示す売注文に対する注文処理が終了する。
図14は、売注文に対する第2のクエリ実行例を示す図である。
マッチング部123は、注文メッセージ142-1を注文キュー122から取り出す。注文メッセージ142-1は、8400円で900株の売注文を示す。すると、マッチング部123は、SQL文142-2をデータベース管理システム124に発行する。SQL文142-2は、買注文表134から買値が8400円以上のレコードを検索して該当レコードに含まれる数量の総和を求める検索クエリである。
データベース管理システム124は、SQL文142-2を受け付けると、買値インデックス137から買値が8400円以上のノードを検索し、該当ノードに含まれる合計数量の総和を求める。このとき、データベース管理システム124は、買注文表134にアクセスしなくてよい。データベース管理システム124は、SQL文142-2に対する処理結果142-3をマッチング部123に応答する。処理結果142-3は、SQL文142-2によって要求された数量の総和が2000株であることを示す。
マッチング部123は、処理結果142-3が示す2000株が、注文メッセージ142-1が示す900株を超えるため、買値に基づいて絞り込んだ一部のレコードが約定相手になると判定する。すると、マッチング部123は、SQL文142-4をデータベース管理システム124に発行する。SQL文142-4は、買注文表134から買値が8400円以上のレコードを検索し、買値毎に該当レコードに含まれる数量の合計を求め、合計数量を買値の降順にソートする検索クエリである。
データベース管理システム124は、SQL文142-4を受け付けると、検索結果を一行ずつ取り出すためのカーソル(カーソル1)をオープンし、カーソル1を示す処理結果142-5をマッチング部123に応答する。
マッチング部123は、処理結果142-5が示すカーソル1を用いて、検索結果の次の一行を取り出すSQL文142-6をデータベース管理システム124に発行する。データベース管理システム124は、SQL文142-6を受け付けると、買値インデックス137から最大の買値である8500円のノードを検索し、該当ノードから合計数量を読み出す。このとき、データベース管理システム124は、買注文表134にアクセスしなくてよい。データベース管理システム124は、SQL文142-6に対する処理結果142-7をマッチング部123に応答する。処理結果142-7は、買値が8500円であり合計数量が400株であることを示す。
マッチング部123は、処理結果142-7が示す400株が、注文メッセージ142-1が示す900株以下であるため、買値が8500円の全てのレコードが約定相手になると判定する。すると、マッチング部123は、SQL文142-8をデータベース管理システム124に発行する。SQL文142-8は、買注文表134から処理結果142-7に該当するレコードを削除する削除クエリである。
データベース管理システム124は、SQL文142-8を受け付けると、買値インデックス137から買値が8500円のノードを検索し、該当ノードから買注文表134のレコードを特定する。データベース管理システム124は、特定したレコードを買注文表134から削除する。また、データベース管理システム124は、レコードの削除が反映されるように買値インデックス137を更新する。データベース管理システム124は、SQL文142-8に対する処理結果142-9をマッチング部123に応答する。処理結果142-9は、レコードの削除が成功したことを示す。
図15は、売注文に対する第2のクエリ実行例を示す図(続き)である。
マッチング部123は、処理結果142-5が示すカーソル1を用いて、検索結果の次の一行を取り出すSQL文143-1をデータベース管理システム124に発行する。データベース管理システム124は、SQL文143-1を受け付けると、買値インデックス137から次に大きい買値である8400円のノードを検索し、該当ノードから合計数量を読み出す。このとき、データベース管理システム124は、買注文表134にアクセスしなくてよい。データベース管理システム124は、SQL文143-1に対する処理結果143-2をマッチング部123に応答する。処理結果143-2は、買値が8400円であり合計数量が1600株であることを示す。
マッチング部123は、処理結果143-2が示す1600株が、注文メッセージ142-1が示す900株のうち未約定の500株を超えるため、注文番号に基づいて絞り込んだ一部のレコードが約定相手になると判定する。すると、マッチング部123は、SQL文143-3をデータベース管理システム124に発行する。SQL文143-3は、買注文表134から買値が8400円以上のレコードを検索し、該当レコードを買値の降順にソートし、同じ買値の中では注文番号の昇順にソートする検索クエリである。
データベース管理システム124は、SQL文143-3を受け付けると、買値インデックス137から買値が8400円以上のノードを検索し、該当ノードから買注文表134のレコードを特定する。データベース管理システム124は、該当レコードを読み出して一時領域に格納し、一時領域のレコードを買値および注文番号でソートする。データベース管理システム124は、検索結果を一行ずつ取り出すためのカーソル(カーソル2)をオープンし、カーソル2を示す処理結果143-4をマッチング部123に応答する。
マッチング部123は、処理結果143-4が示すカーソル2を用いて、検索結果の次の一行を取り出すSQL文143-5をデータベース管理システム124に発行する。データベース管理システム124は、SQL文143-5を受け付けると、一時領域に記憶されたソート済みの検索結果から先頭のレコードを読み出し、読み出したレコードを示す処理結果143-6をマッチング部123に応答する。処理結果143-6は、買値が8400円であり数量が500株であることを示す。
マッチング部123は、処理結果143-6が示す500株が、注文メッセージ142-1が示す900株のうち未約定の500株以下であるため、処理結果143-6が示すレコードの全数量が約定相手になると判定する。すると、マッチング部123は、SQL文143-7をデータベース管理システム124に発行する。SQL文143-7は、買注文表134から処理結果143-6が示すレコードを削除する削除クエリである。
データベース管理システム124は、SQL文143-7を受け付けると、処理結果143-6が示すレコードを買注文表134から削除する。該当レコードは注文番号から特定してもよい。また、データベース管理システム124は、レコードの削除が反映されるように買値インデックス137を更新する。データベース管理システム124は、SQL文143-7に対する処理結果143-8をマッチング部123に応答する。処理結果143-8は、レコードの削除が成功したことを示す。これにより、注文メッセージ142-1が示す売注文に対する注文処理が終了する。
図16は、買注文に対する第1のクエリ実行例を示す図である。
マッチング部123は、注文メッセージ144-1を注文キュー122から取り出す。注文メッセージ144-1は、9000円で100000株の買注文を示す。すると、マッチング部123は、SQL文144-2をデータベース管理システム124に発行する。SQL文144-2は、売注文表133から売値が9000円以下のレコードを検索して該当レコードに含まれる数量の総和を求める検索クエリである。
データベース管理システム124は、SQL文144-2を受け付けると、売値インデックス136から売値が9000円以下のノードを検索し、該当ノードに含まれる合計数量の総和を求める。このとき、データベース管理システム124は、売注文表133にアクセスしなくてよい。データベース管理システム124は、SQL文144-2に対する処理結果144-3をマッチング部123に応答する。処理結果144-3は、SQL文144-2によって要求された数量の総和が98200株であることを示す。
マッチング部123は、処理結果144-3が示す98200株が、注文メッセージ144-1が示す100000株以下であるため、SQL文144-2の検索条件に合う全てのレコードが約定相手になると判定する。すると、マッチング部123は、SQL文144-4をデータベース管理システム124に発行する。SQL文144-4は、売注文表133から売値が9000円以下のレコードを削除する削除クエリである。
データベース管理システム124は、SQL文144-4を受け付けると、売値インデックス136から売値が9000円以下のノードを検索し、該当ノードから売注文表133のレコードを特定する。データベース管理システム124は、特定したレコードを売注文表133から削除する。また、データベース管理システム124は、レコードの削除が反映されるように売値インデックス136を更新する。データベース管理システム124は、SQL文144-4に対する処理結果144-5をマッチング部123に応答する。処理結果144-5は、レコードの削除が成功したことを示す。
マッチング部123は、注文メッセージ144-1が示す100000株のうち1800株が未約定であるため、SQL文144-6をデータベース管理システム124に発行する。SQL文144-6は、買注文表134に、買値が9000円で1800株の買注文を示すレコードを挿入する挿入クエリである。データベース管理システム124は、SQL文144-6を受け付けると、買注文表134にレコードを挿入し、レコードの挿入が反映されるように買値インデックス137を更新する。データベース管理システム124は、SQL文144-6に対する処理結果144-7をマッチング部123に応答する。処理結果144-7は、レコードの挿入が成功したことを示す。これにより、注文メッセージ144-1が示す買注文に対する注文処理が終了する。
図17は、買注文に対する第2のクエリ実行例を示す図である。
マッチング部123は、注文メッセージ145-1を注文キュー122から取り出す。注文メッセージ145-1は、8700円で400株の買注文を示す。すると、マッチング部123は、SQL文145-2をデータベース管理システム124に発行する。SQL文145-2は、売注文表133から売値が8700円以下のレコードを検索して該当レコードに含まれる数量の総和を求める検索クエリである。
データベース管理システム124は、SQL文145-2を受け付けると、売値インデックス136から売値が8700円以下のノードを検索し、該当ノードに含まれる合計数量の総和を求める。このとき、データベース管理システム124は、売注文表133にアクセスしなくてよい。データベース管理システム124は、SQL文145-2に対する処理結果145-3をマッチング部123に応答する。処理結果145-3は、SQL文145-2によって要求された数量の総和が5500株であることを示す。
マッチング部123は、処理結果145-3が示す5500株が、注文メッセージ145-1が示す400株を超えるため、売値に基づいて絞り込んだ一部のレコードが約定相手になると判定する。すると、マッチング部123は、SQL文145-4をデータベース管理システム124に発行する。SQL文145-4は、売注文表133から売値が8700円以下のレコードを検索し、売値毎に該当レコードに含まれる数量の合計を求め、合計数量を売値の昇順にソートする検索クエリである。
データベース管理システム124は、SQL文145-4を受け付けると、検索結果を一行ずつ取り出すためのカーソル(カーソル1)をオープンし、カーソル1を示す処理結果145-5をマッチング部123に応答する。
マッチング部123は、処理結果145-5が示すカーソル1を用いて、検索結果の次の一行を取り出すSQL文145-6をデータベース管理システム124に発行する。データベース管理システム124は、SQL文145-6を受け付けると、売値インデックス136から最小の売値である8600円のノードを検索し、該当ノードから合計数量を読み出す。このとき、データベース管理システム124は、売注文表133にアクセスしなくてよい。データベース管理システム124は、SQL文145-6に対する処理結果145-7をマッチング部123に応答する。処理結果145-7は、売値が8600円であり合計数量が200株であることを示す。
マッチング部123は、処理結果145-7が示す200株が、注文メッセージ145-1が示す400株以下であるため、売値が8600円の全てのレコードが約定相手になると判定する。すると、マッチング部123は、SQL文145-8をデータベース管理システム124に発行する。SQL文145-8は、売注文表133から処理結果145-7に該当するレコードを削除する削除クエリである。
データベース管理システム124は、SQL文145-8を受け付けると、売値インデックス136から売値が8600円のノードを検索し、該当ノードから売注文表133のレコードを特定する。データベース管理システム124は、特定したレコードを売注文表133から削除する。また、データベース管理システム124は、レコードの削除が反映されるように売値インデックス136を更新する。データベース管理システム124は、SQL文145-8に対する処理結果145-9をマッチング部123に応答する。処理結果145-9は、レコードの削除が成功したことを示す。
図18は、買注文に対する第2のクエリ実行例を示す図(続き)である。
マッチング部123は、処理結果145-5が示すカーソル1を用いて、検索結果の次の一行を取り出すSQL文146-1をデータベース管理システム124に発行する。データベース管理システム124は、SQL文146-1を受け付けると、売値インデックス136から次に小さい売値である8700円のノードを検索し、該当ノードから合計数量を読み出す。このとき、データベース管理システム124は、売注文表133にアクセスしなくてよい。データベース管理システム124は、SQL文146-1に対する処理結果146-2をマッチング部123に応答する。処理結果146-2は、売値が8700円であり合計数量が5300株であることを示す。
マッチング部123は、処理結果146-2が示す5300株が、注文メッセージ145-1が示す400株のうち未約定の200株を超えるため、注文番号に基づいて絞り込んだ一部のレコードが約定相手になると判定する。すると、マッチング部123は、SQL文146-3をデータベース管理システム124に発行する。SQL文146-3は、売注文表133から売値が8700円以下のレコードを検索し、該当レコードを売値の昇順にソートし、同じ売値の中では注文番号の昇順にソートする検索クエリである。
データベース管理システム124は、SQL文146-3を受け付けると、売値インデックス136から売値が8700円以下のノードを検索し、該当ノードから売注文表133のレコードを特定する。データベース管理システム124は、該当レコードを読み出して一時領域に格納し、一時領域のレコードを売値および注文番号でソートする。データベース管理システム124は、検索結果を一行ずつ取り出すためのカーソル(カーソル2)をオープンし、カーソル2を示す処理結果146-4をマッチング部123に応答する。
マッチング部123は、処理結果146-4が示すカーソル2を用いて、検索結果の次の一行を取り出すSQL文146-5をデータベース管理システム124に発行する。データベース管理システム124は、SQL文146-5を受け付けると、一時領域に記憶されたソート済みの検索結果から先頭のレコードを読み出し、読み出したレコードを示す処理結果146-6をマッチング部123に応答する。処理結果146-6は、売値が8700円であり数量が1000株であることを示す。
マッチング部123は、処理結果146-6が示す1000株が、注文メッセージ145-1が示す400株のうち未約定の200株を超えるため、処理結果146-6が示すレコードの一部数量が約定相手になると判定する。すると、マッチング部123は、SQL文146-7をデータベース管理システム124に発行する。SQL文146-7は、処理結果146-6が示すレコードの数量を200株だけ減らす更新クエリである。
データベース管理システム124は、SQL文146-7を受け付けると、処理結果146-6が示すレコードを売注文表133から特定する。該当レコードは注文番号から特定してもよい。データベース管理システム124は、該当レコードの数量を1000株から800株に更新する。また、データベース管理システム124は、レコードの更新が反映されるように売値インデックス136を更新する。データベース管理システム124は、SQL文146-7に対する処理結果146-8をマッチング部123に応答する。処理結果146-8は、レコードの更新が成功したことを示す。これにより、注文メッセージ145-1が示す買注文に対する注文処理が終了する。
このように、関係データベースを利用した売注文と買注文のマッチングでは、マッチング部123は、集合関数の一種である合計関数SUMを含むSQL文を頻繁に発行する。これに対して、データベース管理システム124は、売値インデックス136および買値インデックス137に合計値を付加することで、売注文表133および買注文表134へのアクセスを削減して効率的にSQL文を処理することができる。なお、上記ではマッチング部123が発行するSQL文について説明したが、板生成部127が板情報132を生成するためのSQL文についても、売値インデックス136および買値インデックス137に付加された合計値を用いて効率的に処理することができる。
次に、サーバ装置100の処理手順について説明する。
図19は、データベース起動の手順例を示すフローチャートである。
(S10)データベース管理システム124は、テーブル定義ファイル138をロードする。例えば、データベース管理システム124は、HDD103に記憶されているテーブル定義ファイル138をRAM102にロードする。
(S11)データベース管理システム124は、ステップS10でロードされたテーブル定義ファイル138に定義された構造のテーブルをRAM102上に生成する。生成されるテーブルには、売注文表133および買注文表134が含まれる。売注文表133および買注文表134は、注文データベース125に属する。
(S12)データベース管理システム124は、ステップS11で生成された空のテーブルに、予め退避されている初期データをロードする。例えば、テーブル定義ファイル138は、HDD103に記憶されている初期データをロードする。
(S13)データベース管理システム124は、テーブル定義ファイル138から各テーブルの主キーを特定し、主キーの値からレコードを辿ることができるプライマリインデックスを生成する。生成されるプライマリインデックスには、売注文表133に対応するプライマリインデックスであって注文番号を主キーとするものと、買注文表134に対応するプライマリインデックスであって注文番号を主キーとするものが含まれる。
(S14)データベース管理システム124は、テーブル定義ファイル138に従って、初期データがロードされた売注文表133から、売値からレコードを検索できる売値インデックス136を生成する。ここで生成される売値インデックス136の各ノードは、売値、レコード数、アドレスリストへのポインタおよび子ノードへのポインタを含む。また、データベース管理システム124は、テーブル定義ファイル138に従って、初期データがロードされた買注文表134から、買値からレコードを検索できる買値インデックス137を生成する。ここで生成される買値インデックス137の各ノードは、買値、レコード数、アドレスリストへのポインタおよび子ノードへのポインタを含む。
(S15)データベース管理システム124は、ステップS14で生成された売値インデックス136の各ノードに合計数量を挿入する。具体的には、データベース管理システム124は、ノード毎に、アドレスリストから参照されるレコードの中の数量の値を売注文表133から読み出し、読み出した数量の値を合計する。また、データベース管理システム124は、買値インデックス137の各ノードに合計数量を挿入する。具体的には、データベース管理システム124は、ノード毎に、アドレスリストから参照されるレコードの中の数量の値を買注文表134から読み出し、読み出した数量の値を合計する。
図20は、注文処理の手順例を示すフローチャートである。
(S20)マッチング部123は、注文キュー122から注文メッセージを抽出する。以降の注文処理の説明では、売注文を示す注文メッセージ、すなわち、売買種別=2の注文メッセージが抽出された場合を考える。ただし、売注文に対する処理と買注文に対する処理は対称であるため、買注文に対する処理についても併せて言及する。
(S21)マッチング部123は、買値が売注文の指値以上であるレコードを買注文表134から検索して、検索されたレコードに含まれる数量の総和を求めるクエリを発行する。ここで発行されるクエリは、前述のSQL文141-2,142-2に対応する。なお、買注文の注文メッセージに対しては、マッチング部123は、売値が買注文の指値以下であるレコードを売注文表133から検索して、検索されたレコードに含まれる数量の総和を求めるクエリを発行する。この場合に発行されるクエリは、前述のSQL文144-2,145-2に対応する。
(S22)データベース管理システム124は、買値インデックス137の中に、クエリに記載された「買値が売注文の指値以上である」という買値条件を満たすノードが存在するか判断する。該当ノードがある場合はステップS23に進み、該当ノードがない場合はステップS29に進む。なお、買注文の注文メッセージに対しては、データベース管理システム124は、売値インデックス136の中に、クエリに記載された「売値が買注文の指値以下である」という売値条件を満たすノードが存在するか判断する。
(S23)データベース管理システム124は、クエリに記載された買値条件を満たす1以上のノードを買値インデックス137から検索し、検索された1以上のノードそれぞれから合計数量を読み出し、読み出した合計数量の総和を算出する。データベース管理システム124は、算出した総和を含む処理結果をマッチング部123に応答する。ここで生成される処理結果は、前述の処理結果141-3,142-3に対応する。なお、買注文の注文メッセージに対しては、データベース管理システム124は、クエリに記載された売値条件を満たす1以上のノードを売値インデックス136から検索し、検索された1以上のノードそれぞれから合計数量を読み出し、読み出した合計数量の総和を算出する。
(S24)マッチング部123は、ステップS23の総和を「相手数量1」とする。
(S25)マッチング部123は、「相手数量1」が、注文メッセージに含まれる注文数量以下であるか判断する。「相手数量1」が注文数量以下の場合はステップS26に進み、注文数量を超える場合はステップS36に進む。
(S26)マッチング部123は、買値が売注文の指値以上であるレコードを買注文表134から削除するクエリを発行する。ここで発行されるクエリは、前述のSQL文141-4に対応する。なお、買注文の注文メッセージに対しては、マッチング部123は、売値が買注文の指値以下であるレコードを売注文表133から削除するクエリを発行する。この場合に発行されるクエリは、前述のSQL文144-4に対応する。
(S27)データベース管理システム124は、ステップS26のクエリの買値条件を満たすノードを買値インデックス137から検索し、検索されたノードが指し示すレコードを買注文表134から削除する。また、データベース管理システム124は、検索されたノードから当該レコードのアドレスを削除し、合計数量を0にするように買値インデックス137を更新する。また、データベース管理システム124は、プライマリインデックスを更新する。そして、データベース管理システム124は、ステップS26のクエリに対する処理結果をマッチング部123に応答する。ここで生成される処理結果は、前述の処理結果141-5に対応する。なお、買注文の注文メッセージに対しては、データベース管理システム124は、クエリの売値条件を満たすノードを売値インデックス136から検索し、検索されたノードが指し示すレコードを売注文表133から削除する。この場合に生成される処理結果は、前述の処理結果144-5に対応する。
(S28)マッチング部123は、注文数量からステップS24の「相手数量1」を引いた値を「注文残数量」とする。そして、ステップS31に進む。
(S29)データベース管理システム124は、データなしを示す処理結果を生成してマッチング部123に応答する。
(S30)マッチング部123は、注文数量を「注文残数量」とする。
図21は、注文処理の手順例を示すフローチャート(続き1)である。
(S31)マッチング部123は、「注文残数量」が0より大きいか判断する。0より大きい場合はステップS32に進み、0である場合はステップS34に進む。
(S32)マッチング部123は、「注文残数量」に相当する売注文を示すレコードを売注文表133に挿入するクエリを発行する。レコード中の数量は「注文残数量」であり、他のカラムは注文メッセージと同じである。ここで発行されるクエリは、前述のSQL文141-6に対応する。なお、買注文の注文メッセージに対しては、マッチング部123は、「注文残数量」に相当する買注文を示すレコードを買注文表134に挿入するクエリを発行する。この場合に発行されるクエリは、前述のSQL文144-6に対応する。
(S33)データベース管理システム124は、売注文表133にレコードを挿入する。また、データベース管理システム124は、挿入したレコードの売値に対応するノードに当該レコードのアドレスを追加し、当該レコードの数量を当該ノードの合計数量に加算するように、売値インデックス136を更新する。また、データベース管理システム124は、プライマリインデックスを更新する。そして、データベース管理システム124は、処理結果をマッチング部123に応答する。ここで生成される処理結果は、前述の処理結果141-7に対応する。なお、買注文の注文メッセージに対しては、データベース管理システム124は、買注文表134にレコードを挿入して買値インデックス137を更新する。この場合に生成される処理結果は、前述の処理結果144-7に対応する。
(S34)マッチング部123は、これまでの一連のデータ操作を確定させるためのトランザクションコミットを示すクエリをデータベース管理システム124に発行する。
(S35)データベース管理システム124は、これまでの一連のデータ操作を含むトランザクションを確定させて注文データベース125に反映させる。データベース管理システム124は、トランザクションコミットの処理結果をマッチング部123に応答する。そして、ステップS20の注文メッセージに対する注文処理が終了する。
図22は、注文処理の手順例を示すフローチャート(続き2)である。
(S36)マッチング部123は、注文数量を「注文残数量」とする。
(S37)マッチング部123は、買値が売注文の指値以上であるレコードを買注文表134から検索し、検索されたレコードに含まれる数量を買値毎に合計して、買値と合計数量の一覧を求めるクエリを発行する。このとき、処理結果が買値の降順にソートされるようにクエリで指定する。ここで発行されるクエリは、前述のSQL文142-4に対応する。なお、買注文の注文メッセージに対しては、マッチング部123は、売値が買注文の指値以下であるレコードを売注文表133から検索し、検索されたレコードに含まれる数量を売値毎に合計して、売値と合計数量の一覧を求めるクエリを発行する。このとき、処理結果が売値の昇順にソートされるようにクエリで指定する。この場合に発行されるクエリは、前述のSQL文145-4に対応する。
(S38)データベース管理システム124は、クエリ結果を一行ずつ参照させる「カーソル1」をオープンし、「カーソル1」を示す処理結果をマッチング部123に応答する。ここで生成される処理結果は、前述の処理結果142-5,145-5に対応する。
(S39)マッチング部123は、ステップS38でオープンされた「カーソル1」によりクエリ結果の次の一行を取り出すクエリを発行する。ここで発行されるクエリは、前述のSQL文142-6,143-1,145-6,146-1に対応する。
(S40)データベース管理システム124は、買値インデックス137から、「買値が売注文の指値以上」という買値条件を満たす1以上のノードのうち、買値の高い方から優先的に未選択のノード(次のノード)を1つ選択する。データベース管理システム124は、選択したノードから買値および合計数量を読み出し、読み出した買値および合計数量を含む処理結果をマッチング部123に応答する。ここで生成される処理結果は、前述の処理結果142-7,143-2に対応する。なお、買注文を示す注文メッセージに対しては、データベース管理システム124は、売値インデックス136から、「売値が買注文の指値以下」という売値条件を満たす1以上のノードのうち、売値の低い方から優先的に未選択のノード(次のノード)を1つ選択する。この場合に生成される処理結果は、前述の処理結果145-7,146-2に対応する。
(S41)マッチング部123は、取り出した合計数量を「相手数量2」とする。
(S42)マッチング部123は、「相手数量2」が「注文残数量」以下であるか判断する。「相手数量2」が「注文残数量」以下である場合はステップS43に進み、「相手数量2」が「注文残数量」を超える場合はステップS48に進む。
(S43)マッチング部123は、「カーソル1」が現在参照しているクエリ結果に相当するレコードを買注文表134から削除するクエリを発行する。ここで発行されるクエリは、前述のSQL文142-8に対応する。なお、買注文の注文メッセージに対しては、マッチング部123は、「カーソル1」が現在参照しているクエリ結果に相当するレコードを売注文表133から削除するクエリを発行する。この場合に発行されるクエリは、前述のSQL文145-8に対応する。
(S44)データベース管理システム124は、「カーソル1」が参照する買値を含むノードを買値インデックス137から検索し、検索されたノードが指し示すレコードを買注文表134から削除する。また、データベース管理システム124は、検索されたノードから当該レコードのアドレスを削除し、合計数量を0にするように買値インデックス137を更新する。また、データベース管理システム124は、プライマリインデックスを更新する。そして、データベース管理システム124は、ステップS43のクエリに対する処理結果をマッチング部123に応答する。ここで生成される処理結果は、前述の処理結果142-9に対応する。なお、買注文の注文メッセージに対しては、データベース管理システム124は、「カーソル1」が参照する売値を含むノードを売値インデックス136から検索し、検索されたノードが指し示すレコードを売注文表133から削除する。この場合に生成される処理結果は、前述の処理結果145-9に対応する。
(S45)マッチング部123は、「注文残数量」から「相手数量2」を引く。
(S46)マッチング部123は、「注文残数量」が0より大きいか判断する。0より大きい場合はステップS39に進み、0である場合はステップS47に進む。
(S47)マッチング部123は、「カーソル1」をクローズするクエリを発行する。データベース管理システム124は、「カーソル1」の情報を破棄し、クローズ成功を示す処理結果をマッチング部123に応答する。そして、ステップS34に進む。
図23は、注文処理の手順例を示すフローチャート(続き3)である。
(S48)マッチング部123は、買値が売注文の指値以上であるレコードを買注文表134から検索し、検索されたレコードを、買値の降順を第1ソート基準とし注文番号の昇順を第2ソート基準としてソートするクエリを発行する。ここで発行されるクエリは、前述のSQL文143-3に対応する。なお、買注文の注文メッセージに対しては、マッチング部123は、売値が買注文の指値以下であるレコードを売注文表133から検索し、検索されたレコード売値の昇順かつ注文番号の昇順でソートするクエリを発行する。この場合に発行されるクエリは、前述のSQL文146-3に対応する。
(S49)データベース管理システム124は、ステップS48の買値条件を満たすノードを買値インデックス137から検索し、検索されたノードが指し示すレコードを買注文表134から読み出す。データベース管理システム124は、読み出したレコードをRAM102上の一時領域に格納し、買値の降順を第1ソート基準とし注文番号の昇順を第2ソート基準としてソートする。なお、買注文の注文メッセージに対しては、データベース管理システム124は、売値条件を満たすノードを売値インデックス136から検索し、検索されたノードが指し示すレコードを売注文表133から読み出す。
(S50)データベース管理システム124は、クエリ結果を一行ずつ参照させる「カーソル2」をオープンし、「カーソル2」を示す処理結果をマッチング部123に応答する。ここで生成される処理結果は、前述の処理結果143-4,146-4に対応する。
(S51)マッチング部123は、ステップS50でオープンされた「カーソル2」によりクエリ結果の次の一行を取り出すクエリを発行する。ここで発行されるクエリは、前述のSQL文143-5,146-5に対応する。データベース管理システム124は、ステップS49の一時領域にある1以上のレコードのうち、先頭に近い方から優先的に未選択のレコード(次のレコード)を1つ読み出す。データベース管理システム124は、読み出したレコードを含む処理結果をマッチング部123に応答する。ここで生成される処理結果は、前述の処理結果143-6,146-6に対応する。
(S52)マッチング部123は、取り出した数量を「相手数量3」とする。
(S53)マッチング部123は、「相手数量3」が「注文残数量」以下であるか判断する。「相手数量3」が「注文残数量」以下である場合はステップS54に進み、「相手数量3」が「注文残数量」を超える場合はステップS59に進む。
(S54)マッチング部123は、「カーソル2」が参照するレコードを買注文表134から削除するクエリを発行する。ここで発行されるクエリは、前述のSQL文143-7に対応する。なお、買注文の注文メッセージに対しては、マッチング部123は、「カーソル2」が参照するレコードを売注文表133から削除するクエリを発行する。
(S55)データベース管理システム124は、「カーソル2」が参照するレコードを買注文表134から削除する。このとき、データベース管理システム124は、削除するレコードを注文番号を用いて特定してもよく、プライマリインデックスを使用してもよい。また、データベース管理システム124は、削除したレコードの買値に対応するノードから当該レコードのアドレスを削除し、合計数量を当該レコードの数量だけ減少させるように買値インデックス137を更新する。また、データベース管理システム124は、プライマリインデックスを更新する。そして、データベース管理システム124は、ステップS54のクエリに対する処理結果をマッチング部123に応答する。ここで生成される処理結果は、前述の処理結果143-8に対応する。なお、買注文の注文メッセージに対しては、データベース管理システム124は、「カーソル2」が参照するレコードを売注文表133から削除し、売値インデックス136を更新する。
(S56)マッチング部123は、「注文残数量」から「相手数量3」を引く。
(S57)マッチング部123は、「注文残数量」が0より大きいか判断する。0より大きい場合はステップS51に進み、0である場合はステップS58に進む。
(S58)マッチング部123は、「カーソル2」をクローズするクエリを発行する。データベース管理システム124は、「カーソル2」の情報を破棄し、クローズ成功を示す処理結果をマッチング部123に応答する。そして、ステップS46に進む。
図24は、注文処理の手順例を示すフローチャート(続き4)である。
(S59)マッチング部123は、ステップS52の「相手数量3」から現在の「注文残数量」を引いた数量を「相手残数量」とする。
(S60)マッチング部123は、「カーソル2」が参照するレコードに含まれる数量をステップS59の「相手残数量」に更新するクエリを発行する。ここで発行されるクエリは、前述のSQL文146-7に対応する。
(S61)データベース管理システム124は、「カーソル2」が参照するレコードを買注文表134から特定し、特定したレコードに含まれる数量を更新する。このとき、データベース管理システム124は、更新するレコードを注文番号を用いて特定してもよく、プライマリインデックスを使用してもよい。また、データベース管理システム124は、更新したレコードの買値に対応するノードの合計数量を、更新前後の数量の差だけ減少させるように買値インデックス137を更新する。そして、データベース管理システム124は、ステップS60のクエリに対する処理結果をマッチング部123に応答する。ここで生成される処理結果は、前述の処理結果146-8に対応する。なお、買注文の注文メッセージに対しては、データベース管理システム124は、「カーソル2」が参照する売注文表133のレコードを更新し、売値インデックス136を更新する。
(S62)マッチング部123は、「注文残数量」を0にする。これは、全ての注文数量について約定が成立したことを示す。そして、ステップS57に進む。
第2の実施の形態の情報処理システムによれば、売注文表133に対応する売値インデックス136の各ノードに、当該ノードが示す売値をもつレコードの合計数量が登録される。また、買注文表134に対応する買値インデックス137の各ノードに、当該ノードが示す買値をもつレコードの合計数量が登録される。このため、データベース管理システム124は、合計関数SUMを含むクエリに対して、売注文表133や買注文表134から数量のカラムの値を読み出さずに合計関数SUMの結果を応答することができる。よって、合計関数SUMを含むクエリの処理を高速化できる。また、データベース管理システム124が合計関数SUMを含むクエリを高速に実行できるため、データベース管理システム124を使用するアプリケーションが個々のレコードを取得して合計数量を計算しなくてよく、アプリケーションの負荷を軽減することができる。
また、株式の注文処理では、売値毎の合計数量や買値毎の合計数量を用いることで、個々のレコードの数量や注文番号を読み出さなくても、特定の売値をもつレコード群や特定の買値をもつレコード群を一括して処理することができる場合がある。よって、データベース管理システム124が合計関数SUMを含むクエリを高速に実行することで、証券取引所31における株式取引を高速化することができる。特に、現値を大きく下回る指値の売注文または現値を大きく超える指値の買注文が発生するパニック時の株式取引では、1つの注文に対して多数の約定相手の候補が存在する。この場合であっても、合計関数SUMを含むクエリを高速に実行することで、個々のレコードの数量を読み出す方法と比べて株式取引を高速に実行することが可能となる。
なお、第2の実施の形態ではデータベースを利用して株式取引を実現する例を説明したが、第2の実施の形態のデータベース処理を、株式以外の有価証券の取引、先物取引、商品取引など様々な売買取引に適用することも可能である。