はじめに
機械学習でデータの取り扱いでSQLを学び初めていろいろと用語やらDBの種類が現れたため少しまとめて見ました。
まだRDBとMongoDBしかさわれていないためその他のDBはあまり書けていない状況です。
DB
膨大なデータを管理する。
では、データの管理とはなにを指すかというとデータの整合性と永続性を担保するという認識です(現状は)。
DBは下記の概念を元にデータを管理しているようです。
- ACID
- 原子性
- 必ずデータを操作した際に操作が完了した状態もしくは操作が行われていない状態のどちらかのみを保証する
- 一貫性
- データの処理が整合性(データのルール)を保つころとを保証する
- 独立性
- 実行中の処理がその他の処理から見れないことを示す
- 永続性
- データが失われない事を示す
- 原子性
CAP定理
webサービスを想定して作られた分散化データベースの定理
- 整合性
- クライアントは常に同一のデータを見る
- 可用性
- クライアントは読み出し書き出しができる
- 分断耐性
- 物理ネットワークが分断されても(DBサーバー複数台で構築)間違った結果が発生しない
上記性質はすべて完璧に満たすことは出来ず各DBでどれか重視して作られている
RDB vs NoSQL
-
RDB
- 集合と関連のデータのみ扱う
- SQL準拠のクエリを使い操作する
- 検索性が高い
- 水平スケーリング（カラムの数を操作すること)が苦手
-
NoSQL
- Not + Only + SQL」が名前の由来。
- ドキュメント型、グラフ型、キー値型、列指向型等のデータモデルが存在する。
- 導入のモチベーションはRDBで解決できないことを解決するため。(RDBの問題の章に詳細を記載)
- データモデルによって性質が変わる(データモデルの章で概要を記載)
データモデル
| データモデル | DB名 | データモデル概要 |
|---|---|---|
| RDB | MySQL, PostgreSQL... | 集合(行列データ)と関連(リレーショナル)でデータを扱う |
| ドキュメント型 | MongoDB | 階層構造を待たない。データをドキュメントという単位で保持して各ドキュメントにIDが振られる。スキーマレス(データベースの構造を定義しなくてよいということ) |
| グラフ型 | Neo4j | グラフ理論に基づいて設計されている |
| キー値型 | Hibari | キーと値の1:1でデータを表現する |
| 列指向型 | Bigtable, HBase | レコードとカラムの概念があるがRDBと違い事前にカラムを定義しなくてもよい キーと値は1:多の関係を取る |
RDBの問題
- 大量のデータ処理(T,PByte級のデータ)
- DBの水平スケールアウトが苦手
- データモデルが固定されている
MongoDB
- ドキュメント型NoSQLデータベース
- スキーマレスでBSON形式(JSON形式に似た形をとっている)でデータを保持(これを動的スキーマと呼ぶらしい)
- 上記の性質のおかげで複雑な階層関係を持てる
- Web APIとの相性がよい
- MongoDBの格納の仕方()はMySQLの概念で変換した位置づけ
- データベース->コレクション(テーブル)->ドキュメント(レコード)
- コレクション内のドキュメントは独立しておりドキュメント毎に定義を変えられる
- 各データに固有IDの自動付与(インデックスの種類も選択できるらしい)
※詳しくは下記リンク先の方がすごく丁寧にまとめてくださっています
MongoDB超入門
参考文献
まとめ
ちょっと学んだ第一声としては難しい!!
これ難しい!!！！
けどデータのモデリングが扱いたい形にハマったらさぞ気持ち良いだろうと初心者ながら勝手に妄想
DBの選定は都度どういったデータをどのように扱うかを考えるのがまず第一歩だと理解しました。
どれも実際に触ってみて各DBの性質を少しでもわかっているとDBの選定に役立つかもですね。
僕は機械学習の勉強もしているのでその傍らでデータセット毎にDBに突っ込んで扱ってみたら以外と楽しめそうですね。
では、また。