SlideShare a Scribd company logo
1 of 70
Download to read offline
NoSQL入門

      2010年7月8日

(株)Preferred Infrastructure
     海老原 雄一郎

当日の録画が以下で公開されていますので、併せてご覧下さい。
http://www.ustream.tv/recorded/8146586
                                    1
NoSQLとは?
 NoSQL = only SQL
  cf. NoSQL = Not only SQL

  MS SQLのコマンドラインツール osql とは無関係


 SQLが持つ強力な表現力をフル活用する
 こと

 そのようなSQLは、見た人が思わず、”Oh!
 SQL!”と叫んでしまう                    2
アジェンダ
1.   はじめに
2.   SQLのおさらい
3.   SQL一発
4.   SQLチューニングのポイント
5.   ケーススタディ
6.   おわりに



                      3
アジェンダ
1.   はじめに
2.   SQLのおさらい
3.   SQL一発
4.   SQLチューニングのポイント
5.   ケーススタディ
6.   おわりに



                      4
自己紹介
海老原 雄一郎 (@yebihara)
 RDBMSを愛しているソフトウェアエンジニア
 日本オラクルでテクニカルコンサルタントを6年
   データベースの基礎をみっちり
 ソニーでPostgreSQLとMySQL
   OSS DBを社内に広めるプロジェクト
   「現場で使えるMySQL」などで有名な松信さんは当時
   のチームメンバー
 DBセキュリティ製品のアイピーロックスでデータベース三
 昧の日々
   Oracle, MS SQL Server, IBM DB2, Sybase ASE, 日
   立HiRDB, PostgreSQL
 現在: PFI
   とあるシステム開発で久々にMySQLをみっちり
                                                   5
今日の目的
SQLの表現力の強力さを理解する

SQLで効率的にプログラミングを減らす手
法を学ぶ

性能の良いSQLを書けそうな気になる



                       6
主な対象者
リレーショナルデータベースをちょっとは触
ったことがある

シンプルなSQL文なら書ける
 SELECT ~ FROM ~ WHERE ~
 ジョインとかGROUP BYとかはあんまり




                           7
アジェンダ
1.   はじめに
2.   SQLのおさらい
3.   SQL一発
4.   SQLチューニングのポイント
5.   ケーススタディ
6.   おわりに



                      8
SQLの特徴 (1/2)
 主にリレーショナルデータベースを操作するため
 のクエリー言語
   データは行と列で構成される表に格納されている
     表=table, テーブル
     行=row, レコード
     列=column, カラム
   検索結果も表として得られる
   表=集合、要素は順序付けられていない
  employees表
  id     name       birthday   gender   title
  1000   西川 徹       1982/11      M      代表      行
  1010   海老原 雄一郎    1973/11      M              行
  1014   西川 舞       1984/9        F             行
  1018   岡野原 大輔     1982/4       M      フェロー    行

   列            列      列         列         列        9
SQLの特徴 (2/2)
 宣言型プログラミング言語
  「どのようにデータを処理するか?」ではなく、「どのような処理
  結果(データの集合)が欲しいか?」を記述する

  クエリーオプティマイザー
    SQLを翻訳して、実行計画を作成する
    実行計画= 「どのようにデータを処理するか?」
    プランナーと呼ばれることも

  タクシーのメタファー
    タクシーで行き先を告げると、運ちゃん(オプティマイザー)
    が道順(実行計画)を考えて、連れて行ってくれる
    自分で車を運転する場合は、自分で道順を考えないとい
    けない → 手続き型プログラミング
                                   10
標準SQL
ISOで標準化されている
  SQL-92, SQL:1999, SQL:2003, SQL:2008


全てを実装しているRDBMSは存在しない

RDBMS固有の拡張(方言)も多い




                                         11
SQLの種類
DML(Data Manipulation Language)
  データの中身を操作する
  SELECT、INSERT、UPDATE、DELETEなど
  標準SQLの範囲内で結構いける

DDL(Data Definition Language)
  DBオブジェクト(表や索引など)の定義情報を操作する
  CREATE TABLEなど
  主要部分は標準SQLでOK、ただし方言の利用もほぼ必須

その他
  トランザクション制御
  権限管理

                                  12
SELECT文の基本構造 (1/2)
employees表
id     name       birthday   gender     title
1000   西川 徹       1982/11      M        代表
1010   海老原 雄一郎    1973/11      M
1014   西川 舞       1984/9       F
1018   岡野原 大輔     1982/4       M        フェロー




                                   クエリーの結果
SELECT id, name, title             id       name      title
FROM employees                     1000     西川 徹      代表

WHERE gender = „M‟;                1010     海老原 雄一郎
                                   1018     岡野原 大輔    フェロー

                                                              13
SELECT文の基本構造 (2/2)

SELECT id, name, title   選択列リスト

FROM employees           FROM句

WHERE gender = „M‟;      WHERE句



 他にGROUP BY句、HAVING句、 ORDER BY句+ 方言



                                      14
選択列リスト
 出力結果を構成する列のリスト

 記述できるもの                   SELECT id, name, title
       FROM句の表の列(「*」で全ての列) FROM employees
       リテラル値
                           WHERE gender = „M‟;
       式(演算子、関数、スカラー副問合せ)


id      name      birthday   gender   title
1000    西川 徹      1982/11      M      代表
1010    海老原 雄一郎   1973/11      M
1014    西川 舞      1984/9       F
1018    岡野原 大輔    1982/4       M      フェロー
                                                15
FROM句
行を取り出す対象となる表

記述できるもの        SELECT id, name, title
  表、ビュー、副問合せ   FROM employees
  JOIN句
               WHERE gender = „M‟;




                                   16
WHERE句
 FROM句の表に適用する抽出条件

 記述できるもの                                 SELECT id, name, title
       true/false/nullを返す条件式             FROM employees
                                         WHERE gender = „M‟;


id      name        birthday   gender   title
1000    西川 徹        1982/11      M      代表
1010    海老原 雄一郎     1973/11      M
1014    西川 舞        1984/9       F
1018    岡野原 大輔      1982/4       M      フェロー

                                                             17
GROUP BY句
     グループ関数で集計処理を行う場合の集計単位
                                     SELECT gender,
     記述できるもの                                trunc(age(birthday), 10),
       いろいろ記述できるけど、                         count(*)
       選択列リストのうち、グループ関数を             FROM employees
                                     GROUP BY
       含まない全ての列を記述するのが
                                            gender,
       分かりやすい                               trunc(age(birthday), 10);
employees表
id     name      birthday   gender
                                         クエリーの結果
                                          gender   trunc(…)   count(*)
1000   西川 徹      1982/11      M
                                             M        30         1
1010   海老原 雄一郎   1973/11      M
                                             M        20         2
1014   西川 舞      1984/9       F
                                             F        20         1
1018   岡野原 大輔    1982/4       M
                                                                     18
HAVING句
     GROUP BY句による集計結果に適用する抽出条件
                          SELECT gender,
                                 trunc(age(birthday), 10),
     記述できるもの                     count(*)
      いろいろ記述できるけど、        FROM employees
                          GROUP BY
      基本的にはグループ関数を含む条件
                                 gender,
      (でなければWHERE句に書けばよい)
                                 trunc(age(birthday), 10)
                          HAVING count(*) = 1;
employees表
id      name       birthday   gender
                                       クエリーの結果
                                       gender   trunc(…)   count(*)
1000    西川 徹       1982/11      M
                                         M         30         1
1010    海老原 雄一郎    1973/11      M
                                         F         20         1
1014    西川 舞       1984/9       F
1018    岡野原 大輔     1982/4       M
                                                                  19
ORDER BY句
 出力結果の構成行の並び順
  ORDER BY句を指定しないと、          SELECT id, name, title
  並び順は「不定」となる
  順序が重要なら必ず指定する
                             FROM employees
                             WHERE gender = „M‟
 記述できるもの                     ORDER BY birthday;
  選択列リスト中の列
  FROM句の表の列
  上記に基づく式 ⇒ ex. ORDER BY length(name)
  選択列リスト中の列位置 ⇒ ex. ORDER BY 2




                                                 20
結合(ジョイン)
 2つの表から取得した行を連結して、1つ
 の表を構成する操作
  その結果をさらに別の表と結合することもできる


 いろいろな結合
  直積(デカルト積、クロスジョイン)
  等価結合
  内部結合
  外部結合
  半結合
  逆結合
                           21
等価結合

employees表
id      name      dept_id
1000    西川 徹                SELECT emp.id, emp.name, dept.name
1010    海老原 雄一郎   20        FROM employees emp,
1014    西川 舞      10             departments dept
1018    岡野原 大輔    20        WHERE dept.id = emp.dept_id;

departments表                  結果
id     name                   emp.id   emp.name   dept.name
10     総務部                    1010     海老原 雄一郎    技術部
20     技術部                    1014     西川 舞       総務部
30     営業部                    1018     岡野原 大輔     技術部
                                                              22
