Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
リレーショナルリレーショナル
データベースデータベースとのとの
上手な付き合い方上手な付き合い方
奥野 幹也
Twitter: @nippondanji
mikiya (dot) okuno (at) gmail (dot) com
@  まべ...
免責事項
本プレゼンテーションにおいて示されている見解は、私
自身の見解であって、オラクル・コーポレーションの見
解を必ずしも反映したものではありません。ご了承くだ
さい。
自己紹介
●
MySQL サポートエンジニア
– 日々のしごと
● トラブルシューティング全般
●
Q&A 回答
● パフォーマンスチューニング
など
● ライフワーク
– 自由なソフトウェアの普及
● オープンソースではない
●
GPL 万歳...
なぜデータベースを
使うべきか
一言で表すと・・・
開発や運用で
楽をするため!!
データに対する要求
● 整理して格納しておきたい
– データを構造化してどこに何があるか分かるようにしたい
– データに合った構造を選択
●
好きなときに取り出したい
– 容易にアクセスできる手段
– 正しい結果が欲しい!!
● 自由自在に更新...
ファイルではダメなのか
● 構造が一切定義されていない
– データの位置を先頭からのオフセットとしてバイト数で指
定
– データは単なるバイト列
●
seek や read/write といった低レベルの API のみ
– 複雑なアプリケーショ...
表計算ソフトではダメなのか
● 表計算ソフトはあくまでも二次元の表
– データの場所を列と行で指定
– 表同士の演算はできない
●
JOIN 、 UNION 等
●
インデックスによる高速な検索や演算ができない
● 同時アクセスができない
● ...
データベースは便利な道具
● 小難しいけれどもただの厄介者ではない。
– リレーショナルモデル
– トランザクション
●
データ管理や操作における課題を解決するためのもの
– データを矛盾なく格納したい
– 安全に並列処理を行いたい
– クラッ...
トランザクションは
なぜ必要か
同時アクセスによる様々な異常
● ロストアップデート
●
インコンシステントリード
● ダーティーリード
● ノンリピータブルリード
●
ファントムリード
トランザクションで
防げる!!
ロストアップデートの例
データの正しさを保証したい!!
● それがトランザクションの役割
– しかも超かんたん!!
● トランザクションによってできること
– 同時アクセスによる異常を防ぐ
– システムがクラッシュしてもデータが失われない
正しい結果
● 並列で実行しているトランザクションが、ひとつずつ順番に
実行した場合と同じ結果になること。
– トランザクションの順序に保証はない。数ある順序の組み
合わせの中のひとつと同じになる。
– アプリ側で排他制御を考えなくていい。
T...
ACID
● トランザクションが満たすべき性質
– 原子性
● トランザクションに含まれる操作全てが成功
( Commit )か失敗( Abort )になるという性質
– 一貫性
●
トランザクションを実行した前後ではデータの一貫性が
損なわれ...
トランザクションがない場合に
起きること
● 排他制御が不在
– 同時に同じデータへアクセスする場合、更新異常を防ぐ
にはどうする?
– アプリケーション側で大量のロックを記述する?
● トランザクションがあれば、分離性があるので勝手に
やって...
ACID の C
● 一貫性って何?
●
トランザクション理論自体は一貫性を規定しない
– 一貫性を定義するのはアプリケーションの役目
– 制約などを使う
●
制約という仕組みを使って一貫性を記述するのはアプリ
ケーション
つまりトランザクションを使うと・・・
開発や運用が
楽!!
リレーショナルモデル
はなぜ必要か
リレーショナルモデルがない世界
● データモデルの不在
– データモデルはデータ取得のための演算を定義
● 効率よくコンパクトにデータの問い合わせを記述できる
– データの演算をアプリケーションで自前で記述する?
● データベースはただの入れ物...
そもそも
データモデルとは
データモデルとは
● データの論理的な表現方法
– データを表現するためにどんな方法が使えるか
● データを構成する要素
● データに対する演算
– 物理じゃないよ!!
●
物理的な表現方法は、データがどのようなレイアウトで
ファイルに格納され...
データは格納するだけで
終わりではない
● 格納して終わりではない!!
– アプリケーションから利用してこそ意味がある
– 入れっぱなしで OK なら、そもそもデータを格納する意味
はあるのか?
●
どのように出し入れするかが重要
– できるだ...
データモデルと演算
● データモデル上に定義された演算
– データの意味から演算の種類が必然的に決まる
● 整数の四則演算、文字列の分解・連結
● リレーショナルモデルの射影、制限、結合
etc
– 処理系に最初から用意されている
●
高速で信...
プログラミングパラダイムと
データモデル
● プログラミングパラダイム
– 手続き型
– オブジェクト指向
– 関数型
etc etc
● プログラミング言語にはそれぞれ適した書き方がある!!
– Java はオブジェクト指向で使うべき
●
m...
つまりリレーショナルモデルを
使うと・・・
開発やメンテが
楽!!
リレーショナルモデルを
マスターしたい方へ・・・
パフォーマンス
パフォーマンス
パフォーマンス
パフォーマンス
パフォーマンス
パフォーマンス
パフォーマンスは超重要
●
データモデルに沿って DB を設計するだけでは片手落ち
– 満足な性能が出るとは限らない
● 何を表現したかということと、その表現がどのように処理
されるかは別
●
性能が出ないアプリケーションは役に立たない!!
–...
性能を向上させるためのポイント
● 己を知る
– 利用可能な機能を知る
– 製品の実装を知る
● どんな処理が得意なのか
●
敵を知る
– 遅いクエリを特定する
● クエリの仕事量を測定する
●
仕事量を減らすようチューニング
– ボトルネック...
データがどのように
アクセスされるかを知る
● 行データがどのようにクライアントへ届くか
– オプティマイザー
– インデックス
– I/O
– バッファプール
– ネットワーク
– それぞれの処理の仕事量は?
●
それぞれの時点での改善点はな...
クエリの改善
● 不必要なデータにアクセスしていないか
– 不要な結果をクライアントへ送信していないか
● アプリケーション側で結果を絞り込む等
– 効率の悪い書き方をしていないか
●
RDBMS の機能を活用する
– より効率的な実行計画のク...
クエリの改善
その 2
● インデックスを活用する
– 基本中の基本
– 意外と何とかなることが多い
●
そもそも DB 設計は問題ないか?
– クエリはテーブルを入力とした演算
– 入力の設計が良くなければ、クエリが遅くなるのは必然
– 更新...
ベンチマークのすすめ
● コンピュータシステムは複雑過ぎて、実際にどの程度の性
能が出るかということの予測は極めて難しい
●
やってみるのが早い!!
● 測定可能な結果が数値で分かる
– 改善の具体的な目標に
– 具体的な数値無しに性能改善はあ...
まとめ
RDBMS と上手に付き合う
ためのポイント
● リレーショナルモデルを知ろう
– 道具を使うには、使い方を理解する必要がある
– 使い方を知ることで、正しい用途も見えてくる
– なぜその使い方が良いのか、あるいは良くないのかを説
明できる
●...
これからもデータベースと
上手く付き合うには
● テクノロジーは進化する
– CPU 、メモリ、ディスク、 OS 、言語・・・ etc
– 最新テクノロジーは次々登場する
● 原理原則は変わらない
– リレーショナルモデル
– トランザクション...
宣伝: 新書籍「詳解 MySQL 5.7 」
●
MySQL 5.7 の新機能を網羅
– 175 もの新機能を解説
– 新機能の理解に欠かせ
ないアーキテクチャの話
も盛りだくさん
– MySQL の実装について
詳しくなれる!!
Q&Aご静聴ありがとうございました。
Upcoming SlideShare
Loading in …5
×

