Upload
shohei-kobayashi
View
447
Download
3
Embed Size (px)
Citation preview
• Aという情報に対してBという情報を紐付け、追加された情報がカラムの追加することなく取得可能。
• 別テーブルのユニークなIDと紐づけることで、カラムを増やさなくても別テーブルで関連データをばしばし増やせること
関係モデルのメリット
“Music”データベースに流すクエリ
SELECT bands.name,artists.name FROM bands INNER JOIN artists ON bands.id=artists.band_id WHERE bands.name = "Oasis";
“Music”データベースにさっきと同じクエリ実行
SELECT bands.name,artists.name FROM bands INNER JOIN artists ON bands.id=artists.band_id WHERE bands.name = "Oasis";
RDBの使いどころとおさらい
• 関連モデルで使うことが基本である
• もちろん関連以外でも使えるけど、関連性のあるデータを持たせる場面で多く使われる。
• テーブルを結合させるクエリを流すことで、カラムを追加ではなくレコード追加で変更されたデータを取得できる
NoSQLのタイプキー・バリュー型:Key Value Store →キーに対して値をもつ形。 例:DynamoDB/SimpleDB,Redis,Memcached ソート済みカラム型 →ソートキーに対してカラムの集合をもつ形。 例:Cassandra,HBase ドキュメント思考 →XMLやJson等、スキーマレスでデータ構造が柔軟なもの。 例:MongoDB,CouchDB
注:列指向DBとNoSQLは違うよ例:Redshift / BigQuery / Cloudera Impala
• 列のデータをひとまとまりにして取り出すときに効率的であるように設計されたDB群。
• 行指向(通常のRDB)はトランザクションがあったりする細かいデータの出し入れに向くが、こいつらは大きなデータを一発で引っ張るのに向く。
• NoSQLのカラム指向データモデルは多くの行のデータを大量の引っ張るのに向いてないので間違わないでね。
Key-Value Storeのポイント• Keyを元に検索のため、問い合わせが非常にシンプル。
• 更新が細かい単位で不可分( atomic)に行われる
• 関連性がないので書き込み箇所が少なく、問い合わせの実行・解釈も早い
以下のテーブルの場合keyで検索すればvalueが返ってくる。
Key-Value StoreにやらせてはいけないことJoinをしない →複数テーブルをつなげた検索は向いてない トランザクション処理をかまさない → 複数キーの読み書きをatomicに処理不可能なため 整合性がわりと緩めなので厳密すぎる場面は向いてない →データの複製とかがすごくゆるいため
Key-Value Storeの使いどころ高速な性能の活用 →大量のデータを管理するテーブル等をもたせる
例:RDBのキャッシュ、キーに応じたデータの保存
大容量データの保存 →スケーリングが用意なプロダクトなので大量データを保存可能 例:キーと値の組み合わせでたくさん保存★保存★
NoSQL=Not Only SQL
• NoSQLはRDBをサポートするためのDBプロダクト
• NoSQLで全部、RDBで全部ではなく適材適所
• 「RDBはこれだからだめだ!」「NoSQLは機能足りないからつかえない!」ではなくて、マルチDBでなにかをやるようにする。