直積              SELECT emp.id, emp.name, dept.name
                       FROM employees emp,
                            departments dept;
employees表
id      name      dept_id    結果    emp.id   emp.name   dept.name
1000    西川 徹                       1000     西川 徹       総務部

1010    海老原 雄一郎   20               1000     西川 徹       技術部
                                   1000     西川 徹       営業部
1014    西川 舞      10
                                   1010     海老原 雄一郎    総務部
1018    岡野原 大輔    20               1010     海老原 雄一郎    技術部
                                   1010     海老原 雄一郎    営業部
departments表                       1014     西川 舞       総務部
id     name                        1014     西川 舞       技術部
                                   1014     西川 舞       営業部
10     総務部
                                   1018     岡野原 大輔     総務部
20     技術部
                                   1018     岡野原 大輔     技術部
30     営業部                         1018     岡野原 大輔     営業部
                                                                   23
直積から結合を理解する
                                                        SELECT emp.id, emp.name,
                                                               dept.name
emp.id   emp.name   emp.dept_id   dept.id   dept.name   FROM employees emp,
1000     西川 徹                     10        総務部
                                                             departments dept
1000     西川 徹                     20        技術部
1000     西川 徹                     30        営業部         WHERE dept.id = emp.dept_id;
1010     海老原 雄一郎    20            10        総務部
1010     海老原 雄一郎    20            20        技術部
1010     海老原 雄一郎    20            30        営業部
                                                             emp.id   emp.name   dept.name
1014     西川 舞       10            10        総務部
1014     西川 舞       10            20        技術部              1010     海老原 雄一郎    技術部
1014     西川 舞       10            30        営業部              1014     西川 舞       総務部
1018     岡野原 大輔     20            10        総務部              1018     岡野原 大輔     技術部
1018     岡野原 大輔     20            20        技術部
1018     岡野原 大輔     20            30        営業部




                                                                                             24
JOIN構文
 FROM句に表をカンマ区切りで並べて、結
 合条件をWHERE句に書くのは古い記法

 JOIN構文
 SELECT emp.id, emp.name, dept.name
 FROM employees emp
   INNER JOIN departments dept ON dept.id = emp.dept_id;

 SELECT emp.id, emp.name, dept.name
 FROM employees emp
   CROSS JOIN departments dept;
                                                      25
左外部結合
                  どの部門にも所属していない人も出力したい。
employees表
id      name      dept_id
                            SELECT emp.id, emp.name, dept.name
1000    西川 徹
                            FROM employees emp
1010    海老原 雄一郎   20
                              LEFT OUTER JOIN departments dept
1014    西川 舞      10
                                 ON dept.id = emp.dept_id;
1018    岡野原 大輔    20
                              結果
departments表                  emp.id   emp.name   dept.name
id     name                   1000     西川 徹
10     総務部                    1010     海老原 雄一郎    技術部
20     技術部                    1014     西川 舞       総務部
30     営業部                    1018     岡野原 大輔     技術部
                                                              26
完全外部結合
                  どの部門にも所属していない人も出力したい。
employees表        誰も所属していない部門も出力したい。
id      name      dept_id   SELECT emp.id, emp.name, dept.name
1000    西川 徹                FROM employees emp
1010    海老原 雄一郎   20          FULL OUTER JOIN departments dept
1014    西川 舞      10             ON dept.id = emp.dept_id;
1018    岡野原 大輔    20          結果
                              emp.id   emp.name   dept.name
departments表                  1000     西川 徹
id     name                   1010     海老原 雄一郎    技術部
10     総務部                    1014     西川 舞       総務部
20     技術部                    1018     岡野原 大輔     技術部
30     営業部                                        営業部
                                                              27
集合演算
選択列リストの構造が等しい2つのSELECT文の
結果(集合)の演算を行う
 UNION(和) – どちらかに含まれる
 INTERSECT(積) – どちらにも含まれる
 EXCEPT(差) – 1つ目に含まれて、2つ目には含まれない

通常は、重複行(全ての列の値が同じ行)は1行と
して戻される

UNION ALLのようにALLキーワードを指定すると
、重複はそのまま保持される
 集合的ではないけど便利
 重複が発生しないことが保証される場合にALLを使用すると性
 能Up

                                   28
集合演算の例
  employees表
   id     name         birthday   gender   title
   1000   西川 徹         1982/11         M   代表
   1010   海老原 雄一郎      1973/11         M
   1014   西川 舞         1984/9          F
   1018   岡野原 大輔       1982/4          M   フェロー

SELECT *
FROM employees
WHERE birthday < '1980/1/1'
UNION
SELECT *               id       name          birthday   gender   title
FROM employees         1010     海老原 雄一郎       1973/11      M
WHERE gender = 'F'     1014     西川 舞          1984/9        F
ORDER BY id;
                                                                          29
アジェンダ
1.   はじめに
2.   SQLのおさらい
3.   SQL一発
4.   SQLチューニングのポイント
5.   ケーススタディ
6.   おわりに



                      30
SQL一発

        SQLーーーッ!!!




               イッパーーーッツ!!!


                             31
「SQL一発」とは?
 MLや掲示板でよく見かける質問
 「・・・な結果をSQL一発で取得できますか?」

 テーブルから単純に行と列を抽出するだけでは
 欲しい結果イメージが得られない

 アプリケーション側で検索結果を加工すればい
 いのでは?
  コード書くのが面倒
  ツールの制限
    SQLクエリーを受け入れる帳票ツールなど
                           32
SQL一発 ノススメ
SQLを工夫すれば実際に何とかなるケース
も多い
  SQLはとても表現力が高い


アプリケーションコードが簡潔になる
  開発生産性の向上
  バグが入り込む余地が少なくなる


まさに NoSQL!
                       33
SQL一発のデメリット その1
トリッキーで理解しづらいSQLになりやすい
  保守性の低下
  SQLの意味を、書いた人しか理解できない
    1か月経てば、書いた本人ですら忘れる

解決策
  コードレビュー時に、 SQLの意図を日本語(自然言語)で事細
  かに説明させる
    「よく分からないけど、試してみたらうまくいく」はダメ
  その説明をソースコード内のSQLのそばにコメントで残してお
  く
  記法の標準化
    長く複雑なSQLをできるだけ見易くする
    改行、インデントルール
    大文字、小文字の使い分け
                                   34
SQL一発のデメリット その2
SQLの実行性能が悪くなりやすい
  オプティマイザーの限界
  道を知らないタクシーの運ちゃん
  道は知っているけど、渋滞情報を知らない運ちゃん

解決策
  レスポンス要求がシビアな時は使わない

  脳内オプティマイズ
   初めに理想の実行計画を頭の中で考える
   実行計画を確認しながら、クエリーを書く
   タクシーの運ちゃんに道順を指定する
                            35
あれ? 宣言的プログラミングは・・・
1回限りのアドホック処理、事前検証、プロト
タイピング、開発初期で活用しよう

リリース前には、
 性能要件、データ量、値の偏り、実行頻度
などを考慮して、実行計画をチューニング

宣言的な世界と手続き的な世界を行ったり
来たり
  もし同じ処理を手続き型で実現するとしたら、どのような
  アルゴリズムを用いるか?
                               36
アジェンダ
1.   はじめに
2.   SQLのおさらい
3.   SQL一発
4.   SQLチューニングのポイント
5.   ケーススタディ
6.   おわりに



                      37
重要なのは実行計画
速いSQL = 適切な実行計画

実行計画を立てるのはオプティマイザ

オプティマイザの動作を理解することが重要




                       38
オプティマイザが考慮すること
SQLの字面

表の定義情報
 特にインデックス
 クラスター、パーティショニング

ハードウェアリソース
 CPU、メモリ、I/O

統計情報
 行数、ページ数
 列毎の値の分布
 定期的に更新する必要性
                   39
実行計画の主な構成要素
表へのアクセス
 なるべく速く(特に索引)
 なるべく回数を少なく
 なるべく早めに絞り込み


結合アルゴリズム

ソート、集計
 なるべく回数を少なく
 なるべく小さく
                40
索引(インデックス)
普通はB+Tree
 特定の列値を持つレコードを探すほか、
 最大値・最小値の取得、行数のカウント、
 行のソートにも利用される
 部分インデックス、関数インデックス、    日本語Wikipedia「B+木」より引用
 リバースキーインデックス、クラスター
 インデックスなどのバリエーション
 複合(マルチカラム)インデックスの場合、WHERE句で=条件が適
 用される列を先頭にする
 WHERE句で索引列を演算しない(関数インデックスを除く)
               floor(score) = 5   score >= 5 AND score < 6
B+Tree以外にもハッシュインデックス、ビットマップ
インデックスなど
あまり多く定義すると更新性能が悪化する
                                                       41
