多重範囲スキャンでのＮソートクエリを最適に処理する方法及び装置
【課題】本発明は、多重範囲スキャンでのＮソートクエリを最適に処理するための方法及び装置に関する。
【解決手段】本発明によるクエリ処理方法は、クエリ処理装置で実行される各段階が、クエリに含まれた抽出レコード数に基づいてバッファを割り当てる段階と、前記クエリに含まれた第１リストのうち第１属性に係わる第１データを抽出して前記バッファに記憶する段階と、前記クエリに含まれた第１リストのうち抽出されていない第１属性に係わる第２データを抽出する段階と、前記バッファに記憶されたデータ及び前記第２データを比較することにより、前記クエリを満たすように前記バッファを更新する段階と、を含み、前記クエリは、第１属性及び第２属性に基づいてソートされた一つ以上のレコードに対する多重範囲スキャンでのＮソートクエリである。
【解決手段】本発明によるクエリ処理方法は、クエリ処理装置で実行される各段階が、クエリに含まれた抽出レコード数に基づいてバッファを割り当てる段階と、前記クエリに含まれた第１リストのうち第１属性に係わる第１データを抽出して前記バッファに記憶する段階と、前記クエリに含まれた第１リストのうち抽出されていない第１属性に係わる第２データを抽出する段階と、前記バッファに記憶されたデータ及び前記第２データを比較することにより、前記クエリを満たすように前記バッファを更新する段階と、を含み、前記クエリは、第１属性及び第２属性に基づいてソートされた一つ以上のレコードに対する多重範囲スキャンでのＮソートクエリである。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、多重範囲スキャンでのＮソート（Ｎ ｓｏｒｔ）クエリを最小の時間と最小のメモリ空間で、最適に処理するための方法及び装置に関する。より詳細には、データベース管理システム（Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ、以下「ＤＢＭＳ」という）に含まれるインデックス（ｉｎｄｅｘ）を用いて、範囲スキャン（ｒａｎｇｅ ｓｃａｎ）機能を提供する全てのデータ管理システムに適用可能である多重範囲スキャンでのＮソートクエリを最適に処理する方法及び装置に関する。
【背景技術】
【０００２】
インターネットの発達に伴い、インターネットを利用する様々なＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）が脚光を浴びている。ＳＮＳは、オンライン上で知人との人間関係を深め、不特定の人と新しい人間関係を築くことができるようにするサービスを通称するものである。ＳＮＳとしては、韓国ではＳＫコミュニケーションズのサイワールド（Ｃｙｗｏｒｌｄ）、米国ではフェイスブック（Ｆａｃｅｂｏｏｋ）など、それぞれの特性による様々な種類の開発及びサービスが提供されている。
【０００３】
ＳＮＳの一分野として、マイクロブログ（Ｍｉｃｒｏｂｌｏｇ）も最近多くのユーザにより使用されている。マイクロブログとは、一、二文の短いメッセージを利用して多数の人とコミュニケーションができるブログの一種であり、ミニブログ（ｍｉｎｉｂｌｏｇ）とも呼ばれている。マイクロブログの特徴は、短いテキストを用いて、ユーザが互いに情報を発信し、発信した情報がリアルタイムでアップデートされるという特性を有している。また、マイクロブログでは、写真や動画などをアップロードすることもできる。即ち、ブログとメッセンジャを結合したような形態であり、ユーザはまるでチャットをしているような感じを受ける。また、個人の細かい日常の出来事や普段考えていること、感じたこと、感情、情報などを短いテキストで作成して交流するため、書くことや読むことに対する負担なく、簡単に使用できるという長所がある。、このため、マイクロブログは、多くの人気を集めている。マイクロブログの代表的な例としては、ツイッタ（ｔｗｉｔｔｅｒ）、及び韓国ではミートゥデイ（ｍｅ２ｄａｙ）などが挙げられる。
【０００４】
ＳＮＳ、特にマイクロブログの場合、多くのユーザが交わす情報がほぼリアルタイムで更新される。そして、ユーザ本人やユーザと関係がある他のユーザ（以下、「友達」という、少なくとも数人〜数千または数万人以上）が交わす情報から、最新情報の一部のみを抽出してユーザ本人または友達に表示する方式のクエリが非常に頻繁に使用されている。例えば、友達が作成した文章のうち最近作成した所定個数（例えば、Ｎ（Ｎは自然数）個）の文章、またはある特定時点以後に作成されたＮ個の文章のみを抽出するクエリが頻繁に使用されている。このようなクエリの処理は、各友達に対して特定時点以後にその友達が作成した文章を範囲スキャンするだけでなく、全ての友達に対して繰り返して実行する多重範囲スキャン（ｍｕｌｔｉ−ｒａｎｇｅ ｓｃａｎ）の形態で実行しなければならない。そのため、このような多重範囲スキャンによりアクセスする友達の文章のうち最新またはある特定時点以後のＮ個の文章のみをソート順に抽出（以下、このような抽出に用いられるクエリを「Ｎソートクエリ」という）するための作業が必要である。しかし、従来のデータベース管理システム（Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ、以下「ＤＢＭＳ」という）を含むデータ管理システムは、ＳＮＳなどで主に使用されている多重範囲スキャンでのＮソートクエリに対する最適化処理を考慮していない状態である。一例として、既存のＤＢＭＳでは、多重範囲スキャンによりアクセスされる友達の全ての文章を中間結果として抽出した後、抽出した文章を生成時間の逆順にソートしなければならない。このため、その処理速度が非常に遅く、中間結果を記憶するために非常に大きい記憶空間が必要となるという問題点があった。これにより、既存のＤＢＭＳの機能のみでは、ＳＮＳなどで頻繁に実行されるクエリを効率的に処理するには足りない面が多かった。
【０００５】
このような従来のクエリ処理方式は、ユーザ毎に作成した文章の数が多くなるほど、また友達の数が多くなるほど、ＤＢＭＳがスキャンしなければならない全体レコードの数が幾何級数的に増加する。そのため、ソートのために必要な中間レコードセットを格納するための多くのメモリ空間が必要であり、その多くのレコードをソートするための作業実行に対する負担のため、クエリ処理にかかる時間及び空間の無駄が非常に多かった。
【０００６】
従って、ＳＮＳなどで頻繁に使用される多重範囲スキャンでのＮソートクエリを受信した場合、スキャン対象となる友達の文章の数を最小化しながらも、限定された大きさの記憶空間のみを使用して該当クエリ処理を実行することができる方式、即ち、時間及び空間的なコストの面で最適なクエリ処理方式に対する要求が高まっている。
【０００７】
さらに、このようなクエリ処理方式は、既存のＤＢＭＳだけでなく、ＤＢＭＳの前段で範囲スキャン機能を提供する高速のデータリポジトリ、即ち、メモリでのみデータを記憶管理して、そのデータのコレクション（ｃｏｌｌｅｃｔｉｏｎ）に対するインデックスを用いて範囲スキャンを提供する高速のデータリポジトリにおいても、その必要性が高まっている。例えば、最近多く開発されているＮｏＳＱＬデータベース、即ち、ＳＱＬインタフェースを用いたクエリ処理機能を提供するＤＢＭＳでなく、新しいインタフェースを提供し、処理性能またはシステム拡張性に重点を置いているデータベースタイプにこのような高速のデータリポジトリが含まれている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】韓国公開特許第２０００―００４７６３０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明の目的は、上述した従来技術の問題点を解決することにある。
【００１０】
本発明の目的は、多重範囲スキャンでのＮソートクエリを受信した場合、スキャン対象となるレコードの数を最小化にしながら、スキャン中にソートされた結果を直ちに得るようにすることで、クエリ処理にかかる時間を最小化しながらも少ないメモリ空間のみを使用するようにすることである。
【００１１】
本発明の他の目的は、クエリ処理技術をＤＢＭＳまたは高速のデータリポジトリを用いて、ＳＮＳなど多重範囲スキャンでのＮソートクエリを多く使用する環境で用いることで、ＳＮＳなどのサービスを行う時のクエリ処理性能を極大化することにある。本発明のさらに他の目的は、開発者が従来のＤＢＭＳで効果的なクエリ処理のために、ＤＢＭＳ毎に多重範囲スキャンでのＮソートクエリがどのように処理されるか内部的な処理方式を把握し、それに応じてＤＢＭＳ毎に最適化するためにクエリを修正する必要がなく、従来のクエリをそのまま使用しても最適の方式でＮソートクエリが処理されるため、ＳＮＳなどの設計及び開発などにおいてその便宜性及び開発速度の向上を図ることができるようにすることにある。
【課題を解決するための手段】
【００１２】
上記のような本発明の目的を果たし、後述する本発明の特有の効果を果たすための本発明の特徴的な構成は下記のとおりである。
【００１３】
本発明の一実施形態によるクエリ処理方法は、クエリに含まれた抽出レコード数に基づいてバッファを割り当て、前記クエリに含まれた第１リストのうち第１属性に係わる第１データを抽出して前記バッファに記憶し、前記クエリに含まれた前記第１リストのうち抽出されていない前記第１属性に係わる第２データを抽出し、前記バッファに記憶された前記第１データ及び前記第２データを比較することにより、前記クエリを満たすように前記バッファを更新し、前記クエリは、前記第１属性及び前記第２属性に基づいて前記ソートされた一つ以上の前記レコードに対する多重範囲スキャンでのＮソートクエリであることを特徴とする。
【００１４】
本発明の他の態様によるクエリ処理装置は、クエリに含まれた抽出レコード数に基づいてバッファを割り当てるバッファ割り当て部と、前記クエリに含まれた第１リストのうち第１属性に係わる第１データを抽出して前記バッファに記憶し、前記クエリに含まれた第１リストのうち抽出されていない第１属性に係わる第２データを抽出し、前記バッファに記憶されたデータ及び前記第２データを比較することにより、前記クエリを満たすように前記バッファを更新するスキャン部と、を含み、前記クエリは、第１属性及び第２属性に基づいてソートされた一つ以上のレコードに対する多重範囲スキャンでのＮソートクエリであることを特徴とする。
【００１５】
この他にも、本発明を実現するための上記の方法を行うコンピュータプログラムを記録するコンピュータ読み取り可能な記録媒体がさらに提供される。
【発明の効果】
【００１６】
本発明によると、多重範囲スキャンでのＮソートクエリを受信した場合、スキャン対象となるレコードの数を最小化にしながら、スキャン中にソートされた結果を直ちに得るようにすることで、クエリ処理にかかる時間を最小化しながらも少ないメモリ空間のみを使用することができる。
【００１７】
また、本発明によると、クエリ処理技術をＤＢＭＳまたは高速のデータリポジトリに具現し、ＳＮＳなど多重範囲スキャンでのＮソートクエリを多く使用する環境で使用することで、ＳＮＳなどのサービスを行う時のクエリ処理性能を極大化することができる。
【００１８】
また、本発明によると、開発者が従来のＤＢＭＳで効果的なクエリ処理のために、ＤＢＭＳ毎に多重範囲スキャンでのＮソートクエリがどのように処理されるか内部的な処理方式を把握し、それに応じてＤＢＭＳ毎に最適化するためにクエリを修正する必要がなく、従来のクエリをそのまま使用しても最適の方式でＮソートクエリが処理されるため、ＳＮＳなどの設計及び開発などにおいてその便宜性及び開発速度の向上を図ることができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の一実施形態によるＤＢＭＳが多重範囲スキャンでのＮソートクエリ処理時において、インデックスを用いてスキャンする範囲を示す図面である。
【図２】本発明の第１実施形態及び第２実施形態による多重範囲スキャンでのＮソートクエリを処理するクエリ処理装置を示す構成図である。
【図３】本発明の第１実施形態によるスキャン部で実行される多重範囲スキャンでのＮソートクエリの処理方法を示すフローチャートである。
【図４】本発明の第２実施形態によるスキャン部で実行される多重範囲スキャンでのＮソートクエリの処理方法を示すフローチャートである。
【図５】本発明の第２実施形態によるスキャン部で実行される多重範囲スキャンでのＮソートクエリの処理方法を示すフローチャートである。
【図６】本発明の第１実施形態による多重範囲スキャンでのＮソートクエリの処理方法のうちローバッファを更新する工程を示す図面である。
【図７ａ】本発明の第２実施形態による多重範囲スキャンでのＮソートクエリの処理方法のうちスキャンバッファ及びローバッファの形態とスキャンバッファ及びローバッファの更新工程を示す図面である。
【図７ｂ】本発明の第２実施形態による多重範囲スキャンでのＮソートクエリの処理方法のうちスキャンバッファ及びローバッファの形態とスキャンバッファ及びローバッファの更新工程を示す図面である。
【図７ｃ】本発明の第２実施形態による多重範囲スキャンでのＮソートクエリの処理方法のうちスキャンバッファ及びローバッファの形態とスキャンバッファ及びローバッファの更新工程を示す図面である。
【図７ｄ】本発明の第２実施形態による多重範囲スキャンでのＮソートクエリの処理方法のうちスキャンバッファ及びローバッファの形態とスキャンバッファ及びローバッファの更新工程を示す図面である。
【発明を実施するための形態】
【００２０】
以下、本発明の好適な実施形態を、図面を参照して詳細に説明する。以下の実施形態は、当業者が本発明を十分に実施することができるように詳細に説明される。本発明の多様な実施形態は、互いに異なり、必要などに応じて相互に組み合わせることができることを理解すべきである。例えば、ここに記載されている特定形状、構造及び特徴は、一実施形態に関連して本発明の思想及び範囲を外れずに他の実施形態に用いることができる。また、それぞれの開示された実施形態の構成要素の位置または配置は、本発明の思想及び範囲を外れずに変更可能であることを理解すべきである。従って、後述する詳細な説明は限定的な意味で扱うものでなく、本発明の範囲は、適切に説明されるならば、その特許請求の範囲が主張するものと均等な全ての範囲と共に、添付した特許請求の範囲によってのみ限定される。図面において、同一の参照符号は、様々な側面にわたって同一または類似の機能を示す。
【００２１】
以下、本発明が属する技術分野において通常の知識を有する者が本発明を容易に実施できるように、本発明の好適な実施形態について添付図面を参照して詳細に説明する。
【００２２】
［クエリ処理時のスキャン範囲］
図１は、本発明の一実施形態によるＤＢＭＳが、多重範囲スキャンでのＮソートクエリの処理時に、インデックス（ｉｎｄｅｘ）を用いてスキャンする範囲を示す図面である。
【００２３】
多重範囲スキャンでのＮソートクエリを利用するサービスまたはシステムにおいて、ユーザが作成する文章の記憶と検索対象となるデータベースは様々な方式で実現できる。また、一般的に、文章を作成したユーザのＩＤ、作成した時間情報を示すタイムスタンプ（Ｔｉｍｅ Ｓｔａｍｐ）、作成された文章の内容、及び付加的な情報に対する属性をさらに有してもよい。以下、説明の便宜上、ＤＢＭＳとＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）を基に説明する。ＤＢＭＳでユーザのＩＤをｕｓｅｒｉｄ、タイムスタンプをｔｓ、作成された文章の内容をｃｏｎｔｅｎｔｓと命名したテーブルを以下の表１のように示す。表１に示したテーブルの名称をｐｏｓｔｓと仮定する。
【００２４】
【表１】
【００２５】
一方、上記表１のようなｐｏｓｔｓテーブルで、あるユーザの友達全体を対象として最近作成され、または、特定時点から最も近い時期に作成された文章から特定個数の文章のみを抽出するための多重範囲スキャンでのＮソートクエリは多様な方式で実現されてもよく、一般的に以下の例示的なＳＱＬ文のように実現することができる。
【００２６】
ＳＥＬＥＣＴ ｔｓ、 ｕｓｅｒｉｄ
ＦＲＯＭ ｐｏｓｔｓ
ＷＨＥＲＥ ｕｓｅｒｉｄ ＩＮ（ｆｒｉｅｎｄｓ＿ｌｉｓｔ）ＡＮＤ ｔｓ＜ｓｙｓｄａｔｅ（）
ＯＲＤＥＲ ＢＹ ｔｓ ＤＥＳＣ
ＬＩＭＩＴ Ｎ；
（ここで、ｆｒｉｅｎｄｓ＿ｌｉｓｔは所定ユーザの友達のユーザＩＤリストのみを含み、所定ユーザを含んで友達のユーザＩＤリストを含む。これは、該当クエリを実行する特定サービスまたはシステムでどのようなユーザの文章を集めるかによって変わる。また、Ｎは抽出する文章の個数を意味する。）
【００２７】
このＳＱＬ文を効率的に処理するためには、表１に示すｐｏｓｔｓテーブルに対してユーザＩＤの順に、その内部でタイムスタンプの逆順にレコードを速く検索するためのインデックスが必要である。このため、一般的にｕｓｅｒｉｄに対して昇順、ｔｓに対して降順のキー（ｋｅｙ）を有するインデックスを生成し、このようなインデックスを説明の便宜上「ｐｏｓｔｓ_ｕｓｅｒｉｄ_ｔｓ_ｉｎｄｅｘ」と仮定する。
【００２８】
インデックスは、テーブルの各レコードに対応する一つのキーを保持する。ここで、その一つのキーは、キー値とそのキー値を有するレコードの識別子で構成される。例えば、図１に示す範囲１の一番目のキーは、キー値としてＡ及び２０１０−１２−０１ １４：３０：０２を有し、さらに、このキー値を有するレコードの識別子として、Ｒ４を有する。または、メモリに全てのデータを記憶するメインメモリデータベース（Ｍａｉｎ−Ｍｅｍｏｒｙ ＤＢＭＳ：ＭＭＤＢＭＳ）の場合、キー値を有するレコードが常にメモリに記憶されているため、キーのレコード識別子を介して、そのキー値を直接アクセスすることできる。従って、ＭＭＤＢＭＳでインデックスのキーは、一般的にレコード識別子のみを有する。よって、図１に示したインデックスでのキーは、キー値とレコード識別子を全て有する一般的なディスクＤＢＭＳを仮定して表現したものであり、インデックスでのキー構成が図１に限定されず、データリポジトリの具現特性によってインデックスでのキー構成が変わることは自明である。上述した表１のようにレコードが任意の順に記憶されており、図１の右側に示したｐｏｓｔｓテーブルに対して上記のＳＱＬ文を効率的に実行するためには、図１の左側に示したようにｐｏｓｔｓテーブルに係る「ｐｏｓｔｓ_ｕｓｅｒｉｄ_ｔｓ_ｉｎｄｅｘ」インデックスが備えられることが前提とされる。この「ｐｏｓｔｓ_ｕｓｅｒｉｄ_ｔｓ_ｉｎｄｅｘ」インデックスを基に、本発明の実施形態によってＳＱＬ文のような多重範囲スキャンでのＮソートクエリを実行するための具体的な順序については、図６−図７ｄを参照して以下でより詳細に説明する。
【００２９】
［多重範囲スキャンでのＮソートクエリを処理するクエリ処理装置］
図２は、本発明の一実施形態による多重範囲スキャンでのＮソートクエリを処理するクエリ処理装置を示す構成図である。
【００３０】
図２を参照すると、本発明の一実施形態によるクエリ処理装置１００は、クエリ解釈部１１０とクエリ実行部１２０とに大別される。クエリ実行部１２０は、バッファ割り当て部１２１と、スキャン部１２２と、提供部１２３と、を含む。
【００３１】
本発明の一実施形態によるクエリ解釈部１１０は、特定形式によるクエリを受信し、受信されたクエリが多重範囲スキャンでのＮソートクエリであるか否かを判断する。クエリ解釈部１１０に特定形式によるクエリを伝送する伝送装置とは、クエリ処理装置１００との通信を介してクエリ処理装置１００にアクセスしてデータを要求することができる装置または構成要素を全て含む広義の概念である。クエリ処理装置１００に対するクエリ伝送は、伝送装置とクエリ処理装置１００との間の認証などの手順を経て、伝送装置がクエリ処理装置１００にクエリを介して特定データを要求することができる正当な権限があるか否かを予め確認した後に行ってもよい。この場合、認証手順は公知のＤＢＭＳアクセス（ａｃｃｅｓｓ）時に使用される認証手順を利用することができる。クエリ解釈部１１０が受信した特定形式によるクエリは、公知のＳＱＬによるＳＱＬ構文であってもよい。クエリ解釈部１１０はパージング（ｐａｒｓｉｎｇ）機能を利用して、受信されたクエリが多重範囲スキャンでのＮソートクエリであるか否かを判断することができる。
【００３２】
本発明の一実施形態によるクエリ解釈部１１０は、単に多重範囲スキャンでのＮソートクエリであるか否かを判断するだけでなく、受信したクエリを具体的に解釈し、抽出されるべきのレコードの数、スキャン対象となるユーザＩＤ及びソートの基準となるタイムスタンプ値などに関する情報をさらに解釈して抽出する機能をさらに備えていてもよい。
【００３３】
本発明の一実施形態によるクエリ実行部１２０は、クエリ解釈部１１０により解釈された情報に基づいてクエリを実行する。クエリ実行部１２０は、様々な構成要素を有してもよい。なお、多重範囲スキャンでのＮソートクエリに対する効率的な処理方式に焦点を当てその説明を容易にするために、バッファ割り当て部１２１、スキャン部１２２、提供部１２３を有してもよい。まず、本発明の一実施形態によるバッファ割り当て部１２１は、クエリ解釈部１１０により、受信されたクエリが多重範囲スキャンでのＮソートクエリであると判断された場合、メモリ上にスキャンのための一時的な記憶空間であるバッファを割り当てる。割り当てられるバッファの大きさは、クエリ解釈部１１０により解釈された情報のうち抽出されるべきのレコードの個数に対応する。例えば、抽出されるべきのレコードの個数がＮ個であると、バッファ割り当て部１２１は、後述するスキャン部１２２のスキャン方式に応じて、Ｎ個のソートができるローバッファ（ｒｏｗ ｂｕｆｆｅｒ）、またはＮ個のスキャンバッファ（ｓｃａｎ ｂｕｆｆｅｒ）とローバッファ（ｒｏｗ ｂｕｆｆｅｒ）を割り当てる。ここで、ローバッファとは、インデックススキャンにより抽出されるレコードのキー値と識別子を記憶したり、またはレコードの識別子のみを記憶したりすることができるメモリ領域を意味する。また、スキャンバッファとは、多数のユーザに対するインデックススキャンのうち最新のレコードをスキャンしているインデックススキャンの識別子情報を記憶することができるメモリ領域を意味する。次に、本発明の一実施形態によるスキャン部１２２は、バッファ割り当て部１２１により割り当てられた、限定された数のバッファを利用して、最小限のインデックススキャンによりクエリ解釈部１１０により解釈された多重範囲スキャンで最上位のＮソートクエリを行う。本発明の好ましい実施形態によるスキャン部１２２の具体的なクエリ実行順序については後述する。
【００３４】
最後に、本発明の一実施形態による提供部１２３は、スキャン部１２２の動作により実行されたクエリに対する結果として、バッファ割り当て部１２１により割り当てられたローバッファに記憶された特定個数のレコードをクエリに対する結果としてクエリを要請した特定個体に伝送する。
【００３５】
図２に示すクエリ解釈部１１０、クエリ実行部１２０のバッファ割り当て部１２１、スキャン部１２２及び提供部１２３は、物理的に単一の装置内に構成されてもよく、一部またはそれぞれが物理的に異なる装置に構成されてもよく、また、同様の機能を有する物理的に複数存在する装置が並列的に存在してもよい。このように、本発明の実施形態は、各構成部が設けられた機械またはデータベースの物理的な数及び位置に限定されず、多様な方式に設計変更されることということは、本発明が属する技術分野において通常の知識を有する者において自明のことである。
【００３６】
図２の各構成要素は、本発明を説明するために必要な必須構成要素に限定して開示及び説明され、各構成要素は本発明で説明されていない公知の他の機能を実行したり、または図２に示していない、公知の他の機能を実行したりするための別の構成要素がクエリ処理装置１００内に追加され得るということは、本発明が属する技術分野において通常の知識を有する者において自明のことである。
【００３７】
［第１実施形態］
［多重範囲スキャンでＮソートクエリの処理］
次に、図３、図４及び図５を参照して、本発明の好ましい実施形態により、スキャン部１２２で実行される多重範囲スキャンでのＮソートクエリの処理方法について詳細に説明する。
【００３８】
まず、本発明の第１実施形態によると、バッファ割り当て部１２１は抽出されるべきのレコードの数（以下、「Ｎ」という）だけのローバッファを割り当てていることを仮定する。図３に示した本発明の第１実施形態によると、クエリ処理装置１００のスキャン部１２２は、上記表１で仮定した「ｐｏｓｔｓ_ｕｓｅｒｉｄ_ｔｓ_ｉｎｄｅｘ」インデックスを基に各ユーザに対して、最新または特定時点以後の文章のみを検索するためのインデックススキャンを始める（ステップＳ１１０）。インデックススキャンは、インデックスを、たとえばルート（ｒｏｏｔ）ノードから最下位ノードであるリーフ（ｌｅａｆ）ノードまで探索しながら、検索条件を満たす一番目のレコードを検索する（ステップＳ１２０）。検索条件を満たす一番目のレコードが見つけられなかった場合は（Ｓ１３０）、現在ユーザが特定時点以後に作成された文章が存在しないということを意味するため、現在のインデックススキャンを終了する（Ｓ１９０）。検索条件を満たす一番目のレコードが存在する場合は（Ｓ１３０）、スキャン部１２２は、ローバッファに現在のレコード情報を記憶するための作業を以下のように実行する。即ち、まず、Ｎ大きさのローバッファがフル（ｆｕｌｌ）状態であるかを確認する（Ｓ１４０）。ローバッファがフル状態でない場合は（Ｓ１４０）、レコード情報を記憶する空間がローバッファに残っている状態であることを意味するため、現在検索したレコードのタイムスタンプ値とローバッファに記憶されたレコードのタイムスタンプ値とを比較して、タイムスタンプの逆順が維持されるように、ローバッファに挿入すべき位置を探してその位置に現在レコード情報を記録する（Ｓ１７０）。このような方式により、ローバッファ内に記憶されたレコード情報は、常にそのタイムスタンプの逆順にソートされている。ローバッファがフル状態である場合は（Ｓ１４０）、現在検索したレコードのタイムスタンプ値とローバッファに記憶された最後のレコード、即ち、タイムスタンプの逆順にソートされたローバッファで最も小さいタイムスタンプ値を有するレコードのタイムスタンプ値とを比較して、現在検索したレコードをローバッファに挿入できるかを確認する（Ｓ１５０）。現在のレコードのタイムスタンプ値がローバッファにある最後のレコードのタイムスタンプ値より小さいかまたは同一である場合は（Ｓ１５０）、現在のユーザが作成した文章が、既に他のユーザが作成した、即ち、ローバッファ内に記憶されたレコード情報に対応するＮ個の文章より古い文章ということが明らかであるため、現在ユーザに対して検索したレコードをローバッファに挿入する必要がなく、現在ユーザの次のレコードを検索する必要もなくなる。従って、現在ユーザの文章をスキャンする作業を中止する（Ｓ１９０）。現在のレコードのタイムスタンプ値がローバッファにある最後のレコードのタイムスタンプ値より大きい場合は（Ｓ１５０）、最後のレコードをローバッファから除去した後（Ｓ１６０）、ローバッファに現在のレコードを挿入する（Ｓ１７０）。この場合にも、ローバッファに記録されたレコードは、タイムスタンプの逆順へのソートが維持されるように、現在のレコードの適切な挿入位置を探して挿入する（Ｓ１７０）。本発明の第１実施形態によるローバッファへのレコードの挿入によるローバッファの更新を示した図６を参照すると、スキャン部１２２が、既にＮ個のレコードが記憶されているローバッファ内にユーザＣが作成したレコードが抽出され挿入されようとしている。挿入されようとする、ユーザＣが作成したレコードのタイムスタンプは「２０１０−１２−０１ １３：５７：２６」であり、ローバッファに記憶された最後のレコードのタイムスタンプである「２０１０−１１−２９ ２３：４８：０１」より最新のものである。また、２番目に位置するタイムスタンプが「２０１０−１２−０１ １４：０７：０９」であるレコードよりは最新ではないが、３番目に位置するタイムスタンプが「２０１０−１２−０１ １３：４６：５２」であるレコードよりは最新のものであるため、その間に位置するべきである。従って、スキャン部１２２は、ローバッファの最後の位置にあるレコード（識別子がＲ４４であるレコード）を除去し、ローバッファの３番目の位置に現在レコードを記憶する。従って、元のローバッファで３番目の位置からＮ−１番目の位置まで記憶されていたレコードは、ユーザＣが作成したレコードの挿入により一つずつ後側に移動して記憶される。従って、挿入後のローバッファに記憶された最後のレコードは、従来のＮ−１番目の位置に記憶されたレコードと同一の、識別子としてＲ６２を有するレコードであることが分かる。
【００３９】
また、図３をさらに参照すると、ローバッファに現在検索したレコードを挿入した場合には、現在のインデックススキャンにより次のレコードを検索し（Ｓ１８０）、次のレコードの存在有無に応じて（Ｓ１３０）上述の処理工程を繰り返す。
【００４０】
現在のユーザに対するインデックススキャンで検索するレコードがそれ以上ない場合や（Ｓ１３０）、検索したレコードのタイムスタンプがローバッファに記録されたレコードの最小タイムスタンプ値より小さいかまたは同一である場合（Ｓ１５０）、現在のユーザに対するスキャンをそれ以上行う必要がないため、上述のように現在のユーザに対するインデックススキャンを終了する（Ｓ１９０）。
【００４１】
現在のユーザに対するスキャンを終了すると、次のユーザがあるかを確認する（Ｓ２００）。次のユーザがある場合（Ｓ２００）、そのユーザに対するインデックススキャンを始め（Ｓ１１０）、上述の処理工程を繰り返す。次のユーザがない場合（Ｓ２００）、ローバッファにあるレコードが最終のクエリ結果となるため（Ｓ２１０）、全体処理工程を終了する。ここで、ユーザとは、Ｎソート結果を得るクエリを利用するサービスまたはシステムの設計または開発特性によって、所定ユーザ本人を含むかまたは含まない所定ユーザの友達を意味する。
【００４２】
図３に示した本発明の第１実施形態の順序を実行して完了した場合、バッファ割り当て部１２１により割り当てられたＮ個のローバッファに記憶されたＮ個のレコードは、クエリ解釈部１１０により解釈された多重範囲スキャンでのＮソートクエリの実行結果として、所定ユーザの友達（所定ユーザが含まれてもよく、含まれなくてもよい）が作成した全ての文章を対象として最新または特定時点以後に作成されたＮ個の文章を格納していることが分かる。
【００４３】
［第２実施形態］
図４及び図５は本発明の第２実施形態によるスキャン部１２２が多重範囲スキャンでのＮソートクエリを実行する順序を示したフローチャートである。
【００４４】
まず、ＤＢＭＳまたは他のデータリポジトリからインデックススキャンにより特定範囲のレコードを検索する場合の技術的な順序を詳細に説明する。インデックスアクセス時にスキャン対象となるテーブルとインデックスをアクセスするための情報を取り込み、インデックススキャン情報を格納するための構造体に格納しておく。そして、その情報に基づいてそのインデックスをアクセスする。例えば、インデックスのルート（ｒｏｏｔ）ノード識別子などがこれに該当する。また、インデックスを用いて検索するキーの範囲及び範囲内の各キーまたはレコードに対して適用するフィルタリング情報などを保管し、これを用いて検索範囲にあるキーまたはレコードをスキャンする際に検索条件に合致するレコードを探す。その他にも、インデックスで現在アクセスしているキーの位置情報とそのキーを有するレコードの識別子を維持する。このような情報は、初めは空値（ＮＵＬＬ）などとして設定され、一番目のレコードとともに次のレコードを探す度に現在のキーと現在のレコード情報に更新される。インデックススキャンによりスキャン範囲を外れると、スキャン情報が格納されている構造体を破棄するなどのインデックススキャンの終了作業を行う。
【００４５】
次に、本発明の第２実施形態におけるスキャンバッファは、各インデックススキャンが現在指し示しているレコードのタイムスタンプを基準に、最新のタイムスタンプを有するレコードを指し示すインデックススキャンの識別子情報を記憶するバッファである。インデックススキャンの識別子としては、インデックススキャン情報を有している構造体のアドレス（ａｄｄｒｅｓｓ）としてもよく、インデックススキャン情報を有している構造体が配列（ａｒｒａｙ）形態に構成される場合、その配列での位置値になってもよい。または、ＤＢＭＳでなく他のデータリポジトリでは、テーブルの概念がなく実際のレコードのデータがインデックスのキー内に全て含まれてもよく、スキャンの現在のキー位置情報のみを有してスキャンを行ってもよい。例えば、スキャンを開始する際に、現在のキーの位置情報はルートノードに設定された後、一番目のキーまたは次のキーを探す度に現在のキーの位置情報は実際のキーの位置情報に設定されてもよい。この場合、キーの位置情報の大きさが大きくないため、このようなキーの位置情報そのものをスキャンバッファに記録することもできる。従って、スキャンバッファに記録される情報は、インデックススキャン機能を提供する該当データリポジトリの実際の内部方式によって変わることは当業者において自明のことである。
【００４６】
本発明の第２実施形態によると、バッファ割り当て部１２１は抽出されるべきレコードの個数（以下、「Ｎ」個という）だけのスキャンバッファ及びローバッファを割り当てていることを仮定する。図４を参照して、上述の特定レコード抽出の順序及び仮定事項を参照して本発明の第２実施形態を説明する。クエリ処理装置１００のスキャン部１２２は、上述の「ｐｏｓｔｓ_ｕｓｅｒｉｄ_ｔｓ_ｉｎｄｅｘ」インデックスを利用して、各ユーザに対して最新または特定時点以後の文章のみを検索するためのインデックススキャンを開始する（Ｓ３１０）。インデックススキャンは、該当インデックスを探索して検索条件を満たす一番目のレコードを検索する（Ｓ３２０）。検索条件を満たす一番目のレコードが存在しない場合（Ｓ３３０）、現在のユーザが特定時点以後に作成された文章が存在しないということを意味するため、現在のインデックススキャンを終了する（Ｓ３８０）。検索条件を満たす一番目のレコードが存在する場合（Ｓ３３０）、スキャンバッファに現在のインデックススキャン情報を記憶するための処理を実行する。このために、まず、Ｎ大きさのスキャンバッファがフル状態であるかを確認する（Ｓ３４０）。スキャンバッファがフル状態でない場合（Ｓ３４０）、インデックススキャン情報を記憶する空間がスキャンバッファに残っている状態であることを意味するため、現在インデックススキャンが指し示すレコードのタイムスタンプ値とスキャンバッファに記録されたインデックススキャンが指し示すレコードのタイムスタンプ値とを比較して、タイムスタンプの逆順にソートされるように、スキャンバッファに挿入する位置を探して該当位置に現在のインデックススキャン情報を記録する（Ｓ３７０）。このような方式により、スキャンバッファ内に記憶されたインデックススキャン情報は、それぞれのインデックススキャンが指し示すレコードのタイムスタンプが逆順にソートされている。スキャンバッファがフル状態である場合（Ｓ３４０）、現在インデックススキャンが指し示すレコードのタイムスタンプ値と、それぞれのインデックススキャンが指し示すレコードのタイムスタンプの逆順にソートされたスキャンバッファに記憶された最後のインデックススキャンが指し示すレコードのタイムスタンプ値と、を比較することにより、現在のインデックススキャンをスキャンバッファに挿入できるかを確認する（Ｓ３５０）。現在のインデックススキャンが指し示すレコードのタイムスタンプ値がスキャンバッファに記録された最後のインデックススキャンが指し示すレコードのタイムスタンプ値より小さいかまたは同一である場合（Ｓ３５０）、これは、現在インデックススキャンの検索対象となるユーザが作成した文章より最新の文章を作成したユーザに対するインデックススキャンが既にスキャンバッファにＮ個登録されている状態であることを意味するため、現在ユーザに対するインデックススキャンをそれ以上行う必要がなくなる。従って、現在ユーザに対するインデックススキャン作業を中止する（Ｓ３８０）。現在インデックススキャンが指し示すレコードのタイムスタンプ値がスキャンバッファに記録された最後のインデックススキャンが指し示すレコードのタイムスタンプ値より大きい場合（Ｓ３５０）、スキャン部１２２は、それぞれのインデックススキャンが指し示すレコードのタイムスタンプの逆順にソートされたスキャンバッファで最も古いタイムスタンプを有したレコードを指し示すインデックススキャンである最後のインデックススキャン情報をスキャンバッファから除去し、そのスキャンを終了させた後（Ｓ３６０）、現在のインデックススキャンの情報をスキャンバッファに挿入する（Ｓ３７０）。この場合にも、スキャンバッファでインデックススキャンが指し示すレコードのタイムスタンプの逆順にそのインデックススキャンの記憶順序が維持されなければならないため、現在のインデックススキャンの適切な挿入位置を探して挿入する。現在ユーザに対するインデックススキャンで検索する一番目のレコードがない場合（Ｓ３３０）や、現在インデックススキャンが検索した一番目のレコードのタイムスタンプがスキャンバッファに記録された最後のインデックススキャンが指し示すレコードの最小タイムスタンプ値より小さいか同一である場合（Ｓ３５０）は、現在ユーザに対するスキャンをそれ以上行う必要がないため、上述のように現在ユーザに対するインデックススキャンを終了した後（Ｓ３８０）、次のユーザが存在するかを確認する段階（Ｓ３９０）に進む。また、現在のインデックススキャンをスキャンバッファに登録した場合にも（Ｓ３７０）、そのインデックススキャンを終了していない状態で次のユーザが存在するかを確認する段階（Ｓ３９０）に進む。次のユーザが存在する場合（Ｓ３９０）、そのユーザに対するインデックススキャンを始めて（Ｓ３１０）、上述の処理工程を繰り返す。次のユーザが存在しない場合は（Ｓ３９０）、スキャンバッファには最新または特定時点以後に作成されたＮ個のレコードを抽出するに適したインデックススキャンが登録された状態であることを意味する。
【００４７】
このような段階を経て得られるスキャンバッファの一例は図７ａに図示されている。右側のスキャンバッファに記憶されたユーザＡに対するインデックススキャンは、左側の「ｐｏｓｔｓ_ｕｓｅｒｉｄ_ｔｓ_ｉｎｄｅｘ」インデックスにおいてユーザＡによるレコードのうち最もタイムスタンプが最新であるレコードを指し示しており、ユーザＣとＦに対するインデックススキャンもそれぞれユーザＣとＦによるレコードのうち最もタイムスタンプが最新であるレコードを指し示している。また、各インデックススキャンが指し示すレコードのタイムスタンプの逆順にこれらインデックススキャンの位置が順序化されている。
【００４８】
次に、指し示すレコードのタイムスタンプの逆順にソートされた、スキャンバッファに格納されたインデックススキャンを基に、最新または特定時点以後に作成されたＮ個の文章のみを抽出するための順序を、図５を参照して詳細に説明する。スキャン部１２２は、まずスキャンバッファに記録されたインデックススキャンが存在するかを確認する（Ｓ４１０）。インデックススキャンが存在する場合（Ｓ４１０）、スキャンバッファに存在する一番目のインデックススキャンが指し示すレコード、即ち、最新のタイムスタンプを有するレコードを抽出した後（Ｓ４２０）、そのレコードをローバッファに記録する処理を実行する。ここで、スキャンバッファに記憶されたインデックススキャンはそれらがそれぞれ指し示しているレコードのタイムスタンプの逆順、即ち最新の順にソートされているため、段階Ｓ４２０で抽出されるレコードはスキャンバッファの先頭にあるインデックススキャンが指し示すレコードに該当する。この作業は、ローバッファがフル状態であるかを先に確認してから実行する（Ｓ４３０）。ローバッファがフル状態でないと（Ｓ４３０）、ローバッファに空いている先頭の空間にそのレコードを挿入する（Ｓ４４０）。その後、現在のインデックススキャンで次のレコードを検索し（Ｓ４５０）、次のレコードが存在するかを確認する（Ｓ４６０）。次のレコードが存在しない場合（Ｓ４６０）、現在のインデックススキャンをスキャンバッファから除去し、そのインデックススキャンを終了する（Ｓ４７０）。その後、スキャンバッファにインデックススキャンが残っているかを確認する段階（Ｓ４１０）に進む。次のレコードが存在する場合（Ｓ４６０）、現在インデックススキャンが指し示すレコードが次のレコードに変更されたため、そのレコードのタイムスタンプ値を基準にスキャンバッファで現在のインデックススキャンの位置を再調整する（Ｓ４８０）。この場合にも同様に、レコードのタイムスタンプの逆順にソートされたインデックススキャンの順序が維持されるように、適切な位置にインデックススキャン情報を挿入することによりスキャンバッファで位置を再調整する。インデックススキャンの位置を再調整する場合、スキャンバッファにインデックススキャンが残っているということが保障され、また、スキャンバッファに記憶されたインデックススキャンもそれぞれが指し示すレコードのタイムスタンプの逆順にソートされた順序が維持されるため、スキャンバッファで先頭にある、即ち最もタイムスタンプが最新のレコードを指し示すインデックススキャンから現在のレコードを抽出する段階（Ｓ４２０）に進み、上述の順序を繰り返す。
【００４９】
このような実行順序に従ってスキャンバッファで一番目のインデックススキャンが指し示すレコードを抽出する工程を繰り返すと、抽出するレコードの順序もタイムスタンプが最新である順序になる。従って、このようなレコードをローバッファに挿入する場合、ローバッファに挿入する位置を探すために別のバイナリサーチまたは他の方法による再調整などが必要でなく、単にローバッファの先頭から空いている空間順にレコードを追加（ａｐｐｅｎｄ）してローバッファを満たしていくとローバッファ内のレコードの順序は、タイムスタンプの逆順にソートされた順序が維持される。
【００５０】
一方、スキャン部１２２がスキャンバッファにある一番目のインデックススキャンが指し示すレコードを抽出してローバッファに記憶しようとする際に、ローバッファが既にフル状態である場合（Ｓ４３０）、これは、既に最新順序のＮ個のレコードを全て探した状態であることを意味する。従って、それ以上のスキャンを行う必要がないため、スキャンバッファにある全てのインデックススキャンを終了させる（Ｓ４９０）。また、ローバッファにあるＮ個のレコードが最終結果となるため（Ｓ５００）、全体処理工程を終了する。
【００５１】
上記の順序を実行する工程中に、スキャンバッファにインデックススキャンが存在しない場合があり得る（Ｓ４１０）。この場合は、既にローバッファに０個以上のレコードが存在している状態であり、ローバッファにあるそのレコードが最終結果となるため、スキャン部１２２は全体処理工程を終了する。参考に、ローバッファにあるレコードの数が０であると、これはクエリの検索条件を満たすレコードがないということを意味する。即ち、多数のユーザが作成した文章のうち特定時点以後に作成された文章がないということを意味し、この結果が正常な実行結果となるのである。
【００５２】
本発明の第２実施形態によるスキャンバッファからレコードを抽出してローバッファに挿入または追加する一部実行工程を示すと、図７ｂ、図７ｃ、図７ｄのとおりである。図７ｂを参照して、最新レコードを指し示すインデックススキャンがスキャンバッファに登録されており、ローバッファは空いている状態で始める。スキャン部１２２は、まず一番目のインデックススキャンであるＡスキャンでキーの位置情報であるＫ４５４４を介して現在のキーまたは現在のレコードをアクセスしてそのレコードをローバッファの先頭に挿入する。また、Ａスキャンの次のキーであるＫ４５４５に移動して、該当キーが指し示すレコードのタイムスタンプを基準にスキャンバッファでＡスキャンの位置を再調整する。キーの位置情報であるＫ４５４５が指し示すレコードのタイムスタンプ値は「２０１０−１２−０１ １４：０７：０９」であり、スキャンバッファにある二番目のスキャンであるＣスキャンの現在キーの位置情報であるＫ５１２２が指し示すレコードのタイムスタンプ「２０１０−１２−０１ １３：５７：２６」より最新のものであるため、Ａスキャンに対してスキャンバッファで一番目の位置をそのまま維持する。次に、二番目のレコードを探すために図７ｃを参照すると、上記と同様に、スキャン部１２２は、スキャンバッファにある一番目のインデックススキャンであるＡスキャンがＫ４５４５を介して現在指し示すキーをアクセスし、そのキーのレコードをローバッファで空いている先頭、即ち二番目の位置に挿入する。次に、Ａスキャンの次のキーであるＫ４５４６に移動して、そのキーが指し示すそのレコードのタイムスタンプを基準にスキャンバッファでＡスキャンの位置を再調整する。この場合、Ａスキャンの現在レコードのタイムスタンプ（「２０１０−１２−０１ １３：４６：５２」）がＣスキャンの現在レコードのタイムスタンプ（「２０１０−１２−０１ １３：５７：２６」）より最新でないため、スキャンバッファでＣスキャンが先頭に、またＡスキャンが二番目の位置に位置するようにスキャンバッファの位置を再調整する。図７ｄを参照して次のレコードを抽出する工程を説明すると、スキャン部１２２は、スキャンバッファで一番目のインデックススキャンであるＣスキャンの現在レコードを抽出してローバッファに挿入し、Ｃスキャンの次のキーであるＫ５１２３に移動して、スキャンバッファで位置を調整する。この場合にも、ＣスキャンのキーＫ５１２３が指し示すレコードのタイムスタンプ（「２０１０−１１−２７ １０：２２：２５」）がＡスキャンのキーＫ４５４６が指し示すレコードのタイムスタンプ（「２０１０−１２−０１ １３：４６：５２」）より最新でないため、それぞれのキーが指し示すレコードのタイムスタンプの逆順にソートされるように、スキャンバッファ内に記憶されたインデックススキャンの位置が再調整される。このような工程をＮ回実行することにより、ローバッファにはタイムスタンプが最新である順にＮ個レコードが記憶される。
【００５３】
上述の本発明の第１実施形態及び第２実施形態は、以下の点で実行段階の共通点を有していることを確認することができる。
【００５４】
まず、クエリ実行部のバッファ割り当て部は、クエリに含まれた抽出レコード数（例えば、Ｎ個）に基づいてバッファを割り当てる。第１実施形態の場合はＮ個のローバッファが、第２実施形態の場合はＮ個のスキャンバッファ及びローバッファが割り当てられる。次に、ユーザのＩＤ順及びタイムスタンプの逆順にインデックスされてソートされた一つ以上のレコードに対する多重範囲スキャンでのＮソートクエリとしてクエリ解釈部により解釈されたクエリに基づいて、クエリ実行部のスキャン部は一つのユーザＩＤに対するレコードを抽出し、第１実施形態の場合はローバッファに、第２実施形態の場合はスキャンバッファに記憶する。その後、上記で抽出されなかったユーザＩＤに対するレコードを抽出した後バッファに記憶された、上記で抽出されたレコードとタイムスタンプを比較してクエリの内容である多重範囲スキャンでのＮソートクエリを満たすために、そのタイムスタンプの逆順を維持するように、第１実施形態の場合はローバッファを、第２実施形態の場合はスキャンバッファを更新する。
【００５５】
上述のような本発明の実行段階の共通点に、上記で各図面などを参照して詳細に説明した第１実施形態及び第２実施形態の特有の追加的な実行段階を有機的に組み合わせ、本発明の第１実施形態及び第２実施形態を施すことができる。
【００５６】
［従来技術と本発明の実施形態との時間コストの比較］
本発明の第１実施形態及び第２実施形態により、多重範囲スキャンで最上位のＮソートクエリを実行する場合、従来技術に比べ得られる速度上の効果を、以下で計算する時間コストにより確認する。
【００５７】
まず、各実行方式の時間コストを計算するために、以下のような変数を仮定する。
Ｎ：検索しようとするレコードの個数
Ｕｓ：特定ユーザの友達の数
Ｋｔ：該当インデックスで全体キーの数（該当テーブルで全体レコードの数と同一）
Ｋｕ：該当インデックスでユーザ毎の平均キーの数（該当テーブルでユーザ毎の平均レコードの数と同一）
Ｋｓ：本発明の第１実施形態において、ユーザ毎のインデックスを用いてスキャンするようになる平均キーの数
【００５８】
各インデックススキャンでは検索条件を満たす一番目のレコードを探す「ｇｅｔ＿ｆｉｒｓｔ＿ｒｏｗ」演算が１回実行され、次のレコードを探す「ｇｅｔ＿ｎｅｘｔ＿ｒｏｗ」演算が検索条件に合致する全てのレコードが探されるまで繰り返して実行される。全体キーの個数がＫｔであるインデックスにおいて「ｇｅｔ＿ｆｉｒｓｔ＿ｒｏｗ」演算は、一般的にバイナリサーチ（ｂｉｎａｒｙ ｓｅａｒｃｈ）法によりＫｔ個のキーのうち検索条件を満たす一番目のキーを探してレコードをアクセスするため、ｌｏｇ２（Ｋｔ）のコストが消費され、「ｇｅｔ＿ｎｅｘｔ＿ｒｏｗ」演算は現在キーから次のキーを直ちに探してレコードをアクセスすることができるため、１のコストが消費されるといえる。
【００５９】
ｇｅｔ＿ｆｉｒｓｔ＿ｒｏｗ：ｌｏｇ２（Ｋｔ）
ｇｅｔ＿ｎｅｘｔ＿ｒｏｗ：１
【００６０】
従来技術による実行方式では、友達ユーザのそれぞれに対してインデックススキャンが行われなければならないためＵｓ回のインデックススキャンが行われ、各インデックススキャン時にＫｕ個のレコードを抽出して中間レコードセットに記憶する。結局、１回のｌｏｇ２（Ｋｔ）コストとＫｕ回の１コストを有したインデックススキャンがＵｓ回実行される。また、記憶された中間レコードセットをタイムスタンプが最新である順にソートする作業は、全体レコードの数が（Ｕｓ×Ｋｕ）である中間レコードセットに対して実行するため、このようなソートコストは（Ｕｓ×Ｋｕ）×ｌｏｇ２（Ｕｓ×Ｋｕ）であるといえる。従って、従来技術による実行方式により発生する実行時間コストを数式で表すると、以下の数式１のとおりである。
【００６１】
（数式１）
時間コスト（従来技術）＝スキャンコスト＋ソートコスト
＝（Ｕｓ×（ｌｏｇ２（Ｋｔ）＋Ｋｕ））＋（（Ｕｓ×Ｋｕ）×ｌｏｇ２（Ｕｓ×Ｋｕ））
＝Ｕｓ×（ｌｏｇ２（Ｋｔ）＋Ｋｕ＋Ｋｕ×ｌｏｇ２（Ｕｓ×Ｋｕ））
＝Ｕｓ×（ｌｏｇ２（Ｋｔ）＋Ｋｕ×（１＋ｌｏｇ２（Ｕｓ×Ｋｕ）））
【００６２】
一方、本発明の第１実施形態による実行方式も、友達ユーザのそれぞれに対してインデックススキャンが行われなければならないためＵｓ回のインデックススキャンが実行されることは同じであるが、各インデックススキャン時にＫｓ個のレコードのみを抽出し、抽出されたレコードをＮ個のローバッファにソートされた順に格納する。即ち、（ｌｏｇ２（Ｋｔ）＋Ｋｓ）のスキャンコストを有しながら、抽出したＫｓ個のレコードを、Ｎ大きさのローバッファでタイムスタンプの逆順上の挿入位置をバイナリサーチで探して挿入するために、（Ｋｓ×ｌｏｇ２（Ｎ））のコストを有するインデックススキャンがＵｓ回実行される。従って、本発明の第１実施形態による実行方式により発生する実行時間コストを数式で表すると、以下の数式２のとおりである。
【００６３】
（数式２）
時間コスト（第１実施形態）＝Ｕｓ×（ｌｏｇ２（Ｋｔ）＋Ｋｓ＋Ｋｓ×ｌｏｇ２（Ｎ））
＝Ｕｓ×（ｌｏｇ２（Ｋｔ）＋Ｋｓ×（１＋ｌｏｇ２（Ｎ）））
【００６４】
また、本発明の第２実施形態による実行方式の場合、Ｕｓ回のインデックススキャンを実行しながら、「ｇｅｔ＿ｆｉｒｓｔ＿ｒｏｗ」演算で探した一番目のレコードのタイムスタンプを基準に比較して、最新のレコードを指し示しているインデックススキャン情報Ｎ個を記憶するスキャンバッファに挿入するための作業を実行する。従って、Ｕｓ回のインデックススキャンそれぞれに対して一番目のレコードを探すためのｌｏｇ２（Ｋｔ）のコストとスキャンバッファに格納するためのｌｏｇ２（Ｎ）のコストが消費されるため、全体コストは（Ｕｓ×（ｌｏｇ２（Ｋｔ）＋ｌｏｇ２（Ｎ））となる。その後、スキャンバッファに記憶されたＮ個のインデックススキャンを利用してソート−併合（ｓｏｒｔ−ｍｅｒｇｅ）方式で最新のレコードを抽出しながら、最終的にＮ個のローバッファに最新の順にレコードを格納するようになる。これを詳細に説明すると、スキャンバッファにある一番目のインデックススキャンから現在レコードを抽出してローバッファに格納するコストは１が消費され、そのインデックススキャンの次のレコードを得るための「ｇｅｔ＿ｎｅｘｔ＿ｒｏｗ」実行コストも１が消費され、またそのインデックススキャンの新しい現在レコードのタイムスタンプを基準にスキャンバッファでそのインデックススキャンを再位置させるためにｌｏｇ２（Ｎ）のコストが消費される。また、このような作業が最大Ｎ回実行されるため、全体コストは（Ｎ×（ｌｏｇ２（Ｎ）＋２））が消費されるようになる。従って、本発明の第２実施形態による実行方式によって発生する実行時間コストを数式で表すると、以下の数式３のとおりである。
【００６５】
（数式３）
時間コスト（第２実施形態）＝スキャンしながらスキャン情報をスキャンバッファに格納するコスト＋ローバッファに最終レコードを格納するコスト
＝（Ｕｓ×（ｌｏｇ２（Ｋｔ）＋ｌｏｇ２（Ｎ）））＋（Ｎ×（ｌｏｇ２（Ｎ）＋２））
【００６６】
上記で仮定した各変数に以下のような値を代入して、数式１、２、３により計算された実行時間コストの具体的な値は、以下の表２に示す。
【００６７】
Ｎ：２０
Ｕｓ：１００，０００
Ｋｔ：１００，０００，０００
Ｋｕ：１，０００
Ｋｓ：５
【００６８】
【表２】
【００６９】
前記表２に計算されたように、本発明の第１実施形態によると従来技術に比べ約５００倍の速度性能の向上が、第２実施形態によると従来技術に比べ約９００倍の速度性能の向上がなされることが分かる。
【００７０】
また、クエリ実行時に使用される空間コストの面では、従来技術の場合は、Ｕｓ×Ｋｕ個のレコードを中間レコードセットとして抽出してソートするためのバッファが必要である。これだけのバッファを割り当てることができる空間がメモリ内に存在しない場合、メモリでなくディスクを利用してバッファを割り当てなければならないため、メモリとディスクのアクセス（ａｃｃｅｓｓ）速度差による速度上の損失が発生する。これに反して、本発明の第１実施形態の場合はＮ個のローバッファが割り当てられ、第２実施形態の場合はＮ個のスキャンバッファ及びＮ個のローバッファのみが割り当てられればよいため、その空間コストは従来技術に比べ無視できるほど小さいと言える。
【００７１】
ここでのコストの計算は、一つのインデックスに全てのユーザのキーが存在する一般的なＤＢＭＳでの状況を仮定したものである。インデックス機能を提供する他のデータリポジトリの場合は、ユーザ毎に小さい大きさのインデックスを別に作って使用する場合もある。この場合は、各インデックスが有するキーの数がＫｔでなくＫｕとなり、この場合のインデックス探索コストはｌｏｇ２（Ｋｔ）でなくｌｏｇ２（Ｋｕ）となる。
【００７２】
本発明による実施形態は、多様なコンピュータ手段によって実行可能なプログラム命令の形態により実現され、コンピュータ読み取り可能な媒体に記録することができる。この場合、コンピュータ読み取り可能な媒体は、プログラム命令、データファイル、データ構造などを単独に、または組み合わせて含むことができる。このような媒体に記録されるプログラム命令は、本発明のために特別に設計及び構成されたものであってもよく、コンピュータソフトウェア分野の当業者に公知されて使用可能なものであってもよい。コンピュータ読み取り可能な記録媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク及び磁気テープなどの磁気媒体（Ｍａｇｎｅｔｉｃ Ｍｅｄｉａ）、ＣＤ−ＲＯＭ、ＤＶＤなどの光記録媒体（Ｏｐｔｉｃａｌ Ｍｅｄｉａ）、フロプティカルディスク（Ｆｌｏｐｔｉｃａｌ Ｄｉｓｋ）などの磁気−光媒体（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａｌ Ｍｅｄｉａ）、及びＲＯＭ、ＲＡＭ、フラッシュメモリなどの、プログラム命令を記憶及び実行するように特別に構成されたハードウェア装置が含まれる。プログラム命令の例としては、コンパイラーによって作られるもののような機械語コードだけでなく、インタープリターなどを用いてコンピュータによって実行されることができる高級言語コードを含む。前記ハードウェア装置は、本発明の動作を行うために一つ以上のソフトウェアモジュールとして作動するように構成されることができ、その逆も同様である。
【００７３】
以上のように本発明では、具体的な構成要素などのような特定事項と限定された実施形態及び図面によって説明されたが、これは本発明の全般的な理解をより容易にするために提供されたものに過ぎず、本発明は上記の実施形態に限定されるものではなく、本発明が属する分野において通常の知識を有する者であれば、このような記載から多様な修正及び変形が可能である。
【００７４】
従って、本発明の思想は、説明された実施形態に限って決まってはならず、添付する特許請求範囲だけでなく、この特許請求範囲と均等または等価的変形がある全てのものなどは本発明の思想の範囲に属するといえる。
【技術分野】
【０００１】
本発明は、多重範囲スキャンでのＮソート（Ｎ ｓｏｒｔ）クエリを最小の時間と最小のメモリ空間で、最適に処理するための方法及び装置に関する。より詳細には、データベース管理システム（Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ、以下「ＤＢＭＳ」という）に含まれるインデックス（ｉｎｄｅｘ）を用いて、範囲スキャン（ｒａｎｇｅ ｓｃａｎ）機能を提供する全てのデータ管理システムに適用可能である多重範囲スキャンでのＮソートクエリを最適に処理する方法及び装置に関する。
【背景技術】
【０００２】
インターネットの発達に伴い、インターネットを利用する様々なＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）が脚光を浴びている。ＳＮＳは、オンライン上で知人との人間関係を深め、不特定の人と新しい人間関係を築くことができるようにするサービスを通称するものである。ＳＮＳとしては、韓国ではＳＫコミュニケーションズのサイワールド（Ｃｙｗｏｒｌｄ）、米国ではフェイスブック（Ｆａｃｅｂｏｏｋ）など、それぞれの特性による様々な種類の開発及びサービスが提供されている。
【０００３】
ＳＮＳの一分野として、マイクロブログ（Ｍｉｃｒｏｂｌｏｇ）も最近多くのユーザにより使用されている。マイクロブログとは、一、二文の短いメッセージを利用して多数の人とコミュニケーションができるブログの一種であり、ミニブログ（ｍｉｎｉｂｌｏｇ）とも呼ばれている。マイクロブログの特徴は、短いテキストを用いて、ユーザが互いに情報を発信し、発信した情報がリアルタイムでアップデートされるという特性を有している。また、マイクロブログでは、写真や動画などをアップロードすることもできる。即ち、ブログとメッセンジャを結合したような形態であり、ユーザはまるでチャットをしているような感じを受ける。また、個人の細かい日常の出来事や普段考えていること、感じたこと、感情、情報などを短いテキストで作成して交流するため、書くことや読むことに対する負担なく、簡単に使用できるという長所がある。、このため、マイクロブログは、多くの人気を集めている。マイクロブログの代表的な例としては、ツイッタ（ｔｗｉｔｔｅｒ）、及び韓国ではミートゥデイ（ｍｅ２ｄａｙ）などが挙げられる。
【０００４】
ＳＮＳ、特にマイクロブログの場合、多くのユーザが交わす情報がほぼリアルタイムで更新される。そして、ユーザ本人やユーザと関係がある他のユーザ（以下、「友達」という、少なくとも数人〜数千または数万人以上）が交わす情報から、最新情報の一部のみを抽出してユーザ本人または友達に表示する方式のクエリが非常に頻繁に使用されている。例えば、友達が作成した文章のうち最近作成した所定個数（例えば、Ｎ（Ｎは自然数）個）の文章、またはある特定時点以後に作成されたＮ個の文章のみを抽出するクエリが頻繁に使用されている。このようなクエリの処理は、各友達に対して特定時点以後にその友達が作成した文章を範囲スキャンするだけでなく、全ての友達に対して繰り返して実行する多重範囲スキャン（ｍｕｌｔｉ−ｒａｎｇｅ ｓｃａｎ）の形態で実行しなければならない。そのため、このような多重範囲スキャンによりアクセスする友達の文章のうち最新またはある特定時点以後のＮ個の文章のみをソート順に抽出（以下、このような抽出に用いられるクエリを「Ｎソートクエリ」という）するための作業が必要である。しかし、従来のデータベース管理システム（Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ、以下「ＤＢＭＳ」という）を含むデータ管理システムは、ＳＮＳなどで主に使用されている多重範囲スキャンでのＮソートクエリに対する最適化処理を考慮していない状態である。一例として、既存のＤＢＭＳでは、多重範囲スキャンによりアクセスされる友達の全ての文章を中間結果として抽出した後、抽出した文章を生成時間の逆順にソートしなければならない。このため、その処理速度が非常に遅く、中間結果を記憶するために非常に大きい記憶空間が必要となるという問題点があった。これにより、既存のＤＢＭＳの機能のみでは、ＳＮＳなどで頻繁に実行されるクエリを効率的に処理するには足りない面が多かった。
【０００５】
このような従来のクエリ処理方式は、ユーザ毎に作成した文章の数が多くなるほど、また友達の数が多くなるほど、ＤＢＭＳがスキャンしなければならない全体レコードの数が幾何級数的に増加する。そのため、ソートのために必要な中間レコードセットを格納するための多くのメモリ空間が必要であり、その多くのレコードをソートするための作業実行に対する負担のため、クエリ処理にかかる時間及び空間の無駄が非常に多かった。
【０００６】
従って、ＳＮＳなどで頻繁に使用される多重範囲スキャンでのＮソートクエリを受信した場合、スキャン対象となる友達の文章の数を最小化しながらも、限定された大きさの記憶空間のみを使用して該当クエリ処理を実行することができる方式、即ち、時間及び空間的なコストの面で最適なクエリ処理方式に対する要求が高まっている。
【０００７】
さらに、このようなクエリ処理方式は、既存のＤＢＭＳだけでなく、ＤＢＭＳの前段で範囲スキャン機能を提供する高速のデータリポジトリ、即ち、メモリでのみデータを記憶管理して、そのデータのコレクション（ｃｏｌｌｅｃｔｉｏｎ）に対するインデックスを用いて範囲スキャンを提供する高速のデータリポジトリにおいても、その必要性が高まっている。例えば、最近多く開発されているＮｏＳＱＬデータベース、即ち、ＳＱＬインタフェースを用いたクエリ処理機能を提供するＤＢＭＳでなく、新しいインタフェースを提供し、処理性能またはシステム拡張性に重点を置いているデータベースタイプにこのような高速のデータリポジトリが含まれている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】韓国公開特許第２０００―００４７６３０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明の目的は、上述した従来技術の問題点を解決することにある。
【００１０】
本発明の目的は、多重範囲スキャンでのＮソートクエリを受信した場合、スキャン対象となるレコードの数を最小化にしながら、スキャン中にソートされた結果を直ちに得るようにすることで、クエリ処理にかかる時間を最小化しながらも少ないメモリ空間のみを使用するようにすることである。
【００１１】
本発明の他の目的は、クエリ処理技術をＤＢＭＳまたは高速のデータリポジトリを用いて、ＳＮＳなど多重範囲スキャンでのＮソートクエリを多く使用する環境で用いることで、ＳＮＳなどのサービスを行う時のクエリ処理性能を極大化することにある。本発明のさらに他の目的は、開発者が従来のＤＢＭＳで効果的なクエリ処理のために、ＤＢＭＳ毎に多重範囲スキャンでのＮソートクエリがどのように処理されるか内部的な処理方式を把握し、それに応じてＤＢＭＳ毎に最適化するためにクエリを修正する必要がなく、従来のクエリをそのまま使用しても最適の方式でＮソートクエリが処理されるため、ＳＮＳなどの設計及び開発などにおいてその便宜性及び開発速度の向上を図ることができるようにすることにある。
【課題を解決するための手段】
【００１２】
上記のような本発明の目的を果たし、後述する本発明の特有の効果を果たすための本発明の特徴的な構成は下記のとおりである。
【００１３】
本発明の一実施形態によるクエリ処理方法は、クエリに含まれた抽出レコード数に基づいてバッファを割り当て、前記クエリに含まれた第１リストのうち第１属性に係わる第１データを抽出して前記バッファに記憶し、前記クエリに含まれた前記第１リストのうち抽出されていない前記第１属性に係わる第２データを抽出し、前記バッファに記憶された前記第１データ及び前記第２データを比較することにより、前記クエリを満たすように前記バッファを更新し、前記クエリは、前記第１属性及び前記第２属性に基づいて前記ソートされた一つ以上の前記レコードに対する多重範囲スキャンでのＮソートクエリであることを特徴とする。
【００１４】
本発明の他の態様によるクエリ処理装置は、クエリに含まれた抽出レコード数に基づいてバッファを割り当てるバッファ割り当て部と、前記クエリに含まれた第１リストのうち第１属性に係わる第１データを抽出して前記バッファに記憶し、前記クエリに含まれた第１リストのうち抽出されていない第１属性に係わる第２データを抽出し、前記バッファに記憶されたデータ及び前記第２データを比較することにより、前記クエリを満たすように前記バッファを更新するスキャン部と、を含み、前記クエリは、第１属性及び第２属性に基づいてソートされた一つ以上のレコードに対する多重範囲スキャンでのＮソートクエリであることを特徴とする。
【００１５】
この他にも、本発明を実現するための上記の方法を行うコンピュータプログラムを記録するコンピュータ読み取り可能な記録媒体がさらに提供される。
【発明の効果】
【００１６】
本発明によると、多重範囲スキャンでのＮソートクエリを受信した場合、スキャン対象となるレコードの数を最小化にしながら、スキャン中にソートされた結果を直ちに得るようにすることで、クエリ処理にかかる時間を最小化しながらも少ないメモリ空間のみを使用することができる。
【００１７】
また、本発明によると、クエリ処理技術をＤＢＭＳまたは高速のデータリポジトリに具現し、ＳＮＳなど多重範囲スキャンでのＮソートクエリを多く使用する環境で使用することで、ＳＮＳなどのサービスを行う時のクエリ処理性能を極大化することができる。
【００１８】
また、本発明によると、開発者が従来のＤＢＭＳで効果的なクエリ処理のために、ＤＢＭＳ毎に多重範囲スキャンでのＮソートクエリがどのように処理されるか内部的な処理方式を把握し、それに応じてＤＢＭＳ毎に最適化するためにクエリを修正する必要がなく、従来のクエリをそのまま使用しても最適の方式でＮソートクエリが処理されるため、ＳＮＳなどの設計及び開発などにおいてその便宜性及び開発速度の向上を図ることができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の一実施形態によるＤＢＭＳが多重範囲スキャンでのＮソートクエリ処理時において、インデックスを用いてスキャンする範囲を示す図面である。
【図２】本発明の第１実施形態及び第２実施形態による多重範囲スキャンでのＮソートクエリを処理するクエリ処理装置を示す構成図である。
【図３】本発明の第１実施形態によるスキャン部で実行される多重範囲スキャンでのＮソートクエリの処理方法を示すフローチャートである。
【図４】本発明の第２実施形態によるスキャン部で実行される多重範囲スキャンでのＮソートクエリの処理方法を示すフローチャートである。
【図５】本発明の第２実施形態によるスキャン部で実行される多重範囲スキャンでのＮソートクエリの処理方法を示すフローチャートである。
【図６】本発明の第１実施形態による多重範囲スキャンでのＮソートクエリの処理方法のうちローバッファを更新する工程を示す図面である。
【図７ａ】本発明の第２実施形態による多重範囲スキャンでのＮソートクエリの処理方法のうちスキャンバッファ及びローバッファの形態とスキャンバッファ及びローバッファの更新工程を示す図面である。
【図７ｂ】本発明の第２実施形態による多重範囲スキャンでのＮソートクエリの処理方法のうちスキャンバッファ及びローバッファの形態とスキャンバッファ及びローバッファの更新工程を示す図面である。
【図７ｃ】本発明の第２実施形態による多重範囲スキャンでのＮソートクエリの処理方法のうちスキャンバッファ及びローバッファの形態とスキャンバッファ及びローバッファの更新工程を示す図面である。
【図７ｄ】本発明の第２実施形態による多重範囲スキャンでのＮソートクエリの処理方法のうちスキャンバッファ及びローバッファの形態とスキャンバッファ及びローバッファの更新工程を示す図面である。
【発明を実施するための形態】
【００２０】
以下、本発明の好適な実施形態を、図面を参照して詳細に説明する。以下の実施形態は、当業者が本発明を十分に実施することができるように詳細に説明される。本発明の多様な実施形態は、互いに異なり、必要などに応じて相互に組み合わせることができることを理解すべきである。例えば、ここに記載されている特定形状、構造及び特徴は、一実施形態に関連して本発明の思想及び範囲を外れずに他の実施形態に用いることができる。また、それぞれの開示された実施形態の構成要素の位置または配置は、本発明の思想及び範囲を外れずに変更可能であることを理解すべきである。従って、後述する詳細な説明は限定的な意味で扱うものでなく、本発明の範囲は、適切に説明されるならば、その特許請求の範囲が主張するものと均等な全ての範囲と共に、添付した特許請求の範囲によってのみ限定される。図面において、同一の参照符号は、様々な側面にわたって同一または類似の機能を示す。
【００２１】
以下、本発明が属する技術分野において通常の知識を有する者が本発明を容易に実施できるように、本発明の好適な実施形態について添付図面を参照して詳細に説明する。
【００２２】
［クエリ処理時のスキャン範囲］
図１は、本発明の一実施形態によるＤＢＭＳが、多重範囲スキャンでのＮソートクエリの処理時に、インデックス（ｉｎｄｅｘ）を用いてスキャンする範囲を示す図面である。
【００２３】
多重範囲スキャンでのＮソートクエリを利用するサービスまたはシステムにおいて、ユーザが作成する文章の記憶と検索対象となるデータベースは様々な方式で実現できる。また、一般的に、文章を作成したユーザのＩＤ、作成した時間情報を示すタイムスタンプ（Ｔｉｍｅ Ｓｔａｍｐ）、作成された文章の内容、及び付加的な情報に対する属性をさらに有してもよい。以下、説明の便宜上、ＤＢＭＳとＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）を基に説明する。ＤＢＭＳでユーザのＩＤをｕｓｅｒｉｄ、タイムスタンプをｔｓ、作成された文章の内容をｃｏｎｔｅｎｔｓと命名したテーブルを以下の表１のように示す。表１に示したテーブルの名称をｐｏｓｔｓと仮定する。
【００２４】
【表１】
【００２５】
一方、上記表１のようなｐｏｓｔｓテーブルで、あるユーザの友達全体を対象として最近作成され、または、特定時点から最も近い時期に作成された文章から特定個数の文章のみを抽出するための多重範囲スキャンでのＮソートクエリは多様な方式で実現されてもよく、一般的に以下の例示的なＳＱＬ文のように実現することができる。
【００２６】
ＳＥＬＥＣＴ ｔｓ、 ｕｓｅｒｉｄ
ＦＲＯＭ ｐｏｓｔｓ
ＷＨＥＲＥ ｕｓｅｒｉｄ ＩＮ（ｆｒｉｅｎｄｓ＿ｌｉｓｔ）ＡＮＤ ｔｓ＜ｓｙｓｄａｔｅ（）
ＯＲＤＥＲ ＢＹ ｔｓ ＤＥＳＣ
ＬＩＭＩＴ Ｎ；
（ここで、ｆｒｉｅｎｄｓ＿ｌｉｓｔは所定ユーザの友達のユーザＩＤリストのみを含み、所定ユーザを含んで友達のユーザＩＤリストを含む。これは、該当クエリを実行する特定サービスまたはシステムでどのようなユーザの文章を集めるかによって変わる。また、Ｎは抽出する文章の個数を意味する。）
【００２７】
このＳＱＬ文を効率的に処理するためには、表１に示すｐｏｓｔｓテーブルに対してユーザＩＤの順に、その内部でタイムスタンプの逆順にレコードを速く検索するためのインデックスが必要である。このため、一般的にｕｓｅｒｉｄに対して昇順、ｔｓに対して降順のキー（ｋｅｙ）を有するインデックスを生成し、このようなインデックスを説明の便宜上「ｐｏｓｔｓ_ｕｓｅｒｉｄ_ｔｓ_ｉｎｄｅｘ」と仮定する。
【００２８】
インデックスは、テーブルの各レコードに対応する一つのキーを保持する。ここで、その一つのキーは、キー値とそのキー値を有するレコードの識別子で構成される。例えば、図１に示す範囲１の一番目のキーは、キー値としてＡ及び２０１０−１２−０１ １４：３０：０２を有し、さらに、このキー値を有するレコードの識別子として、Ｒ４を有する。または、メモリに全てのデータを記憶するメインメモリデータベース（Ｍａｉｎ−Ｍｅｍｏｒｙ ＤＢＭＳ：ＭＭＤＢＭＳ）の場合、キー値を有するレコードが常にメモリに記憶されているため、キーのレコード識別子を介して、そのキー値を直接アクセスすることできる。従って、ＭＭＤＢＭＳでインデックスのキーは、一般的にレコード識別子のみを有する。よって、図１に示したインデックスでのキーは、キー値とレコード識別子を全て有する一般的なディスクＤＢＭＳを仮定して表現したものであり、インデックスでのキー構成が図１に限定されず、データリポジトリの具現特性によってインデックスでのキー構成が変わることは自明である。上述した表１のようにレコードが任意の順に記憶されており、図１の右側に示したｐｏｓｔｓテーブルに対して上記のＳＱＬ文を効率的に実行するためには、図１の左側に示したようにｐｏｓｔｓテーブルに係る「ｐｏｓｔｓ_ｕｓｅｒｉｄ_ｔｓ_ｉｎｄｅｘ」インデックスが備えられることが前提とされる。この「ｐｏｓｔｓ_ｕｓｅｒｉｄ_ｔｓ_ｉｎｄｅｘ」インデックスを基に、本発明の実施形態によってＳＱＬ文のような多重範囲スキャンでのＮソートクエリを実行するための具体的な順序については、図６−図７ｄを参照して以下でより詳細に説明する。
【００２９】
［多重範囲スキャンでのＮソートクエリを処理するクエリ処理装置］
図２は、本発明の一実施形態による多重範囲スキャンでのＮソートクエリを処理するクエリ処理装置を示す構成図である。
【００３０】
図２を参照すると、本発明の一実施形態によるクエリ処理装置１００は、クエリ解釈部１１０とクエリ実行部１２０とに大別される。クエリ実行部１２０は、バッファ割り当て部１２１と、スキャン部１２２と、提供部１２３と、を含む。
【００３１】
本発明の一実施形態によるクエリ解釈部１１０は、特定形式によるクエリを受信し、受信されたクエリが多重範囲スキャンでのＮソートクエリであるか否かを判断する。クエリ解釈部１１０に特定形式によるクエリを伝送する伝送装置とは、クエリ処理装置１００との通信を介してクエリ処理装置１００にアクセスしてデータを要求することができる装置または構成要素を全て含む広義の概念である。クエリ処理装置１００に対するクエリ伝送は、伝送装置とクエリ処理装置１００との間の認証などの手順を経て、伝送装置がクエリ処理装置１００にクエリを介して特定データを要求することができる正当な権限があるか否かを予め確認した後に行ってもよい。この場合、認証手順は公知のＤＢＭＳアクセス（ａｃｃｅｓｓ）時に使用される認証手順を利用することができる。クエリ解釈部１１０が受信した特定形式によるクエリは、公知のＳＱＬによるＳＱＬ構文であってもよい。クエリ解釈部１１０はパージング（ｐａｒｓｉｎｇ）機能を利用して、受信されたクエリが多重範囲スキャンでのＮソートクエリであるか否かを判断することができる。
【００３２】
本発明の一実施形態によるクエリ解釈部１１０は、単に多重範囲スキャンでのＮソートクエリであるか否かを判断するだけでなく、受信したクエリを具体的に解釈し、抽出されるべきのレコードの数、スキャン対象となるユーザＩＤ及びソートの基準となるタイムスタンプ値などに関する情報をさらに解釈して抽出する機能をさらに備えていてもよい。
【００３３】
本発明の一実施形態によるクエリ実行部１２０は、クエリ解釈部１１０により解釈された情報に基づいてクエリを実行する。クエリ実行部１２０は、様々な構成要素を有してもよい。なお、多重範囲スキャンでのＮソートクエリに対する効率的な処理方式に焦点を当てその説明を容易にするために、バッファ割り当て部１２１、スキャン部１２２、提供部１２３を有してもよい。まず、本発明の一実施形態によるバッファ割り当て部１２１は、クエリ解釈部１１０により、受信されたクエリが多重範囲スキャンでのＮソートクエリであると判断された場合、メモリ上にスキャンのための一時的な記憶空間であるバッファを割り当てる。割り当てられるバッファの大きさは、クエリ解釈部１１０により解釈された情報のうち抽出されるべきのレコードの個数に対応する。例えば、抽出されるべきのレコードの個数がＮ個であると、バッファ割り当て部１２１は、後述するスキャン部１２２のスキャン方式に応じて、Ｎ個のソートができるローバッファ（ｒｏｗ ｂｕｆｆｅｒ）、またはＮ個のスキャンバッファ（ｓｃａｎ ｂｕｆｆｅｒ）とローバッファ（ｒｏｗ ｂｕｆｆｅｒ）を割り当てる。ここで、ローバッファとは、インデックススキャンにより抽出されるレコードのキー値と識別子を記憶したり、またはレコードの識別子のみを記憶したりすることができるメモリ領域を意味する。また、スキャンバッファとは、多数のユーザに対するインデックススキャンのうち最新のレコードをスキャンしているインデックススキャンの識別子情報を記憶することができるメモリ領域を意味する。次に、本発明の一実施形態によるスキャン部１２２は、バッファ割り当て部１２１により割り当てられた、限定された数のバッファを利用して、最小限のインデックススキャンによりクエリ解釈部１１０により解釈された多重範囲スキャンで最上位のＮソートクエリを行う。本発明の好ましい実施形態によるスキャン部１２２の具体的なクエリ実行順序については後述する。
【００３４】
最後に、本発明の一実施形態による提供部１２３は、スキャン部１２２の動作により実行されたクエリに対する結果として、バッファ割り当て部１２１により割り当てられたローバッファに記憶された特定個数のレコードをクエリに対する結果としてクエリを要請した特定個体に伝送する。
【００３５】
図２に示すクエリ解釈部１１０、クエリ実行部１２０のバッファ割り当て部１２１、スキャン部１２２及び提供部１２３は、物理的に単一の装置内に構成されてもよく、一部またはそれぞれが物理的に異なる装置に構成されてもよく、また、同様の機能を有する物理的に複数存在する装置が並列的に存在してもよい。このように、本発明の実施形態は、各構成部が設けられた機械またはデータベースの物理的な数及び位置に限定されず、多様な方式に設計変更されることということは、本発明が属する技術分野において通常の知識を有する者において自明のことである。
【００３６】
図２の各構成要素は、本発明を説明するために必要な必須構成要素に限定して開示及び説明され、各構成要素は本発明で説明されていない公知の他の機能を実行したり、または図２に示していない、公知の他の機能を実行したりするための別の構成要素がクエリ処理装置１００内に追加され得るということは、本発明が属する技術分野において通常の知識を有する者において自明のことである。
【００３７】
［第１実施形態］
［多重範囲スキャンでＮソートクエリの処理］
次に、図３、図４及び図５を参照して、本発明の好ましい実施形態により、スキャン部１２２で実行される多重範囲スキャンでのＮソートクエリの処理方法について詳細に説明する。
【００３８】
まず、本発明の第１実施形態によると、バッファ割り当て部１２１は抽出されるべきのレコードの数（以下、「Ｎ」という）だけのローバッファを割り当てていることを仮定する。図３に示した本発明の第１実施形態によると、クエリ処理装置１００のスキャン部１２２は、上記表１で仮定した「ｐｏｓｔｓ_ｕｓｅｒｉｄ_ｔｓ_ｉｎｄｅｘ」インデックスを基に各ユーザに対して、最新または特定時点以後の文章のみを検索するためのインデックススキャンを始める（ステップＳ１１０）。インデックススキャンは、インデックスを、たとえばルート（ｒｏｏｔ）ノードから最下位ノードであるリーフ（ｌｅａｆ）ノードまで探索しながら、検索条件を満たす一番目のレコードを検索する（ステップＳ１２０）。検索条件を満たす一番目のレコードが見つけられなかった場合は（Ｓ１３０）、現在ユーザが特定時点以後に作成された文章が存在しないということを意味するため、現在のインデックススキャンを終了する（Ｓ１９０）。検索条件を満たす一番目のレコードが存在する場合は（Ｓ１３０）、スキャン部１２２は、ローバッファに現在のレコード情報を記憶するための作業を以下のように実行する。即ち、まず、Ｎ大きさのローバッファがフル（ｆｕｌｌ）状態であるかを確認する（Ｓ１４０）。ローバッファがフル状態でない場合は（Ｓ１４０）、レコード情報を記憶する空間がローバッファに残っている状態であることを意味するため、現在検索したレコードのタイムスタンプ値とローバッファに記憶されたレコードのタイムスタンプ値とを比較して、タイムスタンプの逆順が維持されるように、ローバッファに挿入すべき位置を探してその位置に現在レコード情報を記録する（Ｓ１７０）。このような方式により、ローバッファ内に記憶されたレコード情報は、常にそのタイムスタンプの逆順にソートされている。ローバッファがフル状態である場合は（Ｓ１４０）、現在検索したレコードのタイムスタンプ値とローバッファに記憶された最後のレコード、即ち、タイムスタンプの逆順にソートされたローバッファで最も小さいタイムスタンプ値を有するレコードのタイムスタンプ値とを比較して、現在検索したレコードをローバッファに挿入できるかを確認する（Ｓ１５０）。現在のレコードのタイムスタンプ値がローバッファにある最後のレコードのタイムスタンプ値より小さいかまたは同一である場合は（Ｓ１５０）、現在のユーザが作成した文章が、既に他のユーザが作成した、即ち、ローバッファ内に記憶されたレコード情報に対応するＮ個の文章より古い文章ということが明らかであるため、現在ユーザに対して検索したレコードをローバッファに挿入する必要がなく、現在ユーザの次のレコードを検索する必要もなくなる。従って、現在ユーザの文章をスキャンする作業を中止する（Ｓ１９０）。現在のレコードのタイムスタンプ値がローバッファにある最後のレコードのタイムスタンプ値より大きい場合は（Ｓ１５０）、最後のレコードをローバッファから除去した後（Ｓ１６０）、ローバッファに現在のレコードを挿入する（Ｓ１７０）。この場合にも、ローバッファに記録されたレコードは、タイムスタンプの逆順へのソートが維持されるように、現在のレコードの適切な挿入位置を探して挿入する（Ｓ１７０）。本発明の第１実施形態によるローバッファへのレコードの挿入によるローバッファの更新を示した図６を参照すると、スキャン部１２２が、既にＮ個のレコードが記憶されているローバッファ内にユーザＣが作成したレコードが抽出され挿入されようとしている。挿入されようとする、ユーザＣが作成したレコードのタイムスタンプは「２０１０−１２−０１ １３：５７：２６」であり、ローバッファに記憶された最後のレコードのタイムスタンプである「２０１０−１１−２９ ２３：４８：０１」より最新のものである。また、２番目に位置するタイムスタンプが「２０１０−１２−０１ １４：０７：０９」であるレコードよりは最新ではないが、３番目に位置するタイムスタンプが「２０１０−１２−０１ １３：４６：５２」であるレコードよりは最新のものであるため、その間に位置するべきである。従って、スキャン部１２２は、ローバッファの最後の位置にあるレコード（識別子がＲ４４であるレコード）を除去し、ローバッファの３番目の位置に現在レコードを記憶する。従って、元のローバッファで３番目の位置からＮ−１番目の位置まで記憶されていたレコードは、ユーザＣが作成したレコードの挿入により一つずつ後側に移動して記憶される。従って、挿入後のローバッファに記憶された最後のレコードは、従来のＮ−１番目の位置に記憶されたレコードと同一の、識別子としてＲ６２を有するレコードであることが分かる。
【００３９】
また、図３をさらに参照すると、ローバッファに現在検索したレコードを挿入した場合には、現在のインデックススキャンにより次のレコードを検索し（Ｓ１８０）、次のレコードの存在有無に応じて（Ｓ１３０）上述の処理工程を繰り返す。
【００４０】
現在のユーザに対するインデックススキャンで検索するレコードがそれ以上ない場合や（Ｓ１３０）、検索したレコードのタイムスタンプがローバッファに記録されたレコードの最小タイムスタンプ値より小さいかまたは同一である場合（Ｓ１５０）、現在のユーザに対するスキャンをそれ以上行う必要がないため、上述のように現在のユーザに対するインデックススキャンを終了する（Ｓ１９０）。
【００４１】
現在のユーザに対するスキャンを終了すると、次のユーザがあるかを確認する（Ｓ２００）。次のユーザがある場合（Ｓ２００）、そのユーザに対するインデックススキャンを始め（Ｓ１１０）、上述の処理工程を繰り返す。次のユーザがない場合（Ｓ２００）、ローバッファにあるレコードが最終のクエリ結果となるため（Ｓ２１０）、全体処理工程を終了する。ここで、ユーザとは、Ｎソート結果を得るクエリを利用するサービスまたはシステムの設計または開発特性によって、所定ユーザ本人を含むかまたは含まない所定ユーザの友達を意味する。
【００４２】
図３に示した本発明の第１実施形態の順序を実行して完了した場合、バッファ割り当て部１２１により割り当てられたＮ個のローバッファに記憶されたＮ個のレコードは、クエリ解釈部１１０により解釈された多重範囲スキャンでのＮソートクエリの実行結果として、所定ユーザの友達（所定ユーザが含まれてもよく、含まれなくてもよい）が作成した全ての文章を対象として最新または特定時点以後に作成されたＮ個の文章を格納していることが分かる。
【００４３】
［第２実施形態］
図４及び図５は本発明の第２実施形態によるスキャン部１２２が多重範囲スキャンでのＮソートクエリを実行する順序を示したフローチャートである。
【００４４】
まず、ＤＢＭＳまたは他のデータリポジトリからインデックススキャンにより特定範囲のレコードを検索する場合の技術的な順序を詳細に説明する。インデックスアクセス時にスキャン対象となるテーブルとインデックスをアクセスするための情報を取り込み、インデックススキャン情報を格納するための構造体に格納しておく。そして、その情報に基づいてそのインデックスをアクセスする。例えば、インデックスのルート（ｒｏｏｔ）ノード識別子などがこれに該当する。また、インデックスを用いて検索するキーの範囲及び範囲内の各キーまたはレコードに対して適用するフィルタリング情報などを保管し、これを用いて検索範囲にあるキーまたはレコードをスキャンする際に検索条件に合致するレコードを探す。その他にも、インデックスで現在アクセスしているキーの位置情報とそのキーを有するレコードの識別子を維持する。このような情報は、初めは空値（ＮＵＬＬ）などとして設定され、一番目のレコードとともに次のレコードを探す度に現在のキーと現在のレコード情報に更新される。インデックススキャンによりスキャン範囲を外れると、スキャン情報が格納されている構造体を破棄するなどのインデックススキャンの終了作業を行う。
【００４５】
次に、本発明の第２実施形態におけるスキャンバッファは、各インデックススキャンが現在指し示しているレコードのタイムスタンプを基準に、最新のタイムスタンプを有するレコードを指し示すインデックススキャンの識別子情報を記憶するバッファである。インデックススキャンの識別子としては、インデックススキャン情報を有している構造体のアドレス（ａｄｄｒｅｓｓ）としてもよく、インデックススキャン情報を有している構造体が配列（ａｒｒａｙ）形態に構成される場合、その配列での位置値になってもよい。または、ＤＢＭＳでなく他のデータリポジトリでは、テーブルの概念がなく実際のレコードのデータがインデックスのキー内に全て含まれてもよく、スキャンの現在のキー位置情報のみを有してスキャンを行ってもよい。例えば、スキャンを開始する際に、現在のキーの位置情報はルートノードに設定された後、一番目のキーまたは次のキーを探す度に現在のキーの位置情報は実際のキーの位置情報に設定されてもよい。この場合、キーの位置情報の大きさが大きくないため、このようなキーの位置情報そのものをスキャンバッファに記録することもできる。従って、スキャンバッファに記録される情報は、インデックススキャン機能を提供する該当データリポジトリの実際の内部方式によって変わることは当業者において自明のことである。
【００４６】
本発明の第２実施形態によると、バッファ割り当て部１２１は抽出されるべきレコードの個数（以下、「Ｎ」個という）だけのスキャンバッファ及びローバッファを割り当てていることを仮定する。図４を参照して、上述の特定レコード抽出の順序及び仮定事項を参照して本発明の第２実施形態を説明する。クエリ処理装置１００のスキャン部１２２は、上述の「ｐｏｓｔｓ_ｕｓｅｒｉｄ_ｔｓ_ｉｎｄｅｘ」インデックスを利用して、各ユーザに対して最新または特定時点以後の文章のみを検索するためのインデックススキャンを開始する（Ｓ３１０）。インデックススキャンは、該当インデックスを探索して検索条件を満たす一番目のレコードを検索する（Ｓ３２０）。検索条件を満たす一番目のレコードが存在しない場合（Ｓ３３０）、現在のユーザが特定時点以後に作成された文章が存在しないということを意味するため、現在のインデックススキャンを終了する（Ｓ３８０）。検索条件を満たす一番目のレコードが存在する場合（Ｓ３３０）、スキャンバッファに現在のインデックススキャン情報を記憶するための処理を実行する。このために、まず、Ｎ大きさのスキャンバッファがフル状態であるかを確認する（Ｓ３４０）。スキャンバッファがフル状態でない場合（Ｓ３４０）、インデックススキャン情報を記憶する空間がスキャンバッファに残っている状態であることを意味するため、現在インデックススキャンが指し示すレコードのタイムスタンプ値とスキャンバッファに記録されたインデックススキャンが指し示すレコードのタイムスタンプ値とを比較して、タイムスタンプの逆順にソートされるように、スキャンバッファに挿入する位置を探して該当位置に現在のインデックススキャン情報を記録する（Ｓ３７０）。このような方式により、スキャンバッファ内に記憶されたインデックススキャン情報は、それぞれのインデックススキャンが指し示すレコードのタイムスタンプが逆順にソートされている。スキャンバッファがフル状態である場合（Ｓ３４０）、現在インデックススキャンが指し示すレコードのタイムスタンプ値と、それぞれのインデックススキャンが指し示すレコードのタイムスタンプの逆順にソートされたスキャンバッファに記憶された最後のインデックススキャンが指し示すレコードのタイムスタンプ値と、を比較することにより、現在のインデックススキャンをスキャンバッファに挿入できるかを確認する（Ｓ３５０）。現在のインデックススキャンが指し示すレコードのタイムスタンプ値がスキャンバッファに記録された最後のインデックススキャンが指し示すレコードのタイムスタンプ値より小さいかまたは同一である場合（Ｓ３５０）、これは、現在インデックススキャンの検索対象となるユーザが作成した文章より最新の文章を作成したユーザに対するインデックススキャンが既にスキャンバッファにＮ個登録されている状態であることを意味するため、現在ユーザに対するインデックススキャンをそれ以上行う必要がなくなる。従って、現在ユーザに対するインデックススキャン作業を中止する（Ｓ３８０）。現在インデックススキャンが指し示すレコードのタイムスタンプ値がスキャンバッファに記録された最後のインデックススキャンが指し示すレコードのタイムスタンプ値より大きい場合（Ｓ３５０）、スキャン部１２２は、それぞれのインデックススキャンが指し示すレコードのタイムスタンプの逆順にソートされたスキャンバッファで最も古いタイムスタンプを有したレコードを指し示すインデックススキャンである最後のインデックススキャン情報をスキャンバッファから除去し、そのスキャンを終了させた後（Ｓ３６０）、現在のインデックススキャンの情報をスキャンバッファに挿入する（Ｓ３７０）。この場合にも、スキャンバッファでインデックススキャンが指し示すレコードのタイムスタンプの逆順にそのインデックススキャンの記憶順序が維持されなければならないため、現在のインデックススキャンの適切な挿入位置を探して挿入する。現在ユーザに対するインデックススキャンで検索する一番目のレコードがない場合（Ｓ３３０）や、現在インデックススキャンが検索した一番目のレコードのタイムスタンプがスキャンバッファに記録された最後のインデックススキャンが指し示すレコードの最小タイムスタンプ値より小さいか同一である場合（Ｓ３５０）は、現在ユーザに対するスキャンをそれ以上行う必要がないため、上述のように現在ユーザに対するインデックススキャンを終了した後（Ｓ３８０）、次のユーザが存在するかを確認する段階（Ｓ３９０）に進む。また、現在のインデックススキャンをスキャンバッファに登録した場合にも（Ｓ３７０）、そのインデックススキャンを終了していない状態で次のユーザが存在するかを確認する段階（Ｓ３９０）に進む。次のユーザが存在する場合（Ｓ３９０）、そのユーザに対するインデックススキャンを始めて（Ｓ３１０）、上述の処理工程を繰り返す。次のユーザが存在しない場合は（Ｓ３９０）、スキャンバッファには最新または特定時点以後に作成されたＮ個のレコードを抽出するに適したインデックススキャンが登録された状態であることを意味する。
【００４７】
このような段階を経て得られるスキャンバッファの一例は図７ａに図示されている。右側のスキャンバッファに記憶されたユーザＡに対するインデックススキャンは、左側の「ｐｏｓｔｓ_ｕｓｅｒｉｄ_ｔｓ_ｉｎｄｅｘ」インデックスにおいてユーザＡによるレコードのうち最もタイムスタンプが最新であるレコードを指し示しており、ユーザＣとＦに対するインデックススキャンもそれぞれユーザＣとＦによるレコードのうち最もタイムスタンプが最新であるレコードを指し示している。また、各インデックススキャンが指し示すレコードのタイムスタンプの逆順にこれらインデックススキャンの位置が順序化されている。
【００４８】
次に、指し示すレコードのタイムスタンプの逆順にソートされた、スキャンバッファに格納されたインデックススキャンを基に、最新または特定時点以後に作成されたＮ個の文章のみを抽出するための順序を、図５を参照して詳細に説明する。スキャン部１２２は、まずスキャンバッファに記録されたインデックススキャンが存在するかを確認する（Ｓ４１０）。インデックススキャンが存在する場合（Ｓ４１０）、スキャンバッファに存在する一番目のインデックススキャンが指し示すレコード、即ち、最新のタイムスタンプを有するレコードを抽出した後（Ｓ４２０）、そのレコードをローバッファに記録する処理を実行する。ここで、スキャンバッファに記憶されたインデックススキャンはそれらがそれぞれ指し示しているレコードのタイムスタンプの逆順、即ち最新の順にソートされているため、段階Ｓ４２０で抽出されるレコードはスキャンバッファの先頭にあるインデックススキャンが指し示すレコードに該当する。この作業は、ローバッファがフル状態であるかを先に確認してから実行する（Ｓ４３０）。ローバッファがフル状態でないと（Ｓ４３０）、ローバッファに空いている先頭の空間にそのレコードを挿入する（Ｓ４４０）。その後、現在のインデックススキャンで次のレコードを検索し（Ｓ４５０）、次のレコードが存在するかを確認する（Ｓ４６０）。次のレコードが存在しない場合（Ｓ４６０）、現在のインデックススキャンをスキャンバッファから除去し、そのインデックススキャンを終了する（Ｓ４７０）。その後、スキャンバッファにインデックススキャンが残っているかを確認する段階（Ｓ４１０）に進む。次のレコードが存在する場合（Ｓ４６０）、現在インデックススキャンが指し示すレコードが次のレコードに変更されたため、そのレコードのタイムスタンプ値を基準にスキャンバッファで現在のインデックススキャンの位置を再調整する（Ｓ４８０）。この場合にも同様に、レコードのタイムスタンプの逆順にソートされたインデックススキャンの順序が維持されるように、適切な位置にインデックススキャン情報を挿入することによりスキャンバッファで位置を再調整する。インデックススキャンの位置を再調整する場合、スキャンバッファにインデックススキャンが残っているということが保障され、また、スキャンバッファに記憶されたインデックススキャンもそれぞれが指し示すレコードのタイムスタンプの逆順にソートされた順序が維持されるため、スキャンバッファで先頭にある、即ち最もタイムスタンプが最新のレコードを指し示すインデックススキャンから現在のレコードを抽出する段階（Ｓ４２０）に進み、上述の順序を繰り返す。
【００４９】
このような実行順序に従ってスキャンバッファで一番目のインデックススキャンが指し示すレコードを抽出する工程を繰り返すと、抽出するレコードの順序もタイムスタンプが最新である順序になる。従って、このようなレコードをローバッファに挿入する場合、ローバッファに挿入する位置を探すために別のバイナリサーチまたは他の方法による再調整などが必要でなく、単にローバッファの先頭から空いている空間順にレコードを追加（ａｐｐｅｎｄ）してローバッファを満たしていくとローバッファ内のレコードの順序は、タイムスタンプの逆順にソートされた順序が維持される。
【００５０】
一方、スキャン部１２２がスキャンバッファにある一番目のインデックススキャンが指し示すレコードを抽出してローバッファに記憶しようとする際に、ローバッファが既にフル状態である場合（Ｓ４３０）、これは、既に最新順序のＮ個のレコードを全て探した状態であることを意味する。従って、それ以上のスキャンを行う必要がないため、スキャンバッファにある全てのインデックススキャンを終了させる（Ｓ４９０）。また、ローバッファにあるＮ個のレコードが最終結果となるため（Ｓ５００）、全体処理工程を終了する。
【００５１】
上記の順序を実行する工程中に、スキャンバッファにインデックススキャンが存在しない場合があり得る（Ｓ４１０）。この場合は、既にローバッファに０個以上のレコードが存在している状態であり、ローバッファにあるそのレコードが最終結果となるため、スキャン部１２２は全体処理工程を終了する。参考に、ローバッファにあるレコードの数が０であると、これはクエリの検索条件を満たすレコードがないということを意味する。即ち、多数のユーザが作成した文章のうち特定時点以後に作成された文章がないということを意味し、この結果が正常な実行結果となるのである。
【００５２】
本発明の第２実施形態によるスキャンバッファからレコードを抽出してローバッファに挿入または追加する一部実行工程を示すと、図７ｂ、図７ｃ、図７ｄのとおりである。図７ｂを参照して、最新レコードを指し示すインデックススキャンがスキャンバッファに登録されており、ローバッファは空いている状態で始める。スキャン部１２２は、まず一番目のインデックススキャンであるＡスキャンでキーの位置情報であるＫ４５４４を介して現在のキーまたは現在のレコードをアクセスしてそのレコードをローバッファの先頭に挿入する。また、Ａスキャンの次のキーであるＫ４５４５に移動して、該当キーが指し示すレコードのタイムスタンプを基準にスキャンバッファでＡスキャンの位置を再調整する。キーの位置情報であるＫ４５４５が指し示すレコードのタイムスタンプ値は「２０１０−１２−０１ １４：０７：０９」であり、スキャンバッファにある二番目のスキャンであるＣスキャンの現在キーの位置情報であるＫ５１２２が指し示すレコードのタイムスタンプ「２０１０−１２−０１ １３：５７：２６」より最新のものであるため、Ａスキャンに対してスキャンバッファで一番目の位置をそのまま維持する。次に、二番目のレコードを探すために図７ｃを参照すると、上記と同様に、スキャン部１２２は、スキャンバッファにある一番目のインデックススキャンであるＡスキャンがＫ４５４５を介して現在指し示すキーをアクセスし、そのキーのレコードをローバッファで空いている先頭、即ち二番目の位置に挿入する。次に、Ａスキャンの次のキーであるＫ４５４６に移動して、そのキーが指し示すそのレコードのタイムスタンプを基準にスキャンバッファでＡスキャンの位置を再調整する。この場合、Ａスキャンの現在レコードのタイムスタンプ（「２０１０−１２−０１ １３：４６：５２」）がＣスキャンの現在レコードのタイムスタンプ（「２０１０−１２−０１ １３：５７：２６」）より最新でないため、スキャンバッファでＣスキャンが先頭に、またＡスキャンが二番目の位置に位置するようにスキャンバッファの位置を再調整する。図７ｄを参照して次のレコードを抽出する工程を説明すると、スキャン部１２２は、スキャンバッファで一番目のインデックススキャンであるＣスキャンの現在レコードを抽出してローバッファに挿入し、Ｃスキャンの次のキーであるＫ５１２３に移動して、スキャンバッファで位置を調整する。この場合にも、ＣスキャンのキーＫ５１２３が指し示すレコードのタイムスタンプ（「２０１０−１１−２７ １０：２２：２５」）がＡスキャンのキーＫ４５４６が指し示すレコードのタイムスタンプ（「２０１０−１２−０１ １３：４６：５２」）より最新でないため、それぞれのキーが指し示すレコードのタイムスタンプの逆順にソートされるように、スキャンバッファ内に記憶されたインデックススキャンの位置が再調整される。このような工程をＮ回実行することにより、ローバッファにはタイムスタンプが最新である順にＮ個レコードが記憶される。
【００５３】
上述の本発明の第１実施形態及び第２実施形態は、以下の点で実行段階の共通点を有していることを確認することができる。
【００５４】
まず、クエリ実行部のバッファ割り当て部は、クエリに含まれた抽出レコード数（例えば、Ｎ個）に基づいてバッファを割り当てる。第１実施形態の場合はＮ個のローバッファが、第２実施形態の場合はＮ個のスキャンバッファ及びローバッファが割り当てられる。次に、ユーザのＩＤ順及びタイムスタンプの逆順にインデックスされてソートされた一つ以上のレコードに対する多重範囲スキャンでのＮソートクエリとしてクエリ解釈部により解釈されたクエリに基づいて、クエリ実行部のスキャン部は一つのユーザＩＤに対するレコードを抽出し、第１実施形態の場合はローバッファに、第２実施形態の場合はスキャンバッファに記憶する。その後、上記で抽出されなかったユーザＩＤに対するレコードを抽出した後バッファに記憶された、上記で抽出されたレコードとタイムスタンプを比較してクエリの内容である多重範囲スキャンでのＮソートクエリを満たすために、そのタイムスタンプの逆順を維持するように、第１実施形態の場合はローバッファを、第２実施形態の場合はスキャンバッファを更新する。
【００５５】
上述のような本発明の実行段階の共通点に、上記で各図面などを参照して詳細に説明した第１実施形態及び第２実施形態の特有の追加的な実行段階を有機的に組み合わせ、本発明の第１実施形態及び第２実施形態を施すことができる。
【００５６】
［従来技術と本発明の実施形態との時間コストの比較］
本発明の第１実施形態及び第２実施形態により、多重範囲スキャンで最上位のＮソートクエリを実行する場合、従来技術に比べ得られる速度上の効果を、以下で計算する時間コストにより確認する。
【００５７】
まず、各実行方式の時間コストを計算するために、以下のような変数を仮定する。
Ｎ：検索しようとするレコードの個数
Ｕｓ：特定ユーザの友達の数
Ｋｔ：該当インデックスで全体キーの数（該当テーブルで全体レコードの数と同一）
Ｋｕ：該当インデックスでユーザ毎の平均キーの数（該当テーブルでユーザ毎の平均レコードの数と同一）
Ｋｓ：本発明の第１実施形態において、ユーザ毎のインデックスを用いてスキャンするようになる平均キーの数
【００５８】
各インデックススキャンでは検索条件を満たす一番目のレコードを探す「ｇｅｔ＿ｆｉｒｓｔ＿ｒｏｗ」演算が１回実行され、次のレコードを探す「ｇｅｔ＿ｎｅｘｔ＿ｒｏｗ」演算が検索条件に合致する全てのレコードが探されるまで繰り返して実行される。全体キーの個数がＫｔであるインデックスにおいて「ｇｅｔ＿ｆｉｒｓｔ＿ｒｏｗ」演算は、一般的にバイナリサーチ（ｂｉｎａｒｙ ｓｅａｒｃｈ）法によりＫｔ個のキーのうち検索条件を満たす一番目のキーを探してレコードをアクセスするため、ｌｏｇ２（Ｋｔ）のコストが消費され、「ｇｅｔ＿ｎｅｘｔ＿ｒｏｗ」演算は現在キーから次のキーを直ちに探してレコードをアクセスすることができるため、１のコストが消費されるといえる。
【００５９】
ｇｅｔ＿ｆｉｒｓｔ＿ｒｏｗ：ｌｏｇ２（Ｋｔ）
ｇｅｔ＿ｎｅｘｔ＿ｒｏｗ：１
【００６０】
従来技術による実行方式では、友達ユーザのそれぞれに対してインデックススキャンが行われなければならないためＵｓ回のインデックススキャンが行われ、各インデックススキャン時にＫｕ個のレコードを抽出して中間レコードセットに記憶する。結局、１回のｌｏｇ２（Ｋｔ）コストとＫｕ回の１コストを有したインデックススキャンがＵｓ回実行される。また、記憶された中間レコードセットをタイムスタンプが最新である順にソートする作業は、全体レコードの数が（Ｕｓ×Ｋｕ）である中間レコードセットに対して実行するため、このようなソートコストは（Ｕｓ×Ｋｕ）×ｌｏｇ２（Ｕｓ×Ｋｕ）であるといえる。従って、従来技術による実行方式により発生する実行時間コストを数式で表すると、以下の数式１のとおりである。
【００６１】
（数式１）
時間コスト（従来技術）＝スキャンコスト＋ソートコスト
＝（Ｕｓ×（ｌｏｇ２（Ｋｔ）＋Ｋｕ））＋（（Ｕｓ×Ｋｕ）×ｌｏｇ２（Ｕｓ×Ｋｕ））
＝Ｕｓ×（ｌｏｇ２（Ｋｔ）＋Ｋｕ＋Ｋｕ×ｌｏｇ２（Ｕｓ×Ｋｕ））
＝Ｕｓ×（ｌｏｇ２（Ｋｔ）＋Ｋｕ×（１＋ｌｏｇ２（Ｕｓ×Ｋｕ）））
【００６２】
一方、本発明の第１実施形態による実行方式も、友達ユーザのそれぞれに対してインデックススキャンが行われなければならないためＵｓ回のインデックススキャンが実行されることは同じであるが、各インデックススキャン時にＫｓ個のレコードのみを抽出し、抽出されたレコードをＮ個のローバッファにソートされた順に格納する。即ち、（ｌｏｇ２（Ｋｔ）＋Ｋｓ）のスキャンコストを有しながら、抽出したＫｓ個のレコードを、Ｎ大きさのローバッファでタイムスタンプの逆順上の挿入位置をバイナリサーチで探して挿入するために、（Ｋｓ×ｌｏｇ２（Ｎ））のコストを有するインデックススキャンがＵｓ回実行される。従って、本発明の第１実施形態による実行方式により発生する実行時間コストを数式で表すると、以下の数式２のとおりである。
【００６３】
（数式２）
時間コスト（第１実施形態）＝Ｕｓ×（ｌｏｇ２（Ｋｔ）＋Ｋｓ＋Ｋｓ×ｌｏｇ２（Ｎ））
＝Ｕｓ×（ｌｏｇ２（Ｋｔ）＋Ｋｓ×（１＋ｌｏｇ２（Ｎ）））
【００６４】
また、本発明の第２実施形態による実行方式の場合、Ｕｓ回のインデックススキャンを実行しながら、「ｇｅｔ＿ｆｉｒｓｔ＿ｒｏｗ」演算で探した一番目のレコードのタイムスタンプを基準に比較して、最新のレコードを指し示しているインデックススキャン情報Ｎ個を記憶するスキャンバッファに挿入するための作業を実行する。従って、Ｕｓ回のインデックススキャンそれぞれに対して一番目のレコードを探すためのｌｏｇ２（Ｋｔ）のコストとスキャンバッファに格納するためのｌｏｇ２（Ｎ）のコストが消費されるため、全体コストは（Ｕｓ×（ｌｏｇ２（Ｋｔ）＋ｌｏｇ２（Ｎ））となる。その後、スキャンバッファに記憶されたＮ個のインデックススキャンを利用してソート−併合（ｓｏｒｔ−ｍｅｒｇｅ）方式で最新のレコードを抽出しながら、最終的にＮ個のローバッファに最新の順にレコードを格納するようになる。これを詳細に説明すると、スキャンバッファにある一番目のインデックススキャンから現在レコードを抽出してローバッファに格納するコストは１が消費され、そのインデックススキャンの次のレコードを得るための「ｇｅｔ＿ｎｅｘｔ＿ｒｏｗ」実行コストも１が消費され、またそのインデックススキャンの新しい現在レコードのタイムスタンプを基準にスキャンバッファでそのインデックススキャンを再位置させるためにｌｏｇ２（Ｎ）のコストが消費される。また、このような作業が最大Ｎ回実行されるため、全体コストは（Ｎ×（ｌｏｇ２（Ｎ）＋２））が消費されるようになる。従って、本発明の第２実施形態による実行方式によって発生する実行時間コストを数式で表すると、以下の数式３のとおりである。
【００６５】
（数式３）
時間コスト（第２実施形態）＝スキャンしながらスキャン情報をスキャンバッファに格納するコスト＋ローバッファに最終レコードを格納するコスト
＝（Ｕｓ×（ｌｏｇ２（Ｋｔ）＋ｌｏｇ２（Ｎ）））＋（Ｎ×（ｌｏｇ２（Ｎ）＋２））
【００６６】
上記で仮定した各変数に以下のような値を代入して、数式１、２、３により計算された実行時間コストの具体的な値は、以下の表２に示す。
【００６７】
Ｎ：２０
Ｕｓ：１００，０００
Ｋｔ：１００，０００，０００
Ｋｕ：１，０００
Ｋｓ：５
【００６８】
【表２】
【００６９】
前記表２に計算されたように、本発明の第１実施形態によると従来技術に比べ約５００倍の速度性能の向上が、第２実施形態によると従来技術に比べ約９００倍の速度性能の向上がなされることが分かる。
【００７０】
また、クエリ実行時に使用される空間コストの面では、従来技術の場合は、Ｕｓ×Ｋｕ個のレコードを中間レコードセットとして抽出してソートするためのバッファが必要である。これだけのバッファを割り当てることができる空間がメモリ内に存在しない場合、メモリでなくディスクを利用してバッファを割り当てなければならないため、メモリとディスクのアクセス（ａｃｃｅｓｓ）速度差による速度上の損失が発生する。これに反して、本発明の第１実施形態の場合はＮ個のローバッファが割り当てられ、第２実施形態の場合はＮ個のスキャンバッファ及びＮ個のローバッファのみが割り当てられればよいため、その空間コストは従来技術に比べ無視できるほど小さいと言える。
【００７１】
ここでのコストの計算は、一つのインデックスに全てのユーザのキーが存在する一般的なＤＢＭＳでの状況を仮定したものである。インデックス機能を提供する他のデータリポジトリの場合は、ユーザ毎に小さい大きさのインデックスを別に作って使用する場合もある。この場合は、各インデックスが有するキーの数がＫｔでなくＫｕとなり、この場合のインデックス探索コストはｌｏｇ２（Ｋｔ）でなくｌｏｇ２（Ｋｕ）となる。
【００７２】
本発明による実施形態は、多様なコンピュータ手段によって実行可能なプログラム命令の形態により実現され、コンピュータ読み取り可能な媒体に記録することができる。この場合、コンピュータ読み取り可能な媒体は、プログラム命令、データファイル、データ構造などを単独に、または組み合わせて含むことができる。このような媒体に記録されるプログラム命令は、本発明のために特別に設計及び構成されたものであってもよく、コンピュータソフトウェア分野の当業者に公知されて使用可能なものであってもよい。コンピュータ読み取り可能な記録媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク及び磁気テープなどの磁気媒体（Ｍａｇｎｅｔｉｃ Ｍｅｄｉａ）、ＣＤ−ＲＯＭ、ＤＶＤなどの光記録媒体（Ｏｐｔｉｃａｌ Ｍｅｄｉａ）、フロプティカルディスク（Ｆｌｏｐｔｉｃａｌ Ｄｉｓｋ）などの磁気−光媒体（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａｌ Ｍｅｄｉａ）、及びＲＯＭ、ＲＡＭ、フラッシュメモリなどの、プログラム命令を記憶及び実行するように特別に構成されたハードウェア装置が含まれる。プログラム命令の例としては、コンパイラーによって作られるもののような機械語コードだけでなく、インタープリターなどを用いてコンピュータによって実行されることができる高級言語コードを含む。前記ハードウェア装置は、本発明の動作を行うために一つ以上のソフトウェアモジュールとして作動するように構成されることができ、その逆も同様である。
【００７３】
以上のように本発明では、具体的な構成要素などのような特定事項と限定された実施形態及び図面によって説明されたが、これは本発明の全般的な理解をより容易にするために提供されたものに過ぎず、本発明は上記の実施形態に限定されるものではなく、本発明が属する分野において通常の知識を有する者であれば、このような記載から多様な修正及び変形が可能である。
【００７４】
従って、本発明の思想は、説明された実施形態に限って決まってはならず、添付する特許請求範囲だけでなく、この特許請求範囲と均等または等価的変形がある全てのものなどは本発明の思想の範囲に属するといえる。
【特許請求の範囲】
【請求項１】
クエリに含まれた抽出レコード数に基づいてバッファを割り当て、
前記クエリに含まれた第１リストのうち第１属性に係わる第１データを抽出して前記バッファに記憶し、
前記クエリに含まれた前記第１リストのうち抽出されていない前記第１属性に係わる第２データを抽出し、
前記バッファに記憶された前記第１データ及び前記第２データを比較することにより、前記クエリを満たすように前記バッファを更新し、
前記クエリは、前記第１属性及び前記第２属性に基づいて前記ソートされた一つ以上の前記レコードに対する多重範囲スキャンでのＮソートクエリであることを特徴とするクエリ処理方法。
【請求項２】
前記バッファに記憶することは、
前記第１属性が同一の前記レコードを前記抽出レコード数及び前記第１属性に係わる全ての前記レコードの個数のうち小さい数だけ抽出し、
抽出された前記レコードを前記第１データとして前記バッファに記憶すること特徴とする請求項１に記載のクエリ処理方法。
【請求項３】
前記第２データは、抽出された前記第１データが有する前記第１属性とは異なる前記第１属性を有するレコードであることを特徴とする請求項１または２に記載のクエリ処理方法。
【請求項４】
前記バッファを更新することは、
前記第２データを前記バッファに記憶されたデータと比較して第１条件を満たすかを確認し、
前記第２データが前記第１条件を満たす場合、前記第２データが前記バッファに記憶するように前記バッファを更新して、前記更新されたバッファは、前記クエリを満たすことを特徴とする請求項１乃至３の何れか一つに記載のクエリ処理方法。
【請求項５】
前記第１条件は、前記第２データの前記第２属性が前記バッファに記憶されたデータの第２属性のうち少なくとも何れか一つに先立つ条件であることを特徴とする請求項４に記載のクエリ処理方法。
【請求項６】
前記第２データを前記バッファに記憶するように前記バッファを更新することは、
前記バッファがフル状態である場合、前記バッファに記憶された前記第２データのうち前記第２属性が最も古いレコードを前記バッファから削除し、
前記第２データを含んで前記バッファ内に記憶されたデータが、前記第２属性が最新である順にソートされるように、前記第２データを前記バッファの第１位置に挿入すること特徴とする請求項５に記載のクエリ処理方法。
【請求項７】
前記第２データが前記バッファに記憶されたデータと比較して前記第１条件を満たすか、または前記第２データが存在するまで、前記第１属性が同一の前記第２データを順次的に一つずつ抽出して前記バッファを更新することを繰り返すことを特徴とする請求項４から６の何れか一つに記載のクエリ処理方法。
【請求項８】
前記クエリに含まれた第１リストに残っている全ての前記第１属性に対して、前記第２データを抽出すること及びバッファを更新することを繰り返すことを特徴とする請求項７に記載のクエリ処理方法。
【請求項９】
前記バッファを割り当てることは、前記抽出レコード数に基づいて前記第２バッファをさらに割り当てて、前記バッファは、前記レコードを指し示すスキャン情報を記憶するスキャンバッファであり、前記第２バッファは、前記レコードを記憶するローバッファであることを特徴とする請求項１乃至８の何れか一つに記載のクエリ処理方法。
【請求項１０】
前記バッファを更新することは、
前記第２データであるスキャン情報が指し示すレコードと、前記バッファに記憶されたデータであるスキャン情報が指し示すレコードとを比較して第２条件を満たすかを確認し、
前記第２条件を満たす場合、前記第２データが前記バッファに記憶されるように前記バッファを更新し、前記更新されたバッファは前記クエリを満たすことを特徴とする請求項９に記載のクエリ処理方法。
【請求項１１】
前記第２条件は、前記第２データであるスキャン情報が指し示すレコードの前記第２属性が前記バッファに記憶されたデータであるスキャン情報が指し示すレコードの前記第２属性のうち少なくとも何れか一つに先立つ条件であることを特徴とする請求項１０に記載のクエリ処理方法。
【請求項１２】
前記第２データが前記バッファに記憶されるように前記バッファを更新することは、前記バッファがフル状態である場合、前記バッファに記憶されたデータであるスキャン情報が指し示すレコードのうち第２属性が最も古いレコードを指し示すスキャン情報を前記バッファから削除し、
前記第２データを含んで前記バッファ内に記憶されたデータが指し示すレコードの第２属性が最新である順にソートされるように、前記第２データを前記バッファの第２位置に挿入することを特徴とする請求項１１に記載のクエリ処理方法。
【請求項１３】
前記第１データは、前記第１属性を有する最初のレコードを指し示すスキャン情報であることを特徴とする請求項９から１２の何れか一つに記載のクエリ処理方法。
【請求項１４】
前記クエリに含まれた第１リストに残っている全ての第１属性に対して、前記第２データを抽出すること及びバッファを更新することを繰り返すことを特徴とする請求項１２または１３に記載のクエリ処理方法。
【請求項１５】
前記第２データを抽出すること及びバッファを更新することを繰り返して完了した後、前記スキャン部により、前記バッファのソートされたスキャン情報のうち一番目のスキャン情報が指し示すレコードを前記第２バッファの空いている位置のうち先頭に記憶し、
前記スキャン部により、前記スキャン情報を、前記スキャン情報が指し示すレコードが有する第１属性と同一で前記第２属性が最新である順にソートされたレコードのうち次のレコードを指し示すように移動し、
前記スキャン部により、移動された前記スキャン情報を含んで前記バッファに記憶されたデータであるスキャン情報が指し示すレコードの第２属性が最新である順に前記バッファをソートすることを特徴とする請求項１４に記載のクエリ処理方法。
【請求項１６】
前記第２データを抽出すること及びバッファを更新することを繰り返して完了した後に行う前記記憶は、移動すること及びソートすることが、前記第２バッファがフル状態になるまで繰り返されることを特徴とする請求項１５に記載のクエリ処理方法。
【請求項１７】
前記クエリが、前記第１属性及び前記第２属性に基づいてソートされた一つ以上のレコードに対する多重範囲スキャンでのＮソートクエリであるか否かを判断することをさらに含み、前記判断結果がＮソートクエリである場合にのみ、前記バッファを割り当てること、前記バッファを記憶すること、前記第２データを抽出すること及び前記バッファを更新することが実行されることを特徴とする請求項１から１６の何れか一つに記載のクエリ処理方法。
【請求項１８】
前記第１属性はユーザＩＤであり、前記第２属性はタイムスタンプであることを特徴とする請求項１から１７の何れか一つに記載のクエリ処理方法。
【請求項１９】
請求項１から１８の何れか一つに記載の方法の各段階をコンピュータ上で行うためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項２０】
クエリに含まれた抽出レコード数に基づいてバッファを割り当てるバッファ割り当て部と、
前記クエリに含まれた第１リストのうち第１属性に係わる第１データを抽出して前記バッファに記憶し、前記クエリに含まれた第１リストのうち抽出されていない第１属性に係わる第２データを抽出し、前記バッファに記憶されたデータ及び前記第２データを比較することにより、前記クエリを満たすように前記バッファを更新するスキャン部と、を含み、
前記クエリは、第１属性及び第２属性に基づいてソートされた一つ以上のレコードに対する多重範囲スキャンでのＮソートクエリであることを特徴とするクエリ処理装置。
【請求項１】
クエリに含まれた抽出レコード数に基づいてバッファを割り当て、
前記クエリに含まれた第１リストのうち第１属性に係わる第１データを抽出して前記バッファに記憶し、
前記クエリに含まれた前記第１リストのうち抽出されていない前記第１属性に係わる第２データを抽出し、
前記バッファに記憶された前記第１データ及び前記第２データを比較することにより、前記クエリを満たすように前記バッファを更新し、
前記クエリは、前記第１属性及び前記第２属性に基づいて前記ソートされた一つ以上の前記レコードに対する多重範囲スキャンでのＮソートクエリであることを特徴とするクエリ処理方法。
【請求項２】
前記バッファに記憶することは、
前記第１属性が同一の前記レコードを前記抽出レコード数及び前記第１属性に係わる全ての前記レコードの個数のうち小さい数だけ抽出し、
抽出された前記レコードを前記第１データとして前記バッファに記憶すること特徴とする請求項１に記載のクエリ処理方法。
【請求項３】
前記第２データは、抽出された前記第１データが有する前記第１属性とは異なる前記第１属性を有するレコードであることを特徴とする請求項１または２に記載のクエリ処理方法。
【請求項４】
前記バッファを更新することは、
前記第２データを前記バッファに記憶されたデータと比較して第１条件を満たすかを確認し、
前記第２データが前記第１条件を満たす場合、前記第２データが前記バッファに記憶するように前記バッファを更新して、前記更新されたバッファは、前記クエリを満たすことを特徴とする請求項１乃至３の何れか一つに記載のクエリ処理方法。
【請求項５】
前記第１条件は、前記第２データの前記第２属性が前記バッファに記憶されたデータの第２属性のうち少なくとも何れか一つに先立つ条件であることを特徴とする請求項４に記載のクエリ処理方法。
【請求項６】
前記第２データを前記バッファに記憶するように前記バッファを更新することは、
前記バッファがフル状態である場合、前記バッファに記憶された前記第２データのうち前記第２属性が最も古いレコードを前記バッファから削除し、
前記第２データを含んで前記バッファ内に記憶されたデータが、前記第２属性が最新である順にソートされるように、前記第２データを前記バッファの第１位置に挿入すること特徴とする請求項５に記載のクエリ処理方法。
【請求項７】
前記第２データが前記バッファに記憶されたデータと比較して前記第１条件を満たすか、または前記第２データが存在するまで、前記第１属性が同一の前記第２データを順次的に一つずつ抽出して前記バッファを更新することを繰り返すことを特徴とする請求項４から６の何れか一つに記載のクエリ処理方法。
【請求項８】
前記クエリに含まれた第１リストに残っている全ての前記第１属性に対して、前記第２データを抽出すること及びバッファを更新することを繰り返すことを特徴とする請求項７に記載のクエリ処理方法。
【請求項９】
前記バッファを割り当てることは、前記抽出レコード数に基づいて前記第２バッファをさらに割り当てて、前記バッファは、前記レコードを指し示すスキャン情報を記憶するスキャンバッファであり、前記第２バッファは、前記レコードを記憶するローバッファであることを特徴とする請求項１乃至８の何れか一つに記載のクエリ処理方法。
【請求項１０】
前記バッファを更新することは、
前記第２データであるスキャン情報が指し示すレコードと、前記バッファに記憶されたデータであるスキャン情報が指し示すレコードとを比較して第２条件を満たすかを確認し、
前記第２条件を満たす場合、前記第２データが前記バッファに記憶されるように前記バッファを更新し、前記更新されたバッファは前記クエリを満たすことを特徴とする請求項９に記載のクエリ処理方法。
【請求項１１】
前記第２条件は、前記第２データであるスキャン情報が指し示すレコードの前記第２属性が前記バッファに記憶されたデータであるスキャン情報が指し示すレコードの前記第２属性のうち少なくとも何れか一つに先立つ条件であることを特徴とする請求項１０に記載のクエリ処理方法。
【請求項１２】
前記第２データが前記バッファに記憶されるように前記バッファを更新することは、前記バッファがフル状態である場合、前記バッファに記憶されたデータであるスキャン情報が指し示すレコードのうち第２属性が最も古いレコードを指し示すスキャン情報を前記バッファから削除し、
前記第２データを含んで前記バッファ内に記憶されたデータが指し示すレコードの第２属性が最新である順にソートされるように、前記第２データを前記バッファの第２位置に挿入することを特徴とする請求項１１に記載のクエリ処理方法。
【請求項１３】
前記第１データは、前記第１属性を有する最初のレコードを指し示すスキャン情報であることを特徴とする請求項９から１２の何れか一つに記載のクエリ処理方法。
【請求項１４】
前記クエリに含まれた第１リストに残っている全ての第１属性に対して、前記第２データを抽出すること及びバッファを更新することを繰り返すことを特徴とする請求項１２または１３に記載のクエリ処理方法。
【請求項１５】
前記第２データを抽出すること及びバッファを更新することを繰り返して完了した後、前記スキャン部により、前記バッファのソートされたスキャン情報のうち一番目のスキャン情報が指し示すレコードを前記第２バッファの空いている位置のうち先頭に記憶し、
前記スキャン部により、前記スキャン情報を、前記スキャン情報が指し示すレコードが有する第１属性と同一で前記第２属性が最新である順にソートされたレコードのうち次のレコードを指し示すように移動し、
前記スキャン部により、移動された前記スキャン情報を含んで前記バッファに記憶されたデータであるスキャン情報が指し示すレコードの第２属性が最新である順に前記バッファをソートすることを特徴とする請求項１４に記載のクエリ処理方法。
【請求項１６】
前記第２データを抽出すること及びバッファを更新することを繰り返して完了した後に行う前記記憶は、移動すること及びソートすることが、前記第２バッファがフル状態になるまで繰り返されることを特徴とする請求項１５に記載のクエリ処理方法。
【請求項１７】
前記クエリが、前記第１属性及び前記第２属性に基づいてソートされた一つ以上のレコードに対する多重範囲スキャンでのＮソートクエリであるか否かを判断することをさらに含み、前記判断結果がＮソートクエリである場合にのみ、前記バッファを割り当てること、前記バッファを記憶すること、前記第２データを抽出すること及び前記バッファを更新することが実行されることを特徴とする請求項１から１６の何れか一つに記載のクエリ処理方法。
【請求項１８】
前記第１属性はユーザＩＤであり、前記第２属性はタイムスタンプであることを特徴とする請求項１から１７の何れか一つに記載のクエリ処理方法。
【請求項１９】
請求項１から１８の何れか一つに記載の方法の各段階をコンピュータ上で行うためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項２０】
クエリに含まれた抽出レコード数に基づいてバッファを割り当てるバッファ割り当て部と、
前記クエリに含まれた第１リストのうち第１属性に係わる第１データを抽出して前記バッファに記憶し、前記クエリに含まれた第１リストのうち抽出されていない第１属性に係わる第２データを抽出し、前記バッファに記憶されたデータ及び前記第２データを比較することにより、前記クエリを満たすように前記バッファを更新するスキャン部と、を含み、
前記クエリは、第１属性及び第２属性に基づいてソートされた一つ以上のレコードに対する多重範囲スキャンでのＮソートクエリであることを特徴とするクエリ処理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７ａ】
【図７ｂ】
【図７ｃ】
【図７ｄ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７ａ】
【図７ｂ】
【図７ｃ】
【図７ｄ】
【公開番号】特開２０１２−２５６３１８（Ｐ２０１２−２５６３１８Ａ）
【公開日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【出願番号】特願２０１２−９２６６８（Ｐ２０１２−９２６６８）
【出願日】平成２４年４月１６日（２０１２．４．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＡＣＥＢＯＯＫ
２．ＴＷＩＴＴＥＲ
【出願人】（５０５２０５８１２）エヌエイチエヌ コーポレーション (408)
【公開日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【出願日】平成２４年４月１６日（２０１２．４．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＡＣＥＢＯＯＫ
２．ＴＷＩＴＴＥＲ
【出願人】（５０５２０５８１２）エヌエイチエヌ コーポレーション (408)
[ Back to top ]