Comments
Description
Transcript
エンタープライズ NoSQL For Dummies
これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 エンタープライズ NoSQL MarkLogic スペシャルエディション これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 エンタープライズ NoSQL MarkLogic スペシャルエディション Charlie Brooks著 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 エンタープライズ NoSQL For Dummies®, MarkLogicスペシャルエディション 発行者： John Wiley & Sons, Inc. 111 River St. Hoboken, NJ 07030-5774 www.wiley.com Copyright © 2015 by John Wiley & Sons, Inc. 本出版物のいかなる部分も、1976年アメリカ合衆国著作権法の107条又は108条において許可された場 合を除き、発行者の書面による事前の許諾なしに、電子式、印刷式、写真複写、録音、スキャン等どの ような形式、手段であれ、複製、情報検索システムへの保存、伝送することを禁じます。発行者への許 可申請は以下までお問い合わせください。Permissions Department, John Wiley & Sons, Inc.,111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/ go/permissions。 商標： Wiley、For Dummies、Dummies Manのロゴ、The Dummies Way、Dummies.com、Making Everything Easier、その他関連トレードドレスは、アメリカ合衆国およびその他各国おいて、John Wiley & Sons, Inc.、その関連会社、又はその両方の商標又は登録商標であり、書面による許諾なしに使 用することを禁じます。MarkLogic及びMarkLogicのロゴはMarkLogic社の登録商標です。その他の商 標はそれぞれの所有者に帰属します。John Wiley & Sons, Inc.は本書で言及されている、いかなる製品 およびベンダーとも何ら関係ありません。 賠償責任の制限/免責条項： 本書の発行者及び著者は、本書の内容の正確性及び完全性にいかなる表 明又は保証も行わないものとし、特定目的に対する適合性を含む、いかなる保証も行いません。販売 や販促資料によって何らかの保証を行ったり、保証を拡大したりすることは禁じます。本書に含まれ るアドバイス及び戦略は必ずしもすべての状況に当てはまるものではありません。本書は、本書の発 行者が法務、会計、又はその他専門分野のサービス提供に従事していないという理解のもとで販売さ れるものです。専門的な支援が必要な場合は適切な専門家のサービスを求めてください。本書の発行 者と著者はいずれも、本書により生じる損害に一切責任を負うものではありません。本書で、より詳 しい情報の潜在的なソース、引用元、あるいはその両方として企業組織又はウェブサイトを紹介して いる事実は、著者や発行者が、かかる企業組織又はウェブサイトが提供する情報及びアドバイスを保 証することを意味するものではありません。さらに、本書に掲載されているインターネットのウェブ サイトは、本書が書かれた時点から読者が読まれる時点までの間に、変更又は削除されている可能性 があることにご留意ください。 当社のその他の製品やサービスに関する情報、企業・組織用にカスタマイズしたFor Dummiesスペシャ ルエディションの制作については、当社の事業開発部（米国877-409-4177、[email protected]）に ご連絡いただくか、ウェブサイト（www.wiley.com/go/custompub）をご覧ください。製品やサー ビスへのFor Dummiesブランドのライセンス許諾については、Eメール（BrandedRights&Licenses@ Wiley.com）でお問い合わせください。 ISBN: 978-1-119-08125-8 (pbk); ISBN: 978-1-119-08124-1 (ebk) Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 目次 はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 本書について ............................................................................... 1 本書で使用されるアイコン........................................................ 2 追加リソース ............................................................................... 2 第1章: NoSQLの基礎知識 . . . . . . . . . . . . . . . . . . . . . . . . .5 NoSQLの用語を理解する ........................................................... 5 NoSQLとは何か .......................................................................... 7 4種類のデータベース ....................................................... 7 キーバリューデータベース ................................... 8 ドキュメントデータベース ................................... 8 カラムファミリーデータベース ........................... 8 グラフデータベース............................................... 9 スキーマ非依存................................................................ 10 複雑な結合が不要 ........................................................... 10 水平方向のスケーラビリティ........................................ 10 コモディティハードウェアの利用 ................................ 11 自己完結型 ...................................................................... 11 NoSQLによくある誤解 ............................................................. 12 SQLを使用するかどうかだけの問題？ ......................... 12 大企業用？ ...................................................................... 12 RDBMSの代替物？ ......................................................... 13 特別なハードウェアが必要？........................................ 13 リレーショナルデータベースと共存不可？ ................ 14 NoSQLはあなたのビジネスに適しているか .......................... 14 第2章: さまざまなDBMSの違い . . . . . . . . . . . . . . . . . .17 RDBMSとNoSQLを比較する .................................................... 17 RDBMSの基本原理 ......................................................... 18 NoSQLという代替手法 ................................................... 19 関係の扱い方 ............................................................................. 20 RDBMSの設計 ................................................................. 21 NoSQLの設計 .................................................................. 22 非正規に戻す ............................................................................. 23 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 vi エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション 第3章: NoSQLでデータセンターを変える . . . . . . . . .25 データの分散 ............................................................................. 25 シャーディング............................................................... 26 レプリケーション ........................................................... 27 マスター/スレーブ型レプリケーション ............ 27 ピアツーピア型レプリケーション...................... 27 ACIDテスト：データの一貫性 ................................................. 28 NoSQLにおけるACIDの条件 .......................................... 29 読み取り整合性と更新整合性........................................ 29 ドキュメントの永続性 ............................................................. 30 第4章: エンタープライズNoSQLでできること . . . .33 エンタープライズクラスのレプリケーション ....................... 34 エンタープライズクラスのデータバックアップ ................... 35 複数レコードのACIDトランザクション ................................. 36 エンタープライズクラスのセキュリティ............................... 37 認可とアカウンティング ............................................... 37 認証 .................................................................................. 38 アクセス制御 .................................................................. 38 コンパートメントセキュリティ .................................... 39 ポリシー管理 ............................................................................. 39 アドミンおよび管理ツール...................................................... 40 高可用性 .................................................................................... 41 スケーラビリティ ..................................................................... 42 サードパーティーのソリューションとの統合 ....................... 42 第5章: エンタープライズNoSQLの実例 . . . . . . . . . . .43 異種データの統合 ..................................................................... 43 地方自治体の例............................................................... 43 問題点 .................................................................... 44 ソリューション .................................................... 44 利点........................................................................ 45 投資銀行の例 .................................................................. 46 状況認識の向上 ......................................................................... 46 オペレーショナルデータの格納 .............................................. 48 データの発見と再利用 ............................................................. 49 出版社の例 ...................................................................... 51 放送局の例 ...................................................................... 51 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 目次 vii 第6章: NoSQLソリューションで考慮すべき 10項目 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 ソリューションを導入する準備はできているか ................... 53 そのソリューションは十分にアジャイルか ........................... 54 アプリケーションの要件を満たしているか ........................... 55 データを入れるのに必要な開発期間はどれくらいか ........... 55 新しいツールは必要か ............................................................. 56 クラウド戦略に対応しているか .............................................. 56 エンタープライズ対応か ......................................................... 57 特殊なハードウェアが必要か .................................................. 57 事業の成長に対応できるか...................................................... 58 アプリケーションの開発を加速できるか............................... 58 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 viii エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 出版社 謝辞 本書の出版にご尽力いただいた方々に感謝申し上げます。企業・組織用にカスタマイズし たFor Dummiesスペシャルエディションの制作については、[email protected]までお問 い合わせいただくか、www.wiley.com/go/custompubをご覧ください。製品やサービス へのFor Dummiesブランドのライセンス許諾についてはBrandedRights&Licenses@ Wiley.comまでお問い合わせください。 本書の出版にあたり、以下の方々をはじめとする多くの方々にご協力いただきました。 プロジェクトエディター：Carrie A. Johnson（キャリー・A・ジョンソン） 発注エディター：Connie Santisteban（コニー・サティステバン） 編集マネージャー：Rev Mengle（レヴ・メングル） 事業開発担当：Karen Hattan（カレン・ハタン） カスタム出版プロジェクトスペシャリスト：Michael Sullivan（マイケル・サリヴァン） プロダクションコーディネーター：Melissa Cossell（メリッサ・コセル） 特別協力：Adam Fowler（アダム・ファウラー）、Blossom Coryat（ブロッサム・ コルヤット）、Norm Walsh（ノーム・ウォルシュ） これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 はじめに N oSQLという言葉を耳にしたことがあっても、 それを明確に説 明することは難しいのではないでしょうか。実はNoSQLの背 景には、データの格納・アクセスに関する考え方の根本的な変革が あります。昨今生成される情報のほとんどは、Oracle、MySQL、SQL Server、PostgreSQLといった従来のデータベースでは扱うことが難 しいといわれる非構造化あるいは半構造化データなのです。 NoSQLが意味するものは、非常に広範です（NoSQLを厳密に定義 しようとすることは、ザルで水を むようなもので、ほとんど不可能 「 です）。インターネットでNoSQLデータベースを検索してみると、 非リレーショナル」、 「水平方向にスケーラブル」、そして 「（ほとんど の場合） スキーマ非依存」 といった共通のテーマが見つかると思い ます。 これらが意味するのは、NoSQLがリレーショナルデータベー スモデルの制約を取り払うものだということです。 本書について 『エンタープライズNoSQL For Dummies MarkLogicスペシャルエ ディション』 では、NoSQLの概要について解説します。本書を読み進 めることで、NoSQLとは何か、 また何ではないのか、 リレーショナル データベースマネジメントシステム（RDBMS）の代わりにNoSQLデ ータベースを検討すべきなのはどんなときなのか、 またその両方を 使うべきなのはどんなケースかといったことを理解していけるはず です。 さらに、本書ではエンタープライズNoSQLについて紹介し、他 のNoSQLシステムとどう違うのかを説明します。 NoSQLで、データ格納に関するすべての問題を解決できるわけで はありません。 また、すべてのNoSQLデータベースが同じように作 られているわけでもありません。本書は、最初から最後までお読み いただければうれしいですが、順番を気にせず興味のある章から 必要に応じて読んでも差し支えないように構成されています。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 2 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション 本書で使用されるアイコン 本書では、ページ左側に以下のようなアイコンが登場する箇所があ ります。各アイコンは特に注意してほしい段落を示しています。 ヒントアイコンは、特定の製品や手順について、時間を節約しストレ スを最小限に抑えるためのコツや、新しいやり方を説明している箇 所に表示しています。 ポイントアイコンは、他のことは忘れたとしてもこれだけは覚えてお くべきという情報に表示しています。 注意アイコンは、組織の業務全体や製品へのリスクがともなう深刻 な状況について説明している箇所に表示しています。NoSQLの落と し穴を避けるためには、 このアイコンが表示されている段落の情報 に注意しましょう。 技術情報アイコンは、 トピックを深く理解したい方向けの情報に表 示しています。 これらの段落は飛ばしていただいてもかまいません。 後でNoSQLの仕組みについてより深く技術情報を理解したくなった ときに、役立つでしょう。 追加リソース 本書を読み進まれるなかで「X、Y、あるいはZが可能なデータベー スなんて本当にあるのだろうか？」 と思われる方もいらっしゃるかも しれません。答えは、 イエス。 そのようなデータベースは存在します。 するとあなたはこう考えるかもしれません。 「でも、きっとそれを実 現するには大勢の開発者やアーキテクトが環境設定を行って、デ ータをデータベースに入れる必要があるのだろう」 と。いいえ、そん なことはありません。データを瞬時にデータベースに入れて、それ を即座に検索することは簡単にできるのです。添付ファイルから検 索結果を取り出すことだってできます。 データをアプリケーションに 関連付けたり、新しいアプリケーションを開発するのにも長い時間 はかかりません。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 はじめに 3 『エンタープライズNoSQL For Dummies MarkLogicスペシャル エディション』は、皆さんがエンタープライズNoSQLへの理解を深 めるお手伝いをしますが、 さらに詳しい情報をお求めの方は、以下 のリソースもご活用ください。 ✓MarkLogicは、エンタープライズクラスのNoSQLデータベー スです。MarkLogicのサービスを利用している企業は、新し いアプリケーションの開発に何年もかけることはありません。 数ヵ月、あるいは数週間という短期間での開発を実現してい ます。ユーザー企業の声はこちらでご確認いただけます。 http://po.st/tst4d ✓MarkMailで、6700万通以上のEメールおよび添付ファイルの 内容を検索してみてください。http://markmail.org ✓MarkLogicをダウンロードして、 自分のデータでどんなふうに 使えるかお試しください。jp.marklogic.com これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 4 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第1章 NoSQLの基礎知識 本章の内容 ▶主要なNoSQL用語を理解する ▶NoSQLとは何かを理解し、 NoSQLに対する誤解を解消する ▶NoSQLが自分のビジネスに適しているかを判断する N oSQLはまったく新しい概念というわけではありません（も ちろんNoSQLのソフトウェアには新しいものが出てきてい ますが）。実は1980年代にはすでにリレーショナルデータベース管 理システム（RDBMS）以外のデータベース構造が定義され使用さ れていました。では今いったい何が新しいのかというと、ビッグデ ータによって生じるさまざまな課題があるということです。 ビッグデータとは大規模かつ複雑なデータセットの集合体で、更 新が頻繁、大容量、データの種類が多様で複雑という特性を持って います。ビッグデータでは、データの取得、収集整理、格納、検索、共 有、転送、分析、可視化といったことが課題となります。 ただNoSQL自体は（使用されるコモディティコンピューターが日々 進化している点を除いては）技術的にはそう高度なものではあり ません。NoSQLとはサーバーの性能と機能をアプリケーションの 需要に合致させるための手段であり、 これまでユーザーにはアクセ ス不可能と思われていたデータリソースに、ユーザーがアクセスで きるようにするための方法です。 ですからNoSQLの使用にあたって は、既存の「RDBMSモデル」から 「アプリケーションのクエリに関し て最適化されたモデル」へという発想の転換が必要になります。 こ うした発想の転換をサポートするために、本章ではNoSQLの概要 を説明し、NoSQLによくある誤解を解消していきたいと思います。 NoSQLの用語を理解する NoSQLについて学ぶにあたり、新しい用語や自分が理解しているの とは違う意味で使われている用語があることに戸惑う方もいるかも これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 6 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション しれません。 どうぞご心配なく。 このセクションではNoSQLで使用され る用語について説明していきます。皆さんもすぐにシャーディングや レプリケーションについて、 ちゃんと議論できるようになるはずです。 まずNoSQLの読み方ですが、 ノーシークェル（no sequel）やノーエ スキューエル（no S-Q-L） と発音されることが多いようです。 アドバイ スとしては、話している相手がどう発音するかを聞いて、それと同じ 発音をすると良いでしょう。 では以下に重要なNoSQL用語を説明していきます。 ✓ノード：ノード とは何らかのサービス（通常は演算サービス）、 ローカルストレージ、大規模な分散データやファイルストアへ のアクセスを提供するネットワーク化されたコンピューターの ことを指します。 ✓クラスタ： NoSQLの世界でいうクラスタとは、1つのユニットを 構成する一組のノードのことを意味します。データベースによ って、データセンターの特定のラックに含まれる一連のノード である場合もあれば、同じ列に含まれるノードである場合もあ ります。 とは、特定 ✓シャーディング： シャーディング（または水平分割） フィールドの値でデータベースを分割することを言います。一 部のNoSQLでは各ノードのデータ量を同じくらいにするため にシャーディングが使用されています。シャーディングは直接 キー値をハッシュするか、ロードバランシング（各ノードから 負荷の軽いノードへデータを再分配すること）を行うことで実 現できます（第3章を参照のこと） 。 とはデータベー ✓レプリケーション：レプリケーション（複製） スの可用性を確保するための仕組みです。あるノードに障害 が起きても別のノードにデータの複製が存在するよう、デー タベースの各部分を複数のノードに書き込むことを意味しま す。 レプリケーションの詳細については第3章を参照してくだ さい。 、一貫性（consis✓ACID: ACIDとは原始性/不可分性（atomicity） 、永続性（durability）の頭文字をとっ tency） 、独立性（isolation） たものです。 ACIDは、 例えば銀行の取引やeコマースなどで使わ れるトランザクションシステムに求められる性質を表したもの で、 どのような記録システムにおいても不可欠となります。ACID については第3章で説明します。 ソ ✓BASE: BASEとは基本的に利用可能（basically available）、 （soft-state）、結果的に整合（eventually consisフトステート tent）の頭文字をとったものです。基本的に利用可能とは、デ ータベースが24時間年中無休で利用可能ではない可能性が これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第1章：NoSQLの基礎知識 7 あることを意味します。 ソフトステートとはデータベースの状 態が一時的に不整合となる場合があることを意味します。例 えばあなたが職場のEメールアドレスを変更した場合、あな たの友人がすぐにその情報を知るとは限りません。ただ友人 はいずれあなたのEメールが変更されたことを知ることにな ります。 これが結果的に整合するということです。 NoSQLとは何か データ管理の世界において、NoSQLにはいろいろなものがありま す。以下のセクションではNoSQLの主な特徴を説明していきます。 4種類のデータベース NoSQLは、それまでの階層型（厳密な階層による関係）やネットワ ーク型（レコードセットの導入による多対多の関係） といったデータ モデルとは大きく異なります。RDBMS（リレーショナル型） では関係 （エンティティ）はテーブルで表されます。各行（タプル）が特定のエ ンティティを表し、各列はエンティティの属性を表します。階層型や ネットワーク型と異なり、 リレーショナル型では属性は単一の値しか 持つことができません。つまり、あるエンティティが別の複数のエン ティティに関係していることを表したい場合、別のテーブルを作成し てその関係を示す必要があります。1つのタプルを別のタプルにネス ト化すること （繰り返しグループと呼ばれるプロセス）はできません。 NoSQLデータベースでも、テーブル、行、列という用語が頻繁に使 用されますが、RDBMSで使用されるのと同じ意味や制約は持ちま せん。NoSQLでこれらの用語がどのように使用されるのかを表1-1 にまとめました。 表 1-1 RDBMS 用語 パーティション テーブル 行 列 RDBMS用語とNoSQL用語の比較 NoSQL 用語 シャード ドキュメントルート要素（JSON/XML） ドキュメント/集約 （aggregate） またはレコード 要素/属性、 フィールド、 またはプロパティ NoSQLデータベースには主に4種類あります。以下のセクションで それぞれ説明していきます。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 8 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション キーバリューデータベース キーバリューデータベースでは、データの検索/インデックスのた めのキーと、内容を解釈しないバイト列としてのバリュー（値）でモ デル化します。 このタイプのデータベースはずいぶん前から存在し ていました。任意のレコードをそのキーに基づいて簡単かつ迅速 に読み出すことができますが、複数のレコードを対象として値を検 索することはできません。 キーバリューデータベースの 例として、ウェブ ページを考えて みましょう。この場合URLがキーであり、値となるコンテンツは HTML、PHP、JavaScriptまたはバイナリデータで表されます。 キーバリューデータベースでは通常ユニーク （一意の）キーが必要 となります。暗黙的な順序付けはありませんが、実装によってはキ ーの値によってデータベースを順序付けることもでき、その場合キ ーに対する範囲（レンジ）検索が可能となります。 ドキュメントデータベース ドキュメント （または集約（aggregate））データベースはキーバリュ ーデータベースと非常に似ていますが、違うのはキーに関連付け る値には、構造化あるいは半構造化されたデータを入れられるこ とです。 この値がドキュメントと呼ばれます。キーバリューデータベ ースと違って、 ドキュメント内の要素だけでなく、 ドキュメントの構 造そのものに対してもクエリを実行でき、 クエリの結果としてドキュ メントの一部のみを返すことができます。 ドキュメントデータベースの例として、蔵書データベースがありま す。 この場合、書籍名がキーであり、XMLドキュメントで表される書 籍のメタデータが値となります。 カラムファミリーデータベース カラムファミリーデータベースは理解するのが一番難しいかもしれ ません。 このデータベースは、非常に多くの行と列を持つ、巨大なテ ーブルと考えることができます。 しかし各行には、想定された列の総 数よりも少ない列しかありません。数学的にはこの配列は疎行列と 呼ばれます。 プログラマーはこれを、 キーをキーバリューペアの集合 に対応付けるためのハッシュテーブルまたは辞書と考えます。 カラムファミリーデータベースの例としては、URLがキーで、各列が ドキュメントの異なるバージョンを表すようなデータベースが考え られます。 この場合、1つのカラムファミリーにはそのページのメタ データが含まれ、別のカラムファミリーにはそのページがいつ変更 されたか、何が変更されたか、変更の度合いなどのデータが含まれ ます。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第1章：NoSQLの基礎知識 9 グラフデータベース グラフデータベースは上記のセクションで説明した3つのタイプと は異なり、 さまざまなエンティティ間の関係性に重点が置かれてい ます。 グラフにおけるノードは特定の種類のエンティティ （人または 物）を表し、 ノード間のエッジ（線）は特定の関係を表しています。エ ッジは一方向であり、エッジそのものが属性を持つこともあります。 グラフデータベースの例を図1-1に示しました。 図 1-1: グラフデータベースの例 例として、 メッセージングシステムであるツイッターの「フォロー」関 係を見てみましょう。チャーリーとクリスの関係は「チャーリーはクリ スをフォローしている」 と表すことができます。 この場合、 クリスは必 ずしもチャーリーをフォローしているとは限りません。 このような関 係は「ペア」 として以下のように表すことができます。 Follows (Charlie, Chris) 「トリプル」はアサーション（表明） と呼ばれる一かたまりの情報で、 以下のように表されます。 Charlie, follows, Chris 時間の経過とともに、 これらの個々のアサーションがグループ化され 「ファクト （事実）の網（ウェブ）」が構築されていきます。 この技術が セマンティックウェブの基礎となっています。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 10 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション トリプルについて トリプルの他の例を見てみまし ょう。 Oracle isA. Relational Database Paul Document databases awesome worksFor marklogic Alex worksIn. Marketing London isIn England Horse Riding sport Are typeOf スキーマ非依存 NoSQLデータベースが、 リレーショナルデータベースで言うところ のテーブル、行、列を持たないデータベースであることを考えれ ば、NoSQLが固定されたスキーマを持たないと聞いてもそう驚き ではないでしょう。 複雑な結合が不要 NoSQLデータベースは、結合（join）が必要ない、むしろ推奨されな い設計となっています。何らかの理由があって結合が必要な場合 は、MarkLogicのように複雑な結合を実行できるデータベースを 選択してください。 水平方向のスケーラビリティ データベースへの需要が増加するにつれ、いずれ、処理能力、 スト レージスペース、入力/出力（I/O）サイクルなど、何らかのリソースが 不足してきます。そうなると拡張方法を考えなければなりません。 よ り新しく性能が高いハードウェアを購入してスケールアップ（垂直方 向）するか、同等の処理能力を持つ新しいマシンを購入してスケー ルアウト （水平方向）するかを選ぶことになります。 NoSQLには後者のアプローチが適しており、NoSQLデータベース では新しいマシンを既存のデータベースクラスタに簡単に組み込 めるようになっています。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第1章：NoSQLの基礎知識 11 コモディティハードウェアの利用 設計目的の1つが水平方向の拡張性（前セクションを参照） というこ ともあり、大部分のNoSQLデータベースシステムはコモディティハ ードウェアで運用可能です。ただしコモディティハードウェアといっ てもすべてが安価なわけではありません。 ノードには大容量のメモ リ （16GB以上）、マルチCPU、大容量のディスクスペースが推奨され ます。 あるクラスタ用マシンの推奨スペックは、 クアッドコアCPUを2つ （2∼2.5GHz）、ECC RAM（16∼24GB）、10x 600GB SATAディスクを 4つ、1GBのイーサネットカード1枚となりました。今日このようなマ シンを購入しようとすれば1台約20万円以上します。 とはいえ処理能 力が10倍のマシンを1台買おうとすれば、20万円のマシン10台分の 価格を大きく上回ることは間違いないでしょう。 自己完結型 多くのデータベースシステムは、 ストレージ、 プロセッサ、 メモリなど のリソースを共有しています。 しかしNoSQLでは共有されるものは 一切ありません（ 「シェアードナッシング」 ） 。各ノードはストレージや 処理能力において独立しており、そのためあるクエリがデータベー スのある部分をロックしていても、 それ以外の個々のノードではクエ リを処理できます。 ただし、それぞれのクエリが妨害されることなく並行処理されるた めには、適切な設計およびエンジニアリングによる慎重なシャー ディング（第3章参照）が不可欠となります。 クエリを各ノードに分散 し、 その結果をまとめるというこの方法はMapReduceの技術と似て いますが、NoSQLではその都度リアルタイムで処理結果を返すのに 対し、HadoopのようなMapReduceシステムはバッチモードでのみ 実行されるという点が異なります。NoSQLデータベースの中にはレ コードのシャーディングを自動で行うものもありますが、 これは一部 のデータベースに限られます。 すべてのNoSQLデータベースが複数のマシンで実行されるわけ ではありません。例えばグラフデータベースは、複数ノードによる グラフ計算に時間がかかるため、通常1台のマシンに制限され ます。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 12 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション NoSQLによくある誤解 NoSQLがデータベースの世界に登場したのは比較的遅かったと はいえ、それでもこれまでの間にさまざまな誤解が生まれてきまし た。NoSQLソリューションについて説明すると 「結局のところNoSQL は単なる〇〇だろう？」 とか「NoSQLができるのは××だけでしょ う？」 といった質問を受けるかもしれません。 このセクションではそ ういった疑問に答えていきたいと思います。 SQLを使用するかどうかだけの 問題？ NoSQLをノーエスキューエル（no SQL＝SQLではない） と発音する ノットオンリーエスキューエル（not only SQL＝SQLだけで にせよ、 はない） と発音するにせよ （発音については本章で前述のセクショ ン「NoSQLの用語を理解する」を参照のこと）、NoSQLの本質はSQL クエリ言語を使用するかどうかだけのことではありません。むしろ NoSQLにおいて重要なのは、 リレーショナルデータベースにおけ る保証や制約（第2章参照）を必要と考えるかどうか、またどのよう なときに必要なのかということです。 多くの場合、NoSQLでは独自のクエリ言語を使用する代りに、 アプ リケーションプログラミングインターフェース（API）からデータベー スにアクセスします。 NoSQLデータベースには文字列ベースのクエリ （例えばSelect * from Orders where itemname = "pillows"）を使用で きないものもあります。 しかしHadoopのHiveクエリ言語は明らか にSQL的な構文を使用しています。 また、Cassandraデータベース ではCQL（スィークェルと発音） というクエリを使用しており、 これも SQLと非常に似ています。 大企業用？ クラウド関係の多くの大企業がNoSQLデータベースを使用して いますが（ちなみに「クラウド」も本書では避けて通れない用語 です）、それはこれらの企業のビジネスが、多様で複雑かつ頻繁 に更新されるデータに依存しているためです。例えばYahoo!、 Google、Amazonといった企業はすべて、自社のビジネスニーズを 満たすために2000年代初頭にRDBMSではないデータベースを開 発し始めています。 これらのビジネスニーズはビッグデータ、すな これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第1章：NoSQLの基礎知識 13 わち多様で常に変化し続け、迅速なクエリ結果が求められるデータ という特徴を持っています（結局のところ、反応が遅ければ顧客は 他社に行ってしまいます）。 しかしNoSQLが適しているのは大企業だけではありません。小さ な企業でも、構造化および非構造化データを統合し分断を解消す る際にNoSQLが必要となる場合があります。たとえ事業がずっと小 規模で、扱うデータのサイズがペタバイト規模でなくても、ビッグデ ータ問題に頭を悩ますことはありえます。例えば、非構造化または 半構造化データからどうやってパターンや関係を抽出し、事業に活 用できる情報を導きだすかという課題や、急速に変化する事業環 境に適応するためにそのような情報にいかに迅速にアクセスする かといったような課題が考えられます。 RDBMSの代替物？ NoSQL DBMSは、既存のRDBMSをリプレース（置き換え）するもの ではありません。RDBMSは1970年代に開発が開始され、ACID保証 やインデックスによるパフォーマンスの向上等、データを安全に保 持するための仕組みを多数備えています。 例えば、オンラインのトランザクション処理環境で毎秒何百件もの トランザクションを処理するレコードシステムをすでにお持ちな ら、その既存システムを打ち捨てて新しいシステムを一から作り直 す必要はありません。実際のところNoSQLというのは「破壊的技術」 なのです。なぜならデータのストレージと管理について考え方がこ れまでと違うだけでなく、データベーススペシャリストやアプリケー ションプログラマーにこれまでと異なるスキルセットが要求される からです。 特別なハードウェアが必要？ 垂直拡張を行うRDBMSと違い、NoSQLが性能を発揮するためには 特別なハードウェアは必要ありません。垂直拡張（より巨大なハー ドウェアを追加していくこと） では、特定用途に特化した機器にオフ ロードさせる必要があります。そうなると複雑性、電力消費、物理的 な使用スペースという負担はさらに増加します。その点NoSQLは RDBMSと異なり、 コモディティサーバーを追加することで容易に拡 張可能です。 また多くのNoSQLソリューションはクラウドで実行可能 で、短期間でサーバー数を増減できる弾力的な拡張性のオプション も用意されています。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 14 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション リレーショナルデータベースと共 存不可？ NoSQLデータベースを選択したら、RDBMSを捨て去らなければ ならないというわけではありません。 リレーショナルデータベース をNoSQLデータベースと併用する際には注意が必要ですが、ビ ジネスにとってはそれだけの価値がある場合もあります。 これは NoSQLデータベースが定期的に、あるいはデータベースに対する クエリと並行して実行されるETL（Extract＝抽出、Transform＝変 換、Load＝ロード） プロセスによってアップデートされる場合でも 同様です。 この2種類のデータベースを組み合わせた例として、NoSQLデータ ベース内の取引に関するXMLドキュメントを、企業情報や為替レー という参照データで強化（エンリッチメント）する、 という使い方が 考えられます。 NoSQLはあなたのビジネスに 適しているか 本章を最初から最後までお読みいただいても、 「ここまでの情報は 分かったけれど、実際にNoSQLが自分のビジネスにどんなふうに 役立つのかまだよく分からない」 と思っているかもしれません。 この セクションではそれを説明したいと思います。 以下に当てはまるようであれば、NoSQLがあなたにとって解決策と なる可能性があります。 ✓大量の非構造化または半構造化データがある、 または非構造 化データとリレーショナルデータが混在している ✓ 大量のデータを読み込むと同時に複数のクエリを処理する必 要がある ✓ 複数のプロジェクトでデータを部分的に再利用する必要があ る ✓ スキーマがすぐに変化する、 または6ヵ月未満（場合によっては それ以下）の開発サイクルで新しい情報ソースを取り入れる必 要がある これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第1章：NoSQLの基礎知識 15 ✓ データをモデル化したりスキーマを作成したりすることなく、 複数の異なるデータタイプとデータソースを統合する必要が ある ✓ データに対してどのようなクエリを実行するようになるのか分 からない ✓ ドキュメントの内容を検索できるようにする必要がある 上記があなたのビジネスに当てはまるようであれば、NoSQLソリュ ーションの導入が適切かもしれません。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 16 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第2章 さまざまなDBMSの違い 本章の内容 ▶リレーショナルデータモデリングとNoSQLデータモデリングの違い ▶関係の扱い方 ▶非正規化/正規化を理解する ど んなプロダクトであれソリューションであれ、十分に活用 したいと思ったら、それに見合った準備と心構えが必要 です。最大限活用するには、 まず固定観念を打破しなければなりま せん。 データベース管理システム （DBMS） を最大限に活用したけれ ば、データ管理に対する意識を変える必要があります。 「はいはい。 でもそうはいってもデータはデータでしょ」 と言う人もいるかもしれ ません。でもちょっと待ってください。 「NoSQLデータベースもリレ ーショナルデータベースとそんなに違わないはずだ」などと思って いるとしたら、それは間違いです。 本章ではリレーショナルデータベース管理システム（RDBMS） と NoSQLデータベース管理システム（NoSQL DBMS）の違いについ て説明していきます。 RDBMSとNoSQLを比較する ではRDBMSとNoSQLの大きな違いとは何なのでしょうか? 以前で あれば、ITプロフェッショナル達はこう答えたでしょう。 「RDBMSは 一貫性を重視していてNoSQL DBMSは可用性を重視している」 と。 しかし今は違います。現在これらのデータベース管理システムにお ける最も重要な違いは、柔軟性（スキーマ非依存） と各種データ構 造の扱い方です。 NoSQLデータベースとリレーショナルデータベースでは、機能なら びに保証される対象が異なります。 ラッシュアワーの渋滞した道路 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 18 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション でフェラーリを運転しても十分なパフォーマンスが発揮できないの と同じように、 アプリケーションの要件に基づいて、適切な種類のデ ータベースを選択することが重要なのです。 極めてトランザクショナルな構造化データを扱う場合、RDBMSが適 していると言えます。あるいは構造化データはRDBMSで、非構造化 データはNoSQLソリューションでというようにデータベースの管理を 分けることも考えられます。後者のタイプは「polyglot persistence」 （「多言語共存」混合システム） と呼ばれ、複数のデータ構造に対応 できないNoSQLデータベースの場合、 これが主要なソリューション となります（MarkLogicではドキュメント、値、 トリプルの構造に対応 しています。MarkLogicについては第1章を参照のこと） 。 RDBMSとNoSQL DBMSのそれぞれの強みを生かせる形で、データ 管理アーキテクチャおよびシステムを設計しましょう。 またNoSQLソ リューションにおいても、1つのモデルのみに限定しないほうがよい でしょう。結局のところトリプルストアデータベースとドキュメントデ ータベースでは実現できることが違いますから、目的に合ったツー ルを使用することが大切です。 M a r k L o g i c はトリプルストアとドキュメントデ ータベ ースの 両 方 の 機 能を提 供しています。選 択 肢を限 定したくな い 場 合 は、MarkLogicのソリューションを検討することをお勧めします。 RDBMSの基本原理 RDBMSを使用したことがある方は誰でも、RDBMSデータを扱う基 本的な方法としての「テーブル」になじみがあるはずです。テーブル は以下のような構造になっています。 ✓行はレコードを表し、列はレコードの属性またはフィールドを 表す。 ✓ 同一テーブル内の各行には全く同じ列が並ぶが、列の中には 値が含まれないものもある （これらはNULL値と呼ばれる）。 ✓ 各レコードの行は内部的には特別なキーにより識別される。 キーは開発者に見えない場合もある。 ✓ テーブルの各行は通常一意で、外部からは主キー（通常、特定 のフィールドの組み合わせあるいは単一のフィールド）により 識別される。 ✓ 素早いルックアップを可能にするため、通常はキーならびに任 意の共通ルックアップフィールドを使用してインデックスが作 成される。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第2章：さまざまなDBMSの違い 19 ✓ テーブルの各フィールドには値が1つだけ格納される。 フィー ルド名も一意でなければならない。テーブルには繰り返しグ ループやハッシュマップは含まれない。 と、 ここまではおなじみの内容でしょう。 この方法でデータベースを設計するそもそもの目的は、更新異常を 防ぐことにあります。 「一事実（ファクト）は一箇所にのみ存在する」 と いうのが原則です。つまり、ある値を変更したければ、該当するレコ ードのみにアクセスすればよいことになります。例えば電話番号を 1-413-555-1212から1-617-444-1212に変更したい場合、該当するレコ ードの1つのフィールドのみで変更できなければなりません。たった 1つのフィールドを更新するためにレコード内のデータ全体を再送 信する必要はありません。 このアプローチを採用したRDBMSのテーブル設計においては、 エンティティの関係性を示さなければならなくなったときに問題が 出てきます。 これについては本章の「関係の扱い方」 で説明します。 NoSQLという代替手法 SQLは企業におけるデータの格納・管理の代替手法となること で、RDBMSに変化をもたらしました。 ではなぜさらに別の代替手法 であるNoSQLを選択すべきなのでしょうか？主な理由は以下の通 りです。 ✓NoSQLは考え方の実質的な転換を意味する。NoSQLでは何か する前にスキーマを定義するのではなく、データを読み込ん でから、何が問題なのかを考えることを提唱しています。つま り問題志向型のアプローチをとっており、従来のRDBMSのよ うに格納するためにどのようにデータを構造化するべきかで はなく、データがどのように使用されるか（クエリされるか） と いう点に焦点がおかれています。 ✓NoSQLのデータモデリングは人間にも分かりやすい。ドキュメ ントはほぼ誰が見ても、 その内容を理解できるはずです。XML ドキュメントでは、 ドキュメントの各部分が何を示しているの か明確です。 このようなドキュメントをRDBMSテーブルとして 表現した場合、理解するのがより難しく、 そこで使われているス キーマからビジネスルールを導きだすのも困難です。 第1章で述べた通り、NoSQLはスキーマ非依存です。もちろんスキ ーマを適用させたければそうすることもできますが、通常その必要 はありません。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 20 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション NoSQLについて以下の点を覚えておきましょう。 ✓NoSQLドキュメントでは、各ドキュメントに含まれる属性が同 じである必要はない。 ✓ NoSQLでは、特定のアプリケーションでどのようにデータが使 用されるかを明示的に認識している。 ✓ データベースの物理的なレベルでは、NoSQLはクラスタとして 実行されていることを認識しており、それを踏まえたデータ管 理戦略をとる。 ✓ NoSQLアプリケーションは、特定レベルの一貫性を保つため にレプリケーション設定を指定できる。 本章の残りの部分では、RDBMSとNoSQLの違いについて具体例を 挙げていきたいと思います。 関係の扱い方 複数のデータベースエンティティの関係を表すために、テーブル が別途必要になる場合があります。2つのエンティティが1対1（1:1） の関係の場合、 この関係は片方のエンティティにキーを、もう片方 のエンティティにレコードを埋め込むことによって表すことがで きます。１対多（1:M）の関係も同じやり方で表すことが可能です。 しかし多対多（M:M）の場合は、別途リンクテーブルが必要になり ます。 関係のタイプによって対処しなければならない課題は異なります。 以下に考慮すべき点を挙げておきます。 ✓参照整合性：データベースには参照整合性（データの一貫性） と呼ばれる制約があります。 ここでは外部キーが使用され、そ の値がNULLでない場合はデータベースにそのエンティティ が含まれていることになります。NULLの場合は、関係がまだ 存在しないことを意味します。そのため、あるレコードで外部 キーを使用したい場合、その前にその値を主キーとするレコ ードが必要です。ただしそのテーブル自体にも別の参照整合 性の制約がありうるので注意が必要です。 ✓マッピングテーブル：1:Mの関係では、 これら2つのエンティテ ィの関係を示すためにマッピングテーブル（対応表）を作成 しなければならない場合があります。あるいは、片方のエン ティティのキーをもう片方を表すテーブルに埋め込むことで も関係を示すことができます。マッピングテーブルには各エ ンティティのキーのみが含まれ、1つのエンティティが別のエ これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第2章：さまざまなDBMSの違い 21 ンティティに関連していることを示すことができます。 このテ ーブルには、関係に関する情報の属性が含まれることもあり ます。 一方、M:Mの関係の場合、関係を示すマッピングテーブルが必 須となります。 ✓オブジェクト指向：オブジェクト指向のデータベースのなかに は、オブジェクトとその関係性をRDBMSテーブル形式のマッ ピングとして表現するものもありますが、 これはあまりうまくい きません。 オブジェクトと関係、 どちらがより重要なのでしょう？ その答えは、 そのデータベースを使う目的とそれを使う人によ って異なります。 データベースプログラミングにおいては、 オブ ジェクト的な視点とリレーショナルな視点は常に相いれないの です。 ここで例を考えてみましょう。学生、教授、学部、科目（class）、教室 など大学に関する情報を扱うデータベースを作る必要があるとし ます。さらに、各科目の担当教授は1人のみだとします。 このデータ ベースを、RDBMSとNoSQLそれぞれで作成する方法を以下のセク ションで説明していきます。 RDBMSの設計 この例では、RDBMSテーブルは以下のように定義できます。 create table class { section varchar(10) NOT NULL, class_id Integer NOT NULL UNIQUE, professor : Integer, Primary key(class_id), Foreign key (professor) references Professor} この設計にすべての人が賛成するとは限りません。特に科目のレ コードではNULLを示す値が必要（つまり科目の担当教授が決まっ ていない）かもしれないのでなおさらです。NULLの扱いはアプリ ケーションプログラマーの悩みどころですが、時にNULLは必要悪 といえるでしょう。一部のNoSQLデータベースではドキュメントの 値をNULLとすることを容認したり、あるいはこれらが表示されない ようにします。 この点については以下のセクションで詳しく触れてい きます。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 22 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション 空リスト対NULL値 学生の科目を空リストで表すのな ら、受講登録に関してNULL値を気 にしなくてよいことになります。た だし担当教授が決まっていない科 目を学生が登録した場合はどうで しょう。その場合、 このクラスを担 当する教授が決まってないこと示 すためにNULL値を使用できます。 空リストとNULL値ではどちらが 優れているのでしょうか? 以下を 目安にしてみてください。 ドキュ メントの属性が値を1つしか取ら ない場合はNULL値を使うほうが 好ましく、属性に複数の値が含ま れる場合には空リストを使うほう がより適切です。 ここでは学生は 0、1、あるいは複数の科目を登録 する可能性がありますから、空リ ストのほうが適しています。 さて、 プログラマーは、s1 = new Student()で学生のレコード を作成し、s1.delete()でそのレコードを削除できます。 これは一 見単純なトランザクションですが複数のテーブルの変更が発生しま す。 そのためデータベース全体の参照整合性を保つために、 データ ベースはこれらのテーブルすべてに対する同時アクセスを管理しな ければなりません。 RDBMSでは、 学生を表すテーブルは以下のようなものになるでしょう。 create table student { name : string , student_id : integer NOT NULL, year : integer, Primary Key (student_id)} 学生の複数科目への登録を示すには、生徒と科目の関係を示す以 下のような新しいテーブルを作成する必要があります。 create table student_class { student_id integer NOT NULL, class_id integer NOT NULL, primary key (student_id, class_id)} NoSQLの設計 NoSQLの開発者は、 この例に対して異なるアプローチを取るはず です。その際、さまざまなデータベースコンポーネントが別の名前 で呼ばれます。NoSQLではドキュメント間で同一の属性セットを共 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第2章：さまざまなDBMSの違い 23 有する必要はなく、また、まだ存在しない属性を持たせることもで きます。NoSQLのアプローチでは、学生のレコードは以下のような 形になります。 <student xmlns="http://myeducation. com/education" studentId="5" year="2014"> <student-name>Joe Bloggs</student-name> <class classId="CSC101"> <professor professorId="456"> <professor-name>John Adams</professor-name> <tenured>true</tenured> <yearsEmployed>23</yearsEmployed> </professor> <section>Introduction to Computer Science </section> </class> <class classId="POL245"> . . . </class> </student> 疎データ アプリケーションの中には、連絡 先リストのように何百にも及ぶフ ィールド（自宅電話、携帯電話、 Eメール、Twitter IDなど）が含まれ るものがありますが、通常はその ほとんどのフィールドには値が入 力されていません。結果として連 絡先テーブルの多くの行にNULL 値が入ります。このような状態は 疎（スパース）データ問題とよば れ、RDBMSに無駄が生じることに なります。 これと対照的に、NoSQL データベースでは特定のフィール ド、キー、要素を使って情報を格 納するかしないか選択できます。 そのため、RDBMSのような疎デー タ問題に悩まされることはありま せん。 非正規に戻す RDBMSにおける正規化とは、データベースの設計が一連のテスト に合格するまで、設計の変更をつづけることです。 これらの各テスト では、特定の正規形が示されます。正規形には、1NF（第1正規形）、 2NF（第2正規形）、3NF（第3正規形）、4NF（第4正規形）、BCNF（ボイ ス=コッド正規形） といったいくつかの種類があります。 データによっ ては最初の3つの正規形で十分な場合もあります。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 24 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション まずデータベースから取得したい情報をすべて含んだテーブルを 作成します。本章で前述した大学のデータベース例を使うと、学生 の成績表には年齢、氏名、科目一覧、科目名、教授名等複数の情報 が含まれるでしょう。 このテーブルには、例えば科目名、科目ID、教 授名など重複する要素が含まれるはずです。そのため、特定のフィ ールドを別のテーブルに分けて正規化する必要があります。 一方、データを１つの論理テーブルにまとめることを非正規化と呼 び、非正規化を行うとクエリのパフォーマンスが向上します。NoSQL データベースはそもそもクエリをサポートするために設計されてい るので、そのデータベースに対して実行されることが予想されるク エリに基づいてデータを非正規化することがよくあります。学生/科 目の例をとると問題が良く分かります。複数の科目を別のドキュメ ントコレクションとすべきでしょうか、それとも科目の情報は学生の ドキュメントに埋め込むべきでしょうか？ データではなくクエリのことを考えてデータベースを設計したなら ば、 このアプリケーションではクエリの大部分が学生に関するもの なので、科目の情報を学生ドキュメントに埋め込むほうが理にかな っていると分かるのではないでしょうか。 また学生が多数の科目に 登録するかどうかも検討しなければなりません（どのくらいをもっ て多数とするのかは、 ドキュメントサイズの制約によってある程度 決まってきます）。一方、多くのクエリが科目のみに関連することが 見込まれる場合は、科目を別のコレクションとして作成しても良い でしょう。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第3章 NoSQLでデータセン ターを変える 本章の内容 ▶NoSQLにおけるデータの分散方法を確認する ▶データの整合性を確保する ▶ドキュメントコンテンツの永続性を担保する デ ータセンターはエンタープライズでのコンピューター使用 において一般的なものですが、 これまで常に （特に初期に おいては）課題がつきまとってきました。大規模なデータベースを実 現するために、NoSQLではクラスタとして構成されるネットワーク化 された多数のサーバーを使用します （サーバーが同じサーバールー ムの同じラックにマウントされている場合もあります） 。 この場合、 デ ータを複数のマシンに分散する際に問題がでてきます。 リレーショナ ルデータベース管理システム （RDBMS） とNoSQLデータベース管理シ ステム （NoSQL DBMS）のどちらにおいても、可用性と複数のサーバ ーにおける整合性を両立することが常に課題となります。本章では NoSQLがこの課題にどのように対処しているかを見ていきましょう。 データの分散 データは主に2つの方法で分散されます。 ✓ シャーディング ̶ 異なるノードに異なるデータ ✓ レプリケーション ̶ 複数のノードにデータをコピーするもの で、ピアツーピアあるいはマスター/スレーブで行われる NoSQLでは、 シャーディングまたはレプリケーションのいずれか、 あ るいはその両方を使用することが可能です。NoSQLデータベースに これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 26 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション よって提供される機能は異なります。 このセクションでは一般的な アプローチを紹介していきます。 シャーディング シャーディング（または水平分割） とは、特定フィールドの値でデータ ベースを分割することです。 データベース内のさまざまなドキュメン トが、 フィールドの値に応じて別個のマシンに格納されますが、時 にはデータベースにアクセスするアプリケーションがデータをどの マシンに格納するかを決定します。 また別の実装では、 リモートノー ド上で動作しているデータベースとアプリケーションの間に仲介サ ーバーを設置します。NoSQLデータベースの中には、管理者がシャ ーディングルールを設定する必要があるものもあれば、 自動的に各 ノードにバランスよくデータを分散してくれるものもあります。手動 でルールを設定する方法の弱点は、気付かないうちにノード間の データの不均衡を招いてしまい、一部のノードのレスポンス時間が 遅くなってしまう可能性があることです。RDBMSではパーティショニ ングができますが、 通常パーティションは （特定のディスクパーティシ ョンという形で）1台のマシン内に限られます。 NoSQLデータベースにパーティションを設けるにはさまざまな技術 を使用できます。 ✓データのシャーディングにキー値を使用する。 このアプローチ では、例えばカリフォルニアにホームオフィスを持つ顧客全員 がカリフォルニアデータセンターのノードに格納されます。 このようにデータを格納する方法の1つとしてレンジパーティシ レンジパーティショニングでは、特定のレン ョニングがあります。 ジ （範囲） に含まれるデータが特定のサーバーに格納されます。 どのサーバーにどのレンジが格納されているか確認することが 可能です。 ✓データのシャーディングにロードバランシング（負荷分散） を使 用する。 この場合、データベースでは大きなシャードが複数の マシンで動作する複数の小さなシャードに分割されることが 考えられます。 どのようにデータを分割するかは、DBMSがパ フォーマンスに応じて決定するので、 このプロセスはアプリケ ーション開発者には見えない場合もあります。 ✓キーをハッシュする。 このシナリオでは、 キー値が（理想的には） コンシステントハッシュ より短い値に数学的に変換されます。 法により、特定のキー値を持つドキュメントがハッシュリング （特定のハッシュ値レンジを受け持つサーバー群）のサーバー のいずれかに割り当てられます。 ここでも、詳細はアプリケーシ ョン開発者には見えません。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第3章：NoSQLでデータセンターを変える 27 レプリケーション NoSQLには2通りのレプリケーションがあります。ピアツーピアとマ スター/スレーブです。それぞれ別の理由で整合性の問題がありま す。そのため単一マシンにソリューションを実装可能な場合はなる べくそのようにして、データのリカバリに関しては従来の方法（バッ クアップ等）を使用したほうが良いでしょう。 一部のNoSQLデータベース、特にグラフデータベース（第1章参照） は、シングルサーバーでも十分に機能します。その場合もスケール アップ（垂直方向）は可能ですが、 クエリは1つのノードで実行され ます。変更は1つのノード上でコミットされ、その変更が別のノード に複製されます。ただほとんどのNoSQLデータベースはクラスタで 動作するように意図されているので、遅かれ早かれレプリケーショ ンの問題が発生する可能性があります。通常「結果的に整合」 （第1 章のACIDおよびBASEを参照）するという形なので、一部のノード ではクエリの結果としてデータを返すのが遅くなります。 結果的に整合というのは、変更内容がレプリカ（複製） ノードにコミ ットされるまで、データベースが整合性に欠ける状態となることを 言います。 マスター/スレーブ型レプリケーション レプリケーションはマスター/スレーブ構成のほうがシンプルです。 すべての変更はマスターノードで実行され、 これらの変更がスレ ーブノードへ反映されます。 しかしスレーブに変更が反映される前 に、マスターに障害が発生すると問題となります。そのような場合、 スレーブは別のマスターを新しく選択し、更新を継続します。古いマ スターが復旧したら、競合する変更を調整する必要があります。特に 複数のノードが同じパーティションを更新している場合には調整が 必要です。ベストなシナリオとしては、マスターがすべての書き込み を処理し、複数のスレーブサーバーで読み取りを分担することです。 とはいえ、NoSQLサーバーのうち、 レプリカを新しいマスターにで き、ACIDに準拠しているものでは整合性の問題は生じないため、マ スター/スレーブ間での一貫性の調整は必要ありません。 ピアツーピア型レプリケーション ピアツーピアのレプリケーションでは、マスターノードは存在しま せん。 どのノードも読み取り、書き込みを受け入れることができま す。書き込みは各ピアに伝播され、読み取りはサーバーのどのノー ドでも対応することが可能です。 多くのNoSQLデータベースにおいてレプリケーションは主力機能で す。 しかし、 ここで問題となるのが、 データベースを複数のノードにレ これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 28 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション プリケーションする際、 これらのレプリカが一貫性に欠ける可能性が あることです。2人のユーザーが同じドキュメントを同時に異なるピ アで更新した場合、整合性の問題が生じます。 またドキュメントへの 更新内容が1つのピアから別のピアへまだ伝播されていない場合、 読み取りの一貫性がなくなります。つまりある人にはある値が返され ているのに、別の人には別の値が返されるということがありえます。 ただしこれが問題となるかどうかは場合によります。 一貫性欠如の例としては、 ブログ投稿へのコメント数があります。 つまり見る人によって異なるコメント数が表示されることがありえ ます。ただこのように価値の低いデータではあまり問題にはなりま せん。一方、例えば在庫管理の数字が一貫性に欠けていれば問題 となります。ある人がある在庫数を見て、別の人がそれより少ない 在庫数を見ていたとしたら、突然在庫がなくなって驚くという事態 が生じるかもしれません。 RDBMSではクラスタ内でログとジャーナルを共有することで、かな り前にこの問題を解決しています。一部のNoSQLソリューションで はこの機能が提供され始めていますが、 アプリケーション側でこの 問題に対処しなければならない場合もあります。 ACIDテスト：データの一貫性 ACIDなデータベースでは、 トランザクションが実現されていま 、一貫性（consistency） 、 す。ACIDとは原子性/不可分性（atomicity） 独立性（isolation）、永続性（durability）の頭文字をとったものです。 トランザクションの結果に原始性（不可分性）が ✓ 原子性とは、 ある、つまりすべて実行されるか全く実行されないかのいず れかとなることを意味します。 トランザクションの一部が失敗 したら、 トランザクション全体が失敗となり、データベースの 状態には変更が加えられません。 ✓ 一貫性とはトランザクションにより、データベースが有効な一 貫性のある状態から別の一貫性のある状態に移行することを 意味します。 ✓ 独立性とは、多くのトランザクションが並行して実行されてい ても、ユーザーに返される結果では、それぞれのトランザク ションが独立して実行されたかのように見えることを意味し ます。 ✓ 永続性とは、一度トランザクションが成功したら、他にいかな るシステム障害があろうとも、そのトランザクションの結果が データベースから失われないよう保証することを言います。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第3章：NoSQLでデータセンターを変える 29 NoSQLにおけるACIDの条件 ほとんどのNoSQLデータベースではACIDの条件を緩和しています。 個々のドキュメント更新の原子性は保証するNoSQLデータベースも あります。 つまりすべて実行されるか、 まったく実行されないかのいず れかの状態になるということです。 ただし、 論理トランザクションが、 同 一データベース内の複数のコレクショ ン （テーブル） に対する更新を 必要とする場合、 このような保証はされません。 これは、たとえデータ ベースとデータが同一コンピューター上にあったとしても同様です。 分散コンピューティング環境で作業を行う場合、一貫性、可用性、永 続性のニーズのバランスを取らなければなりません。高い可用性を 実現するために、一部のデータベースでは一貫性と永続性の条件 を緩和しているものもあります。 現実には、大部分のNoSQLデータベースではネットワーク分断（パ ーティション）耐性が必須です（というか避けて通ることができませ ん）。なぜならこれがないとデータベースはある制約された環境下 において最大限に機能できないからです。 この際、データの可用性 とレプリカの一貫性の二つが満たされなくなります。 RDBMSは開発当初、ACIDに準拠していませんでした。その後徐々 にACIDに対応するようになったのです。NoSQLデータベースの場 合もこれと同様です。MarkLogicおよびFoundationDBでは、ACID の一貫性を実現しています。 読み取り整合性と更新整合性 NoSQL DBMSにおける整合性とは、更新および読み取りにおける 一貫性を意味します。RDBMSデータベース設計におけるACIDアプ ローチは、データベース内のデータが内部的な一貫性を保持する ことが目標です。例として大学のデータベースでは、学生がある科 目の討論グループから別のグループに移ったら、その学生はどちら かのグループのみに属しており、両方のグループに属することはな いというのが一貫性です。 この学生がどのグループにも属さない場 合、学生はそもそもこの科目を取っていないということになります。 以下に詳しく説明します。 ✓ 読み取り整合性とは、更新が発生した後、2人のユーザーが同 一のデータを読み取れることを意味します。RDBMSは、 このタ スクをトランザクションとして行います。一方、 レプリケーショ ンを使用しているNoSQLデータベースのなかには（本章で前 述した「レプリケーション」参照のこと） 、すべてのレプリカが更 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 30 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション 新されるまでタイムラグ（不整合ウィンドウ）が発生するものも あります。 このアプローチをレプリケーション整合性と呼びます。 ✓ 更新整合性では、2件の変更が同時に要求され、一方の更新が 成功した場合、他方の更新に対して、今更新しようとしているレ コードは最後に読み取ったものとは内容が違っているというこ とを通知します。 このアプローチを更新整合性と呼びます。 ✓更新整合性の典型的な例としては以下のようなものが挙げら れます。チャーリーはバグを修正するためにfoo.cというファイ ルをチェックアウトします。 ゴードンは別のバグを修正するため に、同じファイルをチェックアウトします。 チャーリーが先に自分 の変更をサブミットした後、 ゴードンが彼の変更をサブミットし ます。 この場合最終的にどちらの変更が反映されるのでしょう？ この場合ゴードンに、彼がオリジナルのファイルをチェックア ウトした後に更新が加えられた旨が通知されるべきです。 ドキュメントの永続性 永続性とは、更新が完了した後、変更されたドキュメントが永続的に 格納されるかどうかに関するものです。通常NoSQLデータベースで は、永続性はレプリケーション （本章前述） を使って実現されます。読 み取りはどのレプリカで実行されるかわからないので、最終的にク ラスタ内の全ノードにデータの全く同一のコピーが存在し、 どのノ ードからも同じデータが得られるようにしなければなりません。 一貫性のある読み取りを実現するために必要となるノード数のこと レプリケーションにはクラス をレプリケーションファクタと呼びます。 タ内の複数のノードが関与します。それらのノードのうち、いくつか のノードが更新（書き込みリクエスト）に応じ、いくつかのノードがク エリ （読み取りリクエスト）に応じる必要があります。 レプリケーショ ンファクタとは、一貫性を実現するために必要なノードの個数のこ とを指します。 マスター/スレーブレプリケーションでは、更新に応じるのは1つのノ ード（マスター）のみですが、 これは変更がその後スレーブノードに 反映されるという前提があるためです。 複数のリーダー（＝読み取りに応じるノード：R） とライター（＝書き 込みに応じるノード：W）でレプリケーションする場合、データの保 存を保証するには、合計ノード数（N）の半数以上で更新（書き込 み）に応じなければなりません。 これを書き込みクォーラム（最低必 （W > N/2） と呼びます。 データベース設計者はこれらの数字を 要数） 調整することで、読み取り整合、常時整合、結果的に整合などの異な るレベルの結果を実現できます。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第3章：NoSQLでデータセンターを変える 31 ここでちょっとした数学の問題です。 ライター数がレプリケーション 実行ノードの数と同じとき （N＝3、W＝3、R＝1） 、最も強固な一貫性 が保証されます。N＝Wの場合、すべてのサーバーが書き込みの完 了を確認してから、 アプリケーションに通知しなければなりません。 そのため当然のこととして、全マシンが同期している状態になりま す。 W＝2、 R＝1、 N＝3 （書き込みクォーラム） の場合、 結果的に整合す る状態になります。3つ目のノードは全体に再び参加する際に、他の 2つのノードに書き込まれたデータに基づいて更新されます。 従来のRDBMSの実装では、データベースエンジンによって書き込 みの成功を担保することで永続性を実現しています。別の技術とし てはトランザクションをジャーナルファイルに保存する方法もありま す。 このファイルには、 ディスクへの最終書き込み以降にデータベー スに適用されたトランザクションのリストが含まれます。更新がディ スクに書き込まれる前にデータベースが異常終了した場合、 データ ベースが再起動した際にジャーナルファイルがデータベースに対し て再生され、データベースを同期させることができます。 NoSQL DBMSの中には、MarkLogicのソリューションのようにジャ ーナル機能を備えているものもあります。 ミッションクリティカルな アプリケーションを実行しており、各トランザクションがコミットされ ることを担保する必要があるのであれば、ACIDに準拠したNoSQL データベースを検討することをお勧めします。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 32 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第4章 エンタープライズ NoSQLでできること 本章の内容 ▶エンタープライズNoSQLとは ▶レプリケーションの使用 ▶データのバックアップ ▶データ整合性の担保 ▶セキュリティに関する重要事項 N oSQLデータベースがエンタープライズコンピューティングに おいて価値があることは、すでに実証されています。NoSQL のムーブメントを最初に形作ったデータベースにはGoogleの BigTableやAmazonのDynamoがあります。 これらは世界最大の検 索企業や世界最大のオンライン小売業者によって使用されました。 しかし、NoSQLをビジネスインテリジェンス用に社内データ管理に 使用するのと、顧客向けのアプリケーションに使用するのとは別物 です。NoSQLデータベースマネジメントシステム （NoSQL DBMS） を ミッションクリティカルなプロジェクトに使用する場合、 プロジェクト 全体のコストを考える必要があるでしょう。 本章では、エンタープライズNoSQL、つまりエンタープライズクラ スのパフォーマンス、セキュリティ、信頼性を提供できるタイプの NoSQL DBMSについて説明します。エンタープライズNoSQLは、 安心して事業を任せられるようなDBMSでなければなりません。そ のため、本章に記載されているような機能を備えていることが必須 となります。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 34 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション エンタープライズクラスのレプ リケーション レプリケーション（第3章参照）は、高可用性、堅牢な災害復旧、高速 なパフォーマンスなど多くの企業の目標達成に有効な機能です。 し かしこれにより、企業のデータおよびコミュニケーションのインフラ に負荷がかかります。 基本的にレプリケーションとは、マスターデータベース （複製元とな るデータベース）を、新規あるいは更新ドキュメントとしてレプリカ データベースに複製することです。 ローカルディスクレプリケーション 多くのNoSQLデータベースでは、 と呼ばれる機能も提供されています。 これはデータを同一クラスタ 内の異なるノードへ複製するものです。NoSQLデータベースにより ますが、読み取り専用レプリカを追加するためにこの機能を使って いるものもあれば、マザーボードが使用不能になった場合に備え てこの機能を使っているものもあります。 この場合、複製データセッ トを持つセカンダリノードがマスターノードに取って代わります。 元のマスターノードには、修復後最新のコピーが取り込まれ、再び このデータセットのマスターとなることができます。 ノードが、ロー カルのディスクストレージではなく一元化されたNASストレージを 使用している場合には、 この機能は必要ありません。 MongoDBのような一部のNoSQLデータベースでは、ハードウェア の故障によりプライマリノードが使えなくなったときにのみクエリ に応じる、読み取り専用レプリカが必要です。 この場合、冗長化のた めだけにコストがかかることになります。一方、MarkLogicのような NoSQLデータベースでは同一の物理ホストにセカンダリレプリカと プライマリホストが共存し、それぞれが同一データベースの別の部 分を担当します。 そのため、 ローカルディスクのフェイルオーバーを 用意できるだけでなく、全体で必要なサーバー数を削減できます。 NoSQLデータベースのレプリケーション戦略は多様です。更新順 序を保証しない（同一ドキュメントへの2件の更新が異なる順番で レプリカに到着する可能性がある） ものもあれば、 トランザクション 準拠（トランザクションを構成するすべての更新が1つのトランザク ションとしてレプリカに適用される）のものもあります。 またレプリケーションにも同期タイプと非同期タイプがあります。同 期タイプの場合、 プライマリサイトはセカンダリサイトが更新される までトランザクションを完了しません。 この場合、更新のレスポンス 時間が長くなることがありえます。そのため多くのNoSQLデータベ これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第4章：エンタープライズNoSQLでできること 35 ースは非同期タイプを採用しています。非同期タイプでは、ローカ ルのトランザクションを完了した後、 どこかの時点でリモートレプリ カクラスタにおいてジャーナルフレームを再生します。 エンタープライズクラスのレプリケーション例 MarkLogicはエンタープライズ を実行可能ですが、更新はできま NoSQLの1つであり、これを見て せん。 レプリケーションが有効化 みるとエンタープライズクラスの されていない状態でマスターに レプリケーションをサ ポートす 格納されたコンテンツは、その後 る際に考慮すべき点がわかりま レプリカデータベースに一括複製 す。MarkLogicのDBMSではジャー （バルクレプリケーション）されま ナルフレームをコピーし、それを す。マスターとレプリカが長期間 レプリカデータベースで再生する 接続されずジャーナルの再生が ことでレプリケーションを実現し できなかった場合にも、一括複製 ています。 アプリケーションはレプ が行われます。 リカデータベースに対してクエリ 非同期でもトランザクションを実現可能です。MarkLogicのような NoSQLデータベースでは、更新が順番通りに適用されることを保 証しています。 これによりリモートレプリカはプライマリと整合性を 保つことができます（多少タイムラグはありますが）。 また非同期レ プリケーションでは、ネットワークレイテンシが大きいときでも、デ ータベースならびにレプリカが動作可能です。 レプリケーションを使って、 プライマリデータセンター以外にデータ のレプリカを保管しておけば、ビジネス継続性と災害復旧を実現で きます。 この場所はプライマリデータセンターから、地理的に十分な 距離がなければなりません。通常自然災害に関しては40∼100マイ ル（約65∼160km）離れていれば十分だと考えられています。 エンタープライズクラスのデー タバックアップ 企業においては、 データベースレベルの整合性のあるバックアップが 必要となります。 この対象にはデータ、 スキーマ定義、環境設定詳細、 ジャーナルなどが含まれます。一部のデータのみをバックアップした り、 その時々にデータを部分的にバックアップすることだけでなく、 デ ータベース全体を一度にバックアップできる機能も必須となります。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 36 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション NoSQLデータベースでは、データベース付属のツールによるバッ クアップ機能や、 ファイルシステムレベルのバックアップ（例：Linux のLVM）が用意されています。詳細設定可能なデータベースのジ ャーナルアーカイブ化を同期できるNoSQLシステムであれば、フ ルバックアップやスナップショットから、ポイントインタイムリカバリ （PITR）で特定のデータをリカバリできます。ジャーナルデータが アクティブなログファイルに書き込まれてから、データをバックアッ プジャーナルに送るまでの時間を指定できるので、 リカバリ目標を しっかりと管理できます。 複数レコードのACIDトランザク ション NoSQLデータベースの中には、特定のドキュメントあるいはレコー ドに関して、原子性を持つ（それ以上分解できない） トランザクショ ンを実現しているものもあります。 これはつまり1件のレコードの更 新において、必要な一連の作業がすべて実行されるか、そうでなけ ればまったく実行されないことを意味します。ただし、複数のドキュ メントを更新する場合には、 これが保証されないことに注意してく ださい。 給与支払いの更新について考えてみましょう。従業員の成績評価に 基づいて昇給率を更新するとします。 これはSQLの疑似コードで表 すと以下のようになります。 Update raise_percent=0.20 in employee where performance_review = 'Superior' この場合、成績が優秀（Superior）の従業員全員に20パーセントの 昇給が行われるようにしたいわけです。更新が迅速に実行されれ ば理想的ですが、システムがドキュメントを1つずつ確認して昇給 率（raise_percent）属性を更新していくのであれば迅速な処理 にはなりえません。その処理の最中にこの同じコレクションを小切 手作成プログラムが処理していた場合、受けられるはずの昇給を 受けられない人が出てくる可能性あります。そのようなことは何と しても避けなければなりません。 もう一つ例を挙げてみましょう。大学のデータベースで、片方が学 生、もう片方が学科という2つのコレクションがあるとします。 この ような設計にしたわけは、使用するアプリケーションが、学生のデ ータとは分けて学科のデータだけにアクセスする必要があるため です。 ここで、新しい学科セクションを追加し、選択した学生をこの 新規セクションに割り当て直したいとします。 この変更は原子性を これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第4章：エンタープライズNoSQLでできること 37 持つものとして（分割不能なものとして）行われなければなりませ ん。つまり新しい学科セクションを作成して該当学生をすべてそこ に移動するか、新しい学科セクションの追加に失敗した場合は全 学生を従来の学科に残したままにするということです。一部の学 生のみが移動されたり、 どちらにも所属しない学生がでてしまう （ その学生が所属する学科がない状態になってしまう） ことは避け たいわけです。 複数ドキュメントのACIDトランザクション（第3章参照）に対応して いるNoSQLデータベースであれば、上記のどちらのケースでも一 切問題は生じません。ただし単一ドキュメントに対してのみ不可分 （原子性）のトランザクションをサポートしているNoSQLデータベ ースの場合、 アプリケーション側での対処が必要となります。 エンタープライズクラスのセキ ュリティ セキュリティは真っ先に考えるべきものであるにも関わらず、後回し にされることが多いのが現実です。 データベースの世界では、 「識別 およびアクセス管理」 （IdAM） システムがセキュリティに不可欠のサ ービスを提供しています。政府機関レベルのセキュリティでは、 ドキ ュメントレベルまで認証と認可が適用されています。 認可とアカウンティング どのユーザーあるいはマシンがどのデータに何を実行することが許 可されているかを識別するには、認可とアカウンティング（監査また アカウンタビリティも）を一緒に使用する必要があります。典型的な リレーショナルデータベース管理システム （RDBMS） では、 データベ ース、 テーブル、 レコード、 フィールドの各レベルで権限が付与され、 作成、読み取り、更新、削除というアクションが許可されます。ただし 大抵の場合、権限管理はアプリケーションが担当します。 このように権限を管理することにより組織のセキュリティポリシー が実装されます。MarkLogicのIdAMシステムは、制定されたポリ シーを実効化するメカニズムとして機能します。 セキュリティポリシーそのものと、データベースに実装する一連の ルールは別物であることを理解しておく必要があります。後者は特 定の動作を実行したり、注意が必要な状況を担当部門に通知する ためにデータベースに実装する規則のことです。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 38 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション 認証 一部のシステムではマシンのログインシステムに基づいてデータ ベースへのアクセスを許可しますが、DBMSがユーザーに再度認 証を求めてからアクセス権を付与するシステムもあります。 この場 合、データベースへのアクセス権はデータベースのメカニズムに よって決定され、マシンのオペレーティングシステムによって付与 される権限には基づいていません。 これが本来あるべき姿でしょ う。でないと、データベースへのアクセスが認可されていないユー ザーが、データベースへのアクセスが許可されたマシン経由で、デ ータベースにアクセスできるようになってしまいます。 MarkLogicのシステムでは、ケルベロス認証プロトコルを実装して いるため、ユーザーと特定のサーバーの相互認証だけでなく、サー バー間の認証と、証明書ベースのセキュリティを提供しています。セ キュリティレベルを上げるためには、マシンへのログイン認証の他 にこういった認証が必要となります。 アクセス制御 システムは、あるユーザーのデジタルアイデンティティ （一人のユー ザーが複数のデジタルアイデンティティを持つことが可能な点に 注意しましょう）を確認したら、次にそのアイデンティティが持つ権 限を確認します。 Linuxの世界では（Linuxはファイル/ドキュメントにおける権限管 理の一般的なメカニズムです）、権限は特定のファイルシステムオ ブジェクトに関連付けられています。 ファイルへのアクセス許可は owner（オーナー）、group（グループ）、world（ワールド）の3つ のクラスに分けられます。各クラスはファイルシステムオブジェクト の読み取り、書き込み、実行を行う権限を持ちます（ファイルシステ ムディレクトリにおける実行は通常の「実行」 とは意味が違います） 。 オーナー、 グループ、ワールドの権限を集約することで、付与される 権限が決定します。権限へ変更を加えたい場合、全員の権限を一覧 化しなければならないので複雑になります。 しかし、ロールベースのアクセス制御（RBAC）でこの問題を解消で きます。RBACでは、データベースにおける権限を、個々のユーザー ベースではなくユーザーのロール（役割）に基づいて設定すること が可能で、ユーザーベースの場合よりも簡単に管理できます。RBAC の主な利点の1つは、ロールの権限の変更がそのロールのユーザ ー全員に反映されることで、同じロールのユーザーであれば常に同 じ権限を許可されている状態が担保されます（さらに「一事実（ファ クト）は一箇所にのみ存在する」の原則が実現されます）。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第4章：エンタープライズNoSQLでできること 39 NoSQLデータベースは、RBACに準拠することでアプリケーション のコード量を減らしています。 これもエンタープライズNoSQLデー タベースであるMarkLogicの利点の1つです。 コンパートメントセキュリティ コンパートメントセキュリティはドキュメントを1つ以上のコンパー トメントに割り当てる技術です。コンパートメントはラベルで表さ れます。 ここでロールを拡張しコンパートメントの指定も含むよう にします。あるドキュメントにアクセスするためには、そのドキュメ ントへのアクセス権限を持つロールがあるだけでなく、適切なコン パートメントに属していなければなりません。 このシステムでは従 来のRBACシステムとは異なり、 コンパートメントに割り当てられた ロールに対して通常のOR論理ではなく、AND論理が使用されます。 Unclassified（未分類）、confidential（社外秘）、secret （部外秘）およびtop-secret（極秘） を含む、 「Classification」 （機密度分類）セキュリティコンパートメントがあるとします。 さら にFinance（財務会計）、HR（人事）、Engineering（設計） という 「Department」 （部署分類）コンパートメントがあるとします。何 億円もの利益が見込まれる新製品の設計書があり、 これを「極秘」 ロールと 「設計」ロールの両方に割り当てます。 この場合「極秘」へ のアクセス権があるが「人事」ロールの人、また「設計」ロールだが 「部外秘」までしかアクセス権がない人はこの設計書を見ることは できません。 「極秘」 と 「設計」ロールの両方を割り当てられているメ ンバーだけが設計書にアクセスできるのです。 コンパートメントセキュリティは、多くの企業や非営利団体の情報 管理に用いることができます。例えばイギリスでは、医師はスキャ ンや検査結果など特定のタイプのドキュメントにのみアクセス可 能で、個人情報のドキュメントなどにはアクセスできません。患者 を診断するにあたり、必要なのは特定の症状に関する検査やスキ ャンの結果だけであり、患者の所得や心理評価の結果などは参照 する必要がないからです。 複雑な環境における情報のセキュリティを確保するには、 アプリケ ーションおよびエンタープライズNoSQLデータベースにコンパート メントセキュリティを採用することを検討したほうがよいでしょう。 ポリシー管理 ポリシー管理は、特定のポリシーに基づいて自動化されたアクショ ンをサポートします。例えば、特定ロールのユーザーのみが特定の これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 40 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション データベースを更新できるようにし、それ以外のユーザーが実行し ようとした場合にはセキュリティ警告を表示するといったことが考 えられます。 スクリプト機能のユースケース アドミン機 能 にスクリプト機 能 があると、データベース管 理 者 はスクリプトを1つ作成して、それ を複数のマシンで実行できるた め、負担が軽減します。ここで紹 介している機能は、他のNoSQLに も一部存在するかもしれません が、MarkLogicでは現時点ですべ て提供されています。 MarkLogicアドミンAPIで提供され ている機能： ✓ 環境間での一貫性の保持（単 一あるいは複数のクラスタに おいて複数の同一インスタン スを設定することで実現） ✓ サーバーメンテナンスの自動 化（定期メンテナス以外にも 特定条件に基づいたバックア ップ等） ✓ サーバーリソースの管理 ✓ サーバー設定の一括更新（大 規模なユーザーサブグループ のロール変更等） ✓ 特定のサーバーイベントに関 するログやEメール通知など の生成 特定のサーバーイベントにスクリ プト機能を対応させることで、再 プロビジョニングを自動化でき ます。またデータベース管理者は MarkLogicのスクリプト機能を活 用することで、時間と共に変化す る需要やCPU使用に応じて、クラ スタを拡大・縮小できます。 アドミンおよび管理ツール エンタープライズクラスのNoSQL DBMSでは、一連のデータベース アドミンツール、その他管理ツール、監視ツールを備えている必要 があります。企業はこれらのツールで以下のことを実施することが できます（但し実施できることはこれだけに限りません）。 ✓データベースの健全性を確認する ✓パフォーマンスを向上させるために変更が必要かどうかをプ ロアクティブに確認する これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第4章：エンタープライズNoSQLでできること 41 ✓データベースの負荷とリソース消費に基づいて必要な設定変 更を実施する ビジネスニーズを満たすためには、時には自社で（あるいは自社の IT部門で）ツールを開発する必要があります。 アプリケーションプロ グラミングインターフェース（API）に基づいた管理・監視ツールは、 すでに大規模な管理・監視システムをインストール済みの大企業に とって大きな利点があります。提供されるAPIを使用することで、企業 はNoSQL DBMSの運用状況に関する情報を、迅速に既存のワークフ ローおよび管理コンソールに統合できるからです。 エンタープライズクラスの製品では、変化するセキュリティおよび 運用要件に企業が対応できるよう、独自ポリシーの作成（あるいは 既存ポリシーの変更） もサポートしています。 標準装備インターフェースにすでにAPIが含まれており、かつ業界 で一般的なシステムマネジメントツールに接続して使用できるの であれば、なお望ましいでしょう。 高可用性 システムの一部に障害が起きても機能し続けることが要求されるビ ジネスクリティカルなアプリケーションでは、高可用性は必須です。 データベースが稼働していようがいなかろうが、 またデータベース に災害復旧サポートがあろうがなかろうが、ユーザーが常にデータ にアクセスできるようにしなければなりません。 可用性は、ACID準拠（第3章参照）、高可用性、および災害復旧レプ リケーションの機能の観点から説明できます。災害復旧サイトに 送られるジャーナルログおよび単一ノードにおけるジャーナリング で、 トランザクションの永続性が保証されます。共有ディスクシステ ムは、ストレージサブシステムにより透過的に処理されるので、 レ プリケーションの必要性が軽減します。つまり共有ディスクは高可 用性を提供します。 ACID準拠、災害復旧レプリケーション、高可用性を組み合わせれ ば、24時間年中無休で稼働させる必要があるデータベースの可用 性要件を満たすことができます。そしてこれこそがエンタープライ ズNoSQLなのです。 例えばMarkLogicは、迅速な自動復旧、 自動同時リカバリ、オンライ ンバックアップ、 ライブ（「ホット」）での設定変更、シェアードナッシ ングアーキテクチャなど、高可用性を実現するための複数の機能を 提供しています。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 42 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション スケーラビリティ ビジネスのニーズに応じて、 リソースを追加・削減し、データベース の規模を拡張・縮小できなければなりません。スケーラビリティは マシンの追加、 レプリケーション、シャーディング（第3章参照）で実 現することが可能です。 レプリカセットで複数のマシンを使用する ことで、可用性も確保できます。 レプリカセットでは、データベース のどの部分に関するものであっても、少なくとも1台のマシンが読 み取りリクエストに応じられる状態でなければなりません（そのた め読み取りに関してパーティション化（分割）が発生しないようにし ておく必要があります） 。 サードパーティーのソリューシ ョンとの統合 サードパーティーのサービスと統合することで、NoSQL DBMSを既 存の管理・監視ソリューションと統合することが可能になります。 ま た例えばHadoopのようなソリューションにより、一括処理およびド キュメントのエンリッチメントを非同期で実行できます。あるいは 既存のリレーショナルビジネスインテリジェンスツールを新しい NoSQLソリューションと統合したい場合もあるでしょう。 このため NoSQLの中には、ODBCや、Tableauのようなツールへのネイティ ブコネクタに対応しているものもあります。 MarkLogicは、Nagios、HP Openview監視ソリューション、および RESTインターフェースを持つサードパーティーツールと統合でき ます。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第5章 エンタープライズ NoSQLの実例 本章の内容 ▶データの統合 ▶状況認識の向上 ▶業務データの安全な格納 ▶複数の用途およびアプリケーションでのデータの再利用 本 章ではNoSQLで実際にどんなことができるかを見ていき ましょう。ビジネスにおいてNoSQLソリューションで実現 できる4つ事項―データの統合、状況認識、業務（オペレーショナル） データの格納、既存データの発見と再利用―を、ユースケースを用 いて説明していきます。 異種データの統合 データの統合とは異なるデータソースをまとめて、そこから新しい 価値あるいは新しい意味を生み出すことです。写真、 ドキュメント、 センサーデータ、 ソーシャルメディアの投稿などのタイプの異なる データはリレーショナルデータベース管理システム（RDBMS）には 格納できません。 しかし、1つのデータベースで複数のデータソース を検索できれば、検索および分析の結果は大幅に向上します。 地方自治体の例 フェアファックス郡は米国で最も大きな郡の1つです。住民は100万 人以上、予算規模は4つの州政府に匹敵します。 またバージニア州 およびワシントンD.C.圏で最大の自治体で、7つの州を上回る人口 を擁しています。 フェアファックス郡の平均世帯収入は、全米でもト これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 44 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション ップレベルで、成人人口の半数以上が4年制大学あるいは高校を 終了しています。 フェアファックス郡は多様性と活気に れた地域 であり、中央情報局（CIA）、国家地球空間情報局（NGA）、国家偵察 局（NRO）、国家テロ対策センター（NCTC）、国家情報長官事務所を はじめとする米国政府機関が拠点を置いています。 問題点 フェアファックス郡は、不動産の履歴情報について、自治体の担当 者、地域の住民、土地開発者など各種関係者からの要請に応えなけ ればならないという課題を抱えていました。大量のデータが、異な るデータベースやファイルシステムに異なるフォーマットで格納さ れていたため、情報を効率よく検索できませんでした（図5-1参照） 。 図 5-1: 従来のRDBMSではデータの取り込み、操作、 スキーマの設定に多 大な時間を要する。 図5-1には、今日多くの企業が抱える状況が示されています。データ （通常はリレーショナルデータ）がサイロに分断されている状態で す。 しかし、 リレーショナルデータは通常企業が持つデータ全体の 20％程度に過ぎません。 さらに、RDBMSはMicrosoft PowerPoint のファイル、PDF形式のコンテンツ、 ドキュメント、画像などを格納で きません。 この形式のデータ管理は非効率でコストもかかります。多 くの企業と同様に、 フェアファックス郡もデータを一箇所に統合する 必要がありました。 ソリューション フェアファックス郡には、異種データを統合し、その整合性を維持 し、アクセスを容易にするソリューションが必要でした。また、既存 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第5章：エンタープライズNoSQLの実例 45 のITインフラにうまく適合し、所有にかかる総コストが低くまた予 測可能なソリューションでなければなりませんでした。 最 終 的 にフェアファックス 郡 は M a r k L o g i c を 選 択しました 。 MarkLogicはスキーマ非依存で、すべての異なるサイロからのデー タをそのままの形式で取り込み、そのデータに瞬時にアクセスする ことを可能にするソリューションです（図5-2参照）。 図 5-2: 1つのDBMSに異種データを統合。 フェアファックス郡は、土地利用データのレポジトリを開発しまし た。それにより郡職員、土地開発者、住民が、用途地域変更や郡の 土地条例、不動産履歴などについてリアルタイムで情報を閲覧で きるようになりました。 このレポジトリは新しく採用したこのNoSQL データベースで運用され、郡職員は関連情報を探すために複数の データベースを検索する必要がなくなり、生産性は大きく高まりま した。また、住民も自分のコンピューターやスマートフォンから情 報にアクセスできるようになりました。 利点 6ヵ月以内に、 フェアファックス郡は以下を実現することができました。 ✓関係者へ提供するサービスの維持および向上、 「開かれた政府 （オープンガバメント）」 という目標の推進、市民や企業からの 評判の向上 ✓総所有コストおよびITリソースの削減 ✓同じデータを使用する新規アプリケーションの迅速な開発 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 46 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション 投資銀行の例 トップクラスの投資銀行は、店頭デリバティブ取引のオペレーショ ナルデータストアとして、20もの異なるRDBMSを使っていました。 各データベースは取引を独自の方法で取り込んでいたため、新し いデリバティブ商品のたびに、 リレーショナル構造に変換するため の開発に時間がかかっていました。多くの場合、取引は無理やり既 存のスキーマに押し込まれている状態でした。結果として、1つの行 に取引トランザクションの異なるパラメータに基づく複数の種類 の情報が格納されることになり、 レポーティングが複雑化し間違い が生じやすくなっていました。 そこで同行は、MarkLogicのデータベースマネジメントシステム （DBMS）を導入し、結果として20もの別々のオペレーショナルデー タストアをすべて一元化できました。 このDBMSにはすべての取引 が元の形式のまま保存されるため、長期の開発サイクルも必要あり ませんでした。 またMarkLogicはACIDトランザクションおよびレプリ ケーションにも対応しているため、 同行はDBMSの信頼性と可用性を 維持することができました。 新しいDBMSにより、他にも以下のような利点が同行にもたらされ ました。 ✓市場投入時間の短縮：新しい金融商品に、数日、数週間、数ヵ月 という期間ではなく、ほんの数時間で対応することが可能にな りました。 ✓データ品質の向上：統合オペレーショナルデータストアによ り、複数のストアが矛盾するデータを含んでいることに起因す る処理エラーがなくなりました。 ✓取引あたりのコスト低下：複数のシステム （および9名の常勤サ ポートスタッフ）を維持するのにかかっていたハードおよびソ フトのコストと、例外管理にかかっていた高額な経費を削減す ることができました。 ✓アジリティの向上：同行は、規制強化などの変わりゆく事業ニ ーズに、高額のリソースを追加することなく対応できるように なりました。 状況認識の向上 状況認識とは、システム内の新しいデータや、 ソーシャルメディアの 投稿やセンサーデータなどの近年のストリーミングデータにリアル このデータは他のシステム タイムで応答（アラート）することです。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第5章：エンタープライズNoSQLの実例 47 （軍事指揮システムや取引システムなど） あるいは他のデバイス （戦 場の兵士が装備しているデバイス、 インスタントメッセージのクライ アント、Eメールなど）に瞬時に送られます。 米連邦航空局（FAA） では、局内システムおよび公開情報ソースから 急速に変化する多様な情報をまとめて、 リアルタイムの危機管理ダ ッシュボードを実現しています。FAAは緊急措置ネットワーク （EON） リアルタイムアプリケーションを使用して、悪天候や緊急事態を監 視・トラッキングし、乗客、 フライト、空港の安全を図っているのです。 地上および上空の緊急事態を適切に管理するため、 EONでは複数の ドキュメントタイプやフィードを処理し、それらの情報からできるだ け早く状況を把握する必要がありました。つまりツイート、天気予報、 ニュース記事、 Eメール、 Microsoft SharePointのドキュメント、 位置情 報データなどの非構造化データ用のバックエンドレポジトリとそれを 検索できるソリューションが必要だったのです。 これらのデータソース は、 職員が迅速に分析・共有できるよう一箇所に集約し、 カスタムアプ リケーションや商用アプリケーションと統合する必要がありました。 MarkLogic NoSQL DBMSを導入して数週間で、FAAは、テキスト全 文、 メタデータ、 ファセット検索、 アラート、複雑なコンテンツを利用 できるようになり、 このDBMSをベースに完全に一元化されたウェ ブベースの緊急コミュニケーションシステムの運用を開始できまし た。現在、EONダッシュボードでは、状況認識データを一元化された 表示で確認できます。 この新しいデータベースにより、FAAはさまざ まな種類の非構造化データを迅速かつ容易にロード、検索、変換、 レンダリングすることができるようになり、状況認識に関するコンテ ンツを一箇所で表示できるようになりました（図5-3参照） 。 図 5-3: 異種データを一箇所にまとめて格納するほうが道理にかなって いる場合がある。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 48 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション オペレーショナルデータの格納 オペレーショナルデータベースは次々に追加される大量の情報を 扱う非常に拡張性の高いエンタープライズ対応データベースで、 コ モディティハードウェアで水平拡張できます。 オペレーショナルデー タベースの例としては、取引プラットフォーム、 ソーシャルメディア、 分析用プラットフォームなどがあります。 ある大規模な金融機関では毎年数十万件の取引を行っていますが、 その多くが複雑で完了までに平均6ヵ月を要します。 このような複雑 な取引において、各アクションはFpML（Financial products Markup Language）形式で表されています。FpMLはオープンソースでXMLベ ースの取引記述標準です。 残念ながら、 このアプローチにはいくつか問題がありました。 ✓この金融機関の取引先機関の多くが、それぞれバージョンの 異なるFpML標準を使用している。 ✓FpML標準自体が、時間と共に改訂されていく。 ✓各取引のドキュメントには取引指示のみしか含まれていない。 担当者が取引を実行したり、 リスクを判断するのに使用した全 ての背景情報が含まれていない。参照データと呼ばれる企業、 為替レート、 その他の重要な情報は、 RDBMSに保存されている。 ✓取引はデータベースにコミットされた直後から、必ずしも可視 性があり利用可能であるわけではなく、 コミット後にドキュメン トを喪失するリスクがある。 ✓規制当局からは、同機関がさらされているリスクに関して、デ ータウェアハウスにおける従来のアプローチで可能な24時間 単位の表示ではなく、5分ごとの提示が要請された。 ✓同機関自身も、 リスクの高いトランザクションをすぐに停止 できるよう、 リスクの高い取引行為を検知することを望んで いた。 エンタープライズNoSQL DBMSであるMarkLogicはこれらの問題 を解決するのに最適のソリューションでした。 ✓XMLドキュメントをネイティブに理解し、 ドキュメント全体をイ ンデックス化することができる。 ✓時間と共に変更されるFpMLスキーマが問題とならない。 フィ ールド、要素、要素‐属性、パスレンジインデックスを使用し て、スキーマが異なるもののなかから共通する要素をまとめ ることができる。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第5章：エンタープライズNoSQLの実例 49 ✓金融機関はデータベースのトリガーにXQueryを使用して、エ ンティティの抽出およびエンリッチメントを実行できる。 これに よりリレーショナルな参照データの取得と取引ドキュメント内 への埋め込みが自動化される。 ✓MarkLogicのDBMSはACIDに準拠しており、可用性が高く、災 害復旧サイトにログを送っているため、 この金融機関の取引ド キュメントはデータベースにコミットされた後は喪失されるこ とがない（ACIDの詳細については第3章参照のこと）。 ✓同一のレンジインデックスを使用することで、全取引データに 関して直後のライブレポートができるため、 あらゆる規制を満 たすことができる。 ✓ビルトインのアラート機能が備わっているため、無効あるいは リスクの高い取引やアクティビティに即座に反応することがで きる。 データの発見と再利用 既存データを他の用途に再利用することができれば、組織にとって 新しい大きな収入源となりえます。 しかし、1つのアプリケーションは 多くのデータソースに接続していることが多く、 カスタマイズ作業が 膨大になりがちです。 そこに他の商品が次々と追加されていくと、次第にアプリケーション とデータソースのつながりがまるでネズミの巣のようにごちゃごち ゃになってしまいます（図5-4参照）。 新しいデータソースやアプリケーションが追加されるたびに状況は 悪化していきます。 こうなるとソリューションの管理が頭痛の種にな ってしまいます。 MarkLogicのソリューションなら、頭痛を起すことなくこの問題を解 決できます。図5-5を図5-4と比べてみてください。図5-5のソリューシ ョンでは、大企業で必要となるような規模で、多数のソースからデ ータを変換することなく読み込み、そのデータをさまざまなタイプ のデバイスやコンピューターにリアルタイムで提供することが可能 です。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 50 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション 図 5-4: 複雑な接続は対処に高いコストを要する。 図 5-5: 接続を合理化することでデータの提供もシンプルになる。 このセクションでは、MarkLogicソリューションを導入し、事業の効 率化を実現した企業の例を2つご紹介します。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第5章：エンタープライズNoSQLの実例 51 出版社の例 シュプリンガー社は科学、技術、医療の書籍や定期刊行物を発行し ている、その分野で有数の出版社です。同社の顧客は、同社のワー クフローの一環としてコンテンツ提供用のウェブベースのソリュー ションを強く要望していました。同社は300万件の画像とこれを説明 するXMLを含むデータベースを構築しましたが、 このコンテンツを 既存のワークフローと統合するのは困難でした。 シュプリンガー社は既存のシステムをMarkLogicに移行し、以下の 利点を実現しました。 ✓ユーザーがウェブサイトを閲覧する時間の増加 ✓バウンス（トップページ閲覧のみでの離脱）率の50パーセント 削減 ✓新しいデータベースには画像500万枚以上の格納容量 放送局の例 英国放送協会（BBC）は常にコンテンツを再利用しています。編集者 はコンテンツをデータベースに保存し、 そのコンテンツは動的に公 開（ダイナミックにパブリッシュ） されます（ダイナミックパブリッシン グとはコンテンツ再利用をさらに強化したものです）。 2012年にロンドンで開催された夏季オリンピック期間中、BBCは MarkLogicのNoSQL DBMSを使用して、ユーザーの設定と興味に 基づいてコンテンツを動的に表示させました。 このソリューション では、 コンテンツを動的に再利用して提供するため、編集者による コンテンツだけでなく選手の詳細、写真、競技結果なども一緒に表 示できました。現在、BBCスポーツのウェブサイトでこのソリューシ ョンがどのように機能しているのか確認することができます。www. bbc.com/sport 詳細は以下のウェブサイトを参照してください。www.marklogic. com/resources/playing-to-audiences-in-the-digitalworld これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 52 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第６章 NoSQLソリューションで 考慮すべき10項目 本章の内容 ▶社内外のニーズを確認する ▶ハードウェアとソフトウェアの要件を確認する ▶成長とイノベーションを想定する 自 社 のアプリケーション やシステムアー キテクチャに NoSQLソリューションを検討する場合、その選択はシン プルでもなければ確実でもありません。NoSQLデータベースには さまざまな利点があります。 しかし、すべてをこなせるわけではあり ませんし、 こなそうともしていません。 本章では、NoSQL製品を検討する際に考慮すべき10項目について 考察していきます。本章を最初から読んでいくことで、適切なソリュ ーションの選定に役立ててください。 ソリューションを導入する準備 はできているか NoSQLデータベースマネジメントシステム（NoSQL DBMS）をビジ ネスに組み込む際には破壊的なインパクトが伴います。技術自体 はそう破壊的なものではありませんが、それによりもたらされる変 化のインパクトが大きいのです。NoSQLとはいわばデータの新し い扱い方です。NoSQLに限らず新しいことには何でも一定の学習が 求められます。 ここで考えなければならないのは、いったいどれぐら いの学習が必要になるのかということです。 あなた（またはITスタッ フ）は以下のことができなければなりません。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 54 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション ✓新しいNoSQLソフトウェアの機能や運用上の特徴に対応できる よう、 アプリケーション設計手順およびシステムアプリケーショ ンアーキテクチャを変更する。 ✓NoSQL DBMSを理解し、 またこのデータベースにおけるクエ リ実行に必要な言語を習得する。JavaのNoSQLアプリケーシ ョンプログラミングインターフェース（API）を使って書き込む 必要がある場合もあれば、全く別のクエリ言語が必要となる 場合もある （ただし、大部分のNoSQLデータベースでは、SQL とネイティブクエリ言語の対応表が用意されている）。 これらのスキルがない場合、社内でスキル開発を行うか、社外から 人材を確保しなければなりません。 どちらの場合も、研修の時間と 予算を準備する必要があります。 そのソリューションは十分にア ジャイルか 言い換えれば、そのソリューションはドキュメント、値、 トリプル、検 索のすべてに対応していて、さらにスキーマ非依存かどうか、そし 全てのデータをさまざまな角度から表示できて、同じ機能が一貫 して実装されるのか、 ということです。それぞれが1つのデータタ イプにしか対応しないデータベースを4つ購入して1つのアプリケ ーションに統合するよりも、多くの異なるデータタイプに対応して いるNoSQLデータベース1つを購入するほうが良策でしょう。 この 点を検討することで、NoSQLソリューションの導入により、 どのよ うなインパクトが組織にもたらされるか（前述の「そのソリューシ ョンを導入する準備はできているか」参照）、また将来他のデータ の利用方法を見つけたときに、そのソリューションを拡張して対応 できるかを判断する助けとなります。 NoSQLソリューションをビジネスに組み込むには、変化への意欲、 変化への順応、新しいスキルの習得、ビジネス課題に対するソリュ ーションの新しい視点が必要となります。導入のインパクトに対す る労力を鑑みてNoSQLソリューションにそれだけの価値があるか、 また最終的に投資に見合った大きな利益が得られるかを見極めな ければなりません。 ベンダーに、顧客が最初のプロジェクトの実装にどれくらいかかっ たかを聞いてみましょう。またその顧客が次のプロジェクトをどれ ぐらいの期間で実装できたか、最初のプロジェクトと同程度のサポ ートが必要だったかどうかを聞いてみましょう。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第6章：NoSQLソリューションで考慮すべき10項目 55 アプリケーションの要件を満た しているか NoSQL DBMSを検討する理由はさまざまです。既存のデータベー スの問題を解決するための場合もあれば、サポートすべきユーザ ー数やデータのタイプ、量が変化することを見込んでの場合もある でしょう。 またあるいは、 プロトタイプの開発に必要な時間と労力を 測定するため、予定されている運用環境におけるパフォーマンスを 測定するため、異なるNoSQLソリューションを評価する環境を整え るためなどの理由で、パイロットプロジェクトを実行している方もい るでしょう。 どのような理由でNoSQLを検討しているにせよ、 どんな問題を解決 したいと思っているのか、 またどの程度のコスト （開発コストと運用 コストの両方）およびパフォーマンスを期待しているのかを確認し ておくことは大切です。 データを入れるのに必要な開 発期間はどれくらいか NoSQLデータベースには、 データが特定の形式でなければならない ものと、 ファイルが特定の種類でさえあればよいものがあります。 デ ータベースがどのように機能するかによって、データが検索に利用 できるまでの時間や、 アプリケーションに接続できるようになるまで の時間はさまざまです。 以下について考えてみましょう。 ✓アプリケーションのニーズを、 このデータベースは標準装備で 満たせるか、それともカスタマイズが必要か ✓もし必要な場合、ETL（Extract＝抽出、Transform＝変 換、Load＝ロード） ソフトウェアを開発するのにどれぐらいの 労力がかかるか ✓ベンダーからソフトウェアやトレーニングが提供されるか ✓社内に専門知識を有する人がいるか、 それともコンサルタント を雇う必要があるか これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 56 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション どのぐらい簡単にデータベースにデータを入れることができるか、 またデータベースに入れたデータはどのくらいの期間でアクセス可 能になるのか、ベンダーに示してもらいましょう。 新しいツールは必要か NoSQLの開発や業務への導入にあたり、既存のツールを廃止し、別 のツールを入手しなければならない場合があります。もちろん、開 発環境を拡張してアプリケーションのプログラミングに必要な言語 をサポートすることも可能でしょう。例えば、Eclipseには複数の言語 モジュールがあります。Komodo EditやVisual Studioも同様で、 これ らはすべて外部ライブラリを介して拡張可能です。 新しいDBMSを既存の管理・監視システムにどのように統合するか を一通り考えてみると、今後想定される課題を特定しやすくなりま す。 そのような課題には、一般的な管理・監視システムに対してベン ダーが提供しているインターフェースが非常に便利な場合があり ます。 クラウド戦略に対応しているか たとえ文書化や明示化がされていなくても、おそらくなんらかのク ラウド戦略をお持ちの組織が多いと思います。検討しているNoSQL ソリューションが、 自社のクラウド戦略に対応しているかを判断する ためには、 まず自社がどのようなクラウドプラットフォームを検討し ているかを知る必要があります。IaaS（サービスとしてのインフラス トラクチャ）なのか、PaaS（サービスとしてのプラットフォーム）なの か、それともSaaS（サービスとしてのソフトウェア）なのか。 またレプ リケーションやデータのバックアップなど、NoSQL DBMSとクラウド をどう組み合わせて使用するつもりなのかも明確にしておく必要が あります。 パブリッククラウドのソリューションを使用する場合、転送中のデー タや保存データに関するセキュリティの懸念にも対処しなければな りません。データセンター内で運用する場合や、 プライベートクラウ ドを使用する場合には検討する必要がない種類の懸念です。あな たの組織もベンダーも、暗号化、パフォーマンス、 アクセス制御とい ったセキュリティ対策に取り組む必要があります。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 第6章：NoSQLソリューションで考慮すべき10項目 57 エンタープライズ対応か エンタープライズNoSQLの特徴（第4章参照）には、バックアップ、 フ レキシブル（柔軟な） レプリケーション、複数ドキュメントのACIDト ランザクション、セキュリティが含まれます。 エンタープライズNoSQLソリューションを検討する場合、さらに以 下も考慮してください。 ✓ベンダーの実績（事業継続年数など） ✓ベンダーの既存顧客が、 自社と類似しているか ✓検討しているDBMSが、 自社の製品開発サイクルおよび現在の メンテナンスニーズにどの程度適合しているか ✓ベンダーはヘルプデスクによるサポートや問題解決を直接提 供しているか、それともサードパーティー経由で提供している か。 また事業所が国内にあるか ✓検討しているDBMSはカスタマイズ可能か、可能な場合は誰が その作業を行うのか ✓ベンダーはデータベースクラスタの健全性と導入を管理する DBAツールを提供しているか 特殊なハードウェアが必要か 大部分のNoSQLソリューションの利点は、DBMSがコモディティハー ドウェア上で動作し、特殊なハードウェアが必要ないことです。 コモ ディティハードウェアは必ずしも安価とは限りませんが、必要に応じ て拡張できるので、その時点で消費している以上のリソースに費用 をかける必要がありません。 またリソースの消費が減った場合は、 そのハードウェアを別の用途に使うことができます。 ソリューションプロバイダーから、データベース用に特殊なハード ウェアを勧められた場合は注意してください。 というのもこれはキャ パシティの増加に対する 「NoSQL的」なやり方ではないからです。な ぜ特殊なハードウェアが必要なのか、ベンダーに詳細な説明を求め ましょう。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 58 エンタープライズ NoSQL For Dummies, MarkLogic スペシャルエディション 事業の成長に対応できるか あなたの組織がビッグデータの問題を抱えているなら （ちなみビッ グデータとは、大量、多様、更新が頻繁、複雑で、ビジネスにとって 非常に重要な非構造化データのことです）、検討しているNoSQLソ リューションが、負荷が増えた場合にどのように対処しうるかを理 解しておくことは非常に重要です。以下の点について確認してみま しょう。 ✓ベンダーの顧客企業の中に、大規模な本番環境で必要不可欠 なデータにそのソリューションを使用している企業はあるか ✓ベンダーの顧客企業は、それぞれの事業環境でそのDBMSの 使用を拡大しているか ✓一般にアクセス可能な公開サイトで、そのソリューションを利 用している顧客はいるか、それらにアクセスして試用すること は可能か アプリケーションの開発を加速 できるか NoSQLデータベースには、セキュリティや一貫性、検索機能を含ん でないものもあり、その場合、膨大な開発費用が生じる可能性があ ります。NoSQLデータベースを検討する際には、アプリケーション 開発に必要なエンタープライズ機能、例えば高度なクエリ機能、 ス テミング（語幹処理）機能、全文検索、地理空間、アラート機能など が組み込まれているものを選ぶといいでしょう。 豊富なアプリケーションライブラリや機能を提供しているデータベ ースを導入することで、実装にかかる時間を、18ヵ月から6∼12ヵ月 へと大幅に短縮できます。 オープンソースのNoSQLデータベースで はなく商用のNoSQLデータベースを購入したほうが、結局は圧倒的 にお得です。是非商用エンタープライズNoSQLデータベースである MarkLogicをお試しになり、実装時間を削減してください。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 Notes これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 Notes これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 Notes これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 Notes これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。 これらの内容は当社が著作権を保有しています。ⓒ 2015 John Wiley & Sons, Inc. いかなる公開、配 布、および不正使用も厳禁します。