NOSQLの基礎知識 ビッグデータを活かすデータベース技術

太田洋 / 本橋信也 / 河野達也 / 鶴見利章

本書はビッグデータの中心的な技術基盤であるNOSQLを
平易かつ包括的・体系的に整理しています。
この分野で国内のリーダー的な立場である開発ベンチャー企業が、会社ぐるみで執筆・監修に取り組み、１冊の本としてまとめあげました。
ビッグデータの解説本は、現在では花盛りですが、技術の視点で現代を捉えている点、確かな技術力の裏打ちがあればこその解りやすさで、表層をなぞるだけの解説書やビジネス書とは一線を画しています。
エンジニアはもちろん、ビッグデータに関心のある方ならどなたでも、効率よくポイントを押さえることができます。

■本書で個別に解説しているNOSQLデータベース(ABC順)
・Amazon Dynamo ・Apache HBase ・Apache Cassandra ・Apache CouchDB
・Google Bigtable ・Hibari ・Hypertable ・InfiniteGraph ・Memcached
・MongoDB ・Neo4j ・Redis ・Riak ・Scalaris ・Tokyo Cabinet/Tyrant ・Voldemort

• カテゴリ: ビジネス・実用
• ジャンル: IT・コンピュータ / 全般
• 出版社: リックテレコム
• 電子版発売日: 2019年08月20日
• コンテンツ形式: EPUB
• サイズ(目安): 6MB

[ブクログ · ★★★★★]

NOSQLの基本がわかる。
データベースの選び方とかもある程度わかるようになる。読んでおいて損はない一冊。

[ブクログ · ★★★★★]

* 分かりやすくてよかった。さくっと読める。
* 基礎知識というタイトル通り、非常に基本的な所から、各種用語、概念等の説明があり、それらも分かりやすくまとまっていた。
* NoSQL 系の DB の一覧や性質による分類もあり、俯瞰して捉えられるようになってよかった。
* まぁ、 Hibari 寄りの内容が一部あるのはしかたないかなと言った感じ。全面に押し出す感じではなかったので、気になる程ではなかった。
* かなり薄くてさくっと読めるので、もう少し厚くして詳細まで書いてくれると嬉しかった。

[ブクログ · ★★★★★]

NOSQLの一般的な解説から、データモデルとアーキテクチャによる各DBの分類、さらにNOSQLを選択する際の基準などもまとまっている。
とりあえず、技術的に興味があって何か触ってみようという段階では最適かな。

[ブクログ · ★★★★☆]

ぱぱっと読んで次に読むべきNOSQLの専門書を見つけるための本。

技術書の分類の中ではかなりすらすら読める内容、20時間かからず読めた。
NOSQLの説明から、さまざまな製品の紹介・分類が行われているため入り口としては適している。内容はまとまっていてよかった。
ただ、技術的な内容は表面しか書いていないので、結局興味を持ったNOSQLの専門書を別途読む必要がありそう。

[ブクログ · ★★★★☆]

NOSQLの各エンジンについての特徴が理解できた。安易になりすぎず、かつ丁寧に解説しているのが嬉しい。

[ブクログ · ★★★★☆]

★★★★☆
NoSQLの基礎がわかる良書
【内容】
本書はビッグデータの中心的な技術基盤であるNOSQLを
平易かつ包括的・体系的に整理しています。

【感想】
すっきりしました。
NoSQLってバズワードすぎてなんとなくレベルだったのですが、しっかり理解出来ました。
100種類以上あるNoSQLもそのうち集約されていくんだろうな。

特にどの製品を選ぶべきかという観点は参考になった。
NoSQLに興味のある人が最初に読むべき本であろう。

個人的には、CassandraとMongoDBが気になるし良さそう。

【引用】
NoSQL
　"SQLだけでなくて、新しいDB技術も利用する必要がある"というムーブメント
　Not only SQLの略
　"RDBでうまく動いているならそれをNoSQLにする必要はない"
　→NoSQLは銀の弾丸ではない。利用目的を絞り込んだDBである。

