Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

Webアプリケーションが今こそ知るべき、 RDBMSのパフォーマンスチューニングの勘所 / B...

soudai sone
February 11, 2019

Webアプリケーションが今こそ知るべき、 RDBMSのパフォーマンスチューニングの勘所 / Basic-of-RDB

soudai sone

February 11, 2019
Tweet

More Decks by soudai sone

Other Decks in Technology

Transcript

  1. 自己紹介 曽根 壮大(34歳) 株式会社オミカレ 副社長/CTO • 日本PostgreSQLユーザ会 勉強会分科会 座長 •

    3人の子供がいます • 技術的にはWeb/LL言語/RDBが好きです そ ね た け と も
  2. 自己紹介 曽根 壮大(34歳) 株式会社オミカレ 副社長/CTO • 日本PostgreSQLユーザ会 勉強会分科会 座長 •

    3人の子供がいます • 技術的にはWeb/LL言語/RDBが好きです そ ね た け と も
  3. • パーサ • リライタ • プランナ • オプティマイザ エグゼキュータ データ

    クライアント ① SQLを実行する ②SQLの構文を解析 構文木の作成を行う ③最適な実行計画を生成 INDEXの利用の有無、 JOINのアルゴリズムなどを決める ④実行計画に沿ってクエリを 実行し、データを取得 ⑤取得した結果を クライアントに返す
  4. 実行計画 -- MySQL mysql> EXPLAIN SELECT * FROM demo WHERE

    id = 100; +----+-------------+-------+------------+-------+---------------+------+---------+-------+------+----------+-------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+-------+---------------+------+---------+-------+------+----------+-------+ | 1 | SIMPLE | demo | NULL | const | id | id | 8 | const | 1 | 100.00 | NULL | +----+-------------+-------+------------+-------+---------------+------+---------+-------+------+----------+-------+ 1 row in set, 1 warning (0.01 sec) -- PostgreSQL postgres=# EXPLAIN SELECT * FROM demo WHERE id = 100; QUERY PLAN ----------------------------------------------------- Seq Scan on demo (cost=0.00..2.40 rows=1 width=38) Filter: (id = 100) (2 rows)
  5. 不要で大きなデータの取得例 記事一覧 1. Laravelカンファレンス登壇 2. 失敗から学ぶRDBの正しい歩き ︙ 1 2 3

    4 5 … 次へ データ SELECT * FROM 記事 ORDER BY id LIMIT 10 OFFSET 1; ブログid タイトル 記事 クエリの結果イメージ 記事データを使っていないのに 取得している
  6. 不要で大きなデータの取得例 記事一覧 1. Laravelカンファレンス登壇 2. 失敗から学ぶRDBの正しい歩き ︙ 1 2 3

    4 5 … 次へ データ SELECT ブログid,タイトル FROM 記事 ORDER BY id LIMIT 10 OFFSET 1; ブログid タイトル クエリの結果イメージ 不要なデータを削除して小さく
  7. N+1問題 foreach ($blogs as $id => $blog) { echo $blog->get();

    } もしget()の度にSQLが発行されたら?
  8. B+Tree INDEXの仕組み WHERE user_id = 4000 ~5000 ~10000 ~2500 ~5000

    ~7500 ~10000 索引ブロックヘッダ user_id = 2501 (ブロックID,行ID)=(100,1) user_id = 2502 (ブロックID,行ID)=(100,2) user_id = 4000 (ブロックID,行ID)=(200,10) : user_id = 4001 (ブロックID,行ID)=(201,1) user_id = 5000 (ブロックID,行ID)=(300,5) : 201番 ブロック 199番 ブロック 200番 ブロック 表データ 10 9
  9. 都道府県 会員 FULL OUTER JOIN 都道府県 会員 LEFT OUTER JOIN

    都道府県 会員 RIGHT OUTER JOIN 都道府県 会員 INNER JOIN
  10. RDBMS Model フレームワーク View 情報をやり取りする Modelが事実を加工し、 情報に変更する 事実をやり取りする SQLでやり取りする プログラミング言語

    でやり取りする ORM リレーショナルモデルをプログラミング言語が 扱うオブジェクトモデルに変換する またはその逆を行う
  11. RDBMS View 会員ページ 会員テーブル 会員サービス 会員データ Model ORM SQL 会員リポジトリ

    サービスに必要な ビジネスロジック キャッシュ ストレージ フレームワーク データクラスはサービスが必要な会員のデー タを取り出し、加工する。 場合によってはキャッシュから取り出したり、 RDBMSから取り出したりする リポジトリクラスはデータのCRUD部分だけを 担う。 ORM経由でもSQLでもサービスクラスからは 関係ない