表へのアクセス方法 (1/2)
 フルテーブルスキャン
  テーブルの物理領域を先頭から最後まで探索
  大きいと時間がかかる。けど、O(n)なので予測しやすい
  マルチブロックリードや先読みによる効率化も可能
  削除済みの領域に注意

 インデックスユニークスキャン
  ユニークなB+Treeインデックスをルートからリーフまで
  辿り、取得した行アドレス(0 or 1) にアクセス
  ユニークキー(主キー含む)列に対する等号(=)による
  WHERE条件
  速い
                                 42
表へのアクセス方法 (2/2)
 インデックスレンジスキャン
  B+Treeインデックスをルートからリーフまで辿り、さらにそこから右
  に辿りながら取得した全ての行アドレス(0以上)にアクセス
  非ユニークインデックスの定義列に対する等号によるWHERE条件
  インデックス定義列に対する不等号、前方一致のLIKEによる
  WHERE条件
  取得行の割合が多いと、テーブルフルスキャンのほうが有利

 フルインデックススキャン
  B+Treeのリーフを左端から右端まで全て探索 → ソート処理なしで
  ソートされた結果
  または、B+Treeインデックスの物理領域を先頭から最後まで探索
  参照列が全てインデックスに含まれる場合、テーブルフルスキャン
  よりもI/O量が少なくなる

                                       43
結合アルゴリズム
ネステッドループジョイン
 レスポンスタイム重視
 省メモリ

ハッシュジョイン
 大量データ向き、スループット重視
 結合条件が等号(=)
 データ量に応じたメモリが必要

マージジョイン
 大量データ向き、スループット重視
 結合条件が等号以外(>, >=, <, <=など)
 メモリが多ければ性能が良くなる

                             44
ネステッドループジョイン
 二重ループで2つの表にアクセスしながら
 結合
     外部表/駆動表: 外側のループでアクセスする表
     内部表: 内側のループでアクセスする表

for rec1 in “SELECT * FROM employees”
loop
  for rec2 in “SELECT * FROM departments WHERE id = :rec1.dept_id”
  loop
    rec1 + rec2 >> result
  end
end

                                                                     45
マージジョイン
       2つの表をそれぞれ結合列でソート
       それぞれ先頭から順に行を取り出しなが
       ら、結合列値が同じ行同士を結合

employees表                 departments表
id     name      dept_id   id   name
1014   西川 舞      10        10   総務部
1010   海老原 雄一郎   20        20   技術部
1018   岡野原 大輔    20        30   営業部
1000   西川 徹



                                          46
ハッシュジョイン
 一方の表から取り出した行を元にハッシュテ
 ーブルを作成(キーは結合列の値)
 もう一方の表から行を取り出し、ハッシュテー
 ブルを参照しながら結果を作成
for rec1 in “SELECT * FROM departments”
loop
  hash[rec1.id] = rec1
end

for rec2 in “SELECT * FROM employees”
loop
  dept = hash[rec2.dept_id]
  rec2 + dept >> result
end
                                          47
オプティマイザに言うことを聞かせる
オプティマイザが思った通りの実行計画を立ててくれ
ないことがある

クエリーの書き換え              全てDBMS
                        依存
ヒント
 クエリーの中に明示的なヒントを埋め込む

オプティマイザパラメータのチューニング
 コストの重み付けの変更
 特定のアルゴリズムの使用許可・不許可

統計情報の固定化
 あえて統計情報を古いままにする

                                48
アジェンダ
1.   はじめに
2.   SQLのおさらい
3.   SQL一発
4.   SQLチューニングのポイント
5.   ケーススタディ
6.   おわりに



                      49
コードの翻訳
       性別コード、国コードなど
        M→男、F→女
        JP→日本、US→アメリカ




employees表                結果
id     name      gender   id     name      gender
1000   西川 徹        M      1000   西川 徹        男
1010   海老原 雄一郎     M      1010   海老原 雄一郎     男
1014   西川 舞        F      1014   西川 舞        女
1018   岡野原 大輔      M      1018   岡野原 大輔      男
                                                    50
CASE式
SELECT id, name,                      最初の記法は、等号以外の比較
       CASE
         WHEN gender = 'M' THEN '男'
                                      演算子も利用可能
         WHEN gender = 'F' THEN '女'
         ELSE 'その他'
       END
                                      選択列リスト以外でも利用可能
FROM employees;
                                      SELECT以外のDMLでもOK
SELECT id, name,
                                       UPDATE文で行が持つ値によって更新
       CASE gender                     値を変えるなど
          WHEN 'M' THEN '男'            UPDATE … SET col=CASE ...;
          WHEN 'F' THEN '女'
          ELSE 'その他'
       END                            なお、王道はコードと翻訳語の対
FROM employees;                       応表を結合
                                       多言語対応もできる

                                                               51
CASEの応用 - 横展開(1/2)
 SELECT CASE dept_id
          WHEN 10 THEN '総務部' WHEN 20 THEN '技術部'
        END AS "部門",
        sum(CASE gender WHEN 'M' THEN 1 ELSE 0 END) AS "男",
        sum(CASE gender WHEN 'F' THEN 1 ELSE 0 END) AS "女"
 FROM employees
 GROUP BY CASE dept_id
            WHEN 10 THEN '総務部' WHEN 20 THEN '技術部'
          END;
employees表                             結果
id     name      gender   dept_id      部門      男   女
1000   西川 徹        M                           1   0
1010   海老原 雄一郎     M        20         総務部     0   1
1014   西川 舞         F       10         技術部     2   0
1018   岡野原 大輔      M        20
                                                          52
CASEの応用 - 横展開(2/2)
     よく分からないので、GROUP BYとsum()を外してみる
SELECT CASE dept_id
         WHEN 10 THEN '総務部' WHEN 20 THEN '技術部'
       END AS "部門",
       CASE gender WHEN 'M' THEN 1 ELSE 0 END AS "男",
       CASE gender WHEN 'F' THEN 1 ELSE 0 END AS "女"
FROM employees;

employees表                             結果
id     name      gender   dept_id       部門     男   女
1000   西川 徹         M                          1   0
1010   海老原 雄一郎      M       20          技術部    1   0
1014   西川 舞         F       10          総務部    0   1
1018   岡野原 大輔       M       20          技術部    1   0
                                                        53
「または」
SELECT *
                                     SELECT *
FROM employees
                                     FROM employees
WHERE birthday < '1980/1/1'
                                     WHERE birthday < '1980/1/1'
UNION
                                        OR gender = 'F'
SELECT *
                                     ORDER BY id;
FROM employees
WHERE gender = 'F'    id      name        birthday   gender   title
ORDER BY id;          1010    海老原 雄一郎     1973/11      M
                      1014    西川 舞        1984/9        F

 以下の条件が全て当てはまる場合は、UNION
 のほうが高速かも(オプティマイザ次第)
       employees表のレコード数が多い
       gender列とbirthday列のそれぞれにインデックスが定義さ
       れている
       それぞれの条件を満たす行の割合が比較的小さい
                                                                      54
全体の中で最小値を持つレコード
最年長の社員はだれか?
  employees表
  id     name      birthday   gender   title
  1000   西川 徹      1982/11      M      代表
  1010   海老原 雄一郎   1973/11      M
  1014   西川 舞      1984/9       F
  1018   岡野原 大輔    1982/4       M      フェロー




  id     name      birthday   gender   title
  1010   海老原 雄一郎   1973/11      M

                                               55
グループ関数の限界
「最年長社員の誕生日」だけなら簡単

SELECT min(birthday)
FROM employees;


しかし、最年長社員の社員番号(id)や名前
(name)は、グループ関数では取得できな
い


                        56
WHERE句内の副問合せ
SELECT *
FROM employees
WHERE birthday = (SELECT min(birthday)
                  FROM employees);


「誕生日が、全社員の中で最も早い誕生日と等
しい人」
副問合せを使った頻出イディオム
birthday列にインデックス
  副問合せの最小値を高速に取得
  主問合せで誕生日が一致する行を高速に取得
                                         57
FROM句内の副問合せ
SELECT *
FROM employees AS e
  INNER JOIN (SELECT min(birthday) AS birthday
                FROM employees
               ) AS oldest
     ON oldest.birthday = e.birthday;

副問合せの結果は、FROM句内で通常の表と
同じように扱うことができる
  「インラインビュー」とも呼ばれる
  注意: 副問合せの結果には、インデックスを定義できない!
  大きな結果を他の表と結合する場合は、マージジョインかハ
  ッシュジョインを使用、ネステッドループジョインなら外部表に
  する
                                                 58
部分集合毎の最大値を持つレコード
男女別の最年少社員はだれか?
 employees表
  id     name      birthday   gender   title
  1000   西川 徹      1982/11      M      代表
  1010   海老原 雄一郎   1973/11      M
  1014   西川 舞      1984/9       F
  1018   岡野原 大輔    1982/4       M      フェロー




  id     name      birthday   gender   title
  1000   西川 徹      1982/11      M      代表
  1014   西川 舞      1984/9       F
                                               59
