Categories: 勉強会

#jpoug DBをリファクタリングしよう、DBとアプリの架け橋 DBFlute@JPOUG> SET EVENTS 20151017のまとめレポ

Oracleの様々な話題を扱うJPOUG> SET EVENTS 20151017というイベントに出てきたのでそのまとめ。

今回はDBをリファクタリングしよう、DBとアプリの架け橋 DBFluteというセッションのレポートです。

他のセッションは以下よりどうぞ。

Oracleの様々な話題を扱うJPOUG> SET EVENTS 20151017というイベントに出てきたのでそのまとめ。今回は障害とオペミスに備える! Oracle Databaseのバックアップを考えようというセッションのレポートです。Oracleで使うバックアップとリストアのお話になります。資料は後ほどアップされるらしいのでアップされ次第にこちらも更新します。他のセッションは以下よりどうぞ。#jpoug ハイパフォーマンスを実現する設計方法とSQLチューニング実践講座@JPOUG> SET EVENTS 20151017のまとめレポ#jpoug DBをリファクタリングしよう、DBと...
#jpoug 「障害とオペミスに備える! Oracle Databaseのバックアップを考えよう」 JP... - もぐめぽろぐ
Oracleの様々な話題を扱うJPOUG> SET EVENTS 20151017というイベントに出てきたのでそのまとめ。今回はハイパフォーマンスを実現する設計方法とSQLチューニング実践講座というセッションのレポートです。SQLチューニング入門の方必見です!他のセッションは以下よりどうぞ。#jpoug 「障害とオペミスに備える! Oracle Databaseのバックアップを考えよう」 JPOUG> SET EVENTS 20151017のまとめレポ#jpoug DBをリファクタリングしよう、DBとアプリの架け橋 DBFlute@JPOUG> SET EVENTS 20151017のまとめレポ#jpoug 5つのoracleに...
#jpoug ハイパフォーマンスを実現する設計方法とSQLチューニング実践講座@JPOUG&gt... - もぐめぽろぐ
Oracleの様々な話題を扱うJPOUG> SET EVENTS 20151017というイベントに出てきたのでそのまとめ。今回は集セッションと称した数々のLTをまとめました他のセッションは以下よりどうぞ。#jpoug 「障害とオペミスに備える! Oracle Databaseのバックアップを考えよう」 JPOUG> SET EVENTS 20151017のまとめレポ#jpoug DBをリファクタリングしよう、DBとアプリの架け橋 DBFlute@JPOUG> SET EVENTS 20151017のまとめレポ#jpoug 5つのoracleに関するLTが行われた集セッション@JPOUG> SET EVENTS 20151017のまとめレポ#jpoug DBエン...
#jpoug 5つのoracleに関するLTが行われた集セッション@JPOUG> SET EVENTS 20151... - もぐめぽろぐ
Oracleの様々な話題を扱うJPOUG> SET EVENTS 20151017というイベントに出てきたのでそのまとめ。今回は最後のセッションで、テーマを投げかけてそれに対して参加者が各々の意見を述べていくというセッションでした。他のセッションは以下よりどうぞ。#jpoug 「障害とオペミスに備える! Oracle Databaseのバックアップを考えよう」 JPOUG> SET EVENTS 20151017のまとめレポ#jpoug ハイパフォーマンスを実現する設計方法とSQLチューニング実践講座@JPOUG> SET EVENTS 20151017のまとめレポ#jpoug DBをリファクタリングしよう、D...
#jpoug DBエンジニアのスキルの現実と伸ばし方@JPOUG> SET EVENTS 20151017のま... - もぐめぽろぐ

DBをリファクタリングしよう、DBとアプリの架け橋 DBFlute

  • DBとアプリをつなぐ部分の最適化もあるのでは
  • アプリはアプリで最適化、DBはDBで最適化しているが、それを融合すれば新しい最適化されるのでは

DBFluteとは

  • O/Rマッパーで、DB管理支援ツール
  • 特徴はDB変更に強い
  • B2Cなどのサービス開発しているところがターゲット
  • DB設計と実装の同時開発ができます

