名言生まれる!
タイトルにもある大主キーという単語がtwitterのTLに一瞬溢れました。
後日もことあるごとに大主キーという人が続出。
もうこれは今年の流行語対象 (in MySQL)といっても過言ではありません。
MySQL Casual Talksとは?
もっと深く浅く、広く狭くMySQLを使っていこうという趣旨のイベントです。 多方面から多様なMySQLの使い方、運用、TipsなどなどのTalkを集めたいと思っております。
https://mysql-casual.connpass.com/event/131551/
というイベントの趣旨の通りvol. 11 でも非常に個性的かつDeepな話が繰り広げられました。
togetter
tmtmsさんがまとめたこちらをどうぞ
発表者 | 内容 | 時間 | 資料URL |
---|---|---|---|
TBD | オープニング | 5分くらい | - |
do_aki | TritonnからElasticSearchへの移行話 | 30分くらい | https://www.slideshare.net/do_aki/tritonn-elasticsearch |
awache | DBRE(Database Reliability Engineering) 始めました ~ Make it visible / No Ops, More Code ~ |
30分くらい | https://speakerdeck.com/_awache/no-ops-more-code |
tom__bo | テーブル定義から見積もるストレージサイズと8.0以降のベンチマーク自動化について | 20分くらい | https://speakerdeck.com/tombo/about-table-size-estimator |
t_kyt | オンプレMySQLをRDSにして解決したこと/しなかったこと(仮) | 15分か20分くらい | |
lhfukamachi | TBD | 10分くらい | https://www.slideshare.net/hidemifukamachi/sql-require-primarykey |
keny_lala | TBD | 5~10分くらい | https://www.slideshare.net/kenken0807/mysql-149112359 |
tmtms | MySQLと令和 | 10分くらい | https://speakerdeck.com/tmtms/mysql-on-reiwa |
TritonnからElasticSearchへの移行話
do_akiさんによる全文検索のお話。
す、すみません。にわかなMySQLerなんでTritonn もSennaも初耳です…。
このTritonn、2009年で開発が止まっており、脆弱性等を考えるとMySQLも5.0から移行しなくてはならず脱Tritonnをする必要が出たことがきっかけらしい。
ここで移行案を色々検討されたところはTritonnに限らず全文検索を使う人には本当に参考になる話。
https://www.slideshare.net/do_aki/tritonn-elasticsearch#10
Elasticsearchを採用されるが、そこでも試行錯誤しているところもやはり参考になる。
DBRE(Database Reliability Engineering) 始めました ~ Make it visible / No Ops, More Code ~
会場を貸してくれたBizreachの_awacheさんのトーク。
「DBREとは何ぞや?」を数か月前に教えてくれたその人の話ということで参加前から非常に楽しみにしてました。
DBREとは、については
を読んだほうが確実なのですが、二つを読んだうえでの自分のいい加減な理解では 「DBを使って開発の手助けをするスペシャリスト」 です。
DBAとの違いがややこしいというか、今までのDBAはDBRE的なこともやってる場合が多いんだと思っていて、
- DBAはデータベースを守るために尽力する(セキュリティ、バックアップ・リストア(本番)、レプリケーション、HA設定等)のに対し、
- DBREはバックアップを開発機に利用するためのパイプを作ったり、そのままでは使えない場合はマスキングが必要なのでその機構を作ったりするイメージ。
まあ、DB大好きな人はどっちの素養も大抵持ってるとは思うんですが、DBAが僧侶、DBREが戦士・魔法使い的な感じでしょうかね?(どっちもやってる人は勇者ですねw)
資料を見るとわかりますが、DBREの存在意義として 3つの非機能要件の共通化 を行い、それを各事業へ提供することで会社のMissionとVisionを具現化しようとしています。
3つの非機能要件の共通化とは
- Provisioning(DBのパラメータセッティング、ユーザ設計等)
- Monitoring(定量モニタリング⇒人材の横断的な移動を可能に)
- Backup(開発環境の構築、定期的バックアップ、マスキングによる安全な開発)
なるほど、DBREとは安心してDBを使えるように積極的に活動することだな!(雑な理解)
そして面白いのはBizreach社のDBREは守備(結局DBA的なことも全部やってる)時もやはりオフェンシブで、例えば
- リストア時に監査ログを全出力
- リストアをする時点でランダムパスワード
- 必要な処理が終わったらインスタンスもスナップショット(バックアップファイル)も全て削除
と言った守備的なところもイケイケ。
- ダンプもパラレル処理(テーブル単位でダンプする)
とか、
- 事業側にマスキングルールを決めさせて、そのルールとなる設定ファイルをcommitしてもらって、
- 欲しい形でデータをTSV形式で作る仕組みを作った。
- これにより責任範囲を明確にして自分たちを守る
とか、
かっこよすぎます!
少しマネさせてもらいます。
テーブル定義から見積もるストレージサイズと8.0以降のベンチマーク自動化について
今回のトークの中で一番みんなが楽しんだのがtom__boさんの話だったと思うw
2年目の子がMySQLのパーサー作るという偉業にチャレンジするもんだから、おじさんたちの目はキラキラしちゃって、見えないはずのマサカリが具現化してた気すらしましたw
テーブルサイズを見積もるためにここまでやろうということすら思わない凡人の自分にはtom__boさんは眩しすぎて、
「ぜひ、うちの会社に来ないか?」(代わりに俺がリストラされるだろうけど)
オンプレMySQLをRDSにして解決したこと/しなかったこと(仮)
t_kytさんのこの話はスライドが上がってないんですが、内容は結構濃くて、メモを後述しておきますが要するにMySQLのことというかDBすらあんまり知らなかったけど、1年間ひたすらバージョンアップ等を繰り返して詳しくなっちゃいました!というもの。
MySQL4.xをRDSで上げるのにまず5.6まで持っていかなければいけないので、その色々な苦労をDBあまり知らない人が悪戦苦闘しながらすることは話としては参考になります。
ここからはLT
Sql require primary_keyを使って主キーを必須にさせる
lhfukamachiさんのLT。
このLTで冒頭の名言が生まれました。
https://www.slideshare.net/hidemifukamachi/sql-require-primarykey#4
スライドがちょっとyokuさんの影響受けてるのはさすがw
MySQLのリアルタイムモニタリングツールを作った話
keny_lalaさんのモニタリングツールの話。
Go製のMySQLのリアルタイムモニタリングツールですが、最後に
「これって需要あります?」
とあったんですが、
めっちゃほしいです!
MySQLと令和
最後の締めはACEのtmtmsさんの文字コードのお話。
これについては既に先日のOracleで聴いてたので知ってはいましたがやはり濃いなぁ…。
まとめ
MySQL Casual Talks、2回目の参加(前回はVol.10)でしたが、今回も非常に面白かったです。
特に@_awacheさんの話は今後の自分の仕事の方向にも影響を与えてくれたいいお話でした。
あとは若い人たちが本当に活気というか才能があって、羨ましいというか頑張らねばという気持ちになりました。
yoku0825さんの幻のLT聞けなかったのはちょっぴり残念でした。
最後に
開場・飲食物を提供してくれたBizreach社と運営を手伝ってくださってた社員の方々と@_awacheさん、 トークしていただいた皆様、 開催してくれた管理人のお二人、 ありがとうございました。
Vol.12も楽しみにしています。