相関副問合せ
SELECT *
FROM employees e1
WHERE e1.birthday = (SELECT max(e2.birthday)
                     FROM employees e2
                     WHERE e2.gender = e1.gender);

  「誕生日が、同性の社員の中で最も遅い誕
  生日と等しい人」
  相関副問合せの頻出イディオム
  gender列+birthday列にインデックス
     副問合せの性能最適化
     カバリングインデックス
                                                     60
行値コンストラクター
SELECT *
FROM employees
WHERE (gender, birthday) IN (SELECT gender, max(birthday)
                             FROM employees
                             GROUP BY gender);


   「性別と誕生日の組が、『男女別の最も遅い誕
   生日』表に含まれる人」
   gender列+birthday列にインデックス
   オプティマイザによっては、employeesを1行評
   価する毎に、副問合せを実行することがある
                                                            61
EXISTS / NOT EXISTS
  SELECT *
  FROM employees e1
  WHERE NOT EXISTS (
           SELECT 1
           FROM employees e2
           WHERE e2.gender = e1.gender
             AND e2.birthday > e1.birthday);

 「同姓に自分より後に生まれた人がいない人」
 副問合せの選択列リストは、参照されないので何でもいい
 副問合せの実行は1行発見したら停止される
 gender列+birthday列にインデックス
 EXISTS句は「少なくとも1行は存在する」場合に真
 最初は理解しづらいが、良い実行計画が得られやすい
                                               62
自己結合 + HAVING (1/2)
 SELECT e1.id, e1.name, e1.gender, e1.birthday
 FROM employees e1
       LEFT OUTER JOIN employees e2
          ON e2.gender = e1.gender
         AND e2.birthday > e1.birthday
 GROUP BY e1.id, e1.name, e1.gender, e1.birthday
 HAVING count(e2.id) = 0;

 「自分より後に生まれた同姓の人数が0」
 自己結合 = 同じ表同士を結合
 gender列+birthday列にインデックス

                                                   63
自己結合 + HAVING (2/2)
   GROUP BYとHAVINGを外し、列を補ってみる。
          SELECT e1.id, e1.name, e1.gender, e1.birthday,
                 e2.id, e2.name, e2.birthday
          FROM employees e1
                LEFT OUTER JOIN employees e2
                   ON e2.gender = e1.gender
                  AND e2.birthday > e1.birthday
e1.id   e1.name    e1.birthday   e1.gender   e2.id   e2.name   e2.birthday
1000    西川 徹       1982/11          M
1010    海老原 雄一郎    1973/11          M        1000    西川 徹      1982/11
1010    海老原 雄一郎    1973/11          M        1018    岡野原 大輔    1982/4
1014    西川 舞       1984/9            F
1018    岡野原 大輔     1982/4           M        1000    西川 徹      1982/11

 「count(e2.id)」はe2.idが非NULLの場合のみカウントされる
                                                                         64
アジェンダ
1.   はじめに
2.   SQLのおさらい
3.   SQL一発
4.   SQLチューニングのポイント
5.   ケーススタディ
6.   おわりに



                      65
今日の目的 (再掲)
SQLの表現力の強力さを理解する

SQLで効率的にプログラミングを減らす手
法を学ぶ

性能の良いSQLを書けそうな気になる



                       66
今日話せなかったこと (1/2)
 実行計画の確認方法
  MySQL
    漢のコンピュータ道 - MySQLの EXPLAINを徹底解説!! -
     http://nippondanji.blogspot.com/2009/03/mysqlexplain.html
     「エキスパートのためのMySQL[運用+管理]トラブルシューティン
     グガイド」

  PostgreSQL
     Explaining Explain ~ PostgreSQLの実行計画を読む ~
     http://lets.postgresql.jp/documents/technical/query_tuning/

  Oracle
     Web、書店でいくらでも情報は見つかる
     究極はマニュアルセットの「パフォーマンス・チューニング・ガイド」
     Oracle Technology Networkで公開されている
     http://www.oracle.com/technology/global/jp/index.html
                                                                   67
今日話せなかったこと (2/2)
 最近のSQL
  共通表式(WITH句)
  OLAP関数
  ウィンドウ関数

 RDBMS依存のSQLチューニング手法

 データベースの論理設計
  テーブル設計がきれいだと、良い性能が得られやすい
  逆に、性能重視であえて非正規化することも

 ORマッパーを介したDBアクセス

 昨今のデータベース界隈の状況

                             68
まとめ
SQLは複雑な処理を簡潔に記述できる

SQLは同じ結果を得るのに、様々な書き方
ができる

SQLの書き方によって性能に大きな違いが
出ることがある

SQLチューニングによって性能を最適化で
きる
                       69
Q&A
      70

More Related Content

Viewers also liked

AWSを使用したインフラ構築~遭難防止アプリにおけるインフラ想定~
AWSを使用したインフラ構築~遭難防止アプリにおけるインフラ想定~AWSを使用したインフラ構築~遭難防止アプリにおけるインフラ想定~
AWSを使用したインフラ構築~遭難防止アプリにおけるインフラ想定~Yuto Kudo
 
Amazon webservice(aws)と他社サーバのコストパフォーマンス比較
Amazon webservice(aws)と他社サーバのコストパフォーマンス比較Amazon webservice(aws)と他社サーバのコストパフォーマンス比較
Amazon webservice(aws)と他社サーバのコストパフォーマンス比較株式会社雲屋ネットワーク
 
ココが違うよEC2 ~オンプレミスVMとの徹底⽐比較~
ココが違うよEC2 ~オンプレミスVMとの徹底⽐比較~ココが違うよEC2 ~オンプレミスVMとの徹底⽐比較~
ココが違うよEC2 ~オンプレミスVMとの徹底⽐比較~Ryuta Otaki
 
SQL Server for SharePoint 2013
SQL Server for SharePoint 2013SQL Server for SharePoint 2013
SQL Server for SharePoint 2013Mayumi Mitaki
 
Oracle と sql server 比べてみよう (sql server)
Oracle と sql server 比べてみよう (sql server)Oracle と sql server 比べてみよう (sql server)
Oracle と sql server 比べてみよう (sql server)Masayuki Ozawa
 
S08 Microsoft Azure SQL Server の活用 (IaaS 環境における設定や運用)
S08 Microsoft Azure SQL Server の活用 (IaaS 環境における設定や運用)S08 Microsoft Azure SQL Server の活用 (IaaS 環境における設定や運用)
S08 Microsoft Azure SQL Server の活用 (IaaS 環境における設定や運用)Microsoft Azure Japan
 
プレゼンテーション アンチパターン から見るスタンダードなプレゼン
プレゼンテーション アンチパターン から見るスタンダードなプレゼンプレゼンテーション アンチパターン から見るスタンダードなプレゼン
プレゼンテーション アンチパターン から見るスタンダードなプレゼン真俊 横田
 
[db tech showcase Tokyo 2015] B36:Hitachi Advanced Data Binder 実践SQLチューニング方法 ...
[db tech showcase Tokyo 2015] B36:Hitachi Advanced Data Binder 実践SQLチューニング方法 ...[db tech showcase Tokyo 2015] B36:Hitachi Advanced Data Binder 実践SQLチューニング方法 ...
[db tech showcase Tokyo 2015] B36:Hitachi Advanced Data Binder 実践SQLチューニング方法 ...Insight Technology, Inc.
 
Sql server のバックアップとリストアの基礎
Sql server のバックアップとリストアの基礎Sql server のバックアップとリストアの基礎
Sql server のバックアップとリストアの基礎Masayuki Ozawa
 
クラウドデザインパターンから始めるクラウドの利点と弱点の理解~提案から設計・開発・保守に活かす!~
クラウドデザインパターンから始めるクラウドの利点と弱点の理解~提案から設計・開発・保守に活かす!~クラウドデザインパターンから始めるクラウドの利点と弱点の理解~提案から設計・開発・保守に活かす!~
クラウドデザインパターンから始めるクラウドの利点と弱点の理解~提案から設計・開発・保守に活かす!~貴志 上坂
 
Web エンジニアが postgre sql を選ぶ 3 つの理由
Web エンジニアが postgre sql を選ぶ 3 つの理由Web エンジニアが postgre sql を選ぶ 3 つの理由
Web エンジニアが postgre sql を選ぶ 3 つの理由Soudai Sone
 
データベース入門2
データベース入門2データベース入門2
データベース入門2tadaaki hayashi
 
AWS/Azure二大クラウドプラットフォーム十番勝負
AWS/Azure二大クラウドプラットフォーム十番勝負AWS/Azure二大クラウドプラットフォーム十番勝負
AWS/Azure二大クラウドプラットフォーム十番勝負Takuya Tachibana
 
[B24] Oracle から SQL Server システム移行の勘所 by Norio Nakamura
[B24] Oracle から SQL Server システム移行の勘所 by Norio Nakamura[B24] Oracle から SQL Server システム移行の勘所 by Norio Nakamura
[B24] Oracle から SQL Server システム移行の勘所 by Norio NakamuraInsight Technology, Inc.
 
