特許 6550448 データ管理装置、データ管理方法、およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6550448

(24)【登録日】2019年7月5日

(45)【発行日】2019年7月24日

(54)【発明の名称】データ管理装置、データ管理方法、およびプログラム

(51)【国際特許分類】

   G06F 16/13 20190101AFI20190711BHJP

   G06F 16/22 20190101ALI20190711BHJP

【ＦＩ】

   G06F16/13 200

   G06F16/22

【請求項の数】10

【全頁数】15

(21)【出願番号】特願2017-242030(P2017-242030)

(22)【出願日】2017年12月18日

(65)【公開番号】特開2019-109693(P2019-109693A)

(43)【公開日】2019年7月4日

【審査請求日】2018年10月10日

【新規性喪失の例外の表示】特許法第３０条第２項適用 平成２９年７月３日”ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｙａｈｏｏｊａｐａｎ／ｍｕｌｔｉｐｌｅ−ｄｉｍｅｎｓｉｏｎ−ｓｐｒｅａｄ／ｃｏｍｍｉｔｓ／ｍａｓｔｅｒ？ａｆｔｅｒ＝４ｃ９６ｅ０４９３５５６５３９ｃ２８ａｅ９２ａ９ｆｆｆａｂｃ８ａ３０ｆ２１４５４＋６９”

【早期審査対象出願】

(73)【特許権者】

【識別番号】500257300

【氏名又は名称】ヤフー株式会社

(74)【代理人】

【識別番号】100106909

【弁理士】

【氏名又は名称】棚井 澄雄

(74)【代理人】

【識別番号】100149548

【弁理士】

【氏名又は名称】松沼 泰史

(74)【代理人】

【識別番号】100154852

【弁理士】

【氏名又は名称】酒井 太一

(74)【代理人】

【識別番号】100174986

【弁理士】

【氏名又は名称】林 康旨

(72)【発明者】

【氏名】鈴木 周一

(72)【発明者】

【氏名】山田 洸二

【審査官】 田名網 忠雄

(56)【参考文献】

【文献】 特開２０１６−０９９６４７（ＪＰ，Ａ）

【文献】 特開２０１７−１６７９１７（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００５／００５００９２（ＵＳ，Ａ１）

【文献】 特表２０１６−５１９８１０（ＪＰ，Ａ）

【文献】 特開２００８−２４３１９３（ＪＰ，Ａ）

【文献】 加藤 慶信 外４名，軽い！速い！ ビッグデータ 分析システムの作り方，日経ＳＹＳＴＥＭＳ，日本，日経ＢＰ社 Nikkei Business Publications,Inc.，２０１３年 ９月２６日，第246号／2013年10月号，p.42-p.59

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １６／００−１６／９５８

(57)【特許請求の範囲】

【請求項1】

データの提供元に対応するデータフォーマットで作成された複数のレコードであって、データ項目とデータ本体とが対応付けられた複数のレコードをそれぞれ解釈し、一つの共通形式のレコードに変換する解釈部と、
前記データ項目ごとに、前記データ本体と前記共通形式のレコードを特定可能なインデックス情報とを対応付けたデータセットを、カラムデータとして記憶部に記憶させる変換部と、を備え、
前記解釈部により変換される共通形式のレコードは、前記カラムデータに対応するデータ項目のうち一部を含まない場合があり、
前記変換部は、あるデータ項目について、前記インデックス情報が列方向に連続しない場合でも、前記連続しないインデックス情報をそれぞれ含む二つのデータセットの間に空の記憶領域を設けない、
データ管理装置。

【請求項2】

前記変換部は、前記解釈部により変換された共通形式のレコードに含まれるデータ項目が、前記カラムデータに対応していない場合、新たなデータ項目に対応するカラムデータを設定する、
請求項１記載のデータ管理装置。

【請求項3】

前記変換部は、前記解釈部により変換された共通形式のレコードが階層構造を含む場合、前記階層構造における下位の階層のレコードから作成された前記データセットをカラムデータとして前記記憶部に格納し、前記下位の階層のレコードに対して上位の階層のレコードから作成された前記データセットに、前記下位の階層のレコードから作成された前記データセットの格納場所を示す情報を埋め込んでカラムデータとして前記記憶部に記憶させる、
請求項１または２記載のデータ管理装置。

【請求項4】

前記変換部は、それぞれが互いに異なる数値型のデータ形式で定義された同じデータ項目に対応する二以上のカラムデータに関して、所望のタイミングで前記数値型のうち桁の多い方のデータ形式に揃えて一つのカラムデータを再構成する、
請求項１から３のうちいずれか１項記載のデータ管理装置。

【請求項5】

少なくとも前記カラムデータに含まれるデータ本体を、入力されたデータ要求に含まれるデータ項目ごとに前記記憶部から読み出して出力するデータ利用者インターフェースを更に備える、
請求項１から４のうちいずれか１項記載のデータ管理装置。

