ホワイト ペーパー
データ仮想化と
NOSQL データ ストア
はじめに データ管理やデータ ストレージの分野には、従来の SQL ベースのリレーショナル デー タベースよりも優れた手法を模索する動きがあります。 こうした傾向は 2009 年に始まり、NoSQL（「no SQL」を意味する）と呼ばれていました が、その表記はその後、NOSQL（「not only SQL」を意味する）に変わりました。 残念ながらいずれの表記も、否定的な内容しか表していないため、データ ストア全体の 混乱を招く原因となっています。 一般に、NOSQL データ ストアは、厳密には表形式やリレーショナル形式でないデータ を管理するため、データの作成や取得に SQL を使用しても意味がないものと定義され ています。具体的に言うと、NOSQL データ ストアは通常、リレーショナル形式ではく、 分散され、水平方向に拡張可能なオープン ソース ストアですが、個々の NOSQL デー タ ストアを見ると例外もあります。 NOSQL のアクセス標準はまだ完全には策定されておらず、各データ ストアごとに、 NOSQL データへのアクセスに適した Java ベースの API が用意されています。 Cisco Data Virtualization Platform では、これらの API を使用して 3 種類の NOSQLデータ ソースにアクセスし、それらのデータ ソースを統合します。
このホワイト ペーパーでは、市場における主な NOSQL データ ソースについて説明し、
Cisco Data Virtualization Platform を使用してそれらのソースを他のソースに統合す る方法について説明します。
ビジネスと IT の原動力
データの出現でした。こうした大企業によるカスタム エンジニアリング開発からさまざま な NOSQL データ ストアが生まれました。 予測分析、顧客の声、顧客離れ防止、不正行為対策などの「ビッグデータ」の使用例が 見られ、このタイプのデータ ストアへの需要はさらに高まっています。 こうしたデータの保存や処理方法により、新たなデータ ストアを求める動機が浮き彫り になりました。 • 1 テラバイトあたりのコスト：NOSQL データ ソースの多くは、大量に作成される Web スケールのデータ（Web サイトのクリック ストリームなど）を処理するために 考案されました。この大量のデータを従来のリレーショナル データベースに保存 すると、コストがかかり非効率的です。NOSQL データ ソースの多くはオープン ソースで、一般的なハードウェア上で稼働します。このため、Oracle や Teradata などのベンダーが提供する従来のデータベースと比べて 1 テラバイトあたりのコ ストを大幅に削減できます。 • 分散処理：Web スケールのデータは、量が膨大であるため、従来型のデータ ベースの保存、インデックス作成、検索では適切に処理できません。NOSQL データ ソースでは、水平方向に拡張するストレージ アーキテクチャと、分散デー タを効率的に処理するために設計された並列アルゴリズムが導入されています （最も顕著な例が「MapReduce」です）。 • データ形状の妥当性：成功を収めている多くの Web ベース サービスでは、リ レーショナル形式では効率的に表現できないデータが導入されており、より適した 新たなデータ構造を求める動機となっています。たとえば、ソーシャル メディア Web サイトでは、このようなサービスに固有のソーシャル リレーションシップを表 すためにグラフ データベースを採用しています。 NOSQL データ ストアの状況 NOSQL データ ストアを誕生させる動機となったのは Web スケールのデータでしたが、 これがきっかけとなり、処理言語として SQL を使用しないさまざまなデータ ストアが広 まりました（そのため、NOSQL データ ストアを正確に定義することが難しくなりました）。 NOSQL データ ストアの一般的な分類方法はありませんが、以下のカテゴリ分けでほ ぼすべてをカバーできます。 表形式/カラム型データ ストア 表形式のスパース データを保存するこのストアは、従来の表形式データベースに最も 似ています。例としては、Hadoop/HBase（Yahoo!）、BigTable（Google）、Hypertable、 VoltDB などがあります。その主なデータ取得パラダイムでは、一般にハンドコーディン グされた MapReduce アルゴリズムを利用するカラム フィルタが使用されます。
ドキュメント ストア この NOSQL データ ソースには、非構造化（テキスト）ドキュメントまたは半構造化 （XML）ドキュメントが保存されます。例としては、MongoDB、MarkLogic、CouchDB な どがあります。データの取得パラダイムはさまざまに異なりますが、ドキュメントは常に 一意のハンドルにより取得できます。XML データ ソースでは XQuery を利用します。テ キスト ドキュメントはインデックス化されるため、キーワード検索などにより簡単に取得 できます。 グラフ データベース ノード、エッジ、およびプロパティを含むグラフ指向のデータを保存する NOSQL ソース で、ソーシャル ネットワークにおける関連付けの保存によく使用されます。例としては、 Neo4J、AllegroGraph、FlockDB などがあります。データ取得は、特定のノードから関 連付けを取得することに焦点をあてています。 キー/値ストア このソースには、従来のハッシュ テーブルのようなシンプルなキーと値のペアが保存さ れます。これはさらに、インメモリ ソリューションとディスク ベースのソリューションに分け られます。おそらく、NOSQL システムはこのカテゴリに分類されるものが最も多く、それ ぞれの特性は微妙に異なります。例としては、Memcached、Cassandra（Facebook）、 SimpleDB、Dynamo（Amazon）、Voldemort（Linked-In）、Kyoto Cabinet などがあり ます。データ取得パラダイムはシンプルで、キーを指定すると値が返されます。値の中 身を検索できる、より複雑な「クエリ」メカニズムを提供するものもありますが、通常、値 はアクセスできないものと見なされます。 オブジェクト データベースと複数値データベース このタイプのストアは NOSQL よりも前に存在していましたが、この動きの一環として新 たに見直されています。オブジェクト データベースにはオブジェクトが保存されます（オ ブジェクト指向のプログラミングと同様）。複数値データベースには表形式データが保存 されますが、個々のセルに複数の値を保存できます。例としては、Objectivity、 GemStone、Unidata などがあります。データの取得には独自のクエリ言語が使用され ます。 その他の NOSQL ソース その他にも、上記いずれのカテゴリにも当てはまらない、NOSQL データ ストアがありま す。例としては、GT.M、IBM Lotus/Domino、ISIS ファミリなどがあります。 データ仮想化を使用した NOSQL データ ストアの統合
Cisco Data Virtualization Platform は、さまざまなソースのデータを検出、アクセス、 フェデレーション、抽出、および配信するためのシンプルで完全な開発環境とランタイム 環境を提供します。
通常、アクセスは標準ベースのプロトコルおよび API を介して行われます。たとえば、 SQL ベースのソースの場合は JDBC や ODBC、Web サービスの場合は HTTP や SOAP、メッセージの場合は JMS、エンタープライズおよびクラウドベースのアプリケー ションの場合は API が使用されます。これらの方法により、ソース データは、物理的な 保存場所や保存方法に関係なく、単一の仮想の場所から安全に取得されます。 NOSQL のアクセス標準はまだ完全には策定されておらず、各データ ストアごとに、 NOSQL データへのアクセスに適した Java ベースの API が用意されています。Cisco Data Virtualization Platform では、これらの API のほか、Cisco Information Server のカスタム Java プロシージャ（CJP）リソースを使用して NOSQL データにアクセスし、 データを統合します。この統合には、3 種類の NOSQL システムが特に適しています。 表形式/カラム型データ ストア、XML ドキュメント ストア、およびキー/値ストアです。それ ぞれの統合方式の詳細について以下で説明します。 将来、NOSQL をリードする企業が現れ、使用パターンが標準化されたら、シスコは完 全なサポート アダプタを開発して、特定の NOSQL データ ストアとのさらに綿密な統合 を実現します。 表形式/カラム型データ ストア
Cisco Data Virtualization Platform では、Hive を介した Hadoop アクセスがサポート されています。Cisco Information Server（CIS）でも、MapReduce InputFormat を介し て Hadoop にデータを提供できます。
Hadoop がソースの場合、CIS は Apache Hive を介して Apache Hadoop に SQL ク エリを送信します。結果セットがすでに存在する場合は、Hive から直接データが返され ます。結果セットの削減が必要な場合は、データが CIS に返される前に、Hive によって 適切な MapReduce 関数が実行されます。これは、Hadoop クエリ専用の
MapReduce コーディングを強化する標準的な SQL アプローチです。
CIS Hadoop Connector は、MapReduce 開発者が事実上、CIS のビューやデータ サービスをオンデマンドで MapReduce ジョブに統合できるようにする、MapReduce InputFormat API の高性能実装です。CIS では、Hadoop データ ストアへの一括レプリ ケーションや広範な Java コーディング、パフォーマンスの低いクエリ アプローチを使用 することなく、従来のエンタープライズ データへの MapReduce のネイティブ アクセスを シンプルにします。さらに、CIS は、並列処理などの最適化処理を InputFormat API に
自動的に追加します。これにより、CIS から MapReduce に返されるデータが適切に分 散され、MapReduce のパフォーマンスが最適化されます。
その他のタイプの表形式/カラム型ストアの場合は、Cisco Data Virtualization Platform の最初の実装で表形式データが統合されているため、データの取得と処理は容易です。 このアプローチでは、「テーブル関数」を SQL 文の FROM 句に組み込む CIS の機能 が利用されます。つまり、カーソルを返す任意のシスコ プロシージャ リソースをテーブ ルとしてビュー エディタにドロップし、SQL 文の FROM 句に表示することができます。 特定の NOSQL データ ストアでは、NOSQL システムの Java API を利用する CJP テーブル関数の集まりを実装できます。各 CJP は、基になる NOSQL データ ストアの 異なるテーブルにアクセスを提供します。CJP は、入力引数を受け取ってテーブルの データをフィルタ処理し、さらに NOSQL システムの処理能力を利用することができます。 ビューの「仮想カラム」機能を利用して、実行時にクライアント クエリからフィルタの値を 指定することもできます。 これらの表形式/カラム型 NOSQL データ ソースには膨大なデータ セットが保存されて いるため、大規模なクエリを行う際は注意が必要です。テーブル関数を実装した場合、 対象となるデータ ソースのデータを、入力パラメータを利用して十分に削減する必要が あります。また、これらのデータ ソースに対する要求の処理にはかなりの時間がかかる 場合があるため（ライブ クエリというよりもバッチ ジョブに近い時間がかかります）、何ら かの形でキャッシュを導入しておくことをお勧めします。 このアプローチでは、基になる NOSQL システムのデータにフル アクセスできるため、 短期的なニーズのほとんどに対応できるでしょう。ただし、このアプローチにはデメリット や非効率な点がいくつかあります。たとえば、CJP のカーソルで指定したカラムは、現 在のクエリですべて必要とされるわけではない場合でも、常にすべて取得されます。ま た、基になるシステムで一般的なフィルタリングや集約を実行できる場合がありますが、 そうした機能を CIS で使用するための CJP のインターフェイスは限られています。特定 の NOSQL 表形式データ ストアが普及すれば、その特定のデータ ソースの機能を完 全に統合して利用するためのカスタム アダプタが開発されるものと見込まれます。 XML ドキュメント ストア XML ドキュメント ストアでは XQuery がデータ取得パラダイムとして優先的に使用され るため、Cisco Data Virtualization Platform では組み込みの XQuery エンジンと XML ネイティブ データ型を利用して、このカテゴリの NOSQL データ ストアから簡単にドキュ メントを取得し、処理することができます。
Java API を使用する特定の NOSQL XML ドキュメント ストアの場合は、少なくとも 2 つの CJP プロシージャが必要です。どちらの CJP も、いずれかのアップストリーム XML 操作機能（XSLT 変換など）でさらに操作できる XML ドキュメントを返します。1 つ 目の CJP は唯一の入力引数としてドキュメント ハンドル（一意の識別子）を受け取り、 API を使用してそのドキュメントを取得し、返します。2 つ目の CJP は唯一の入力引数 として XQuery の指定を受け取り、API を使用してクエリを実行し、結果を 1 つのドキュ メントとして返します。もちろん、さらに詳細なパラメータを受け取る追加の CJP を実装 することもでき、複数のビューへの統合が容易になります。 このアプローチでは、基になる XML データ ソースのデータにフル アクセスできるため、 ほとんどのニーズに十分に対応することができます。 キー/値ストア
Cisco Data Virtualization Platform では、キー/値ストアを 2 つの方法で統合できます。 1 つ目は、カスタムの SQL 関数を使用する方法です。つまり、パラメータとしてキーを 受け取り値を返す関数を作成します。この関数は、シスコ データ仮想化全体で、複数の SQL 文で使用できます。 2 つ目は、CIS でキャッシュ ターゲットとしてインメモリのキー/値ストアを利用する方法 です。当社の大企業や政府機関のお客様は、主にこの方法を取っています。このアプ ローチは、小規模なデータ セットやプロシージャの結果に対して最適ですが、大規模な 表形式データ セットには適していません。さらに、この形式のキャッシュ統合では、 キャッシュされている表形式データとキャッシュされているキー/値のデータの間でイン ピーダンス不整合が生じることがよくあるため（キャッシュ データはキー/値ストア内でア クセス不可）、セット全体を取得して処理する必要があります。現在、この形式での統合 は当社のプロフェッショナル サービス部門からご利用いただけます。 まとめ NOSQL データ ストアは、Web スケールのデータをサポートする手法として急速に普及 しています。予測分析、顧客の声、顧客離れ防止、不正行為対策などの「ビッグデータ」 の使用例が見られ、需要はさらに高まっています。 NOSQL システムにはさまざまなタイプがあり、それぞれに固有の使用例やメリットがあ ります。各 NOSQL データ ストアには、これらのソースにアクセスし、統合するために使 用できる独自の非標準 API があります。
Cisco Data Virtualization Platform は、これらの NOSQL ソースのデータを企業内外 の他のデータと統合するのに適しています。Cisco Data Virtualization Platform では、 表形式/カラム型データ ストア、XML ドキュメント ストア、インメモリのキー/値ストアの 3 種類の NOSQL データ ストアを統合します。 現在、シスコは、標準リソースを使用した最小限のプログラミングによる、NOSQL デー タ ストアのデータへの基本アクセスを提供しています。将来的に NOSQL の特定分野 をリードする企業が出現したときには、シスコは標準製品アダプタを作成してさらに綿密 な統合を実現します。
©2015 Cisco Systems, Inc. All rights reserved.
Cisco、Cisco Systems、および Cisco Systems ロゴは、Cisco Systems, Inc.またはその関連会社の米国およびその他の一定の国における登録商標または商標です。 本書類またはウェブサイトに掲載されているその他の商標はそれぞれの権利者の財産です。 「パートナー」または「partner」という用語の使用は Cisco と他社との間のパートナーシップ関係を意味するものではありません。(1502R) この資料の記載内容は 2015 年 2 月現在のものです。 この資料に記載された仕様は予告なく変更する場合があります。 シスコシステムズ合同会社 〒107‐6227 東京都港区赤坂 9-7-1 ミッドタウン・タワー http://www.cisco.com/jp お問い合せ先
