JP2015176276A - データ処理装置及びデータ処理方法 - Google Patents

Abstract

【課題】パーティションの運用において管理にかかるユーザの負荷を軽減するデータ処理装置を得ること。【解決手段】複数のパーティションから構成されるデータベースのパーティションに時系列データをその時間に応じて振り分けるデータ振り分け条件を保持するパーティション運用手順記憶部と、新たな時系列データがデータ振り分け条件に該当せず、時系列データを保存するパーティションが存在しない場合、データベースに新たなパーティションを作成するように指示するとともに、時系列データに対応するデータ振り分け条件をパーティション運用手順記憶部に追加するパーティション管理判定部と、を備えた。【選択図】 図１

Description

本発明は、データベースシステムにおけるテーブルパーティションの運用自動化と、それらをデータ種別ごとに管理するための実現方式に関する。

ログやセンサデータなど、時系列で蓄積され続けるデータ（以下、時系列データと称す）は、データの発生周期と蓄積期間によっては大規模なデータとなる。このような大規模なデータをデータベースシステムで管理する場合、１個のテーブルではなく、複数のテーブルに分散させることにより、データの登録、削除、及び検索等の応答性能を向上させるのが一般的である（下記非特許文献１参照）。なお、データベースにおいて、データを複数のテーブルに分散させることをテーブルパーティションと呼ぶ。

このとき、１個の親テーブルに属する複数の子テーブルが存在することになるため、これらの子テーブルを適切に運用管理する必要がある。このような課題に対して、親テーブルごとに子テーブルの命名規則と蓄積対象とする時間軸の範囲、および、属する子テーブルの個数を設定することにより、子テーブルの運用管理を自動化する技術がある（参考文献２）。また、例えばＰｏｓｔｇｒｅＳＱＬやＯｒａｃｌｅなどのデータベースシステムが備えるトリガおよびトリガ関数といった機能によっても、課題を解決できる。

ｈｔｔｐ：／／ｌｅｔｓ．ｐｏｓｔｇｒｅｓｑｌ．ｊｐ／ｄｏｃｕｍｅｎｔｓ／ｔｅｃｈｎｉｃａｌ／ｐａｒｔｉｔｉｏｎｉｎｇ／１

特開２００３−６００７号公報

しかしながら、非特許文献１及び特許文献１では、親テーブルの単位で子テーブルを設定するため、親テーブル数の増加に伴って子テーブルの設定が増加する。また、非特許文献１では、テーブルパーティションの運用管理の手順を詳細に設定することが可能である反面、複雑である。したがって、非特許文献１及び特許文献１では、パーティションの運用において管理にかかるユーザの負荷が大きいという問題点があった。

本発明は上記のような問題点を解決するためになされたもので、パーティションの運用において管理にかかるユーザの負荷を軽減するデータ処理装置を得ることを目的としている。

複数のパーティションから構成されるデータベースのパーティションに時系列データをその時間に応じて振り分けるデータ振り分け条件を保持するパーティション運用手順記憶部と、新たな時系列データがデータ振り分け条件に該当せず、時系列データを保存するパーティションが存在しない場合、データベースに新たなパーティションを作成するように指示するとともに、時系列データに対応するデータ振り分け条件をパーティション運用手順記憶部に追加するパーティション管理判定部と、を備えた。

本発明によれば、パーティションの運用において管理にかかるユーザの負荷を軽減することができる。

実施の形態１に係るデータ処理装置の構成を示すブロック図。 実施の形態１に係るパーティション管理判定部の処理の流れを示すフローチャート。 実施の形態１に係るサービス定義情報記憶部が保持するサービス定義情報を示す図。 実施の形態１に係るパーティション運用記憶部が保持するパーティション運用手順の定義情報を示す図。 実施の形態２に係るパーティション管理判定部の処理の流れを示すフローチャート。 実施の形態１に係るパーティション運用記憶部が保持するパーティション運用手順の定義情報を示す図。