【請求項6】

前記データ利用者インターフェースは、指定されたデータ項目を含まないレコードに関しては、当該データ項目に対応するデータを、該当するデータが存在しないことを示す任意の形態のデータで埋める、
請求項５記載のデータ管理装置。

【請求項7】

前記データ利用者インターフェースは、指定されたデータ項目が、前記カラムデータとして設定されていないデータ項目である場合、当該データ項目についてのデータを全て、該当するデータが存在しないことを示す任意の形態のデータで埋める、
請求項５または６記載のデータ管理装置。

【請求項8】

前記データ利用者インターフェースは、所定のデータ項目におけるデータ本体が設定条件を満たすレコードを特定可能な情報を前記記憶部から読み出す要求を受け付け、前記所定のデータ項目のカラムデータに含まれるデータセットのデータ本体を順に検索し、データ本体が設定条件を満たすレコードを特定可能な情報を出力する、
請求項５から７のうちいずれか１項記載のデータ管理装置。

【請求項9】

コンピュータが、
データの提供元に対応するデータフォーマットで作成された複数のレコードであって、データ項目とデータ本体とが対応付けられた複数のレコードをそれぞれ解釈し、一つの共通形式のレコードに変換し、
前記データ項目ごとに、前記データ本体と前記共通形式のレコードを特定可能なインデックス情報とを対応付けたデータセットを、カラムデータとして記憶部に記憶させ、
前記変換される共通形式のレコードは、前記カラムデータに対応するデータ項目のうち一部を含まない場合があり、
前記コンピュータは、
あるデータ項目について、前記インデックス情報が列方向に連続しない場合でも、前記連続しないインデックス情報をそれぞれ含む二つのデータセットの間に空の記憶領域を設けない、
データ管理方法。

【請求項10】

コンピュータに、
データの提供元に対応するデータフォーマットで作成された複数のレコードであって、データ項目とデータ本体とが対応付けられた複数のレコードをそれぞれ解釈し、一つの共通形式のレコードに変換させ、
前記データ項目ごとに、前記データ本体と前記共通形式のレコードを特定可能なインデックス情報とを対応付けたデータセットを、カラムデータとして記憶部に記憶させる処理を行わせ、
前記変換される共通形式のレコードは、前記カラムデータに対応するデータ項目のうち一部を含まない場合があり、
前記コンピュータに、
あるデータ項目について、前記インデックス情報が列方向に連続しない場合でも、前記連続しないインデックス情報をそれぞれ含む二つのデータセットの間に空の記憶領域を設けさせない、
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データ管理装置、データ管理方法、およびプログラムに関する。

【背景技術】

【0002】

従来、中国、日本、および韓国の言語のための名前を検出する方法が知られている（特許文献１参照）。この方法では、構造化されたデータを扱っている。

【0003】

ところで、データベースにおけるデータ構造には、行指向型のデータ構造と列指向型のデータ構造がある。行指向型のデータ構造とは、ひとつのレコードを、ひとまとまりの論理構造として保持するデータ構造である。これに対し、列指向型のデータ構造が知られている。列指向型のデータ構造とは、同じインデックス（ユーザの属性データであれば、名前、年齢、性別といったもの）に対応するデータを、ひとまとまりの論理構造として保持するデータ構造である。論理構造とは、データを検索する際に使用される、キー、ＬＢＡ（Logical Block Addressing）、論物変換テーブル上のラベル、その他の論理的な情報をいう。行指向型のデータ構造は、データの追加や削除などが容易であるのに対し、列指向型のデータ構造は、インデックスごとの統計処理に向いているといった違いがある。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１３−１０９３６４号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

ここで、行指向型のデータ構造を扱うＪＳＯＮなどの機能では、データのツリー構造を自動生成することができるが、ネットワーク、記憶装置、ソフトウェア処理の面でコストが大きい。特に、列指向型のデータ構造を有するデータベースから統計処理のためのデータを読み出す際の処理時間は長くなってしまう。

【0006】

一方、列指向型のデータ構造でデータを格納した場合、採用され得る全てのインデックスの管理と、データの追加や削除などが困難である。特に、Ｓｔｒｅａｍ形式でデータが入力される場合、レコードごとにデータを処理することが想定されるが、レコードごとの処理から直接的に列指向型に書き込むことはできない。また、列指向型においては、書き込み失敗時の管理や重複排除を行う有効な方法が開発されていない。

【0007】

本発明は、このような事情を考慮してなされたものであり、非構造的な入力データについて列志向型としての利用を可能にしつつ、入力レコードの特定も容易に行うことができるデータ管理装置、データ管理方法、およびプログラムを提供することを目的の一つとする。

【課題を解決するための手段】

【0008】

