(57)【要約】      （修正有）【課題】非構造な入力データを、データ項目ごとに高速に読み出し可能な態様で保存すると共に、入力データの追加や削除を容易に行うことができるデータ管理装置、データ管理方法およびプログラムを提供する。【解決手段】データベースサーバは、フロントエンドインターフェースに、入力されたデータ格納要求を解釈して抽象表現に変換する解釈部と、解釈部により抽象表現に変換されたデータを、予め配列が確保されていない列指向型のデータ構造で管理しながら記憶部に記憶させる変換部と、を備える。【選択図】図６
2018156233.tif 000002
【特許請求の範囲】
【請求項１】
入力されたデータ格納要求を解釈して抽象表現に変換する解釈部と、
前記解釈部により抽象表現に変換されたデータを、予め配列が確保されていない列指向型のデータ構造で管理しながら記憶部に記憶させる変換部と、
を備えるデータ管理装置。
【請求項２】
前記変換部は、前記列指向型のデータ構造で管理されるデータを、行方向に読み出し可能にするための参照情報を前記記憶部に記憶させる、
請求項１記載のデータ管理装置。
【請求項３】
前記列指向型のデータ構造は、前記データ格納要求に含まれるレコードに含まれるデータが、データ項目ごとにひとまとまりの論理構造でまとめられたデータ構造であり、
前記変換部は、前記データ格納要求に含まれるデータ項目が、前記列指向型のデータ構造に設定されていないデータ項目である場合、新たな列を追加する、
請求項１または２記載のデータ管理装置。
【請求項４】
前記列指向型のデータ構造で管理されるデータを、入力されたデータ要求に含まれるデータ項目ごとに前記記憶部から読み出して出力するデータ利用者インターフェースを更に備える、
請求項１から３のうちいずれか１項記載のデータ管理装置。
【請求項５】
前記データ利用者インターフェースは、指定されたデータ項目を含まないレコードに関しては、当該データ項目に対応するデータを、該当するデータが存在しないことを示す任意の形態のデータで埋める、
請求項４記載のデータ管理装置。
【請求項６】
前記データ利用者インターフェースは、指定されたデータ項目が、前記列指向型のデータ構造に設定されていないデータ項目である場合、当該データ項目についてのデータを全て、該当するデータが存在しないことを示す任意の形態のデータで埋める、
請求項４または５記載のデータ管理装置。
【請求項７】
コンピュータが、
入力されたデータ格納要求を解釈して抽象表現に変換し、
前記抽象表現に変換されたデータを、予め配列が確保されていない列指向型のデータ構造で管理しながら記憶部に記憶させる、
データ管理方法。
【請求項８】
コンピュータに、
入力されたデータ格納要求を解釈して抽象表現に変換させ、
前記抽象表現に変換されたデータを、予め配列が確保されていない列指向型のデータ構造で管理しながら記憶部に記憶させる処理を行わせる、
プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ管理装置、データ管理方法、およびプログラムに関する。
【背景技術】
【０００２】
従来、中国、日本、および韓国の言語のための名前を検出する方法が知られている（特許文献１参照）。この方法では、構造化されたデータを扱っている。
【０００３】
ところで、データベースにおけるデータ構造には、行指向型のデータ構造と列指向型のデータ構造がある。行指向型のデータ構造とは、ひとつのレコードを、ひとまとまりの論理構造として保持するデータ構造である。これに対し、列指向型のデータ構造が知られている。列指向型のデータ構造とは、同じインデックス（ユーザの属性データであれば、名前、年齢、性別といったもの）に対応するデータを、ひとまとまりの論理構造として保持するデータ構造である。論理構造とは、データを検索する際に使用される、キー、ＬＢＡ（Logical Block Addressing）、論物変換テーブル上のラベル、その他の論理的な情報をいう。行指向型のデータ構造は、データの追加や削除などが容易であるのに対し、列指向型のデータ構造は、インデックスごとの統計処理に向いているといった違いがある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３−１０９３６４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ここで、行指向型のデータ構造を扱うＪＳＯＮなどの機能では、データのツリー構造を自動生成することができるが、ネットワーク、記憶装置、ソフトウェア処理の面でコストが大きい。特に、列指向型のデータ構造を有するデータベースから統計処理のためのデータを読み出す際の処理時間は長くなってしまう。
【０００６】
一方、列指向型のデータ構造でデータを格納した場合、採用され得る全てのインデックスの管理と、データの追加や削除などが困難である。特に、Ｓｔｒｅａｍ形式でデータが入力される場合、レコードごとにデータを処理することが想定されるが、レコードごとの処理から直接的に列指向型に書き込むことはできない。また、列指向型においては、書き込み失敗時の管理や重複排除を行う有効な方法が開発されていない。
【０００７】
本発明は、このような事情を考慮してなされたものであり、非構造な入力データを、データ項目ごとに高速に読み出し可能な態様で保存すると共に、入力データの追加や削除を容易に行うことができるデータ管理装置、データ管理方法、およびプログラムを提供することを目的の一つとする。
【課題を解決するための手段】
【０００８】
本発明の一態様は、入力されたデータ格納要求を解釈して抽象表現に変換する解釈部と、前記解釈部により抽象表現に変換されたデータを、予め配列が確保されていない列指向型のデータ構造で管理しながら記憶部に記憶させる変換部と、を備えるデータ管理装置である。
【発明の効果】
【０００９】
本発明の一態様によれば、非構造な入力データを、データ項目ごとに高速に読み出し可能な態様で保存すると共に、入力データの追加や削除を容易に行うことができる。
【図面の簡単な説明】
【００１０】
【図１】jsonフォーマットによるログの一例を示す図である。
【図２】図１のログを木構造で表現した図である。
【図３】jsonフォーマットによるログの他の一例を示す図である。
【図４】図３のログを木構造で表現した図である。
【図５】カラムナーファイルのデータを木構造で表現した図である。
【図６】データ管理装置の一例であるデータベースサーバ１００の使用環境と構成の一例を示す図である。
【図７】解釈部１１２の機能について説明するための図である。
【図８】変換部１１４の機能について説明するための図（その１）である。
【図９】スキーマ情報１５４Ｂの一例を示す図（その１）である。
【図１０】変換部１１４の機能について説明するための図（その２）である。
【図１１】スキーマ情報１５４Ｂの一例を示す図（その２）である。
【図１２】変換部１１４の機能について説明するための図（その３）である。
【図１３】スキーマ情報１５４Ｂの一例を示す図（その３）である。
【図１４】変換部１１４により実行される処理の流れの一例を示すフローチャートである。
【図１５】データ利用者インターフェース１２０による出力データのイメージを示す図である。
【図１６】データ利用者インターフェース１２０により実行される処理の流れの一例を示すフローチャートである。
【図１７】変換部１１４による他の機能について説明するための図である。
【図１８】図１７の例に対応したスキーマ情報１５４Ｂの一例を示す図である。
【発明を実施するための形態】
【００１１】
以下、図面を参照し、本発明のデータ管理装置、データ管理方法、およびプログラムの実施形態について説明する。データ管理装置は、クライアントから受信したデータを記憶装置に保管すると共に、データ送信元のクライアント、或いは他のクライアントからの要求に応じたデータを記憶装置から読み出して提供する装置である。データ管理装置をＤＢＭＳ（データベース管理システム）と称してもよい。クライアントには、エンドユーザの使用する端末装置において動作するアプリケーションプログラムと協調して動作するアプリケーションサーバ（以下、フロントエンドサーバと称する）、蓄積されたデータを統計データなどとして利用するデータ利用者サーバなどが含まれる。
【００１２】
先に、本発明の概念的側面について説明する。近年のHadoopはhiveやprestoに代表される"SQL on Hadoop"でRDB的にhdfsにアクセスすることが主流であり、過去に言われていた「非構造な大量のデータ」のファイルを直接扱うケースはまれになってきた。一方、格納されるデータは、取得時には非構造な「ログ」であることがほとんどである。そこで、多くの場合「規則性のある非構造データ」としてデータを取得・加工することになる。この、「規則性のある非構造データ」の代表がjsonやxmlであり、これは「ネストを含むkey value形式」で表現でき、これは木構造として見ることができる。図１は、jsonフォーマットによるログの一例を示す図であり、図２は図１のログを木構造で表現した図である。木構造による表現は「ネストを含むkey value形式」の抽象化に適している。図３は、jsonフォーマットによるログの他の一例を示す図であり、図４は図３のログを木構造で表現した図である。
【００１３】
図４で示すように、「ネストを含むkeyvalue」は(x, z)平面で、配列に関してはy方向に次元を拡張する事が可能であり、多次元空間での木構造は「ネストを含むkeyvalue形式」、すなわちschemaを表現するのに適している事がわかる。この「多次元空間での木構造」をデータフォーマット（json, xml, avro, message pack等）から切り離して抽象化したオブジェクトにしたものが「schemaobject」である。
【００１４】
一方、Hadoopに代表される分散型ストレージは、当初は大量の非構造データに対し高スループット高レイテンシでアクセスすることを主眼に設計・開発されたが、近年では、高スループットかつ低レイテンシを実現するために、データを構造化して配置するケースが増えてきている。hdfs上に構造化する際はカラムナーと呼ばれる、RDB的なデータを永続化するファイルフォーマットが一般的であり、代表的なものとしてhive ORC file、apache parquetがある。カラムナーファイルのデータを木構造で表現すると、図５に示すような「root直下のみの階層しかない2次元木」で描くことができる。図５は、カラムナーファイルのデータを木構造で表現した図である。
【００１５】
カラムナーファイルフォーマットの利点は、「カラム毎にアクセスすることによる省コスト可」であり、メモリ・CPU・IOどの観点でも、Hadoopで馴染みのある他の非構造データ用のファイルフォーマットを凌駕する。一方で、カラムナーファイルには「データに構造化を強制する」という弱点がある。前述のとおり、データは取得時には非構造な「ログ」であり、構造化しようにも「多次元的な木構造」という高度な表現は不可能である。
【００１６】
この問題を解決するのが、本発明で採用する方式である。これは、多次元的な（木構造で言うと深さ方向の）広がりをもつデータを永続化することができるファイルフォーマットである。前述したschemaobjectをそのまま記述する形式を取るので、「ネストを含むkey valueの配列」という表現力を保ったままデータを保持することができる。
【００１７】
一般に、データのカラムナフォーマットの弱点は「データの構造化」の部分であり、多次元的なデータを二次元へ次元圧縮するロジックと処理をどこかで実装する必要がでてきてしまい、それが俗にいう「スキーマ」である。スキーマの管理や変更には大きなコストが伴う。本発明の方式では、次元圧縮処理が不要であるため、データの保存においては、この「スキーマ問題」から解放される。また、カラムナファイルでは構造上不可能な、配列やStruct型の「特定の値」へのアクセスも、そのカラムを全展開することなく木の探索としてアクセスできる点でも大きな利点がある。
【００１８】
以下、具体的な構成および機能について説明する。図６は、データ管理装置の一例であるデータベースサーバ１００の使用環境と構成の一例を示す図である。エンドユーザの使用する一以上の端末装置１０は、フロントエンドサーバ２０と通信する。端末装置１０では、アプリケーションプログラムが動作し、アプリケーションプログラムの実行に必要なデータをフロントエンドサーバ２０との間で送受信する。フロントエンドサーバ２０は、端末装置１０から取得したデータのうち保存が必要なデータを、プロキシサーバ３０を介してデータベースサーバ１００に送信して保管させる。また、フロントエンドサーバ２０は、アプリケーションプログラムの実行に必要なデータをデータベースサーバ１００から読み出し、端末装置１０に送信する。このような、一以上の端末装置１０とフロントエンドサーバ２０との組み合わせが複数存在する。それぞれのフロントエンドサーバ２０は、ＪＳＯＮ（JavaScript（登録商標） Object Notation）、ＭｙＳＱＬなどの任意の形式で、データベースサーバ１００に対してデータの書き込み要求または読み出し要求を行う。
【００１９】
一方、データ利用者サーバ５０は、フロントエンドサーバ２０から収集されたデータのうち、利用規約によって統計処理などに利用することが許可されているデータを、データベースサーバ１００から取得する。なお、フロントエンドサーバ２０とデータ利用者サーバ５０の区別は厳密なものである必要はなく、フロントエンドサーバ２０の一部がデータ利用者サーバ５０として動作することがあってもよい。また、データ利用者サーバ５０は、プロキシサーバ３０を介してデータベースサーバ１００と通信してもよい。図６に示す各装置は、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）などのネットワークを介して相互に通信可能に接続されている。
【００２０】
データベースサーバ１００は、例えば、図示しないＮＩＣ（Network Interface Card）などの通信インターフェースの他、フロントエンドインターフェース１１０と、データ利用者インターフェース１２０と、記憶部１５０とを備える。フロントエンドインターフェース１１０およびデータ利用者インターフェース１２０は、それぞれ、ＣＰＵ（Central Processing Unit）などのプロセッサがプログラム（ソフトウェア）を実行することにより実現される。また、これらの機能部のうち一方または双方は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）などのハードウェアにより実現されてもよいし、ソフトウェアとハードウェアが協働することで実現されてもよい。
【００２１】
フロントエンドインターフェース１１０は、例えば、解釈部１１２と、変換部１１４とを備える。解釈部１１２は、フロントエンドサーバ２０から取得されるデータを抽象化する。また、解釈部１１２は、フロントエンドサーバ２０にデータを提供する際には、抽象化されたデータを、フロントエンドサーバ２０に対応した形式に変換する。変換部１１４は、行指向型のデータを列指向型のデータに変換して記憶部１５０に記憶部１５０に記憶させる。データ利用者インターフェース１２０は、データ利用者サーバ５０から取得した要求に応じたデータを記憶部１５０から読み出し、データ利用者サーバ５０に送信する。これらの機能の詳細については後述する。
【００２２】
記憶部１５０は、例えば、キャッシュメモリ１５２と、不揮発性メモリ１５４とを備える。キャッシュメモリ１５２は、ＲＡＭ（Random Access Memory）、レジスタ、フラッシュメモリなどで実現される。また、不揮発性メモリ１５４は、ＨＤＤ（Hard Disk Drive）、フラッシュメモリなどで実現される。不揮発性メモリ１５４には、クライアントデータ１５４Ａとスキーマ情報１５４Ｂとが格納される。スキーマ情報１５４Ｂは、参照情報の一例である。記憶部１５０は、データベースサーバ１００がネットワークを介してアクセス可能なＮＡＳ（Network Attached Storage）であってもよい。
【００２３】
［フロントエンドインターフェース］
以下、フロントエンドインターフェース１１０の機能について説明する。フロントエンドインターフェース１１０の解釈部１１２は、フロントエンドサーバ２０ごとに定義が異なるデータを、一つの共通する形式に変換する。図７は、解釈部１１２の機能について説明するための図である。ここでは、ａａａａａというユーザ名（ｎａｍｅ）を有するユーザの年齢（ａｇｅ）が２４才であるというデータを示している。以下、このｎａｍｅやａｇｅなどの情報をインデックスと称する。これに対し、図７の下図は、データベースサーバ１００が扱うことのできる抽象化されたデータを模式的に示している。解釈部１１２は、図７に例示したように、フロントエンドサーバ２０から取得されたデータ格納要求を解釈し、抽象化する処理を行って、データを変換部１１４に渡す。
【００２４】
フロントエンドインターフェース１１０により抽象化されたデータは、特に処理を加えなければ、行指向型のデータ構造を有するものとなるのが通常である。変換部１１４は、抽象化したデータを更に、列指向型のデータ構造に変換し、クライアントデータ１５４Ａとして記憶部１５０の不揮発性メモリ１５４に記憶させる。
【００２５】
図８は、変換部１１４の機能について説明するための図（その１）である。ここでは、レコード１〜レコード３の３つのレコードがフロントエンドサーバ２０から取得され、解釈部１１２によって抽象化されたものとする。レコード１は、データ項目としてｉｄ（識別情報）、ｎａｍｅ（ユーザ名）、ｓｅｘ（性別）を含んでいる。図では、レコード１のｉｄという意味でｉｄ（１）などと表記している。他のデータ項目に関しても同様である。また、レコード２は、データ項目としてｉｄ、ｎａｍｅ、ａｇｅ（年齢）を含んでおり、レコード３は、データ項目としてｉｄ、ｎａｍｅを含んでいる。これらの抽象化されたレコードは、キャッシュメモリ１５２に格納される。
【００２６】
キャッシュメモリ１５２に一定量のデータが格納されると、変換部１１４は、これらを予め配列が確保されていない列指向型のデータ構造で管理しながら不揮発性メモリ１５４に記憶させる。図８の例では、［ｉｄ（１）、ｉｄ（２）、ｉｄ（３）］、［ｎａｍｅ（１）、ｎａｍｅ（２）、ｎａｍｅ（３）］、［ｓｅｘ（１）］、および［ａｇｅ（２）］のそれぞれが、ひとまとまりの論理構造を有するように管理される。
【００２７】
ここで、変換部１１４は、後に行方向への検索が可能となるように、スキーマ情報１５４Ｂを不揮発性メモリ１５４に格納しておく（一時的にキャッシュメモリ１５２に格納してもよい）。図９は、スキーマ情報１５４Ｂの一例を示す図（その１）である。図示するように、スキーマ情報１５４Ｂは、ログを木構造で表現した情報である。この情報に基づいて、例えばレコード２の情報を読み出す要求がフロントエンドサーバ２０から取得された場合、木の探索としてアクセスすることができる。なお、スキーマ情報１５４Ｂの形式は図９に示すものに限らず、任意の形式を採用してよい。
【００２８】
更に別のレコードを記憶する要求が取得された場合、変換部１１４は、以下の手法でデータを管理する。変換部１１４は、（手法１）既に管理されているデータ構造に追加する形でデータを管理してもよいし、（手法２）キャッシュメモリ１５２から不揮発性メモリ１５４にデータを移すごとに管理するデータを区分してもよい。
【００２９】
（手法１）
図１０は、変換部１１４の機能について説明するための図（その２）である。ここでは、更に、レコード４〜レコード６の３つのレコードがフロントエンドサーバ２０から取得され、解釈部１１２によって抽象化されたものとする。レコード４は、データ項目としてｎａｍｅ、ａｇｅ、ｊｏｂを含んでいる。また、レコード５は、データ項目としてｉｄ、ｎａｍｅ、ｓｅｘを含んでおり、レコード６は、データ項目としてｉｄ、ｎａｍｅ、ｊｏｂを含んでいる。これらの抽象化されたレコードは、キャッシュメモリ１５２に格納される。
【００３０】
キャッシュメモリ１５２に一定量のデータが格納されると、変換部１１４は、これらを列指向型のデータ構造で管理しながら不揮発性メモリ１５４に記憶させる。ここで、レコード４〜６には、レコード１〜３には含まれていなかったｊｏｂ（職業）というデータ項目が含まれている。この場合、変換部１１４は、新たな列を設定し、データを管理する。図１０の例では、［ｉｄ（１）、ｉｄ（２）、ｉｄ（３）、ｉｄ（５）、ｉｄ（６）］、［ｎａｍｅ（１）、ｎａｍｅ（２）、ｎａｍｅ（３）、ｎａｍｅ（４）、ｎａｍｅ（５）、ｎａｍｅ（６）］、［ｓｅｘ（１）、ｓｅｘ（５）］、［ａｇｅ（２）、ａｇｅ（４）］、および［ｊｏｂ（４）、ｊｏｂ（６）］のそれぞれが、ひとまとまりの論理構造を有するように管理される。この場合、スキーマ情報１５４Ｂは、図１１に示すような内容となる。図１１は、スキーマ情報１５４Ｂの一例を示す図（その２）である。
【００３１】
（手法２）
図１２は、変換部１１４の機能について説明するための図（その３）である。ここでは、図１２で例示したレコード１〜３に対する処理をセッション１、続いて取得されたレコード４〜６に対する処理をセッション２と称する。図１２の例では、セッション１として、［ｉｄ（１）、ｉｄ（２）、ｉｄ（３）］、［ｎａｍｅ（１）、ｎａｍｅ（２）、ｎａｍｅ（３）］、［ｓｅｘ（１）］、および［ａｇｅ（２）］のそれぞれが、ひとまとまりの論理構造を有するように管理されると共に、セッション２として、［ｉｄ（５）、ｉｄ（６）］、［ｎａｍｅ（４）、ｎａｍｅ（５）、ｎａｍｅ（６）］、［ｓｅｘ（５）］、［ａｇｅ（４）］、および［ｊｏｂ（４）、ｊｏｂ（６）］のそれぞれが、ひとまとまりの論理構造を有するように管理される。この場合、スキーマ情報１５４Ｂは、図１３に示すような内容となる。図１３は、スキーマ情報１５４Ｂの一例を示す図（その３）である。
【００３２】
このようにデータを管理することで、例えば、「全ユーザのｊｏｂを取得したい」といった要求がデータ利用者サーバ５０から取得された場合、データベースサーバ１００は、他のデータ項目（ｉｄ、ｎａｍｅ、ａｇｅ、ｓｅｘ、…）を参照せずに、データ項目「ｊｏｂ」のデータを読み出すことができる。この結果、読み出しに要する時間を短縮し、データ利用のニーズに迅速に対応することができる。なお、不揮発性メモリ１５４がＨＤＤである場合、シーク時間が短くなるように、ひとまとまりの論理構造を、例えば同じトラック内に保持するようにすると好適であるが、これに限定されるものではない。
【００３３】
図１４は、変換部１１４により実行される処理の流れの一例を示すフローチャートである。まず、変換部１１４は、不揮発性メモリ１５４への書き込みタイミングが到来するまで待機する（Ｓ１００）。不揮発性メモリ１５４への書き込みタイミングとは、前述したようにキャッシュメモリ１５２に一定量のデータが格納されたタイミング、データベースサーバ１００がシャットダウンされるタイミング、直近までの集計処理が依頼されたタイミングなど、任意に定義することができる。
【００３４】
不揮発性メモリ１５４への書き込みタイミングが到来すると、変換部１１４は、キャッシュメモリ１５２に格納されたレコードを一つ選択し（Ｓ１０２）、そのレコードに含まれるデータ項目を一つ選択する（Ｓ１０４）。そして、変換部１１４は、選択したデータ項目が、既に管理済のデータ項目であるか否かを判定する（Ｓ１０６）。
【００３５】
選択したデータ項目が、既に管理済のデータ項目である場合、変換部１１４は、そのデータ項目の末尾にデータを追加する（Ｓ１０８）。一方、選択したデータ項目が、既に管理済のデータ項目でない場合、変換部１１４は、列を新たに設定（定義）し、設定した列にデータを書き込む（Ｓ１１０）。また、変換部１１４は、書き込んだデータ項目に関する情報をスキーマ情報１５４Ｂに追加する（Ｓ１１２）。
【００３６】
次に、変換部１１４は、選択されているレコードの全てのデータ項目を選択したか否かを判定する（Ｓ１１４）。選択されているレコードの全てのデータ項目を選択していない場合、Ｓ１０４に処理が戻される。選択されているレコードの全てのデータ項目を選択した場合、変換部１１４は、キャッシュメモリ１５２に格納されている全てのレコードを選択したか否かを判定する（Ｓ１１６）。キャッシュメモリ１５２に格納されている全てのレコードを選択していない場合、Ｓ１０２に処理が戻される。キャッシュメモリ１５２に格納されている全てのレコードを選択した場合、本フローチャートの１ルーチンの処理が終了する。
【００３７】
［データ利用者インターフェース］
以下、データ利用者インターフェース１２０の機能について説明する。データ利用者インターフェース１２０は、例えば、データ利用者サーバ５０からの要求に応じて、表形式のデータ（配列データ）を提供する。データ利用者サーバ５０からの要求は、任意のデータ項目を指定して行われる。この際に、データ利用者インターフェース１２０は、指定されたデータ項目を含まないレコードに関しては、そのデータ項目に対応するデータを「ｎｕｌｌ」（或いはブランクなど、「該当データ無し」を示す任意の形態であってよい）とした表形式のデータを生成してデータ利用者サーバ５０に提供する。また、データ利用者インターフェース１２０は、指定されたデータ項目が既に管理されているデータ項目の中に無い場合、エラーを返すのではなく、そのデータ項目についてのデータを全て「ｎｕｌｌ」（或いはブランクなど、「該当データ無し」を示す任意の形態であってよい）とした表形式のデータを生成してデータ利用者サーバ５０に提供する。なお、データ利用者サーバ５０からの要求は、例えば所定の拡張子を指定することで行われてよい。
【００３８】
例えば、図１０に示すようなデータがクライアントデータ１５４Ａとして不揮発性メモリ１５４に格納されている状態で、データ項目［ｓｅｘ、ａｇｅ、ｊｏｂ、ｈｏｂｂｙ（趣味）］を指定したデータの要求があったとする。この場合、データ利用者インターフェース１２０による出力データのイメージは、図１５のようになる。図１５は、データ利用者インターフェース１２０による出力データのイメージを示す図である。図示するように、データ利用者インターフェース１２０による出力データは、データの有無に拘わらず、レコードごと且つデータ項目ごとにデータを配列化して表したデータである。これによって、データベースサーバ１００は、データ利用者サーバ５０のニーズに応じた形式でデータを提供することができる。
【００３９】
図１６は、データ利用者インターフェース１２０により実行される処理の流れの一例を示すフローチャートである。まず、データ利用者インターフェース１２０は、データの要求を取得するまで待機する（Ｓ２００）。データの要求を取得すると、データ利用者インターフェース１２０は、スキーマ情報１５４Ｂから、現時点でのレコードの最大数を取得する（Ｓ２０２）。この最大数をｎとする。次に、データ利用者インターフェース１２０は、データの要求に含まれるデータ項目数×ｎの配列を定義する（Ｓ２０４）。この配列が、出力データの枠組みとなる。
【００４０】
次に、データ利用者インターフェース１２０は、データの要求からデータ項目を一つ選択し（Ｓ２０６）、選択したデータ項目が、既にクライアントデータ１５４Ａに設定済であるか否かを判定する（Ｓ２０８）。データ利用者インターフェース１２０は、選択したデータ項目が、既にクライアントデータ１５４Ａに設定済でない場合、当該データ項目のデータを全てｎｕｌｌにする（Ｓ２１０）。
【００４１】
一方、選択したデータ項目が、既にクライアントデータ１５４Ａに設定済である場合、データ利用者インターフェース１２０は、クライアントデータ１５４Ａから、現在選択されているデータ項目のデータを一つ読み出す（Ｓ２１２）。次に、データ利用者インターフェース１２０は、Ｓ２１２において読み出し可能なデータが存在しなかったか否かを判定する（Ｓ２１４）。Ｓ２１２において読み出し可能なデータが存在した場合、データ利用者インターフェース１２０は、その読み出しに至るまでにレコード番号が飛ばされたか否かを判定する（Ｓ２１６）。レコード番号が飛ばされた場合、データ利用者インターフェース１２０は、飛ばされたレコード番号のデータをｎｕｌｌにする（Ｓ２１８）。そして、データ利用者インターフェース１２０は、クライアントデータ１５４Ａから読み出したデータをＳ２０４で設定した配列に含める（Ｓ２２０）。
【００４２】
Ｓ２１０の処理を行った後、或いは、Ｓ２１４において肯定的な判定を得た後、データ利用者インターフェース１２０は、繰り返しＳ２０６が行われる中で全てのデータ項目を選択したか否かを判定する（Ｓ２２２）。全てのデータ項目を選択していない場合、Ｓ２０６に処理が戻される。一方、全てのデータ項目を選択した場合、データを出力する（Ｓ２２４）。この段階で、配列における全てのデータに、クライアントデータ１５４Ａから読み出されたデータ、或いはｎｕｌｌが格納されている筈である。
【００４３】
データベースサーバ１００が管理するクライアントデータ１５４Ａは、一つのデータ項目の中に、更に階層的なデータを含んでもよい。例えば、ｈｏｂｂｙのように、複数のデータが該当するようなデータ項目が存在する。この場合、図１７に示すようなデータが変換部１１４に渡される場合がある。図１７は、変換部１１４による他の機能について説明するための図である。図中、ｈｏｂｂｙ（１−ｈ）はレコード１におけるデータ項目ｈｏｂｂｙのｈ番目のデータを示している。変換部１１４は、これらを同様に列指向型のデータ構造で管理すると共に、同一のレコードに含まれるデータであることをスキーマ情報１５４Ｂに残しておく。図１８は、図１７の例に対応したスキーマ情報１５４Ｂの一例を示す図である。
【００４４】
以上説明した本発明のデータ管理装置、データ管理方法、およびプログラムによれば、入力された書き込み要求を解釈して抽象表現に変換する解釈部１１２と、解釈部１１２により抽象表現に変換されたデータを、予め配列が確保されていない列指向型のデータ構造に変換して、記憶部１５０に記憶させる変換部１１４と、を備えることにより、非構造な入力データを、データ項目ごとに高速に読み出し可能な態様で保存すると共に、入力データの追加や削除を容易に行うことができる。
【００４５】
以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。
【符号の説明】
【００４６】
１０  端末装置
２０  フロントエンドサーバ
３０  プロキシサーバ
５０  データ利用者サーバ
１００  データベースサーバ
１１０  フロントエンドインターフェース
１１２  解釈部
１１４  変換部
１２０  データ利用者インターフェース
１５０  記憶部
１５２  キャッシュメモリ
１５４  不揮発性メモリ
１５４Ａ  クライアントデータ
１５４Ｂ  スキーマ情報
【図１】
2018156233.tif 000003
【図２】
2018156233.tif 000004
【図３】
2018156233.tif 000005
【図４】
2018156233.tif 000006
【図５】
2018156233.tif 000007
【図６】
2018156233.tif 000008
【図７】
2018156233.tif 000009
【図８】
2018156233.tif 000010
【図９】
2018156233.tif 000011
【図１０】
2018156233.tif 000012
【図１１】
2018156233.tif 000013
【図１２】
2018156233.tif 000014
【図１３】
2018156233.tif 000015
【図１４】
2018156233.tif 000016
【図１５】
2018156233.tif 000017
【図１６】
2018156233.tif 000018
【図１７】
2018156233.tif 000019
【図１８】
2018156233.tif 000020
【手続補正書】
【提出日】平成29年7月31日(2017.7.31)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
入力されたデータ格納要求を解釈し、多次元空間での木構造をデータフォーマットから切り離して抽象化したオブジェクトに変換する解釈部と、
前記解釈部により抽象表現に変換されたデータを、前記変換されたデータとは別のデータ構造であって、予め配列が確保されていない列指向型のデータ構造で管理しながら記憶部に記憶させると共に、前記抽象化したオブジェクトを前記記憶部に記憶させる変換部と、
を備えるデータ管理装置。
【請求項２】
前記変換部は、前記抽象化したオブジェクトをそのまま前記記憶部に記憶させる、
請求項１記載のデータ管理装置。
【請求項３】
前記列指向型のデータ構造は、前記データ格納要求に含まれるレコードに含まれるデータが、データ項目ごとにひとまとまりの論理構造でまとめられたデータ構造であり、
前記変換部は、前記データ格納要求に含まれるデータ項目が、前記列指向型のデータ構造に設定されていないデータ項目である場合、新たな列を追加する、
請求項１または２記載のデータ管理装置。
【請求項４】
前記列指向型のデータ構造で管理されるデータを、入力されたデータ要求に含まれるデータ項目ごとに前記記憶部から読み出して出力するデータ利用者インターフェースを更に備える、
請求項１から３のうちいずれか１項記載のデータ管理装置。
【請求項５】
前記データ利用者インターフェースは、指定されたデータ項目を含まないレコードに関しては、当該データ項目に対応するデータを、該当するデータが存在しないことを示す任意の形態のデータで埋める、
請求項４記載のデータ管理装置。
【請求項６】
前記データ利用者インターフェースは、指定されたデータ項目が、前記列指向型のデータ構造に設定されていないデータ項目である場合、当該データ項目についてのデータを全て、該当するデータが存在しないことを示す任意の形態のデータで埋める、
請求項４または５記載のデータ管理装置。
【請求項７】
コンピュータが、
入力されたデータ格納要求を解釈し、多次元空間での木構造をデータフォーマットから切り離して抽象化したオブジェクトに変換し、
前記抽象表現に変換されたデータを、前記変換されたデータとは別のデータ構造であって、予め配列が確保されていない列指向型のデータ構造で管理しながら記憶部に記憶させると共に、前記抽象化したオブジェクトを前記記憶部に記憶させる、
データ管理方法。
【請求項８】
コンピュータに、
入力されたデータ格納要求を解釈させ、多次元空間での木構造をデータフォーマットから切り離して抽象化したオブジェクトに変換させ、
前記抽象表現に変換されたデータを、前記変換されたデータとは別のデータ構造であって、予め配列が確保されていない列指向型のデータ構造で管理しながら記憶部に記憶させると共に、前記抽象化したオブジェクトを前記記憶部に記憶させる処理を行わせる、
プログラム。
【手続補正書】
【提出日】平成29年11月13日(2017.11.13)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
入力されたデータ格納要求を解釈し、多次元空間での木構造をデータフォーマットから切り離して抽象化したオブジェクトに変換する解釈部と、
前記解釈部により抽象表現に変換されたデータを、前記変換されたデータとは別のデータ構造であって、予め配列が確保されていない列指向型のデータ構造で管理しながら記憶部に記憶させると共に、前記抽象化したオブジェクトに基づいて、前記列指向型のデータ構造で管理されるデータを、行方向に読み出し可能にするための参照情報を生成し、前記生成した参照情報を前記記憶部に記憶させる変換部と、
を備えるデータ管理装置。
【請求項２】
前記列指向型のデータ構造は、前記データ格納要求に含まれるレコードに含まれるデータが、データ項目ごとにひとまとまりの論理構造でまとめられたデータ構造であり、
前記変換部は、前記データ格納要求に含まれるデータ項目が、前記列指向型のデータ構造に設定されていないデータ項目である場合、新たな列を追加する、
請求項１記載のデータ管理装置。
【請求項３】
前記列指向型のデータ構造で管理されるデータを、入力されたデータ要求に含まれるデータ項目ごとに前記記憶部から読み出して出力するデータ利用者インターフェースを更に備える、
請求項１または２記載のデータ管理装置。
【請求項４】
前記データ利用者インターフェースは、指定されたデータ項目を含まないレコードに関しては、当該データ項目に対応するデータを、該当するデータが存在しないことを示す任意の形態のデータで埋める、
請求項３記載のデータ管理装置。
【請求項５】
前記データ利用者インターフェースは、指定されたデータ項目が、前記列指向型のデータ構造に設定されていないデータ項目である場合、当該データ項目についてのデータを全て、該当するデータが存在しないことを示す任意の形態のデータで埋める、
請求項３または４記載のデータ管理装置。
【請求項６】
コンピュータが、
入力されたデータ格納要求を解釈し、多次元空間での木構造をデータフォーマットから切り離して抽象化したオブジェクトに変換し、
前記抽象表現に変換されたデータを、前記変換されたデータとは別のデータ構造であって、予め配列が確保されていない列指向型のデータ構造で管理しながら記憶部に記憶させると共に、前記抽象化したオブジェクトに基づいて、前記列指向型のデータ構造で管理されるデータを、行方向に読み出し可能にするための参照情報を生成し、前記生成した参照情報を前記記憶部に記憶させる、
データ管理方法。
【請求項７】
コンピュータに、
入力されたデータ格納要求を解釈させ、多次元空間での木構造をデータフォーマットから切り離して抽象化したオブジェクトに変換させ、
前記抽象表現に変換されたデータを、前記変換されたデータとは別のデータ構造であって、予め配列が確保されていない列指向型のデータ構造で管理しながら記憶部に記憶させると共に、前記抽象化したオブジェクトに基づいて、前記列指向型のデータ構造で管理されるデータを、行方向に読み出し可能にするための参照情報を生成し、前記生成した参照情報を前記記憶部に記憶させる処理を行わせる、
プログラム。