実施の形態１．
データベースとして著名なＰｏｓｔｇｒｅＳＱＬやＯｒａｃｌｅなどは、外部アプリケーションからのデータ登録または検索に関するリクエストを、ＳＱＬ文で受け取って実行するのが一般的である。ＳＱＬ文の作成は煩雑である一方で、同じ目的のＳＱＬ文は共通する部分が多い。本発明のデータ処理装置は、アプリケーションに対してデータベースへの入出力機能を提供するものである。アプリケーションは、本発明のデータ処理装置により、ＳＱＬ文を意識せずにデータベースへアクセスすることが可能となる。本実施の形態は、アプリケーションから時系列データを登録するときの、パーティションの運用に関するものである。また、分散されたデータを保存するテーブルをパーティションと呼ぶ。

図１は、実施の形態１に係るデータ処理装置１１の構成を示すブロック図である。データ処理装置１１は、リクエスト解析部１２、サービス定義情報記憶部１３、パーティション管理判定部１４、パーティション運用手順記憶部１５、クエリ発行部１６、クエリ実行部１７、結果取得部１８、及びレスポンス発行部１９により構成される。

リクエスト解析部１２は、アプリケーションからデータ登録のリクエストを受け取ると、リクエストに基づいて対応するサービス定義情報をサービス定義情報記憶部１３から取得する。リクエスト解析部１２は、取得したサービス定義情報をパーティション管理判定部１４に出力する。次に、パーティション管理判定部１４は、パーティション運用手順の定義情報を、パーティション運用手順記憶部１５から取得する。パーティション運用手順の定義情報は、サービスごとに定義されたパーティションの運用に関する手順の定義情報である。

パーティション管理判定部１４は、パーティション運用手順の定義情報とリクエスト解析部１２から入力されたサービス定義情報を比較する。パーティション管理判定部１４は、条件によってパーティション運用処理を追加する。また、パーティション管理判定部１４は条件によってクエリ文を変更し、クエリ文をクエリ発行部１６に出力する。クエリ発行部１６はクエリ文をクエリ実行部１７に出力する。クエリ実行部１７はデータベース２０に対してクエリを実行する。結果取得部１８は、データベース２０より結果を取得し、レスポンス発行部１９に出力する。レスポンス発行部１９は、アプリケーションに結果を出力する。

図２は、実施の形態１に係るパーティション管理判定部１４の処理の流れを示すフローチャートである。
図３は、実施の形態１に係るサービス定義情報記憶部１３が保持するサービス定義情報３１を示す図である。サービス定義情報３１ａは、サービス名がデータ登録サービスである。サービス定義情報３１ａのパラメータ、及びクエリ文はあらかじめユーザが登録する。

図４は、実施の形態１に係るパーティション運用記憶部１５が保持するパーティション運用手順の定義情報４１を示す図である。パーティション運用手順の定義情報４１ａは、サービス名がデータ登録サービスである。パーティション運用手順の定義情報４１ａのクエリタイプ、パーティションキー、パーティション運用条件、パーティション運用処理、データ振り分け条件、及びデータ振り分け処理はあらかじめユーザが登録する。

次に、パーティション管理判定部１４の動作について説明する。
図２において、パーティション管理判定部１４は、リクエスト解析部１２からサービス定義情報が入力されると処理を開始する。パーティション管理判定部１４は、パーティション運用手順記憶部１５からパーティション運用手順の定義情報を取得する（Ｓ２１）。パーティション管理判定部１４は、パーティション運用手順の定義情報の検索には、リクエスト解析部１２から入力されたサービス定義情報のサービス名をキーとして利用する。サービス名は、データベース２０へのアクセスを要求するリクエストの内容を示すものである。リクエスト解析部１２から入力されたサービス定義情報を３１ａ、取得したパーティション運用手順の定義情報を４１ａとして、説明する。

