読者です 読者をやめる 読者になる 読者になる

一人前になりたい

ガジェットとかアプリとかプログラミングとか

DB勉強会に参加した話

DB 勉強会 NoSQL MySQL DB SQL NoSQL MySQL

こちらの勉強会に参加してきました。


すろっくとゆかいななかまたちの技術系勉強会.vol1 Theme:DB - connpass


今回はDBに関する勉強会ということで、
業務ではよく使ってるけどきちんと勉強したことってあんまりなかったなと思い、参加してみました。

会場はココ。(秋葉原ルノアール
f:id:iidaapp:20150305211231j:plain

会議室貸してくれるの知らなかった〜。


【勉強会概要】
・最初はDB勉強会ってことだったけど、
 定期的に技術キャッチアップ的に開催したいとのこと。

・土日中心?


どちらもありがたい!
自分から発信するのはまだちょっと自信ないけど、
みんなで集まって勉強しよう!っていうスタンスは非常にありがたい。
僕もいつかこういう場で発言してみたい。


【内容まとめ】

RDBとNoSQLの基礎

主催者であるsrockstyleさんのLT。
NoSQLってなにそれおいしいの?状態だったので興味津々でした。


RDBのおさらいと使いドコロ

そもそもRDBってなに?
関係データベース (Relational Data Base)

・2つのテーブルは別々のデータだけど、
 ひとつの情報で連結して情報抽出出来るモデル。

・関連モデルで使うのが基本。


■ NoSQLの基礎

NoSQLNot Only SQL

RDB以外のDBプロダクト全部
・3つの型に分類される

① キーバリュー型 - Redis、Memcached
② ソート済みカラム型 - Cassandra、HBase
③ ドキュメント指向型 - MongoDB、CouchDB


■ 列指向DBとは違う
- Redshift、BigQuery

列指向DBってなに?
→列のデータをひとまとまりにして、
 取り出すときに効率的であるように設計されたDB

つまり、でっかいデータをガバっと持ってくるのに適している。


■ Key-Value Storeのポイント

・keyを元に検索するため、問い合わせがシンプル
・更新が細かい単位で不可分(atomic)に行われる
(補足:トランザクションはアトミックを行うための仕組み)
・整合性がわりと緩めなので、データが厳密すぎる場面は向いてない
(データの複製とかは向いてない)


■ NoSQLの使いドコロ

・出し入れが高速なので、パッと入れてパッと出すとき
・大容量のデータを保存するとき

例外:ドキュメント指向DB

ドキュメント指向DBとは?
→「ドキュメント」と呼ばれる構造的データを
 JSONライクな形式で表現し、
 そのドキュメントの集合を「コレクション」として管理する。


・NoSQLはRDBをサポートするためのもの
・適材適所で使う
・データはRDB、キャッシュはNoSQL


■ まとめ
RDBはテーブル同士を関連する形で使う
・NoSQLはRDBをサポートする形で使う
・NoSQLをRDBのように扱わないように!


・怖くない象さん

kamichiduさんのTL。
PostgreSQLは怖くないよって内容。
スライドにところどころ出てきたポスグレのマスコットが怖すぎた…

PostgreSQLとは
OSS?なDBMS

OSSってなに?
オープンソースソフトウェア (Open Source Software)


PostgreSQLの特徴

・どぎつくない方言
→基本的にどのSQLにも方言はあるそう。
 その中でも素のSQLに近い構文で書ける。

・つまり
→素直な可愛い子
→手軽で単純な実行性能も高い


■ そもそもSQLとは

DBMSに対する問い合わせ言語
・ISO規格

ISO規格ってなに?
国際標準化機構International Organization for Standardization)
 が制定する国際規格。


SQLには3つの種類がある

DDL(Data Definition Language:データ定義言語)
→create、alter、drop

DML(Data Manipulation Language:データ操作言語)
→select、insert、update、delete

・DCL(Data Control Language:データ制御言語)
commit, rollback


■ ISO規格は後付で生まれた。

それまで、DBMSの各ベンダが独自拡張していた
→それが方言

ポータビリティ
→どれだけISO規格に準拠しているか


■ 主要DBMSのISO規格への準拠

・どんどん準拠していってる
・方言が問題になることはあまりない
OracleですらSQL2003あたりに準拠している
(10gあたりから)
DBMSのドキュメントに規格にどれだけ準拠しているか書いてる


■ ポータビリティ

・同じSQLPostgreSQLでもMySQLでも動くかどうか
・複雑なSQLになるほどポータビリティは下がりやすい
・完璧にするのは現実的には不可能に近い
・ライブラリに任せるのも手
 perlSQL;;Maker、SQL::abstract
 Java→JOOQ、Querydsl
・ORMを使うのも手
(速度の面で劣る)


MySQL vs PostgreSQL

クラスタリングする際の課題
MySQLには標準にある、PostgreSQLには3rd party製しかない)
レプリケーション
MySQLには標準にある、PostgreSQLにもある!)


■ あとは好み
・シンプルなものならPostgreSQL
・ただし実運用では何かとツールを導入する必要がある


■まとめ
PostgreSQLかわいい
SQLには3つの分類がある
・主に使うのはDML、DCL
・ISO規格は実用性について微妙

(ところどころに氷菓が出てきたような…うっ頭が)

・ハンズオン

すろっくさん扮するクソPMが設計したクソDBを、
いかに正規化&最適化するかっていうハンズオン。


…。



【概要】

音楽アプリ用のDBだが、
ひとつのテーブルにめちゃくちゃなカラムが存在しているため、
それを整理しつつ、綺麗なDBを目指す。

2チームに分かれて作業。
作業後にお互いの正規化についてプレゼンし、
ツッコミを入れ合う(マサカリを投げ合う)。


【考えたこと】

(メモを全く取っていなかったため、細かく思い出せず)
(次からはきちんとメモ取ります…)


【まとめ】

・情報は要素ごとにテーブルにまとめる
・idを振ってデータを関連付ける
・どのデータからでもある程度どんな情報でも引っ張ってこれるようにする
・狙い所はなにか?
→早さ、データ取得の容易さ、わかりやすさ
・そもそもアプリの要件によっても設計が変わる



お疲れ様でした。


・勉強会を通してのまとめ

RDBとNoSQLを用途によって使いわけよう
RDB:関連付いたデータをまとめる
→NoSQL:それ以外のぽんぽん出し入れするデータを入れる

PostgreSQLMySQLにもそれぞれの良さがある
→大きな機能差は無い
→導入する上で必要なものが変わる可能性があるから気をつける

正しいDB設計を学ぶには実際に触ってみるのが一番
→その際にきちんと考えて設計すること

正規化にあたってデータを正しく整理する
→目的と用途によって、テーブルの関連付けを考える

クソPMは楽だけど夜道に気をつける
→恨みを買う可能性大



以上です。

楽しかったので次回も期待!