ギャップその1 DB設計の意図が伝わらない

  • DBの定義がわからないことで、DB設計の意図も伝わりにくいという問題

DBFluteはDBを伝える

  • 実際のテーブルからテーブル定義書を自動生成します(SchemaHTML)
    • 区分値も定義をしておけばドキュメントが自動生成される

  • DB定義はJavaDocコメントに。
    • プログラムを書いてる途中にjavadocからテーブルの特徴がわかるようになる

ギャップその2 DB変更される

  • 気づいたらDB変わって落ちて影響範囲ありすぎてデグレする問題
    • アプリがSQLをかいていると中々変えれないので継ぎ接ぎのようなDB設計になってしまう
  • ローカル開発用DBがすごい古い問題

DBFluteはDB変更に強い

  • 会員を検索して並べるといったとき。
    • プログラムからはO/Rマッパーで読み込みができる
    • DBの構造がそのままクラスになって使える
    • このクラスは自動生成されるので、DBが変わったら自動生成し直す
    • DB変更があるとコンパイルエラーになるので修正箇所がわかりやすくなり、DB変更検知ができる
  • SQLのコメントのように書くことができるのでコードをそのままコピペしてSQLを試すことができる
  • アプリに存在するSQLを全部実行するツールもある
    • CIで回しておけば落ちるSQLがコミットされていたら検知することもできる

  • DBAの人もDB変更の影響規模を探りやすい
    • さきほどのツールを叩くだけで影響範囲を探ることができる

ギャップその3 DB変更がアプリに伝わらない

  • 何が変わったのかわからず放置してしまう

DBFluteはDB変更を伝えることができる

  • 履歴を自動出力することができる
    • ストアドプロシージャの変更も見ることもできる

ギャップその4 アプリがぐるぐる回す

  • 1回のリクエストで300回のSQLがあった際に、1個1個のSQLが早いとDB側では調整できない
    • フレームワークのLazyLoad機能によって上記現象になってしまうことがある

DBFluteは明文主義

  • 要望としてLazyLoadを要求されたことがあるが、LazyLoadでパフォーマンスが悪くなった経験があるので導入はしていない
  • SQLの発行回数をログにだす機能があります
    • 発行しすぎ警告のログが本番でも出ます
    • しかしあえて発行し過ぎを許容するのなら制限を解除する仕組みもあります
    • ぐるぐる系を撲滅したいのではなく、ぐるぐる系を管理したい!!
  • Webフレームワークとの連携も大切
  • SQLをソースにべたっとかけばぐるぐるが消えるのは間違い
    • LazyLoadしなくてSQLを組み立てるツールのほうが対処しやすい

ギャップその5 本番とスキーマが違う

  • おちた -> 調べる -> 本番DB違う
    • alter書いた-> index書き忘れた -> 実行し忘れた

DBFluteは差分大好き

  • AlterCheckでAlter文の整合性をチェックする
    • 前のDB + 差分DDL = 最新のフルDDLになるはず
  • SchemaSyncCheckで2つのDBの差分をとることができる

ギャップその6 パフォーマンス考慮お願い

DBFluteはSQLを大切にする

  • 発行されるSQLは徹底的に綺麗にフォーマットしてログで確認しやすくしている
  • SQLの実行時間と結果件数をログに出す
  • どこからよばれたSQLかをログに出す
  • SQL自身にアプリのクラスも埋め込んでいるのでDB側でSQLを抽出してもどこのSQLかすぐわかる
  • update文は無駄な事前検索などはしないようにしている

まとめ

  • RDBを強く意識させるO/RマッパーにすることでアプリやさんのDBの変化に敏感になる
    • DBの最適化をあてはめるにはアプリ屋と連携する必要がある

@mogmetの所感

O/Rマッパーは僕もあまり使いたくない派の人でしたが、このO/RマッパーはDBもわかってる方が作られているので非常にDBにも優しそうなライブラリだなと感じました。

うまく使えば障害検知や対処も早く済む感じもしますね!

mogmet

View Comments