次に、パーティション管理判定部１４は、パーティション運用手順の定義情報４１ａのクエリタイプが、サービス定義情報３１ａのクエリ文に含まれるクエリの種類と一致するか判定する（Ｓ２２）。

クエリの種類が一致する場合、パーティション管理判定部１４は、パーティション運用手順の定義情報４１ａのデータ振り分け条件を参照し、いずれかのデータ振り分け条件に一致するかを判定する（Ｓ２３）。

一致するデータ振り分け条件が存在する場合、パーティション管理判定部１４は、対応するデータ振り分け処理に記載されている内容を実行する（Ｓ２４）。データ振り分け処理には、サービス定義情報３１ａのクエリ文に対する処理が記述されている。パーティション管理判定部１４は、変更したクエリ文をクエリ発行部１６へ出力する。

一致するデータ振り分け条件が存在しない場合、パーティション管理判定部１４は、パーティション運用手順の定義情報４１ａを参照し、パーティション運用条件に一致するか判定する（Ｓ２５）。

パーティション運用条件に一致する場合、パーティション管理判定部１４は、パーティション運用処理をサービス定義情報３１ａのクエリ文の前に追加する（Ｓ２６）。パーティション運用処理をクエリ文の前に追加することにより、パーティションを最新の状態にしてからクエリ文を実行することができる。

このように、データ振り分け条件とデータ振り分け処理を月単位で記述することにより、月単位でのパーティション運用を実現することができる。同様にして、年単位や日単位、週単位などのパーティション運用も実現することができる。

Ｓ２２において、クエリの種類が一致しない場合、パーティション管理判定部１４は、サービス定義情報３１ａに含まれるクエリ文を、クエリ発行部１６に出力し、処理を終了する。Ｓ２５において、運用条件と一致しない場合についても同様である。

パーティション管理判定部１４が処理を終了すると、クエリ発行部１６は、パラメータ値を設定し、クエリ実行部１７へ出力する。パラメータ値は、アプリケーションからのリクエストに含まれているものとする。クエリ実行部１７は、入力されたクエリを実行し、データベース２０にアクセスする。結果取得部１８はデータベース２０からクエリ実行結果を受け取り、レスポンス発行部１９に出力する。レスポンス発行部１９は、クエリ実行結果をもとにアプリケーション向けの応答を作成し、出力する。

パーティション運用手順の定義情報４１ａの詳細について説明する。
クエリタイプｉｎｓｅｒｔは、データの登録を示す。パーティションキーＩｎｓｅｒｔＴｉｍｅは、テーブルパーティションを日時の単位で行うことを示す。ＩｎｓｅｒｔＴｉｍｅは、Ｔｉｍｅｓｔａｍｐ型の一種である。Ｔｉｍｅｓｔａｍｐ型は、日時を表すデータ型である。

ｌａｔｅｓｔｙｅａｒ＿ｏｆ＿ｔａｂｌｅｓは、データベース２０の最新のデータ登録用テーブルを対象とし、指定された条件を満たすパーティションキーの年の値を返す関数である。ｙｅａｒは、引数の年の値を返す関数である。ｌａｔｅｓｔｍｏｎｔｈ＿ｏｆ＿ｔａｂｌｅｓは、データベース２０の最新のデータ登録用テーブルを対象とし、指定された条件を満たすパーティションキーの月の値を返す関数である。ｍｏｎｔｈは、引数の月の値を返す関数である。

