2019年1月11日金曜日

PHPerKaigi2019 のCfPに5本のMySQLトークを出しました!

TL;DR


それぞれ完全新作なので「本当に大丈夫?」感が否み切れないアレとなっておりますが、自分用のメモを兼ねて概要を書いておきます。
  • 障害対応の勘所
    • まずはアプリケーションのエラーログを見ましょう
    • エラーログと /var/log/messages を見ましょう
    • スローログと /var/log/sa あたりを見ましょう
    • 初動を加速できるような情報を残しておきましょう
    • パラメーターは安全弁(なこともある)
  • 夢見る冗長構成
    • MySQL InnoDB Cluster と他のHAソリューションの違い
    • キモはMySQL Routerを通してInnoDB Cluster側の状態をアプリケーションが気にしなくていいこと(それ、 mikasafabric for MySQL でもできるよ)
    • 逆にMySQL Routerに隠蔽されるから面倒なこと(それ mikasafa略)
    • PXCとかNDBCLUSTERとの違いはしゃらっと
    • 吊るしのMySQLの方がマッチするケース、マルチマスターで幸せになれるケース
  • ログDB
    • 「定期的にダンプしてS3にでも放り込むのが一番幸せになるんじゃ?」って話
    • トランザクションで保護されるメリットはある
    • SQLが使えるメリットはS3 SELECTの登場で多少変わってきている
      • これを活かせば、メモリーにもストレージにもお財布にも優しくなる
      • S3 SELECTが使えなくても、都度展開とか何ならgrepとかさ…
    • ログなので、エンドユーザートラフィックで参照されることはない、っていうケースを想定
      • この前提が無い場合はRDBMSもまあまあ悪くない選択なのでは?
  • 大量レコード vs ORM
    • 100万行のフェッチ、DBMSとしては大したことないけど、アプリケーションは100万要素の行オブジェクトを全生成するのつらくない?
      • というかつらくて爆死していた
    • GROUP BY, Window関数, サブクエリーあたりを使って、DBMS内部で何とかできるものは何とかすればいいのでは?
    • やりすぎるとSQLおじさんになるので見極めがきっと大事
  • ユニットテスト
    • CIが薄いplackをキック, コンテナ起動してportを返す, テストデータ挿入, ユニットテスト, 薄いplackでコンテナを破棄させる, 終了
    • DBのMock代わり(?)にdockerコンテナを使ってみた話です
    • ひねったのは薄いplackがPOSTでスキーマを作成するSQLを受け取って、それを流してからポート番号を返すところ(えっ)
それでは、(採択されれば) PHPerKaigi2019 でお待ちしております!







0 件のコメント :

コメントを投稿