本発明の一態様は、入力されたレコードを解釈し、データ項目とデータ本体との対応関係が認識可能な抽象表現に変換する解釈部と、前記データ項目ごとに、前記データ本体と前記レコードを特定可能なインデックス情報とを対応付けたデータセットを、カラムデータとして記憶部に記憶させる変換部と、を備えるデータ管理装置である。

【発明の効果】

【0009】

本発明の一態様によれば、非構造的な入力データについて列志向型としての利用を可能にしつつ、入力レコードの特定も容易に行うことことができる。

【図面の簡単な説明】

【0010】

【図1】jsonフォーマットによるログの一例を示す図である。

【図2】図１のログを木構造で表現した図である。

【図3】jsonフォーマットによるログの他の一例を示す図である。

【図4】図３のログを木構造で表現した図である。

【図5】カラムナーファイルのデータを木構造で表現した図である。

【図6】データ管理装置の一例であるデータベースサーバ１００の使用環境と構成の一例を示す図である。

【図7】解釈部１１２の機能について説明するための図である。

【図8】変換部１１４の機能について説明するための図（その１）である。

【図9】変換部１１４の機能について説明するための図（その２）である。

【図10】変換部１１４により実行される処理の流れの一例を示すフローチャートである。

【図11】変換部１１４のキャスト機能について説明するための図である。

【図12】変換部１１４のデータ分割機能について説明するための図である。

【図13】データ利用者インターフェース１２０による出力データのイメージを示す図である。

【図14】データ利用者インターフェース１２０により実行される処理の流れの一例を示すフローチャートである。

【発明を実施するための形態】

【0011】

以下、図面を参照し、本発明のデータ管理装置、データ管理方法、およびプログラムの実施形態について説明する。データ管理装置は、クライアントから受信したデータを記憶装置に保管すると共に、データ送信元のクライアント、或いは他のクライアントからの要求に応じたデータを記憶装置から読み出して提供する装置である。データ管理装置をＤＢＭＳ（データベース管理システム）と称してもよい。クライアントには、エンドユーザの使用する端末装置において動作するアプリケーションプログラムと協調して動作するアプリケーションサーバ（以下、フロントエンドサーバと称する）、蓄積されたデータを統計データなどとして利用するデータ利用者サーバなどが含まれる。

【0012】

先に、本発明の概念的側面について説明する。近年のHadoopはhiveやprestoに代表される"SQL on Hadoop"でRDB的にhdfsにアクセスすることが主流であり、過去に言われていた「非構造な大量のデータ」のファイルを直接扱うケースはまれになってきた。一方、格納されるデータは、取得時には非構造な「ログ」であることがほとんどである。そこで、多くの場合「規則性のある非構造データ」としてデータを取得・加工することになる。この、「規則性のある非構造データ」の代表がjsonやxmlであり、これは「ネストを含むkey value形式」で表現でき、これは木構造として見ることができる。図１は、jsonフォーマットによるログの一例を示す図であり、図２は図１のログを木構造で表現した図である。木構造による表現は「ネストを含むkey value形式」の抽象化に適している。図３は、jsonフォーマットによるログの他の一例を示す図であり、図４は図３のログを木構造で表現した図である。

【0013】

図４で示すように、「ネストを含むkeyvalue」は(x, z)平面で、配列に関してはy方向に次元を拡張する事が可能であり、多次元空間での木構造は「ネストを含むkeyvalue形式」、すなわちschemaを表現するのに適している事がわかる。この「多次元空間での木構造」をデータフォーマット（json, xml, avro, message pack等）から切り離して抽象化したオブジェクトにしたものが「schemaobject」である。

【0014】

一方、Hadoopに代表される分散型ストレージは、当初は大量の非構造データに対し高スループット高レイテンシでアクセスすることを主眼に設計・開発されたが、近年では、高スループットかつ低レイテンシを実現するために、データを構造化して配置するケースが増えてきている。hdfs上に構造化する際はカラムナーと呼ばれる、RDB的なデータを永続化するファイルフォーマットが一般的であり、代表的なものとしてhive ORC file、apache parquetがある。カラムナーファイルのデータを木構造で表現すると、図５に示すような「root直下のみの階層しかない2次元木」で描くことができる。図５は、カラムナーファイルのデータを木構造で表現した図である。

【0015】

カラムナーファイルフォーマットの利点は、「カラム毎にアクセスすることによる省コスト可」であり、メモリ・CPU・IOどの観点でも、Hadoopで馴染みのある他の非構造データ用のファイルフォーマットを凌駕する。一方で、カラムナーファイルには「データに構造化を強制する」という弱点がある。前述のとおり、データは取得時には非構造な「ログ」であり、構造化しようにも「多次元的な木構造」という高度な表現は不可能である。

【0016】

この問題を解決するのが、本発明で採用する方式である。これは、多次元的な（木構造で言うと深さ方向の）広がりをもつデータを永続化することができるファイルフォーマットである。前述したschemaobjectをそのまま記述する形式を取るので、「ネストを含むkey valueの配列」という表現力を保ったままデータを保持することができる。

