本橋信也のレビュー一覧
-
-
-
-
-
-
Posted by ブクログ
★★★★☆
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" に由来 -
Posted by ブクログ
データベースとしてのNOSQLについて、その技術要素とビジネス的価値について述べた本。
NOSQLというのがどういうものなのかについて客観的に大枠を捉えた知識を手に入れて、自分の断片的な知識とすり合わせ、補おうと考えて、本書を手にした。結果は、想像以上によく書けていて驚いた。「さすが後発」という評価レベルを超えてるｗ
NOSQLという言葉はクラウドの枠組みの中で語られることがほとんどで、純粋にデータベースの技術要素として語られることは少ない。また、RDBを扱う言語としてのSQLとその対称としてのNOSQLという語られ方をすることがほとんどで、純粋にデータベースという切り口で語られることは少ない。さらに言えば、よくNOSQLデータベース一覧みたいな資料やサイトを見かけるが、「このリストを見た後この情報で何か意味のあることにつなげられるのか？」という当然の疑問を解消してくれる有意義なまとまった情報は見たことがない。道具の本質を的確に捉えた資料はみかけない、という感じ。。
しかし、本書では、アプリケーションから見たときのデータベースのあり方という前提を当然のように踏まえて、NOSQLという技術要素に代表されるデータベースを類型化し、類型化したデータベースごとの特徴を実体としてのデータベースを引き合いに出しながら、非常に簡潔に述べている。さらには、そのビジネス価値へのつなげかたまで。
結構な量の技術書を読んで、大概の技術書は数ページに1箇所は確実に首をかしげるような表現が見られ、「技術書はこんなものなんだな」という認識でいたのが、本書を読んできれいにくつがえされた。相当よくまとまってる。ありがちな偏見も見られない。
内容自体は、CAP定理、Hadoop、Dynamo、Bigtable、Memcached、HBase、Cassandra、Neo4jなど、これが書いてないとまずいだろ的な内容をすべて含んだものだ。これだけ見ればオーソドックスな内容だが、正直これらの内容を過不足なく含んだ上、脱線せずに一定の客観性を保ちながらまとまった資料は本書以外に見たことがない。すごい。 -
-
Posted by ブクログ
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では、単体のコンピュータでは何十時間もかかる大量データのバッチ処理を複数のコンピュータで並列処理することで、迅速に処理することができます。 -
-
-