リレーショナルデータベースとの上手な付き合い方

15,795 views

Published on

まべ☆てっく Vol.1にて発表したスライドです。リレーショナルデータベースをどのように使うべきか、あるいはそもそも何故データベースを使うべきなのかといったことについて解説しています。

Published in: Software

リレーショナルデータベースとの上手な付き合い方

  1. 1. リレーショナルリレーショナル データベースデータベースとのとの 上手な付き合い方上手な付き合い方 奥野 幹也 Twitter: @nippondanji mikiya (dot) okuno (at) gmail (dot) com @  まべ☆てっく vol.1
  2. 2. 免責事項 本プレゼンテーションにおいて示されている見解は、私 自身の見解であって、オラクル・コーポレーションの見 解を必ずしも反映したものではありません。ご了承くだ さい。
  3. 3. 自己紹介 ● MySQL サポートエンジニア – 日々のしごと ● トラブルシューティング全般 ● Q&A 回答 ● パフォーマンスチューニング など ● ライフワーク – 自由なソフトウェアの普及 ● オープンソースではない ● GPL 万歳!! – 最近はまってる趣味はリカンベントに乗ること ● ブログ – 漢のコンピュータ道 – http://nippondanji.blogspot.com/
  4. 4. なぜデータベースを 使うべきか
  5. 5. 一言で表すと・・・ 開発や運用で 楽をするため!!
  6. 6. データに対する要求 ● 整理して格納しておきたい – データを構造化してどこに何があるか分かるようにしたい – データに合った構造を選択 ● 好きなときに取り出したい – 容易にアクセスできる手段 – 正しい結果が欲しい!! ● 自由自在に更新したい – データの整合性を保ちたい – 複数のユーザーから同時に更新したい
  7. 7. ファイルではダメなのか ● 構造が一切定義されていない – データの位置を先頭からのオフセットとしてバイト数で指 定 – データは単なるバイト列 ● seek や read/write といった低レベルの API のみ – 複雑なアプリケーションによるデータ操作を表現するには 貧弱過ぎる – 高度なデータ操作はアプリケーション側で実装しなけれ ばならない – 壮大なる車輪の再発明の危険性 ● 同時アクセス時の排他制御 ● マシンクラッシュにおけるデータの完全性
  8. 8. 表計算ソフトではダメなのか ● 表計算ソフトはあくまでも二次元の表 – データの場所を列と行で指定 – 表同士の演算はできない ● JOIN 、 UNION 等 ● インデックスによる高速な検索や演算ができない ● 同時アクセスができない ● トランザクションがない
  9. 9. データベースは便利な道具 ● 小難しいけれどもただの厄介者ではない。 – リレーショナルモデル – トランザクション ● データ管理や操作における課題を解決するためのもの – データを矛盾なく格納したい – 安全に並列処理を行いたい – クラッシュしてもデータが失われないようにしたい
  10. 10. トランザクションは なぜ必要か
  11. 11. 同時アクセスによる様々な異常 ● ロストアップデート ● インコンシステントリード ● ダーティーリード ● ノンリピータブルリード ● ファントムリード トランザクションで 防げる!!
  12. 12. ロストアップデートの例
  13. 13. データの正しさを保証したい!! ● それがトランザクションの役割 – しかも超かんたん!! ● トランザクションによってできること – 同時アクセスによる異常を防ぐ – システムがクラッシュしてもデータが失われない
  14. 14. 正しい結果 ● 並列で実行しているトランザクションが、ひとつずつ順番に 実行した場合と同じ結果になること。 – トランザクションの順序に保証はない。数ある順序の組み 合わせの中のひとつと同じになる。 – アプリ側で排他制御を考えなくていい。 Tx1 Tx2 Tx3 = Tx2 Tx1 Tx3
  15. 15. ACID ● トランザクションが満たすべき性質 – 原子性 ● トランザクションに含まれる操作全てが成功 ( Commit )か失敗( Abort )になるという性質 – 一貫性 ● トランザクションを実行した前後ではデータの一貫性が 損なわれてはならないという性質 – 分離性(独立性) ● 同時に実行している複数のトランザクションが、互いに影 響を与えないという性質 – 永続性 ● いったんコミットが完了したトランザクションが消失しない という性質
  16. 16. トランザクションがない場合に 起きること ● 排他制御が不在 – 同時に同じデータへアクセスする場合、更新異常を防ぐ にはどうする? – アプリケーション側で大量のロックを記述する? ● トランザクションがあれば、分離性があるので勝手に やってくれる。 ● エラー処理が超複雑に – どこまで処理が進んだかによってエラー処理も場合分け ● 10 の更新から成るトランザクションは、 10 のケースにつ いてエラー処理が必要。 – トランザクションがあれば原始性があるので、処理が中 断するとすべての更新をロールバック。 – クラッシュ後のデータは正しいか? ● そもそもどうやって確かめる? – トランザクションの永続性があれば COMMIT したデータが 存在することが保証される。
  17. 17. ACID の C ● 一貫性って何? ● トランザクション理論自体は一貫性を規定しない – 一貫性を定義するのはアプリケーションの役目 – 制約などを使う ● 制約という仕組みを使って一貫性を記述するのはアプリ ケーション
  18. 18. つまりトランザクションを使うと・・・ 開発や運用が 楽!!
  19. 19. リレーショナルモデル はなぜ必要か
  20. 20. リレーショナルモデルがない世界 ● データモデルの不在 – データモデルはデータ取得のための演算を定義 ● 効率よくコンパクトにデータの問い合わせを記述できる – データの演算をアプリケーションで自前で記述する? ● データベースはただの入れ物という考え ● 実際そういう現場が多いからデスマーチに・・・ ● 正規化理論の不在 – 正規化理論は、更新によって生じるデータの矛盾を、 データベース設計そのものにより防ぐ理論。 ● ACID の C – データの矛盾をアプリケーションで自前で記述する? ● チェックのための処理が大量に必要に・・・
  21. 21. そもそも データモデルとは
  22. 22. データモデルとは ● データの論理的な表現方法 – データを表現するためにどんな方法が使えるか ● データを構成する要素 ● データに対する演算 – 物理じゃないよ!! ● 物理的な表現方法は、データがどのようなレイアウトで ファイルに格納されているか等 ● データベース設計のことじゃないよ!!
  23. 23. データは格納するだけで 終わりではない ● 格納して終わりではない!! – アプリケーションから利用してこそ意味がある – 入れっぱなしで OK なら、そもそもデータを格納する意味 はあるのか? ● どのように出し入れするかが重要 – できるだけ簡単かつ的確に出し入れしたい – 必要なデータは何かを簡潔に定義できること – ≒ データに対する演算
  24. 24. データモデルと演算 ● データモデル上に定義された演算 – データの意味から演算の種類が必然的に決まる ● 整数の四則演算、文字列の分解・連結 ● リレーショナルモデルの射影、制限、結合 etc – 処理系に最初から用意されている ● 高速で信頼できる操作 ● 用意された演算を適切に使えば簡素に書ける – 反例:文字列で配列を実装するケースを考えよ ● 遅い ● 実装できてもバグだらけ ● そもそも実装する意味がない
  25. 25. プログラミングパラダイムと データモデル ● プログラミングパラダイム – 手続き型 – オブジェクト指向 – 関数型 etc etc ● プログラミング言語にはそれぞれ適した書き方がある!! – Java はオブジェクト指向で使うべき ● main メソッドに全てのロジックを記述するべきではない ● データモデルにはそれぞれ適した DB 設計がある!! – 「データベースは単なるデータの入れ物だ」という考え 方は、 Java で main メソッドに全てを記述するのに等し い
  26. 26. つまりリレーショナルモデルを 使うと・・・ 開発やメンテが 楽!!
  27. 27. リレーショナルモデルを マスターしたい方へ・・・
  28. 28. パフォーマンス パフォーマンス パフォーマンス パフォーマンス パフォーマンス パフォーマンス
  29. 29. パフォーマンスは超重要 ● データモデルに沿って DB を設計するだけでは片手落ち – 満足な性能が出るとは限らない ● 何を表現したかということと、その表現がどのように処理 されるかは別 ● 性能が出ないアプリケーションは役に立たない!! – アプリケーションは実用的であってこそ意味がある – 実用的なレスポンスが得られることは絶対条件
  30. 30. 性能を向上させるためのポイント ● 己を知る – 利用可能な機能を知る – 製品の実装を知る ● どんな処理が得意なのか ● 敵を知る – 遅いクエリを特定する ● クエリの仕事量を測定する ● 仕事量を減らすようチューニング – ボトルネックを特定する ● 時間が掛かっている箇所 ● アクセスが集中している箇所 彼を知り己を知れば百戦殆うからず (孫子)
  31. 31. データがどのように アクセスされるかを知る ● 行データがどのようにクライアントへ届くか – オプティマイザー – インデックス – I/O – バッファプール – ネットワーク – それぞれの処理の仕事量は? ● それぞれの時点での改善点はないか – 実行計画は適切か? – もっと良いインデックスはないか? – I/O の効率は改善できるか? – より速いディスクが必要か? – バッファプールその他のキャッシュは十分か? – ネットワーク帯域は十分か? – ボトルネックはどこか?
  32. 32. クエリの改善 ● 不必要なデータにアクセスしていないか – 不要な結果をクライアントへ送信していないか ● アプリケーション側で結果を絞り込む等 – 効率の悪い書き方をしていないか ● RDBMS の機能を活用する – より効率的な実行計画のクエリへの書き換え ● 非効率な書き方を避ける – ストアドファンクションを使わない ● 同じ結果を産む、より良い実行計画 – サブクエリを JOIN に書き換える
  33. 33. クエリの改善 その 2 ● インデックスを活用する – 基本中の基本 – 意外と何とかなることが多い ● そもそも DB 設計は問題ないか? – クエリはテーブルを入力とした演算 – 入力の設計が良くなければ、クエリが遅くなるのは必然 – 更新は正規化でシンプルに
  34. 34. ベンチマークのすすめ ● コンピュータシステムは複雑過ぎて、実際にどの程度の性 能が出るかということの予測は極めて難しい ● やってみるのが早い!! ● 測定可能な結果が数値で分かる – 改善の具体的な目標に – 具体的な数値無しに性能改善はあり得ない ● システムの限界性能を知る – キャパシティプランニングの指標に
  35. 35. まとめ
  36. 36. RDBMS と上手に付き合う ためのポイント ● リレーショナルモデルを知ろう – 道具を使うには、使い方を理解する必要がある – 使い方を知ることで、正しい用途も見えてくる – なぜその使い方が良いのか、あるいは良くないのかを説 明できる ● トランザクションを知ろう – トランザクションは開発を大幅に効率化する – エラー処理が簡略化 ● パフォーマンスを向上するための仕組みを知ろう – RDBMS の実装 – クエリの改善 アーキテクチャや 理論の理解は超重要
  37. 37. これからもデータベースと 上手く付き合うには ● テクノロジーは進化する – CPU 、メモリ、ディスク、 OS 、言語・・・ etc – 最新テクノロジーは次々登場する ● 原理原則は変わらない – リレーショナルモデル – トランザクション – アーキテクチャ ● CPU がどのように命令を実行するか ● データベースの基本的な仕組み 理論+トレンド
  38. 38. 宣伝: 新書籍「詳解 MySQL 5.7 」 ● MySQL 5.7 の新機能を網羅 – 175 もの新機能を解説 – 新機能の理解に欠かせ ないアーキテクチャの話 も盛りだくさん – MySQL の実装について 詳しくなれる!!
  39. 39. Q&Aご静聴ありがとうございました。

×