【0017】

一般に、データのカラムナフォーマットの弱点は「データの構造化」の部分であり、多次元的なデータを二次元へ次元圧縮するロジックと処理をどこかで実装する必要がでてきてしまい、それが俗にいう「スキーマ」である。スキーマの管理や変更には大きなコストが伴う。本発明の方式では、次元圧縮処理が不要であるため、データの保存においては、この「スキーマ問題」から解放される。また、カラムナファイルでは構造上不可能な、配列やStruct型の「特定の値」へのアクセスも、そのカラムを全展開することなく木の探索としてアクセスできる点でも大きな利点がある。

【0018】

以下、具体的な構成および機能について説明する。図６は、データ管理装置の一例であるデータベースサーバ１００の使用環境と構成の一例を示す図である。エンドユーザの使用する一以上の端末装置１０は、フロントエンドサーバ２０と通信する。端末装置１０では、アプリケーションプログラムが動作し、アプリケーションプログラムの実行に必要なデータをフロントエンドサーバ２０との間で送受信する。フロントエンドサーバ２０は、端末装置１０から取得したデータのうち保存が必要なデータを、プロキシサーバ３０を介してデータベースサーバ１００に送信して保管させる。また、フロントエンドサーバ２０は、アプリケーションプログラムの実行に必要なデータをデータベースサーバ１００から読み出し、端末装置１０に送信する。このような、一以上の端末装置１０とフロントエンドサーバ２０との組み合わせが複数存在する。それぞれのフロントエンドサーバ２０は、ＪＳＯＮ（JavaScript（登録商標） Object Notation）、ＭｙＳＱＬなどの任意の形式で、データベースサーバ１００に対してデータの書き込み要求または読み出し要求を行う。

【0019】

一方、データ利用者サーバ５０は、フロントエンドサーバ２０から収集されたデータのうち、利用規約によって統計処理などに利用することが許可されているデータを、データベースサーバ１００から取得する。なお、フロントエンドサーバ２０とデータ利用者サーバ５０の区別は厳密なものである必要はなく、フロントエンドサーバ２０の一部がデータ利用者サーバ５０として動作することがあってもよい。また、データ利用者サーバ５０は、プロキシサーバ３０を介してデータベースサーバ１００と通信してもよい。図６に示す各装置は、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）などのネットワークを介して相互に通信可能に接続されている。

【0020】

データベースサーバ１００は、例えば、図示しないＮＩＣ（Network Interface Card）などの通信インターフェースの他、フロントエンドインターフェース１１０と、データ利用者インターフェース１２０と、記憶部１５０とを備える。フロントエンドインターフェース１１０およびデータ利用者インターフェース１２０は、それぞれ、ＣＰＵ（Central Processing Unit）などのプロセッサがプログラム（ソフトウェア）を実行することにより実現される。また、これらの機能部のうち一方または双方は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）などのハードウェアにより実現されてもよいし、ソフトウェアとハードウェアが協働することで実現されてもよい。

【0021】

フロントエンドインターフェース１１０は、例えば、解釈部１１２と、変換部１１４とを備える。解釈部１１２は、フロントエンドサーバ２０から取得されるデータを抽象化する。また、解釈部１１２は、フロントエンドサーバ２０にデータを提供する際には、抽象化されたデータを、フロントエンドサーバ２０に対応した形式に変換する。変換部１１４は、行指向型のデータを列指向型のデータに変換して記憶部１５０に記憶部１５０に記憶させる。データ利用者インターフェース１２０は、データ利用者サーバ５０から取得した要求に応じたデータを記憶部１５０から読み出し、データ利用者サーバ５０に送信する。これらの機能の詳細については後述する。

【0022】

記憶部１５０は、例えば、キャッシュメモリ１５２と、不揮発性メモリ１５４とを備える。キャッシュメモリ１５２は、ＲＡＭ（Random Access Memory）、レジスタ、フラッシュメモリなどで実現される。また、不揮発性メモリ１５４は、ＨＤＤ（Hard Disk Drive）、フラッシュメモリなどで実現される。不揮発性メモリ１５４には、列志向型データ１５４Ａが格納される。記憶部１５０は、データベースサーバ１００がネットワークを介してアクセス可能なＮＡＳ（Network Attached Storage）であってもよい。

【0023】