BIG DATAへの対応
　Volume(膨大な量)
　Velocity(速く処理する)
　Variety(構造が複雑化)
　→処理するにはRDBでは限界がある。

NoSQL
　DBクラスタを水平拡張
　汎用的なハードで使える
　複雑で多種多様に変化するデータ構造に対応
　高可用性と高信頼性

NoSQLの欠点
　機能が弱い（joinすらない)
　データの整合性が弱い(結果整合性：最終的に一致すればOK）

Hadoop
　並列分散処理を行うためのフレームワーク
　Hadoop Distributed File System(HDFS)
　　分散ファイルシステム
　MapReduce
　　並列分散バッチ処理プログラム
　　MapタスクとReduceタスクに別れる
　　Map・・・元データを分解・抽出・変換→出力
　　Reduce・ Mapデータを集約→出力

NoSQLのデータモデル
　100種類以上ある。
　主に以下の４つに分類される
　　キー・バリュー型
　　カラム指向型
　　ドキュメント指向型
　　グラフ型
　複数ノードで動く分散システムである。
　　マスタ型
　　Ｐ２Ｐ型

キー・バリュー型(KVS)
　キーとバリュー(値)が１対１の関係。
　２列のテーブルのイメージ
　製品：Dynamo,Voldemort,Riak,Redisなど

カラム指向
　行キーが、複数の列を持つことができる。
　列は動的に追加できる。
　行を増やすだけでなく列も増やせるDB
　製品：Bigtable,Cassandra,HBaseなど

ドキュメント指向型
　JSONなどドキュメントの形で管理する。
　ビッグデータ対応というより、使いやすさに重点。
　分散とか速度では、KVSやカラム指向にはかなわない
　製品：CouchDB,MongoDBなど

グラフ型
　データとデータの繋がりを管理できる。
　製品：InfiniteGraph,Neo4jなど

CAP定理
　分散システムは最大２つしか満たせない
　C:整合性・・・データが常に同じか
　A:可用性・・・どのクライアントも読み書きできる(Lockしない)
　P:分断耐性・・ネットワーク切れても平気か
　
　NoSQLはまずPが大切(分散型なので)

CA
　整合性と可用性
　REBMS(Oracle/SQLServer)

AP
　可用性と分断耐性
　Dynamo,Cassandra,Vodemort,CouchDB,Riak

CP
　整合性と分断耐性
　Bigtable,MongoDB,HBase,Redis

NoSQL選定基準
　利用目的を明確にすること
　→それにあったNoSQLを選定する

整合性重視
　◎HBase
　○Cassandra,Riak,Voldemort
　×MongoDB,CouchDB,Neo4j

拡張性重視(スケールアウト)
　◎HBase,Cassandra,Riak
　○MongoDB,Voldemort,InfiniteGraph
　×CouchDB,Neo4j,Redis

柔軟性重視
　データモデルを簡単に設計できる
　◎MongoDB,CouchDB,Neo4j,InfiniteGraph
　○Riak,Cassandra,HBase

機能性重視
　・Neo4j,InfiniteGraph・・ソーシャルグラフ
　・CouchDB,MongoDB,Riak・ MapReduceで分散高速大量データ集計
　・Cassandra,HBase・・・・Hadoopで分散高速大量データ集計
　・Neo4j,Redis,Riak・・・ 全文検索
　・Neo4j,Redis・・・・・・トランザクション
　・Cassandra,MongoDB・・・索引を付けられる
　
永続性重視
　◎Cassandra,HBase,InfiniteGraph,Neo4j,Voldemort,Riak
　○MongoDB,CouchDB,Redis

商用サポート
　◎HBase,Cassandra
　○MongoDB,CouchDB,Riak,Neo4j,InfiniteGraph

コミュニティ
　◎Cassandra,CouchDB,HBase,MongoDB,Riak,Neo4j

総合評価
　◎Cassandra
　◎HBase
　◎MongoDB
　
パッケージ製品
　Cloudian(Cassandra,Redis)
　
HBase
　カラム指向・マスタ型
　Hadoop環境で稼働する
　MapReduceも可能
　強い整合性
　難易度が高いらしい
　Facebookのリアルタイム分析で使用

Cassandra
　カラム指向・Ｐ２Ｐ型
　Hadoopでも動作可能
　結果整合性のレベル調整が可能
　ギリシャ神話の悲劇の預言者Cassandra王妃が由来

MongoDB
　ドキュメント指向型・マスタ型
　レプリカセットも使える（マスタ死んでも平気）
　MapReduce適用可能
　インデックス機能あり
　N.Y.Timesで使用
　英語で「ばかでかい」を意味する "humongous" に由来

[ブクログ · ★★★★☆]

データベースとしてのNOSQLについて、その技術要素とビジネス的価値について述べた本。



NOSQLというのがどういうものなのかについて客観的に大枠を捉えた知識を手に入れて、自分の断片的な知識とすり合わせ、補おうと考えて、本書を手にした。結果は、想像以上によく書けていて驚いた。「さすが後発」という評価レベルを超えてるｗ



NOSQLという言葉はクラウドの枠組みの中で語られることがほとんどで、純粋にデータベースの技術要素として語られることは少ない。また、RDBを扱う言語としてのSQLとその対称としてのNOSQLという語られ方をすることがほとんどで、純粋にデータベースという切り口で語られることは少ない。さらに言えば、よくNOSQLデータベース一覧みたいな資料やサイトを見かけるが、「このリストを見た後この情報で何か意味のあることにつなげられるのか？」という当然の疑問を解消してくれる有意義なまとまった情報は見たことがない。道具の本質を的確に捉えた資料はみかけない、という感じ。。

しかし、本書では、アプリケーションから見たときのデータベースのあり方という前提を当然のように踏まえて、NOSQLという技術要素に代表されるデータベースを類型化し、類型化したデータベースごとの特徴を実体としてのデータベースを引き合いに出しながら、非常に簡潔に述べている。さらには、そのビジネス価値へのつなげかたまで。

結構な量の技術書を読んで、大概の技術書は数ページに1箇所は確実に首をかしげるような表現が見られ、「技術書はこんなものなんだな」という認識でいたのが、本書を読んできれいにくつがえされた。相当よくまとまってる。ありがちな偏見も見られない。



内容自体は、CAP定理、Hadoop、Dynamo、Bigtable、Memcached、HBase、Cassandra、Neo4jなど、これが書いてないとまずいだろ的な内容をすべて含んだものだ。これだけ見ればオーソドックスな内容だが、正直これらの内容を過不足なく含んだ上、脱線せずに一定の客観性を保ちながらまとまった資料は本書以外に見たことがない。すごい。

[ブクログ · ★★★★☆]

NOSQLの概要を知ることができるいい本。

それぞれのNOSQL製品がどういった場面で使用されているか知ることができます。RDBはわかるけど、NOSQLはまだよくしらん、でもこれから勉強しな、、、という人にはピッタリではないかと思います。

[ブクログ · ★★★★☆]

NOSQLって、SQL以外のいろいろなDB(風)システムの総称なのか。それからして知らなかった。

読み進めていくと、自分がいかにRDBの思想に「毒されて」いるかわかる。
データをRDB風に格納する必要性なんかほとんど無かったのに。

中でもAP(可用性+分断耐性)重視するシステムに魅力感じるのはそれがいかにもNOSQLっぽく思えるからか。
サーバーというと堅牢でCP(整合性+分断耐性)重視という印象が強いので、全体的にバランスとって最終的に辻褄合わせるやり方は斬新で夢を感じる。

[ブクログ · ★★★☆☆]

　NOSQLのお勉強。
　ビッグデータへの対応とは、３つのV、すなわち、膨大な量＝Volume、速さ＝Velocity、多種多様＝Varietyに対応することを意味します。

■キー・バリュー型のデータモデル
　NOSQLデータベースのなかには、RDBのようなテーブルや関係性を定義せず、「キー」と「バリュー」という組み合わせからなるシンプルなデータモデルを基本とするものがあります。
　ここで言うキーとは、RDBにおけるキーの概念とやや異なり、バリューに付した識別番号のようなものです。

■カラム指向型のデータモデル
　キーが1つのバリューと対になるのではなく、行に対して付されたキー(行キー)が、複数のカラム(列)を持つことができます。
　また、行ごとの列の数は(カラム数)は、RDBのテーブルのように静的・固定ではなく、動的に追加していくこともできます。また、キー・バリュー型と異なり、ある行キーの全てのカラムにバリューが挿入されていないことも許容します。

　RDBとの決定的な違いとして、カラムの数を後から増やすことができます。RDBの行(レコード)のように、データの発生に応じて動的に、かつほぼ無限に、カラムを追加していくことが可能なのです。

■ドキュメント指向型のデータモデル
　JSONやXMLといったデータ記述書式で記述されたドキュメントの形で、データを管理します。各ドキュメントは階層構造を持たず、相互の関係が横並び(フラット)に管理されます。

　…RDBのように固定されたデータ設計(スキーマ)が不要なことから「スキーマレスである」と言われています。

■グラフ型のデータモデル
　グラフ型は、データとデータ間のつながり(関係性)を管理できるデータモデルです。…
　これにより、個々のデータが持つ属性に依存することなく、相互の”つながり方”だけを独立した形で保持することができます。RDBでも、データのエンティティ(実体)と関係性を切り離して保持しますが、その関係性はテーブルやテーブル間の構造として固定化され、データはその関係性によって規定されます。対してグラフ型では、各データが他のデータに対し、それぞれ自由な関係性を持つことができます。データは固定的な関係性に規定されず、他のデータとの関係を変化させることも許容されます。なぜならその関係性は、テーブルの構造とも、テーブル間のリレーションシップとも異なるからです。そのときの関係表現(ノーテーション)は、n対nのノード間における経路や分岐や方向性を、関係線で示した記法となります。
　
　ノード：関係性を保持する主体を表します。頂点とも言います。
　リレーションシップ：ノード間における関係の有無と、その関係の方向を表します。
　プロパティ：ノードの属性とリレーションシップの属性です。

　RDBは、あるデータが更新されている最中には、同じデータを別のユーザーが更新することがないよう、そのデータにロックを掛け、最初の更新が完了して全てのノードに反映されるまで待ちます。データベース管理システムのこの動作を「同時実行制御(排他制御)」と言います。これにより、どのノードにあるどのデータを読み出しても、常にデータの一貫性が保たれるようにします。
　これに対し「弱い整合性」は、最初の更新からわずかな時間を経たのちには、全てのノードで最新版のデータが呼び出される状態になるという特性です。仮にある瞬間を捉えると、ひとつのノードのデータだけが更新された後、他のノードで更新前のバージョンが読み出される可能性があります。それでも、「”結果的に”全てのノードのデータが同じになればよい」とする考え方です。

■CAP定理
　分断耐性とは、複数のノードからなる分散型システムのネットワークが分断されたとしても、間違った結果を引き起こさないという特性です。間違った結果とは、例えば、データの不整合が発生することを指しています。分断耐性は「システムが継続して使えること」、つまり「可用性」とは異なる特性なので注意してください。…
　これら３つの特性、即ち、整合性、可用性、分断耐性は、分散型データベースシステムの三大用件であり、頭文字をとってCAP定理と総称されます。そして分散システムにおいては、「3つのうち最大2つしか満たすことができない」という定理があります。これは「CAP定理」として、NOSQLの技術者には広く知られています。

　もう一方のBASEとは、「アプリケーションは基本的にどんな時でも動き(Basically Available)、常に整合性を保つ必要はないが(Soft-state)、結果として整合性がとれる状態に至る(Eventual Consistency)という特性を備えているべきである」という考え方です。

　シャーディングでは、予め定めた規則に従って、各ノードにデータを割り当てていきます。

　Hadoopでは、単体のコンピュータでは何十時間もかかる大量データのバッチ処理を複数のコンピュータで並列処理することで、迅速に処理することができます。