ｃｒｅａｔｅ＿ｌａｔｅｓｔ＿ｐａｒｔｉｔｉｏｎは、現在の日時情報に基づいてデータベース２０に新規にパーティションを生成する関数である。ｄｒｏｐ＿ｏｌｄｅｓｔ＿ｐａｒｔｉｔｉｏｎは、データベース２０から最も古いパーティションを削除する関数である。ｕｐｄａｔｅ＿ｔａｂｌｅｎａｍｅｓ＿ｐａｒｔｃｏｎｄｉｔｉｏｎは、データ振り分け条件及びデータ振り分け処理の更新を行う関数である。当該関数は、ｃｒｅａｔｅ＿ｌａｔｅｓｔ＿ｐａｒｔｉｔｉｏｎによって生成された新規のパーティションに対応するデータ振り分け条件及びデータ振り分け処理を追加する。また、当該関数は、ｄｒｏｐ＿ｏｌｄｅｓｔ＿ｐａｒｔｉｔｉｏｎによって削除されたパーティションに対応するデータ振り分け条件及びデータ振り分け処理を削除する。ａｄｄｓｔｒ＿ｉｎｓｅｒｔ＿ｔａｂｌｅｎａｍｅは、サービス定義情報３１ａのクエリ文のテーブル名に引数の文字列を追加する関数である。

データ振り分け条件が「ＩｎｓｅｒｔＴｉｍｅ ＞＝ ‘２０１４０１０１’ ａｎｄ ＩｎｓｅｒｔＴｉｍｅ ＜＝ ‘２０１４０１３１’」で、データ振り分け処理が「ａｄｄｓｔｒ ｉｎｓｅｒｔ ｔａｂｌｅｎａｍｅ（‘−２０１４０１’）；」の場合は、２０１４年１月の場合に当該処理を実行することを示している。データ振り分け条件が「ＩｎｓｅｒｔＴｉｍｅ ＞＝ ‘２０１４０２０１’ ａｎｄ ＩｎｓｅｒｔＴｉｍｅ ＜＝ ‘２０１４０２２８’」で、データ振り分け処理が「ａｄｄｓｔｒ ｉｎｓｅｒｔ ｔａｂｌｅｎａｍｅ（‘−２０１４０２’）；」の場合は、２０１４年２月の場合に当該処理を実行することを示している。

パーティション運用手順の定義情報４１ａのパーティション運用処理、パーティション運用条件、及びデータ振り分け処理に記述している関数はパーティション管理判定部１４が保持している関数の一例である。パーティション管理判定部１４がこのような関数を実装しておくことにより、処理を共通化することができる。パーティション運用にかかるコストを削減することもできる。

例えば、データベース２０のデータ登録用テーブルに２０１３年１２月までのデータが登録されていたとする。このとき、アプリケーションからのリクエストのクエリタイプがｉｎｓｅｒｔで、２０１４年１月のデータの場合、パーティション運用手順の定義情報４１ａのパーティション運用条件の「ｌａｔｅｓｔｙｅａｒ＿ｏｆ＿ｔａｂｌｅｓ（）＜ｙｅａｒ（ＩｎｓｅｒｔＴｉｍｅ）」が真となり、パーティション管理判定部１４はパーティション運用処理を追加する。追加する処理は、２０１４年１月のパーティションを生成する処理、最も古いパーティションを削除する処理、削除するパーティションに対応するデータ振り分け条件及びデータ振り分け処理をパーティション運用手順の定義情報４１ａから削除する処理、並びに追加するパーティションに対応するデータ振り分け条件及びデータ振り分け処理をパーティション運用手順の定義情報４１ａへ追加する処理である。

したがって、本実施の形態では、複数のパーティションから構成されるデータベースのパーティションに時系列データをその時間に応じて振り分けるデータ振り分け条件を保持するパーティション運用手順記憶部と、新たな時系列データがデータ振り分け条件に該当せず、時系列データを保存するパーティションが存在しない場合、データベースに新たなパーティションを作成するように指示するとともに、時系列データに対応するデータ振り分け条件をパーティション運用手順記憶部に追加するパーティション管理判定部とを備えたので、パーティションの運用において管理にかかるユーザの負荷を軽減することができる。また、管理にかかるコストも低減できる。