［フロントエンドインターフェース］
以下、フロントエンドインターフェース１１０の機能について説明する。フロントエンドインターフェース１１０の解釈部１１２は、フロントエンドサーバ２０ごとに定義が異なるデータを、一つの共通する形式に変換する。図７は、解釈部１１２の機能について説明するための図である。ここでは、Ｍａｒｋというユーザ名（ｎａｍｅ）を有するユーザの年齢（ａｇｅ）が３０才であるというデータを示している。これに対し、図７の下図は、データベースサーバ１００が扱うことのできる抽象化されたデータを模式的に示している。解釈部１１２は、図７に例示したように、フロントエンドサーバ２０から取得されたデータ格納要求を解釈し、抽象化する処理を行って、データを変換部１１４に渡す。なお、ｓｔｒｉｎｇやｉｎｔは後述するデータ形式である。

【0024】

フロントエンドインターフェース１１０により抽象化されたデータは、特に処理を加えなければ、行指向型のデータ構造を有するものとなるのが通常である。変換部１１４は、抽象化したデータを更に、列指向型のデータ構造に変換し、列志向型データ１５４Ａとして記憶部１５０の不揮発性メモリ１５４に記憶させる。

【0025】

図８は、変換部１１４の機能について説明するための図（その１）である。ここでは、レコード１〜レコード３の３つのレコードがフロントエンドサーバ２０から取得され、解釈部１１２によって抽象化されたものとする。レコード１は、データ項目としてｉｄ（識別情報）、ｎａｍｅ（ユーザ名）、ｓｅｘ（性別）を含んでいる。また、レコード２は、データ項目としてｉｄ、ｎａｍｅ、ａｇｅ（年齢）を含んでおり、レコード３は、データ項目としてｉｄ、ｎａｍｅを含んでいる。これらの抽象化されたレコードは、例えばレコード番号に対応付けられてキャッシュメモリ１５２に格納される。

【0026】

キャッシュメモリ１５２に一定量のデータが格納されると、変換部１１４は、これらを予め配列が確保されていない列指向型のデータ構造で管理しながら不揮発性メモリ１５４に記憶させる。列志向型のデータ構造において、一単位のデータ（以下、データセット）は、ＩｎｄｅｘとＶａｌｕｅの組み合わせを含む。データセットに含まれるＩｎｄｅｘとＶａｌｕｅは、互いに対応付けられて不揮発性メモリ１５４に記憶される。「互いに対応付けられて」とは、例えば、格納場所を示すアドレス情報が、メモリ空間において連続して、あるいはポインタを介して辿ることができる位置に書き込まれていることをいう。このデータセットの格納態様は、「多次元空間での木構造」をデータフォーマット（json, xml, avro, message pack等）から切り離して抽象化したオブジェクトにしたschemaobjectを、メモリ空間にそのまま格納することに相当する。

【0027】

Ｉｎｄｅｘとは、Ｖａｌｕｅすなわちデータ本体が、そのテーブル（データのより大きい管理単位）において、何レコード目から抽出されたものであるかを示す情報（換言すると、オフセット情報）である。Ｉｎｄｅｘは、「インデックス情報」の一例である。同じデータ項目のデータセットは、例えば、論理構造に関して近い位置で、不揮発性メモリ１５４に記憶される。「論理構造に関して近い位置で」とは、例えば、あるデータセットを参照した後に、次のデータセットを参照するために、メモリ空間における連続したアドレスを参照すればよい、あるいは一つまたは少数のポインタを辿るだけで参照することができることをいう。

【0028】

以下、同じデータ項目の一以上のデータセット、すなわち列志向型で管理される一以上のデータセットのことをカラムデータと称する。図８の例では、データ項目「ｉｄ」についてレコード１、２、３のデータセットが、データ項目「ｎａｍｅ」についてレコード１、２、３のデータセットが、データ項目「ｓｅｘ」についてレコード１のデータセットが、データ項目「ａｇｅ」についてレコード２のデータセットが、それぞれカラムデータとして管理される。

【0029】

また、カラムデータには、そのデータ項目のデータ形式などを記述したヘッダが付与される。データ形式には、［ｓｔｒｉｎｇ（文字列）］、［ｉｎｔ（整数）］、［ｌｏｎｇ（桁の長い整数）］、［ｆｌｏａｔ（小数点表記）］、［ｄｏｕｂｌｅ（桁の長い小数点表記）］などがある。

【0030】

更に別のレコードを記憶する要求が取得された場合、変換部１１４は、以下の手法でデータを管理する。変換部１１４は、（手法１）既に管理されているデータ構造に追加する形でデータを管理してもよいし、（手法２）キャッシュメモリ１５２から不揮発性メモリ１５４にデータを移すごとに管理するデータを区分してもよい。以下では手法１について説明する。手法２を採用する場合、データの読み出しの際に適宜、データの結合処理が行われる。

【0031】

図９は、変換部１１４の機能について説明するための図（その２）である。ここでは、更に、レコード４〜レコード６の３つのレコードがフロントエンドサーバ２０から取得され、解釈部１１２によって抽象化されたものとする。レコード４は、データ項目としてｎａｍｅ、ａｇｅ、ｊｏｂを含んでいる。また、レコード５は、データ項目としてｉｄ、ｎａｍｅ、ｓｅｘを含んでおり、レコード６は、データ項目としてｉｄ、ｎａｍｅ、ｊｏｂを含んでいる。これらの抽象化されたレコードは、キャッシュメモリ１５２に格納される。