リクルートのビッグデータ活用基盤とデータ活用に向けた取組み
リクルートのビッグデータ活用基盤とデータ活用に向けた取組みリクルートのビッグデータ活用基盤とデータ活用に向けた取組み
リクルートのビッグデータ活用基盤とデータ活用に向けた取組みRecruit Technologies
 
それでもボクはMicrosoft Azure を使う
それでもボクはMicrosoft Azure を使うそれでもボクはMicrosoft Azure を使う
それでもボクはMicrosoft Azure を使うMasaki Takeda
 
45分で理解する SQL Serverでできることできないこと
45分で理解する SQL Serverでできることできないこと45分で理解する SQL Serverでできることできないこと
45分で理解する SQL ServerでできることできないことInsight Technology, Inc.
 
[teratail Study ~機械学習編#2~] Microsoft AzureのAI関連サービス
[teratail Study ~機械学習編#2~] Microsoft AzureのAI関連サービス[teratail Study ~機械学習編#2~] Microsoft AzureのAI関連サービス
[teratail Study ~機械学習編#2~] Microsoft AzureのAI関連サービスNaoki (Neo) SATO
 
プレゼン初心者に ありがちな アンチパターン 野望篇
プレゼン初心者に ありがちな アンチパターン 野望篇プレゼン初心者に ありがちな アンチパターン 野望篇
プレゼン初心者に ありがちな アンチパターン 野望篇真俊 横田
 

Viewers also liked (20)

AWSを使用したインフラ構築~遭難防止アプリにおけるインフラ想定~
AWSを使用したインフラ構築~遭難防止アプリにおけるインフラ想定~AWSを使用したインフラ構築~遭難防止アプリにおけるインフラ想定~
AWSを使用したインフラ構築~遭難防止アプリにおけるインフラ想定~
 
Amazon webservice(aws)と他社サーバのコストパフォーマンス比較
Amazon webservice(aws)と他社サーバのコストパフォーマンス比較Amazon webservice(aws)と他社サーバのコストパフォーマンス比較
Amazon webservice(aws)と他社サーバのコストパフォーマンス比較
 
ココが違うよEC2 ~オンプレミスVMとの徹底⽐比較~
ココが違うよEC2 ~オンプレミスVMとの徹底⽐比較~ココが違うよEC2 ~オンプレミスVMとの徹底⽐比較~
ココが違うよEC2 ~オンプレミスVMとの徹底⽐比較~
 
SQL Server for SharePoint 2013
SQL Server for SharePoint 2013SQL Server for SharePoint 2013
SQL Server for SharePoint 2013
 
Oracle と sql server 比べてみよう (sql server)
Oracle と sql server 比べてみよう (sql server)Oracle と sql server 比べてみよう (sql server)
Oracle と sql server 比べてみよう (sql server)
 
S08 Microsoft Azure SQL Server の活用 (IaaS 環境における設定や運用)
S08 Microsoft Azure SQL Server の活用 (IaaS 環境における設定や運用)S08 Microsoft Azure SQL Server の活用 (IaaS 環境における設定や運用)
S08 Microsoft Azure SQL Server の活用 (IaaS 環境における設定や運用)
 
プレゼンテーション アンチパターン から見るスタンダードなプレゼン
プレゼンテーション アンチパターン から見るスタンダードなプレゼンプレゼンテーション アンチパターン から見るスタンダードなプレゼン
プレゼンテーション アンチパターン から見るスタンダードなプレゼン
 
[db tech showcase Tokyo 2015] B36:Hitachi Advanced Data Binder 実践SQLチューニング方法 ...
[db tech showcase Tokyo 2015] B36:Hitachi Advanced Data Binder 実践SQLチューニング方法 ...[db tech showcase Tokyo 2015] B36:Hitachi Advanced Data Binder 実践SQLチューニング方法 ...
[db tech showcase Tokyo 2015] B36:Hitachi Advanced Data Binder 実践SQLチューニング方法 ...
 
Sql server のバックアップとリストアの基礎
Sql server のバックアップとリストアの基礎Sql server のバックアップとリストアの基礎
Sql server のバックアップとリストアの基礎
 
クラウドデザインパターンから始めるクラウドの利点と弱点の理解~提案から設計・開発・保守に活かす!~
クラウドデザインパターンから始めるクラウドの利点と弱点の理解~提案から設計・開発・保守に活かす!~クラウドデザインパターンから始めるクラウドの利点と弱点の理解~提案から設計・開発・保守に活かす!~
クラウドデザインパターンから始めるクラウドの利点と弱点の理解~提案から設計・開発・保守に活かす!~
 
Web エンジニアが postgre sql を選ぶ 3 つの理由
Web エンジニアが postgre sql を選ぶ 3 つの理由Web エンジニアが postgre sql を選ぶ 3 つの理由
Web エンジニアが postgre sql を選ぶ 3 つの理由
 
データベース入門2
データベース入門2データベース入門2
データベース入門2
 
AWS/Azure二大クラウドプラットフォーム十番勝負
AWS/Azure二大クラウドプラットフォーム十番勝負AWS/Azure二大クラウドプラットフォーム十番勝負
AWS/Azure二大クラウドプラットフォーム十番勝負
 
[B24] Oracle から SQL Server システム移行の勘所 by Norio Nakamura
[B24] Oracle から SQL Server システム移行の勘所 by Norio Nakamura[B24] Oracle から SQL Server システム移行の勘所 by Norio Nakamura
[B24] Oracle から SQL Server システム移行の勘所 by Norio Nakamura
 
リクルートのビッグデータ活用基盤とデータ活用に向けた取組み
リクルートのビッグデータ活用基盤とデータ活用に向けた取組みリクルートのビッグデータ活用基盤とデータ活用に向けた取組み
リクルートのビッグデータ活用基盤とデータ活用に向けた取組み
 
SQL Server 入門
SQL Server 入門SQL Server 入門
SQL Server 入門
 
それでもボクはMicrosoft Azure を使う
それでもボクはMicrosoft Azure を使うそれでもボクはMicrosoft Azure を使う
それでもボクはMicrosoft Azure を使う
 
45分で理解する SQL Serverでできることできないこと
45分で理解する SQL Serverでできることできないこと45分で理解する SQL Serverでできることできないこと
45分で理解する SQL Serverでできることできないこと
 
[teratail Study ~機械学習編#2~] Microsoft AzureのAI関連サービス
[teratail Study ~機械学習編#2~] Microsoft AzureのAI関連サービス[teratail Study ~機械学習編#2~] Microsoft AzureのAI関連サービス
[teratail Study ~機械学習編#2~] Microsoft AzureのAI関連サービス
 
プレゼン初心者に ありがちな アンチパターン 野望篇
プレゼン初心者に ありがちな アンチパターン 野望篇プレゼン初心者に ありがちな アンチパターン 野望篇
プレゼン初心者に ありがちな アンチパターン 野望篇
 

More from Preferred Networks

PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57Preferred Networks
 
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3Preferred Networks
 
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...Preferred Networks
 
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...Preferred Networks
 
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55Preferred Networks
 
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2Preferred Networks
 
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2Preferred Networks
 
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2Preferred Networks
 
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演Preferred Networks
 
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)Preferred Networks
 
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)Preferred Networks
 
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)Preferred Networks
 
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語るKubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語るPreferred Networks
 
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張Preferred Networks
 
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会Preferred Networks
 
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2Preferred Networks
 
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...Preferred Networks
 
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...Preferred Networks
 
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...Preferred Networks
 
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50Preferred Networks
 

More from Preferred Networks (20)

PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
 
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
 
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
 
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
 
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
 
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
 
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
 
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
 
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
 
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
 
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
 
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
 
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語るKubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
 
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
 
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
 
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
 
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
 
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
 
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
 
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
 

Recently uploaded

ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦Sadao Tokuyama
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfMatsushita Laboratory
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~arts yokohama
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-LoopへTetsuya Nihonmatsu
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdfAyachika Kitazaki
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 

Recently uploaded (12)

2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
 
2024 04 minnanoito
2024 04 minnanoito2024 04 minnanoito
2024 04 minnanoito
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 

introduction_to_only_SQL

  • 1. NoSQL入門 2010年7月8日 (株)Preferred Infrastructure 海老原 雄一郎 当日の録画が以下で公開されていますので、併せてご覧下さい。 http://www.ustream.tv/recorded/8146586 1
  • 2. NoSQLとは? NoSQL = only SQL cf. NoSQL = Not only SQL MS SQLのコマンドラインツール osql とは無関係 SQLが持つ強力な表現力をフル活用する こと そのようなSQLは、見た人が思わず、”Oh! SQL!”と叫んでしまう 2
  • 3. アジェンダ 1. はじめに 2. SQLのおさらい 3. SQL一発 4. SQLチューニングのポイント 5. ケーススタディ 6. おわりに 3
  • 4. アジェンダ 1. はじめに 2. SQLのおさらい 3. SQL一発 4. SQLチューニングのポイント 5. ケーススタディ 6. おわりに 4
  • 5. 自己紹介 海老原 雄一郎 (@yebihara) RDBMSを愛しているソフトウェアエンジニア 日本オラクルでテクニカルコンサルタントを6年 データベースの基礎をみっちり ソニーでPostgreSQLとMySQL OSS DBを社内に広めるプロジェクト 「現場で使えるMySQL」などで有名な松信さんは当時 のチームメンバー DBセキュリティ製品のアイピーロックスでデータベース三 昧の日々 Oracle, MS SQL Server, IBM DB2, Sybase ASE, 日 立HiRDB, PostgreSQL 現在: PFI とあるシステム開発で久々にMySQLをみっちり 5
  • 8. アジェンダ 1. はじめに 2. SQLのおさらい 3. SQL一発 4. SQLチューニングのポイント 5. ケーススタディ 6. おわりに 8
  • 9. SQLの特徴 (1/2) 主にリレーショナルデータベースを操作するため のクエリー言語 データは行と列で構成される表に格納されている 表=table, テーブル 行=row, レコード 列=column, カラム 検索結果も表として得られる 表=集合、要素は順序付けられていない employees表 id name birthday gender title 1000 西川 徹 1982/11 M 代表 行 1010 海老原 雄一郎 1973/11 M 行 1014 西川 舞 1984/9 F 行 1018 岡野原 大輔 1982/4 M フェロー 行 列 列 列 列 列 9
  • 10. SQLの特徴 (2/2) 宣言型プログラミング言語 「どのようにデータを処理するか?」ではなく、「どのような処理 結果(データの集合)が欲しいか?」を記述する クエリーオプティマイザー SQLを翻訳して、実行計画を作成する 実行計画= 「どのようにデータを処理するか?」 プランナーと呼ばれることも タクシーのメタファー タクシーで行き先を告げると、運ちゃん(オプティマイザー) が道順(実行計画)を考えて、連れて行ってくれる 自分で車を運転する場合は、自分で道順を考えないとい けない → 手続き型プログラミング 10
  • 11. 標準SQL ISOで標準化されている SQL-92, SQL:1999, SQL:2003, SQL:2008 全てを実装しているRDBMSは存在しない RDBMS固有の拡張(方言)も多い 11
  • 12. SQLの種類 DML(Data Manipulation Language) データの中身を操作する SELECT、INSERT、UPDATE、DELETEなど 標準SQLの範囲内で結構いける DDL(Data Definition Language) DBオブジェクト(表や索引など)の定義情報を操作する CREATE TABLEなど 主要部分は標準SQLでOK、ただし方言の利用もほぼ必須 その他 トランザクション制御 権限管理 12
  • 13. SELECT文の基本構造 (1/2) employees表 id name birthday gender title 1000 西川 徹 1982/11 M 代表 1010 海老原 雄一郎 1973/11 M 1014 西川 舞 1984/9 F 1018 岡野原 大輔 1982/4 M フェロー クエリーの結果 SELECT id, name, title id name title FROM employees 1000 西川 徹 代表 WHERE gender = „M‟; 1010 海老原 雄一郎 1018 岡野原 大輔 フェロー 13
  • 14. SELECT文の基本構造 (2/2) SELECT id, name, title 選択列リスト FROM employees FROM句 WHERE gender = „M‟; WHERE句 他にGROUP BY句、HAVING句、 ORDER BY句+ 方言 14
  • 15. 選択列リスト 出力結果を構成する列のリスト 記述できるもの SELECT id, name, title FROM句の表の列(「*」で全ての列) FROM employees リテラル値 WHERE gender = „M‟; 式(演算子、関数、スカラー副問合せ) id name birthday gender title 1000 西川 徹 1982/11 M 代表 1010 海老原 雄一郎 1973/11 M 1014 西川 舞 1984/9 F 1018 岡野原 大輔 1982/4 M フェロー 15
  • 16. FROM句 行を取り出す対象となる表 記述できるもの SELECT id, name, title 表、ビュー、副問合せ FROM employees JOIN句 WHERE gender = „M‟; 16
  • 17. WHERE句 FROM句の表に適用する抽出条件 記述できるもの SELECT id, name, title true/false/nullを返す条件式 FROM employees WHERE gender = „M‟; id name birthday gender title 1000 西川 徹 1982/11 M 代表 1010 海老原 雄一郎 1973/11 M 1014 西川 舞 1984/9 F 1018 岡野原 大輔 1982/4 M フェロー 17
  • 18. GROUP BY句 グループ関数で集計処理を行う場合の集計単位 SELECT gender, 記述できるもの trunc(age(birthday), 10), いろいろ記述できるけど、 count(*) 選択列リストのうち、グループ関数を FROM employees GROUP BY 含まない全ての列を記述するのが gender, 分かりやすい trunc(age(birthday), 10); employees表 id name birthday gender クエリーの結果 gender trunc(…) count(*) 1000 西川 徹 1982/11 M M 30 1 1010 海老原 雄一郎 1973/11 M M 20 2 1014 西川 舞 1984/9 F F 20 1 1018 岡野原 大輔 1982/4 M 18
  • 19. HAVING句 GROUP BY句による集計結果に適用する抽出条件 SELECT gender, trunc(age(birthday), 10), 記述できるもの count(*) いろいろ記述できるけど、 FROM employees GROUP BY 基本的にはグループ関数を含む条件 gender, (でなければWHERE句に書けばよい) trunc(age(birthday), 10) HAVING count(*) = 1; employees表 id name birthday gender クエリーの結果 gender trunc(…) count(*) 1000 西川 徹 1982/11 M M 30 1 1010 海老原 雄一郎 1973/11 M F 20 1 1014 西川 舞 1984/9 F 1018 岡野原 大輔 1982/4 M 19
  • 20. ORDER BY句 出力結果の構成行の並び順 ORDER BY句を指定しないと、 SELECT id, name, title 並び順は「不定」となる 順序が重要なら必ず指定する FROM employees WHERE gender = „M‟ 記述できるもの ORDER BY birthday; 選択列リスト中の列 FROM句の表の列 上記に基づく式 ⇒ ex. ORDER BY length(name) 選択列リスト中の列位置 ⇒ ex. ORDER BY 2 20
  • 21. 結合(ジョイン) 2つの表から取得した行を連結して、1つ の表を構成する操作 その結果をさらに別の表と結合することもできる いろいろな結合 直積(デカルト積、クロスジョイン) 等価結合 内部結合 外部結合 半結合 逆結合 21
  • 22. 等価結合 employees表 id name dept_id 1000 西川 徹 SELECT emp.id, emp.name, dept.name 1010 海老原 雄一郎 20 FROM employees emp, 1014 西川 舞 10 departments dept 1018 岡野原 大輔 20 WHERE dept.id = emp.dept_id; departments表 結果 id name emp.id emp.name dept.name 10 総務部 1010 海老原 雄一郎 技術部 20 技術部 1014 西川 舞 総務部 30 営業部 1018 岡野原 大輔 技術部 22
  • 23. 直積 SELECT emp.id, emp.name, dept.name FROM employees emp, departments dept; employees表 id name dept_id 結果 emp.id emp.name dept.name 1000 西川 徹 1000 西川 徹 総務部 1010 海老原 雄一郎 20 1000 西川 徹 技術部 1000 西川 徹 営業部 1014 西川 舞 10 1010 海老原 雄一郎 総務部 1018 岡野原 大輔 20 1010 海老原 雄一郎 技術部 1010 海老原 雄一郎 営業部 departments表 1014 西川 舞 総務部 id name 1014 西川 舞 技術部 1014 西川 舞 営業部 10 総務部 1018 岡野原 大輔 総務部 20 技術部 1018 岡野原 大輔 技術部 30 営業部 1018 岡野原 大輔 営業部 23
  • 24. 直積から結合を理解する SELECT emp.id, emp.name, dept.name emp.id emp.name emp.dept_id dept.id dept.name FROM employees emp, 1000 西川 徹 10 総務部 departments dept 1000 西川 徹 20 技術部 1000 西川 徹 30 営業部 WHERE dept.id = emp.dept_id; 1010 海老原 雄一郎 20 10 総務部 1010 海老原 雄一郎 20 20 技術部 1010 海老原 雄一郎 20 30 営業部 emp.id emp.name dept.name 1014 西川 舞 10 10 総務部 1014 西川 舞 10 20 技術部 1010 海老原 雄一郎 技術部 1014 西川 舞 10 30 営業部 1014 西川 舞 総務部 1018 岡野原 大輔 20 10 総務部 1018 岡野原 大輔 技術部 1018 岡野原 大輔 20 20 技術部 1018 岡野原 大輔 20 30 営業部 24
  • 25. JOIN構文 FROM句に表をカンマ区切りで並べて、結 合条件をWHERE句に書くのは古い記法 JOIN構文 SELECT emp.id, emp.name, dept.name FROM employees emp INNER JOIN departments dept ON dept.id = emp.dept_id; SELECT emp.id, emp.name, dept.name FROM employees emp CROSS JOIN departments dept; 25
  • 26. 左外部結合 どの部門にも所属していない人も出力したい。 employees表 id name dept_id SELECT emp.id, emp.name, dept.name 1000 西川 徹 FROM employees emp 1010 海老原 雄一郎 20 LEFT OUTER JOIN departments dept 1014 西川 舞 10 ON dept.id = emp.dept_id; 1018 岡野原 大輔 20 結果 departments表 emp.id emp.name dept.name id name 1000 西川 徹 10 総務部 1010 海老原 雄一郎 技術部 20 技術部 1014 西川 舞 総務部 30 営業部 1018 岡野原 大輔 技術部 26
  • 27. 完全外部結合 どの部門にも所属していない人も出力したい。 employees表 誰も所属していない部門も出力したい。 id name dept_id SELECT emp.id, emp.name, dept.name 1000 西川 徹 FROM employees emp 1010 海老原 雄一郎 20 FULL OUTER JOIN departments dept 1014 西川 舞 10 ON dept.id = emp.dept_id; 1018 岡野原 大輔 20 結果 emp.id emp.name dept.name departments表 1000 西川 徹 id name 1010 海老原 雄一郎 技術部 10 総務部 1014 西川 舞 総務部 20 技術部 1018 岡野原 大輔 技術部 30 営業部 営業部 27
  • 28. 集合演算 選択列リストの構造が等しい2つのSELECT文の 結果(集合)の演算を行う UNION(和) – どちらかに含まれる INTERSECT(積) – どちらにも含まれる EXCEPT(差) – 1つ目に含まれて、2つ目には含まれない 通常は、重複行(全ての列の値が同じ行)は1行と して戻される UNION ALLのようにALLキーワードを指定すると 、重複はそのまま保持される 集合的ではないけど便利 重複が発生しないことが保証される場合にALLを使用すると性 能Up 28
  • 29. 集合演算の例 employees表 id name birthday gender title 1000 西川 徹 1982/11 M 代表 1010 海老原 雄一郎 1973/11 M 1014 西川 舞 1984/9 F 1018 岡野原 大輔 1982/4 M フェロー SELECT * FROM employees WHERE birthday < '1980/1/1' UNION SELECT * id name birthday gender title FROM employees 1010 海老原 雄一郎 1973/11 M WHERE gender = 'F' 1014 西川 舞 1984/9 F ORDER BY id; 29
  • 30. アジェンダ 1. はじめに 2. SQLのおさらい 3. SQL一発 4. SQLチューニングのポイント 5. ケーススタディ 6. おわりに 30
  • 31. SQL一発 SQLーーーッ!!! イッパーーーッツ!!! 31
  • 32. 「SQL一発」とは? MLや掲示板でよく見かける質問 「・・・な結果をSQL一発で取得できますか?」 テーブルから単純に行と列を抽出するだけでは 欲しい結果イメージが得られない アプリケーション側で検索結果を加工すればい いのでは? コード書くのが面倒 ツールの制限 SQLクエリーを受け入れる帳票ツールなど 32
  • 33. SQL一発 ノススメ SQLを工夫すれば実際に何とかなるケース も多い SQLはとても表現力が高い アプリケーションコードが簡潔になる 開発生産性の向上 バグが入り込む余地が少なくなる まさに NoSQL! 33
  • 34. SQL一発のデメリット その1 トリッキーで理解しづらいSQLになりやすい 保守性の低下 SQLの意味を、書いた人しか理解できない 1か月経てば、書いた本人ですら忘れる 解決策 コードレビュー時に、 SQLの意図を日本語(自然言語)で事細 かに説明させる 「よく分からないけど、試してみたらうまくいく」はダメ その説明をソースコード内のSQLのそばにコメントで残してお く 記法の標準化 長く複雑なSQLをできるだけ見易くする 改行、インデントルール 大文字、小文字の使い分け 34
  • 35. SQL一発のデメリット その2 SQLの実行性能が悪くなりやすい オプティマイザーの限界 道を知らないタクシーの運ちゃん 道は知っているけど、渋滞情報を知らない運ちゃん 解決策 レスポンス要求がシビアな時は使わない 脳内オプティマイズ 初めに理想の実行計画を頭の中で考える 実行計画を確認しながら、クエリーを書く タクシーの運ちゃんに道順を指定する 35
  • 37. アジェンダ 1. はじめに 2. SQLのおさらい 3. SQL一発 4. SQLチューニングのポイント 5. ケーススタディ 6. おわりに 37
  • 39. オプティマイザが考慮すること SQLの字面 表の定義情報 特にインデックス クラスター、パーティショニング ハードウェアリソース CPU、メモリ、I/O 統計情報 行数、ページ数 列毎の値の分布 定期的に更新する必要性 39
  • 40. 実行計画の主な構成要素 表へのアクセス なるべく速く(特に索引) なるべく回数を少なく なるべく早めに絞り込み 結合アルゴリズム ソート、集計 なるべく回数を少なく なるべく小さく 40
  • 41. 索引(インデックス) 普通はB+Tree 特定の列値を持つレコードを探すほか、 最大値・最小値の取得、行数のカウント、 行のソートにも利用される 部分インデックス、関数インデックス、 日本語Wikipedia「B+木」より引用 リバースキーインデックス、クラスター インデックスなどのバリエーション 複合(マルチカラム)インデックスの場合、WHERE句で=条件が適 用される列を先頭にする WHERE句で索引列を演算しない(関数インデックスを除く) floor(score) = 5 score >= 5 AND score < 6 B+Tree以外にもハッシュインデックス、ビットマップ インデックスなど あまり多く定義すると更新性能が悪化する 41
  • 42. 表へのアクセス方法 (1/2) フルテーブルスキャン テーブルの物理領域を先頭から最後まで探索 大きいと時間がかかる。けど、O(n)なので予測しやすい マルチブロックリードや先読みによる効率化も可能 削除済みの領域に注意 インデックスユニークスキャン ユニークなB+Treeインデックスをルートからリーフまで 辿り、取得した行アドレス(0 or 1) にアクセス ユニークキー(主キー含む)列に対する等号(=)による WHERE条件 速い 42
  • 43. 表へのアクセス方法 (2/2) インデックスレンジスキャン B+Treeインデックスをルートからリーフまで辿り、さらにそこから右 に辿りながら取得した全ての行アドレス(0以上)にアクセス 非ユニークインデックスの定義列に対する等号によるWHERE条件 インデックス定義列に対する不等号、前方一致のLIKEによる WHERE条件 取得行の割合が多いと、テーブルフルスキャンのほうが有利 フルインデックススキャン B+Treeのリーフを左端から右端まで全て探索 → ソート処理なしで ソートされた結果 または、B+Treeインデックスの物理領域を先頭から最後まで探索 参照列が全てインデックスに含まれる場合、テーブルフルスキャン よりもI/O量が少なくなる 43
  • 44. 結合アルゴリズム ネステッドループジョイン レスポンスタイム重視 省メモリ ハッシュジョイン 大量データ向き、スループット重視 結合条件が等号(=) データ量に応じたメモリが必要 マージジョイン 大量データ向き、スループット重視 結合条件が等号以外(>, >=, <, <=など) メモリが多ければ性能が良くなる 44
  • 45. ネステッドループジョイン 二重ループで2つの表にアクセスしながら 結合 外部表/駆動表: 外側のループでアクセスする表 内部表: 内側のループでアクセスする表 for rec1 in “SELECT * FROM employees” loop for rec2 in “SELECT * FROM departments WHERE id = :rec1.dept_id” loop rec1 + rec2 >> result end end 45
  • 46. マージジョイン 2つの表をそれぞれ結合列でソート それぞれ先頭から順に行を取り出しなが ら、結合列値が同じ行同士を結合 employees表 departments表 id name dept_id id name 1014 西川 舞 10 10 総務部 1010 海老原 雄一郎 20 20 技術部 1018 岡野原 大輔 20 30 営業部 1000 西川 徹 46
  • 47. ハッシュジョイン 一方の表から取り出した行を元にハッシュテ ーブルを作成(キーは結合列の値) もう一方の表から行を取り出し、ハッシュテー ブルを参照しながら結果を作成 for rec1 in “SELECT * FROM departments” loop hash[rec1.id] = rec1 end for rec2 in “SELECT * FROM employees” loop dept = hash[rec2.dept_id] rec2 + dept >> result end 47
  • 48. オプティマイザに言うことを聞かせる オプティマイザが思った通りの実行計画を立ててくれ ないことがある クエリーの書き換え 全てDBMS 依存 ヒント クエリーの中に明示的なヒントを埋め込む オプティマイザパラメータのチューニング コストの重み付けの変更 特定のアルゴリズムの使用許可・不許可 統計情報の固定化 あえて統計情報を古いままにする 48
  • 49. アジェンダ 1. はじめに 2. SQLのおさらい 3. SQL一発 4. SQLチューニングのポイント 5. ケーススタディ 6. おわりに 49
  • 50. コードの翻訳 性別コード、国コードなど M→男、F→女 JP→日本、US→アメリカ employees表 結果 id name gender id name gender 1000 西川 徹 M 1000 西川 徹 男 1010 海老原 雄一郎 M 1010 海老原 雄一郎 男 1014 西川 舞 F 1014 西川 舞 女 1018 岡野原 大輔 M 1018 岡野原 大輔 男 50
  • 51. CASE式 SELECT id, name, 最初の記法は、等号以外の比較 CASE WHEN gender = 'M' THEN '男' 演算子も利用可能 WHEN gender = 'F' THEN '女' ELSE 'その他' END 選択列リスト以外でも利用可能 FROM employees; SELECT以外のDMLでもOK SELECT id, name, UPDATE文で行が持つ値によって更新 CASE gender 値を変えるなど WHEN 'M' THEN '男' UPDATE … SET col=CASE ...; WHEN 'F' THEN '女' ELSE 'その他' END なお、王道はコードと翻訳語の対 FROM employees; 応表を結合 多言語対応もできる 51
  • 52. CASEの応用 - 横展開(1/2) SELECT CASE dept_id WHEN 10 THEN '総務部' WHEN 20 THEN '技術部' END AS "部門", sum(CASE gender WHEN 'M' THEN 1 ELSE 0 END) AS "男", sum(CASE gender WHEN 'F' THEN 1 ELSE 0 END) AS "女" FROM employees GROUP BY CASE dept_id WHEN 10 THEN '総務部' WHEN 20 THEN '技術部' END; employees表 結果 id name gender dept_id 部門 男 女 1000 西川 徹 M 1 0 1010 海老原 雄一郎 M 20 総務部 0 1 1014 西川 舞 F 10 技術部 2 0 1018 岡野原 大輔 M 20 52
  • 53. CASEの応用 - 横展開(2/2) よく分からないので、GROUP BYとsum()を外してみる SELECT CASE dept_id WHEN 10 THEN '総務部' WHEN 20 THEN '技術部' END AS "部門", CASE gender WHEN 'M' THEN 1 ELSE 0 END AS "男", CASE gender WHEN 'F' THEN 1 ELSE 0 END AS "女" FROM employees; employees表 結果 id name gender dept_id 部門 男 女 1000 西川 徹 M 1 0 1010 海老原 雄一郎 M 20 技術部 1 0 1014 西川 舞 F 10 総務部 0 1 1018 岡野原 大輔 M 20 技術部 1 0 53
  • 54. 「または」 SELECT * SELECT * FROM employees FROM employees WHERE birthday < '1980/1/1' WHERE birthday < '1980/1/1' UNION OR gender = 'F' SELECT * ORDER BY id; FROM employees WHERE gender = 'F' id name birthday gender title ORDER BY id; 1010 海老原 雄一郎 1973/11 M 1014 西川 舞 1984/9 F 以下の条件が全て当てはまる場合は、UNION のほうが高速かも(オプティマイザ次第) employees表のレコード数が多い gender列とbirthday列のそれぞれにインデックスが定義さ れている それぞれの条件を満たす行の割合が比較的小さい 54
  • 55. 全体の中で最小値を持つレコード 最年長の社員はだれか? employees表 id name birthday gender title 1000 西川 徹 1982/11 M 代表 1010 海老原 雄一郎 1973/11 M 1014 西川 舞 1984/9 F 1018 岡野原 大輔 1982/4 M フェロー id name birthday gender title 1010 海老原 雄一郎 1973/11 M 55
  • 57. WHERE句内の副問合せ SELECT * FROM employees WHERE birthday = (SELECT min(birthday) FROM employees); 「誕生日が、全社員の中で最も早い誕生日と等 しい人」 副問合せを使った頻出イディオム birthday列にインデックス 副問合せの最小値を高速に取得 主問合せで誕生日が一致する行を高速に取得 57
  • 58. FROM句内の副問合せ SELECT * FROM employees AS e INNER JOIN (SELECT min(birthday) AS birthday FROM employees ) AS oldest ON oldest.birthday = e.birthday; 副問合せの結果は、FROM句内で通常の表と 同じように扱うことができる 「インラインビュー」とも呼ばれる 注意: 副問合せの結果には、インデックスを定義できない! 大きな結果を他の表と結合する場合は、マージジョインかハ ッシュジョインを使用、ネステッドループジョインなら外部表に する 58
  • 59. 部分集合毎の最大値を持つレコード 男女別の最年少社員はだれか? employees表 id name birthday gender title 1000 西川 徹 1982/11 M 代表 1010 海老原 雄一郎 1973/11 M 1014 西川 舞 1984/9 F 1018 岡野原 大輔 1982/4 M フェロー id name birthday gender title 1000 西川 徹 1982/11 M 代表 1014 西川 舞 1984/9 F 59
  • 60. 相関副問合せ SELECT * FROM employees e1 WHERE e1.birthday = (SELECT max(e2.birthday) FROM employees e2 WHERE e2.gender = e1.gender); 「誕生日が、同性の社員の中で最も遅い誕 生日と等しい人」 相関副問合せの頻出イディオム gender列+birthday列にインデックス 副問合せの性能最適化 カバリングインデックス 60
  • 61. 行値コンストラクター SELECT * FROM employees WHERE (gender, birthday) IN (SELECT gender, max(birthday) FROM employees GROUP BY gender); 「性別と誕生日の組が、『男女別の最も遅い誕 生日』表に含まれる人」 gender列+birthday列にインデックス オプティマイザによっては、employeesを1行評 価する毎に、副問合せを実行することがある 61
  • 62. EXISTS / NOT EXISTS SELECT * FROM employees e1 WHERE NOT EXISTS ( SELECT 1 FROM employees e2 WHERE e2.gender = e1.gender AND e2.birthday > e1.birthday); 「同姓に自分より後に生まれた人がいない人」 副問合せの選択列リストは、参照されないので何でもいい 副問合せの実行は1行発見したら停止される gender列+birthday列にインデックス EXISTS句は「少なくとも1行は存在する」場合に真 最初は理解しづらいが、良い実行計画が得られやすい 62
  • 63. 自己結合 + HAVING (1/2) SELECT e1.id, e1.name, e1.gender, e1.birthday FROM employees e1 LEFT OUTER JOIN employees e2 ON e2.gender = e1.gender AND e2.birthday > e1.birthday GROUP BY e1.id, e1.name, e1.gender, e1.birthday HAVING count(e2.id) = 0; 「自分より後に生まれた同姓の人数が0」 自己結合 = 同じ表同士を結合 gender列+birthday列にインデックス 63
  • 64. 自己結合 + HAVING (2/2) GROUP BYとHAVINGを外し、列を補ってみる。 SELECT e1.id, e1.name, e1.gender, e1.birthday, e2.id, e2.name, e2.birthday FROM employees e1 LEFT OUTER JOIN employees e2 ON e2.gender = e1.gender AND e2.birthday > e1.birthday e1.id e1.name e1.birthday e1.gender e2.id e2.name e2.birthday 1000 西川 徹 1982/11 M 1010 海老原 雄一郎 1973/11 M 1000 西川 徹 1982/11 1010 海老原 雄一郎 1973/11 M 1018 岡野原 大輔 1982/4 1014 西川 舞 1984/9 F 1018 岡野原 大輔 1982/4 M 1000 西川 徹 1982/11 「count(e2.id)」はe2.idが非NULLの場合のみカウントされる 64
  • 65. アジェンダ 1. はじめに 2. SQLのおさらい 3. SQL一発 4. SQLチューニングのポイント 5. ケーススタディ 6. おわりに 65
  • 67. 今日話せなかったこと (1/2) 実行計画の確認方法 MySQL 漢のコンピュータ道 - MySQLの EXPLAINを徹底解説!! - http://nippondanji.blogspot.com/2009/03/mysqlexplain.html 「エキスパートのためのMySQL[運用+管理]トラブルシューティン グガイド」 PostgreSQL Explaining Explain ~ PostgreSQLの実行計画を読む ~ http://lets.postgresql.jp/documents/technical/query_tuning/ Oracle Web、書店でいくらでも情報は見つかる 究極はマニュアルセットの「パフォーマンス・チューニング・ガイド」 Oracle Technology Networkで公開されている http://www.oracle.com/technology/global/jp/index.html 67
  • 68. 今日話せなかったこと (2/2) 最近のSQL 共通表式(WITH句) OLAP関数 ウィンドウ関数 RDBMS依存のSQLチューニング手法 データベースの論理設計 テーブル設計がきれいだと、良い性能が得られやすい 逆に、性能重視であえて非正規化することも ORマッパーを介したDBアクセス 昨今のデータベース界隈の状況 68
  • 70. Q&A 70