また、パーティション運用手順記憶部は、パーティションに対するパーティション運用処理と、パーティション運用処理を実行するパーティション運用条件とを対応付けたパーティション運用手順の定義情報を保持し、パーティション管理判定部は、データベースへのアクセスを要求するリクエストに対応するパーティション運用手順の定義情報のパーティション運用条件が真の場合、パーティション運用処理を実行するように指示するとともに、パーティション運用処理を実行した後に、リクエストに応じたデータの処理であるクエリをデータベースに対して実行するクエリ実行部を備えたので、パーティションの運用手順を個別に設定する必要がない。

実施の形態２．
以上の実施の形態１では、データ１件単位でパーティション運用の条件判定をするようにしたものであるが、本実施の形態においては、複数件のデータをまとめて処理する実施の形態を示す。例えば、アプリケーションからの１回のリクエストで２０１４年１月のデータを複数登録する場合である。複数件のデータについてまとめてパーティション運用の条件判定を実施することにより処理を効率化できる。
なお、本実施の形態においては、データ処理装置１１の構成は、図１と同じである。

パーティション管理判定部１４の動作について説明する。
図５は、実施の形態２に係るパーティション管理判定部１４の処理の流れを示すフローチャートである。Ｓ５０１は、図２のＳ２１と同様のため、説明を割愛する。

Ｓ５０２において、パーティション管理判定部１４は、リクエスト解析部１２から入力されたリクエストに含まれる複数件のデータから１件ずつ順番に取得する（Ｓ５０２）。

パーティション管理判定部１４は、Ｓ５０２で取得したデータに対してクエリの種類が一致するかを判定する（Ｓ５０３）。一致するクエリの種類が存在する場合、パーティション管理判定部１４は、Ｓ５０２で取得したデータに対してデータ振り分け条件のいずれかに一致するかについて判定する（Ｓ５０４）。一致するデータ振り分け条件が存在する場合、パーティション管理判定部１４は、データ振り分け条件に対応するデータ振り分け処理に記載されている内容を実行する（Ｓ５０５）。

Ｓ５０３において、一致するクエリの種類が存在しない場合、処理はＳ５０２へ進む。

Ｓ５０４において、一致するデータ振り分け条件が存在しない場合、パーティション管理判定部１４は、Ｓ５０２で取得したデータに対して、対応する運用条件と一致するかについて判定する（Ｓ５０６）。運用条件と一致する場合、パーティション管理判定部１４は、対応するパーティション運用処理を実行する（Ｓ５０７）。

Ｓ５０６において、運用条件に一致しない場合、処理はＳ５０２へ進む。

パーティション管理判定部１４は、リクエストに含まれる複数件の全てのデータに対してＳ５０３〜Ｓ５０７の処理を実行しているかを判定する（Ｓ５０８）。全てのデータを処理している場合、処理はＳ５０９へ進む。全てのデータを処理していない場合、処理はＳ５０２へ進む。

パーティション管理判定部１４は、サービス定義情報３１のクエリ文が最小となるように、複数のデータについて同一の処理をまとめる。例えば、クエリタイプが”ｉｎｓｅｒｔ”の場合、同一のパーティションに対してデータを登録するクエリ文は、”ｉｎｓｅｒｔ ｉｎｔｏ ｔａｂｌｅ＿Ａ−２０１３０４ ｖａｌｕｅｓ（ ），ｖａｌｕｅｓ（・・・），・・・”というように１個のクエリ文にする（Ｓ５０９）。

パーティション管理判定部１４は、パーティション運用手順の定義情報４１ａを参照し、パーティション運用条件に一致するか判定する（Ｓ５１０）。

パーティション運用条件に一致する場合、パーティション管理判定部１４は、パーティション運用処理をサービス定義情報３１ａのクエリ文の前に追加する（Ｓ５１１）。

Ｓ５１０において、パーティション運用条件に一致しない場合、処理は終了する。

パーティション管理判定部１４は処理を終了すると、クエリ文をクエリ発行部１６に出力する。以降の処理は、実施の形態１と同様である。