【0032】

キャッシュメモリ１５２に一定量のデータが格納されると、変換部１１４は、これらを列指向型のデータ構造で管理しながら不揮発性メモリ１５４に記憶させる。ここで、レコード４〜６には、レコード１〜３には含まれていなかったｊｏｂ（職業）というデータ項目が含まれている。この場合、変換部１１４は、新たなカラムデータを設定し、データを管理する。図９の例では、データ項目「ｉｄ」についてレコード１、２、３、５、６のデータセットが、データ項目「ｎａｍｅ」についてレコード１、２、３、４、５、６のデータセットが、データ項目「ｓｅｘ」についてレコード１のデータセットが、データ項目「ａｇｅ」についてレコード２、４、５のデータセットが、データ項目「ｊｏｂ」についてレコード４、６のデータセットが、それぞれカラムデータとして管理される。

【0033】

このようにデータを管理することで、例えば、「全ユーザのｊｏｂを取得したい」といった要求がデータ利用者サーバ５０から取得された場合、データベースサーバ１００（データ利用者インターフェース１２０）は、他のデータ項目（ｉｄ、ｎａｍｅ、ａｇｅ、ｓｅｘ、…）のカラムデータを参照せずに、データ項目「ｊｏｂ」のカラムデータを読み出すことができる。この結果、読み出しに要する時間を短縮し、データ利用のニーズに迅速に対応することができる。なお、不揮発性メモリ１５４がＨＤＤである場合、シーク時間が短くなるように、ひとまとまりの論理構造を、例えば同じトラック内に保持するようにすると好適であるが、これに限定されるものではない。

【0034】

また、例えば、データベースサーバ１００（データ利用者インターフェース１２０）は、所定のデータ項目におけるＶａｌｕｅ（データ本体）が設定条件を満たすＩｎｄｅｘ（レコードを特定可能な情報）を記憶部１５０から読み出す要求を受け付け、結果を返すことができる。具体的には、「ａｇｅのＶａｌｕｅが４５以上のレコードを取得したい」といった要求がデータ利用者サーバ５０から取得された場合、他のデータ項目（ｉｄ、ｎａｍｅ、ｓｅｘ、ｊｏｂ…）を参照せずに、データ項目「ａｇｅ」のカラムデータに含まれるＩｎｄｅｘを読み出すことができる。この場合、データベースサーバ１００（データ利用者インターフェース１２０）は、「ａｇｅ」のカラムデータから順にデータセットを読み出し、Ｖａｌｕｅの示す値が４５以上であるデータセットのＩｎｄｅｘを抽出する。この抽出したＩｎｄｅｘは、「ａｇｅ」が４５以上であるレコードに対する付番であるため、データベースサーバ１００は、例えば、列志向型データ１５４Ａとは別に保存されているレコードごとのデータを検索し、「ａｇｅ」が４５以上であるレコードを取得することができる。図９の例では、Ｉｎｄｅｘが４と５であるデータセットが条件に該当するため、データベースサーバ１００は、４番目のレコードと５番目のレコードを抽出する。

【0035】

また、図８および図９に示すように、変換部１１４は、Ｉｎｄｅｘが列方向に連続しない場合でも、連続しないＩｎｄｅｘを含むデータセットの間に空のメモリ領域を設けない。これによって、データベースサーバ１００は、データを読み出す際にメモリ領域をスキップする処理などを省略することができ、処理速度を向上させることができる。また、本実施形態では、データセットに含まれるＩｎｄｅｘとＶａｌｕｅとを互いに対応付けて不揮発性メモリ１５４に記憶させるため、予め設定されたデータ項目に関するデータセットでなくても列志向型データ１５４Ａに追加することができる。すなわち、任意のタイミングで自由にデータ項目を追加することができる。

【0036】

図１０は、変換部１１４により実行される処理の流れの一例を示すフローチャートである。まず、変換部１１４は、不揮発性メモリ１５４への書き込みタイミングが到来するまで待機する（Ｓ１００）。不揮発性メモリ１５４への書き込みタイミングとは、前述したようにキャッシュメモリ１５２に一定量のデータが格納されたタイミング、データベースサーバ１００がシャットダウンされるタイミング、直近までの集計処理が依頼されたタイミングなど、任意に定義することができる。

【0037】

不揮発性メモリ１５４への書き込みタイミングが到来すると、変換部１１４は、キャッシュメモリ１５２に格納されたレコードを一つ選択し（Ｓ１０２）、そのレコードに含まれるデータ項目を一つ選択する（Ｓ１０４）。そして、変換部１１４は、選択したデータ項目が、既に管理済のデータ項目であるか否かを判定する（Ｓ１０６）。

