XML-DB「NeoCore」と全文検索エンジン・NoSQLとの違い

XMLデータベース（XML DB）「NeoCore」と全文検索エンジンとの違い

一般的に、ドキュメントやコンテンツのデータは、利用が進むほど格納すべきデータが増えるため、それらの管理を行うシステム内に占める容量もどんどん増大します。また、格納だけで終わるわけではありません、そのような状況となると、格納後閲覧・再利用を行う際に、取り出す方法が問題となります。

大量のデータ内から目当てのコンテンツを探すという意味では、検索エンジンとデータベースは一見同じような機能を提供するように見えますが、取り出す方法が異なります。検索エンジンは複数のキーワードがヒットする情報を抽出することができるため、非常に手軽な方法ですが、次のような問題があります。

対象となるデータが巨大になればなるほど、検索結果の候補数が増大する

例）同じような性質をもった、①100件のデータと、②100万件のデータから「制御装置 最新」などのキーワードで検索をかけると、検索結果の候補数は、②の場合は①の場合の1万倍となります。

似たデータばかりを格納しているデータの集合体から目当ての情報を取り出しにくい

例）1万件のデータの集合体から「制御装置 最新」に関係するデータを抽出しようとしても、半分のデータに同一のキーワードが含まれていると候補は5,000件抽出されることになり、余り検索の意味をなしません。

キーワードと直接一致するデータしか検索できない

例）1万件のデータから「2010年1月～3月までに制御装置に関する記述が最新化されたデータ」という抽出は、検索エンジンでは不可能です

これらの課題を解決するのが、NeoCoreが実装する「Xpath/Xquery」の技術となります。W3Cに準拠しているXpath/Xquery により、大量のXMLデータに対してクエリ（データベースに対する問い合わせ言語）を用いた検索を行うことができるため、例えば以下のような検索を行うことができます。

格納するドキュメント数やコンテンツ数が増加することが明確である場合、Xpath/Xqueryによる検索が可能なXMLデータベース「NeoCore」でXMLデータを保持しておくと、探したいデータがすぐに探せるので安心ですね！

XMLデータベース（XML DB）「NeoCore」とNoSQLとの違い

NoSQLとは、一般に "Not only SQL" と解釈される概念で、RDBをはじめとする、データの堅牢性を保証するACID特性※ を担保するデータベース管理システムとは異なるカテゴリに属するデータベースとなります。XMLデータベース「NeoCore」もACID特性を有しており、データの堅牢性や、確実なトランザクション処理などを行えることが特徴となっています。

一般的にNoSQLに属するカテゴリのデータベースでは、大規模かつ単純なデータを分散処理することに適しており、大きく分けて以下が存在します。

• キーバリュー型データベース
  キーバリューストア（Key Value Storeとも呼ばれ、キーに対してバリュー（値）を格納する単純なアーキテクチャを持つデータベースとなる。バリューの形式としては、BLOB（Binary Large Object）形式による単純なバイナリデータで格納されることが一般的である。製品としては、memchaed、Redis、BigTableなどがある。
• ソート済みカラム指向（列志向）データベース
  行キーに対してカラム（名前と値の組み合わせ）の集合を管理するデータベースであり、行ごとに好きな名前のカラムを好きな数だけ格納することが可能なアーキテクチャを持つデータベース管理システムとなる。製品としては、Apache Cassandra, Apache HBaseなどがある。

そのほかにも、ドキュメント指向型といったものもあり、Webに特化した場合はJSON、コンテンツマスタとしてデータベース化し再利用や流用を行う場合はXMLで管理されることが多くなります。したがってXMLデータベースもドキュメント指向データベースのカテゴリに入るデータベースという事になります。
※ACID特性：関連する複数の処理を一つの処理単位にまとめて管理するトランザクション処理に求められる4つの特性（原子性・一貫性・独立性・永続性）のこと。

XMLを活用した新しい開発スタイル

アプリケーションの設計変更コストを削減する「NeoCore」

ビジネス環境がスピード化・多様化する中で、情報系システムの開発・運用フェーズで「仕様変更が頻繁に発生する」事は、もはや避けられない状況です。ビジネスが変われば当然管理すべきデータも変わり、さらにデータを支えるアプリケーションにも影響が及びます。従来のRDBは、厳密なスキーマ情報を前提とするデータベースであるため、「仕様変更＝スキーマ変更」となり、さらに適正なパフォーマンスを確保するために「インデックス再設計」が必要でした。

「NeoCore」は、厳密なスキーマ設計を必要としないため、ビジネスサイドからの要求によって発生するスキーマ設計とインデックス再設計にかかるシステムエンジニアコストと時間を大幅に削減する事を可能にしました。