したがって、パーティション管理判定部は、リクエストに複数のデータに対する処理が含まれている場合、すべてのデータについてデータ振り分け条件を判定し、データ振り分け条件が真ならばデータ振り分け処理を実行するので、ユーザは効率的にパーティションの運用をすることができる。

実施の形態３．
以上の実施の形態２では、複数件のデータをまとめて処理するようにしたものであるが、本実施の形態においては、テーブルの残ディスク容量に基づいてパーティション運用処理を実行する実施の形態を示す。

本実施の形態においては、データ処理装置１１の構成は、図１と同じである。なお、テーブルと物理ディスクまたは論理ディスクが１対１に対応づく構成とする。
また、パーティション管理判定部１４の動作は、図２と同じである。

図６は、実施の形態３に係るパーティション運用記憶部１５が保持するパーティション運用手順の定義情報４１を示す図である。パーティション運用手順の定義情報４２ａは、サービス名がデータ登録サービスである。パーティション運用手順の定義情報４２ａのクエリタイプ、パーティションキー、パーティション運用条件、パーティション運用処理、データ振り分け条件、及びデータ振り分け処理はあらかじめユーザが登録する。
パーティションキーは「＊（アスタリスク）」であり、全データを対象とする。データ振り分け条件は「ｒｅｓｔ（ｄｉｓｋ００１）＞１００［ＧＢ］」である。データ振り分け処理は「ａｄｄｓｔｒ＿ｉｎｓｅｒｔ＿ｔａｂｌｅｎａｍｅ（‘＿ｄｉｓｋ００１’）」である。また、パーティション運用条件は「ｒｅｓｔ（ｇｅｔ＿ｄｉｓｋ＿ｎａｍｅ＿ｏｆ＿ｍａｘ（））＜１００［ＧＢ］」である。パーティション運用処理は「ｃｒｅａｔｅ＿ｎｅｗ＿ｐａｒｔｉｔｉｏｎ（），ｄｒｏｐ＿ｏｌｄｅｓｔ＿ｐａｒｔｉｔｉｏｎ（）」である。

ｒｅｓｔは全ディスク容量を参照する関数である。ｇｅｔ＿ｄｉｓｋ＿ｎａｍｅ＿ｏｆ＿ｍａｘは残ディスク容量が最大のディスク名を取得する関数である。ｃｒｅａｔｅ＿ｎｅｗ＿ｐａｒｔｉｔｉｏｎは未使用のディスク領域に新規パーティションを割り当てる関数である。ｄｒｏｐ＿ｏｌｄｅｓｔ＿ｐａｒｔｉｔｉｏｎは最も古いデータの集合であるパーティションを削除する関数である。これらの関数は、それぞれユーザが定義する。なお、

全ディスク容量が１００ＧＢより大きい場合、パーティション管理判定部１４はデータ振り分け処理を実行する。全ディスク容量が１００ＧＢ以下で、残ディスク容量が最大のディスクの容量が１００ＧＢより少ない場合、パーティション管理判定部１４は、未使用のディスク領域に新規パーティションを割り当て、最も古いデータの集合であるパーティションを削除する。

したがって、パーティション管理判定部は、データベースの残ディスク容量に応じてデータ振り分け処理とパーティション運用処理とを実行するので、ユーザが残ディスク容量を管理する必要がない。よって、パーティションの運用において管理にかかるユーザの負荷を軽減することができる。

１１ データ処理装置
１２ リクエスト解析部
１３ サービス定義情報記憶部
１４ パーティション管理判定部
１５ パーティション運用手順記憶部
１６ クエリ発行部
１７ クエリ実行部
１８ 結果取得部
１９ レスポンス発行部
２０ データベース
３１、３１ａ サービス定義情報
４１、４１ａ、４２ａ パーティション運用手順の定義情報

Claims (9)