【0038】

選択したデータ項目が、既に管理済のデータ項目である場合、変換部１１４は、そのデータ項目の末尾にＩｎｄｅｘとＶａｌｕｅを追加する（Ｓ１０８）。一方、選択したデータ項目が、既に管理済のデータ項目でない場合、変換部１１４は、列を新たに設定（定義）し、設定した列にＩｎｄｅｘとＶａｌｕｅを書き込む（Ｓ１１０）。

【0039】

次に、変換部１１４は、選択されているレコードの全てのデータ項目を選択したか否かを判定する（Ｓ１１２）。選択されているレコードの全てのデータ項目を選択していない場合、Ｓ１０４に処理が戻される。選択されているレコードの全てのデータ項目を選択した場合、変換部１１４は、キャッシュメモリ１５２に格納されている全てのレコードを選択したか否かを判定する（Ｓ１１４）。キャッシュメモリ１５２に格納されている全てのレコードを選択していない場合、Ｓ１０２に処理が戻される。キャッシュメモリ１５２に格納されている全てのレコードを選択した場合、本フローチャートの１ルーチンの処理が終了する。

【0040】

［拡張機能］
変換部１１４は、同じデータ項目について、データ形式が異なるが、統合可能なデータ形式であるデータが入力された場合、これらをキャストして一つのカラムデータにしてもよい。統合可能なデータ形式とは、例えば、ｉｎｔ（整数）とｌｏｎｇ（桁の長い整数）の組、あるいはｆｌｏａｔ（小数点表記）とｄｏｕｂｌｅ（桁の長い小数点表記）の組である。変換部１１４は、それぞれが互いに異なる数値型のデータ形式で定義された同じデータ項目に対応する二以上のカラムデータに関して、所望のタイミングで数値型のうち桁の多い方のデータ形式に揃えて一つのカラムデータを再構成する。

【0041】

図１１は、変換部１１４のキャスト機能について説明するための図である。例えば、「ｔｉｍｅｓ（ログイン回数）」のようなデータ項目について、レコード１０、１５、１７ではデータ形式［ｉｎｔ］で入力され、レコード２２でＶａｌｕｅの桁が長いためデータ形式［ｌｏｎｇ］で入力された場合、当初のカラムデータは図１１の上図のように二つに分けて設定される。この場合、変換部１１４は、任意のタイミングで、データ項目［ｉｎｔ］のデータセットのデータ形式を［ｌｏｎｇ］に変更して統合する。これによって、データ形式の異なるデータセットについても、例えば合計を求めるような統計処理を効率的に行うことができる。

【0042】

変換部１１４は、例えば、データ形式として［ａｒｒａｙ］が指定されている場合、複数のデータ項目を分割してカラムデータとする。すなわち、変換部１１４は、入力されたレコードが階層構造を含む場合、階層構造をカラムデータの形成するメモリ空間に展開して記憶部１５０に記憶させる。図１２は、変換部１１４のデータ分割機能について説明するための図である。図示するように、変換部１１４は、［ａｒｒａｙ］形式の「ｄａｔｅ」を構成する「ｙｙ」と「ｍｍ」と「ｄｄ」をそれぞれデータ項目とし、親空間（上位空間）とは別のメモリ空間（子空間（下位空間））において、カラムデータとして列志向型で管理する。この場合、変換部１１４は、親空間における［ａｒｒａｙ］に対応するカラムデータのＶａｌｕｅに、子空間におけるオフセット情報であるＣｈｉｌｄＩｎｄｅｘの先頭値と、ｌｅｎｇｔｈ（何カラム目まで該当するデータがあるかを示す値）とを格納する。図１２の例では、親空間のデータ項目「ｄａｔｅ」のＩｎｄｅｘ＝１０のデータセットにおけるＶａｌｕｅの「ＣｈｉｌｄＩｎｄｅｘ（７，２）」は、子空間におけるＣｈｉｌｄＩｎｄｅｘ＝７および８のデータセットが対応することを示している。また、変換部１１４は、それらが［ａｒｒａｙ］からの派生であることを示す情報を、子空間におけるカラムデータに付加しておく。これによって、元々は次元数が他のデータ項目よりも多い（階層構造の）入力データを、フラットなデータ構造で管理することができる。

【0043】

