同じ職場のエンジニアに『NOSQLの基礎知識』はいいぞ〜と勧められて読もうとしているのですが、マーケターレベルだと、2章と4章を読めば良いとのことです。それ以外は実際に手を動かす人が必要な知識らしい。なので、今回は1、2、4章に書かれている内容を簡単にまとめてみようと思います。
NOSQLとは(1章)
- Not Only SQLの略で、SQLではないと言う意味。
- RDBは単体のハードウェア上で利用するには最適だが、複数台並べてデータを分散して管理するのが不得意だがNOSQLはそれが得意。
- SQLは膨大かつ多種多様で激しく変化するデータの塊を制限なしに保存することが難しいが、NOSQLはそれを可能にする。
NOSQLの特徴(2章)
- 機能がRDBほど豊富ではない
Joinなどの演算子もサポートされていない。（今はMongoDBではlookupとかいう機能が付いている模様） - データの整合性がゆるい
- 結果整合性で良いという考え
一時的なデータの不整合は問題としない。 - NOSQLは正規化、更新書き込み量の最小化、メモリキャッシュの利用などの専門性が不要。
- SQLとNOSQLは補完関係にある。
SQLは豊富な機能とデータの整合性に強いが、ビッグデータに弱い。NOSQLはその逆。
NOSQLの種類(2章)
- 世界に100種類以上存在
ビッグデータに関連するカテゴリは以下の4つ
・キーバリュー
・カラム指向
・ドキュメント指向
・グラフ型 -
一般的なRDBなどのSQL
将来どのようなデータが発生するか想定の範囲内で設計が行われる。 -
キーバリュー
・キーとバリューの対が行として格納される。（データモデルがシンプル）
・キーを指定すればバリューを探し出せるのでサーバが何台増えても対応でき、スケールアウトに適している。
・複数のサーバに複数のバリューを複製した場合、複数のバージョンが存在する可能性がある。
・具体的なNOSQL：Dynamo,Voldemort,Riak,Hibari,Redis,Scalaris,Tokyo Cabinet/Tyrant -
カラム指向
・キーの付された行が複数のカラムを持つことを許容している。
・あるカラムにおいて全てにデータが格納されていなくても良い。
・カラム数を後から増やしても良い。
・具体的なNOSQL：Bigtable,Cassandra,HBase,Hypertable -
ドキュメント指向
・JSONやXMLといったデータ記述形式で記述されている。
・各ドキュメントは階層構造を持たず、相互の関係が横並びに管理されている。
・具体的なNOSQL：CouchDB,MongoDB -
グラフ型
・データとデータ間のつながりを管理できる。
・個々のデータの属性に依存することなく、相互のつながり方だけを独立した形で保存できる。
・ノード（頂点）、リレーションシップ（関係の有無、関係の方向）、プロパティ（属性）の３つの要素から構成。
・属性は、期間や有効/無効のデータなどを持たせることができる。
・データ間の関係性を示すグラフを作成するという目的のために開発され、最適化されている。
・具体的なNOSQL：InfiniteGraph,Neo4j
HadoopはNOSQLではない(4章)
- Hadoopは複数のソフトウェアを包含するフレームワーク
- HDFSは大量のデータを複数のサーバに分散して格納する点でNOSQLのように見えるが、MapReduceによるバッチ処理前提となっており、リアルタイムでの応答の速さを求められる対話型のNOSQLとは分けて捉える必要がある。
MapReduce処理(4章)
- MapReduceは大規模なデータを複数のノードで並列分散処理するためのプログラミングパターン
- データ処理をMapタスク（膨大な元データを分解し必要な情報を抽出し有用な形に変換して出力）とReduceタスク（抽出された情報を集約し一塊のデータとして出力）の2段階のフェーズで分けて行う。
- 多くのNOSQLにもMapReduceは実装されている。
さいごに
これまでR、Python、SQLしか心得ていなかった自分の知識の狭さを、エンジニアと一緒に働くことで実感しました。一冊読むくらいでエンジニアの話に少しはついていけると思うと読書の幅は広げておきたいですね。今後、データを活用したマーケティング支援ツールの開発を先導する際に、技術選定などの意思決定に役立つかもしれません。データアナリストという職種である者からすると、マーケティング・エンジニアリング・データサイエンスを緩急つけて学んでくというスタンスが重要なのかもと思う今日この頃です。
