「NOSQLの基礎知識」を読みました
勉強記録
今日は「NOSQLの基礎知識」を読みました。
全てを理解するのはまだ難しく、理解できたところ、重要そうなところをまとめてみました。
<第1章> NoSQLとは何か？
SQL以外のデータベースの総称
・ビッグデータに対応する
Volume 膨大な量
Velocity 速さ
Variety 多種多様
の3つのVに対応するということ
もし今RDBだけで上手く動いているのなら、無理にNoSQLを使う必要はない
RDBを使っていて、整合性を一部犠牲にしてでもどうしてもパフォーマンスを上げたいときにNoSQLの使用を検討する。
（NoSQLのデメリット）
・機能が豊富ではない
書き込み、読み出しというシンプルな動作である
・データ整合性が緩い
データの整合性とは、データが更新された場合、次に誰がアクセスしても同じ結果が得られることである。
RDBMSは排他的制御の仕組みを備えており、データの整合性を保っている。そのためにデータ量が増えると処理が遅くなってしまう。
NoSQLはそうしたデータ整合性を緩めることで、処理が速くしている。
・結果整合性でよいという考え
アクセスを行う都度、排他的制御を行っていると、大量に速く処理するのは難しい。
NoSQLは、データの整合性は全てのアプリケーションにおいて必ずしも必要であるわけではない→つまり結果的に整合性がとれていればいいという考え
パフォーマンス向上だけに目を向けてむやみにNoSQLを使うのではなく、必要に応じてRDBとNoSQLを使い分けるべき。
<第2章> NoSQLのデータモデル
NoSQLのデータベースは世界に100種類以上もある。
データモデル（データ構造）によって分類できる。
そもそもSQLのデータモデルは・・・
RDBはテーブルの形でデータ構造の設計をし、その上でテーブル間の関係性を定義する。
RDBの設計では正規化によってデータの冗長性と不整合を排除している。
これにより、データベースにデータが登録される前に間違ったデータが入らないようにしている。
データ同士の関係性をあらかじめ明確にしているので、データの結合や検索、集計などSQL文を使ってさまざまな機能が使えるようになっている。
（NoSQLのデータモデル）
・キー・バリュー型のデータモデル（KVS) 重要！
キーとバリューという組み合わせのシンプルなデータモデル。
キーとバリューがそれぞれ対になっていて、新しいデータが追加されるごとに行が追加されていく（データが増えるにしたがって表が縦方向に伸びていく）。
有名なのは、Memcached、Redis
・カラム指向型のデータモデル
キー・バリュー型を少し高度にしたデータモデル。
行に対して付されたキー（行キー）が、複数のカラムを持つことができる。
縦方向だけでなく、横方向にも伸ばしていくことができる。
キー・バリュー型と違って、ある行キーの全てのカラムにバリューが挿入されていないことも許容している。
有名なのは、Cassandra、HBase
・ドキュメント指向型のデータモデル
有名なのは、CouchDB、MongoDB
・グラフ型のデータモデル
データとデータの関係性を管理できるデータモデル。
それぞれのデータが他のデータに対して、自由な関係性を持つことができる。
この関係性はグラフ理論に基づいて表現されることから、グラフ型と呼ばれている。
（キー・バリュー型の特徴）
キーとバリューだけなので、データモデルがシンプルである。
スケールアウトに最適。
※スケールアウトとは、データ量が増えたときにサーバーを追加してデータの保存容量を拡張していくこと。
これと似ている「スケールアップ」言葉は、ハードディスクをより大きなものに置換することで保存容量を増やすやり方。
複数のサーバーに複数のバリューを複製することで、どれかのサーバーがダウンしても対応できるようにしている。
でも、あるサーバーのバリューが更新されることで、システム内に複数のバージョンが混在してしまう心配もある。
（カラム志向型の特徴）
キー・バリューと同様にスケールアウトに適している。
名前が似ているカラムナデータベースとは全く違うので注意。
スケールアウトしたいからという理由だけでNoSQLを選択するべきではない。
あくまで一番大切なのはデータの整合性を保つこと。RDBでもシャーディング はできるし、よく検討してからNoSQLを使う。
<第3章> アーキテクチャの基本概念と技術
NoSQLデータベースのアーキテクチャに着目すると、大きく2種類に分けることができる。
※アーキテクチャとは構造とか構成といった意味
・マスタ型のアーキテクチャ
マスタノードが複数のノードを管理する構造。
マスタノードが停止するとシステムも停止してしまうため、マスタの冗長化やマスタ停止時に他のノードがマスタの役割を代行するなどして、障害に備える
P2P型では、それぞれのノードがお互いの情報ほ交換しあっていて、もしひとつがダウンしてしまっても他のノードがその役割を引き継ぐ。
（強い整合性と弱い整合性）
強い整合性はRDBの特徴で、必ず最近バーションに更新されたデータが呼び出されることを保証している。
弱い整合性は最初の更新からわずかな時間をたったのちに、全てのノードで最新版のデータが呼び出される状態になるという特性。つまり、他のノードで更新前のバージョンが読み出される可能性はあるけど、「結果的に」整合性が保たれればよいという、強い整合性よりも厳密さが緩いことを意味する。
（CAP定理）
整合性（Consistency)、可用性（Availability)、分断耐性（Partition Tolerance)は、分散型データベースシステムの三大要素でCAPという。
しかし、分散システムにおいてこの３つのうち最大でも２つしか満たすことができないという定理があり、これを「CAP定理」という。
※可用性とは、システムが継続して稼働できる能力のこと。
※分断耐性とは、複数のノードからなる分散型システムのネットワークが分断されても、間違った結果を引き起こさないということ。
（ACIDとBASE)
データベースの特性
ACIDはトランザクションが信頼性をもって実行されるための必要条件
BASEはアプリケーションは基本的にどんな時でも動き、常に整合性を保つ必要はないけど、結果として整合性がとれる状態にあるという特性を備えているべきであるという考え方。
<第4章> HadoopはNoSQL?
Hadoop(ハドゥープ）とは？
並列分散処理を行うためのソフトウェア集。大規模なデータを処理するためのミドルウェアである。
<第5章> 主なNoSQLデータベース製品
様々なNoSQLデータベース製品がある。
主に使われるのはキー・バリュー型のMemcachedとRedis
<第6章> NoSQLデータベースの選択基準
NoSQLデータベースを選ぶ際には、各製品の技術的特性を見極める必要がある。
・整合性（システム内のどの複製を読みだしても、データ同士に矛盾や時差がない状態を保てるか）
・拡張性（スケールアウトが可能か）
・柔軟性（データモデルを簡単に設計できるか）
・機能性（機能が豊富か）
・永続性（ノード障害などのときにも、データを失うことなく安全に保たれるか）
RDBは拡張性と柔軟性が抜け落ちている。
しかし、それを補うといって拡張性重視でカラム指向型にするとSELECTが使えないし、柔軟性重視でドキュメント指向型にすると整合性がとれない。
なにもよりも「整合性」が最も大事である。
その上で、パフォーマンスに問題が出てきた時に、整合性を一部犠牲にしたり、非正規化していいところは非正規化するなどしてパフォーマンスをあげる。