1. 複数のパーティションから構成されるデータベースの前記パーティションに時系列データをその時間に応じて振り分けるデータ振り分け条件を保持するパーティション運用手順記憶部と、
   新たな時系列データが前記データ振り分け条件に該当せず、前記時系列データを保存するパーティションが存在しない場合、前記データベースに新たなパーティションを作成するように指示するとともに、前記時系列データに対応するデータ振り分け条件を前記パーティション運用手順記憶部に追加するパーティション管理判定部と、
   を備えることを特徴とするデータ処理装置。
2. 前記パーティション運用手順記憶部は、前記パーティションに対するパーティション運用処理と、前記パーティション運用処理を実行するパーティション運用条件とを対応付けたパーティション運用手順の定義情報を保持し、
   前記パーティション管理判定部は、前記データベースへのアクセスを要求するリクエストに対応するパーティション運用手順の定義情報のパーティション運用条件が真の場合、前記パーティション運用処理を実行するように指示するとともに、
   前記パーティション運用処理を実行した後に、前記リクエストに応じたデータの処理であるクエリを前記データベースに対して実行するクエリ実行部を備えることを特徴とする請求項１に記載のデータ処理装置。
3. 前記パーティション運用手順記憶部は、前記データ振り分け条件と、前記データ振り分け条件に該当する場合にクエリの実行文を変更するデータ振り分け処理とを、パーティション運用手順の定義情報にさらに対応付け、
   前記パーティション管理判定部は、前記データ振り分け条件が真の場合、前記クエリの実行文を変更するデータ振り分け処理を実行し、
   前記クエリ実行部は、変更された前記クエリを実行することを特徴とする請求項２に記載のデータ処理装置。
4. 前記パーティション管理判定部は、複数のパーティションに対応したデータ振り分け条件とデータ振り分け処理とを設けることを特徴とする請求項３に記載のデータ処理装置。
5. 前記パーティション管理判定部は、前記リクエストに複数のデータに対する処理が含まれている場合、すべてのデータについてデータ振り分け条件を判定し、データ振り分け条件が真ならばデータ振り分け処理を実行することを特徴とする請求項３又は４に記載のデータ処理装置。
6. 前記パーティション管理判定部は、前記データベースの同一のパーティションに対する前記クエリ文が複数ある場合、複数の前記クエリ文をまとめることを特徴とする請求項５に記載のデータ処理装置。
7. 前記パーティション管理判定部は、前記データベースの残ディスク容量に応じてデータ振り分け処理とパーティション運用処理とを実行することを特徴とする請求項３又は４に記載のデータ処理装置。
8. 前記リクエストの種類とクエリとを対応付けたサービス定義情報を保持するサービス定義情報記憶部と、
   前記リクエストを受信するとその種類に対応するサービス定義情報を前記サービス定義情報記憶部から取得し、出力するリクエスト解析部と、
   前記データベースから前記クエリに対する結果を取得し、出力する結果取得部と、
   前記結果取得部から入力される結果より前記リクエストに対するレスポンスを生成し、出力するレスポンス発行部と、
   を備え、
   前記パーティション管理判定部は、前記リクエスト解析部から入力された前記サービス定義情報のクエリの種類に対応するパーティション運用手順の定義情報を前記パーティション運用手順記憶部から取得する請求項１から５のいずれか一項に記載のデータ処理装置。
9. 複数のパーティションから構成されるデータベースの前記パーティションに時系列データをその時間に応じて振り分けるデータ振り分け条件を保持するパーティション運用手順記憶ステップと、
   新たな時系列データが前記データ振り分け条件に該当せず、前記時系列データを保存するパーティションが存在しない場合、前記データベースに新たなパーティションを作成するように指示するとともに、前記時系列データに対応するデータ振り分け条件を前記パーティション運用手順記憶部に追加するパーティション管理判定ステップと、
   を有するデータ処理方法。

Images