［データ利用者インターフェース］
以下、データ利用者インターフェース１２０の機能について説明する。データ利用者インターフェース１２０は、例えば、データ利用者サーバ５０からの要求に応じて、表形式のデータ（配列データ）を提供する。データ利用者サーバ５０からの要求は、任意のデータ項目を指定して行われる。この際に、データ利用者インターフェース１２０は、指定されたデータ項目を含まないレコードに関しては、そのデータ項目に対応するデータを「ｎｕｌｌ」（或いはブランクなど、「該当データ無し」を示す任意の形態であってよい）とした表形式のデータを生成してデータ利用者サーバ５０に提供する。また、データ利用者インターフェース１２０は、指定されたデータ項目が既に管理されているデータ項目の中に無い場合、エラーを返すのではなく、そのデータ項目についてのデータを全て「ｎｕｌｌ」（或いはブランクなど、「該当データ無し」を示す任意の形態であってよい）とした表形式のデータを生成してデータ利用者サーバ５０に提供する。なお、データ利用者サーバ５０からの要求は、例えば所定の拡張子を指定することで行われてよい。

【0044】

例えば、図９に示すようなデータが列志向型データ１５４Ａとして不揮発性メモリ１５４に格納されている状態で、データ項目［ｓｅｘ、ａｇｅ、ｊｏｂ、ｈｏｂｂｙ（趣味）］を指定したデータの要求があったとする。この場合、データ利用者インターフェース１２０による出力データのイメージは、図１３のようになる。図１３は、データ利用者インターフェース１２０による出力データのイメージを示す図である。図示するように、データ利用者インターフェース１２０による出力データは、データの有無に拘わらず、レコードごと且つデータ項目ごとにデータを配列化して表したデータである。これによって、データベースサーバ１００は、データ利用者サーバ５０のニーズに応じた形式でデータを提供することができる。

【0045】

図１４は、データ利用者インターフェース１２０により実行される処理の流れの一例を示すフローチャートである。まず、データ利用者インターフェース１２０は、データの要求を取得するまで待機する（Ｓ２００）。データの要求を取得すると、データ利用者インターフェース１２０は、スキーマ情報１５４Ｂから、現時点でのレコードの最大数を取得する（Ｓ２０２）。この最大数をｎとする。次に、データ利用者インターフェース１２０は、データの要求に含まれるデータ項目数×ｎの配列を定義する（Ｓ２０４）。この配列が、出力データの枠組みとなる。

【0046】

次に、データ利用者インターフェース１２０は、データの要求からデータ項目を一つ選択し（Ｓ２０６）、選択したデータ項目が、既に列志向型データ１５４Ａに設定済であるか否かを判定する（Ｓ２０８）。データ利用者インターフェース１２０は、選択したデータ項目が、既に列志向型データ１５４Ａに設定済でない場合、当該データ項目のデータを全てｎｕｌｌにする（Ｓ２１０）。

【0047】

一方、選択したデータ項目が、既に列志向型データ１５４Ａに設定済である場合、データ利用者インターフェース１２０は、列志向型データ１５４Ａから、現在選択されているデータ項目のデータを一つ読み出す（Ｓ２１２）。次に、データ利用者インターフェース１２０は、Ｓ２１２において読み出し可能なデータが存在しなかったか否かを判定する（Ｓ２１４）。Ｓ２１２において読み出し可能なデータが存在した場合、データ利用者インターフェース１２０は、その読み出しに至るまでにレコード番号が飛ばされたか否かを判定する（Ｓ２１６）。レコード番号が飛ばされた場合、データ利用者インターフェース１２０は、飛ばされたレコード番号のデータをｎｕｌｌにする（Ｓ２１８）。そして、データ利用者インターフェース１２０は、列志向型データ１５４Ａから読み出したデータをＳ２０４で設定した配列に含める（Ｓ２２０）。

【0048】

Ｓ２１０の処理を行った後、或いは、Ｓ２１４において肯定的な判定を得た後、データ利用者インターフェース１２０は、繰り返しＳ２０６が行われる中で全てのデータ項目を選択したか否かを判定する（Ｓ２２２）。全てのデータ項目を選択していない場合、Ｓ２０６に処理が戻される。一方、全てのデータ項目を選択した場合、データを出力する（Ｓ２２４）。この段階で、配列における全てのデータに、列志向型データ１５４Ａから読み出されたデータ、或いはｎｕｌｌが格納されている筈である。

【0049】

以上説明した本発明のデータ管理装置、データ管理方法、およびプログラムによれば、入力されたレコードを解釈してデータ項目とデータ本体との対応関係が認識可能な抽象表現に変換し、データ項目ごとに、データ本体とレコードを特定可能なインデックス情報とを対応付けたデータセットを、カラムデータとして記憶部１５０に記憶させることにより、非構造的な入力データについて列志向型としての利用を可能にしつつ、入力レコードの特定も容易に行うことができる。

【0050】

以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

【符号の説明】

【0051】

１０ 端末装置
２０ フロントエンドサーバ
３０ プロキシサーバ
５０ データ利用者サーバ
１００ データベースサーバ
１１０ フロントエンドインターフェース
１１２ 解釈部
１１４ 変換部
１２０ データ利用者インターフェース
１５０ 記憶部
１５２ キャッシュメモリ
１５４ 不揮発性メモリ
１５４Ａ 列志向型データ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】