♡♡♡主キー大主キー♡♡♡（MySQL Casual Talks vol.11）
名言生まれる！
タイトルにもある大主キーという単語が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が戦士・魔法使い的な感じでしょうかね？(どっちもやってる人は勇者ですねｗ)
資料を見るとわかりますが、DBREの存在意義として ３つの非機能要件の共通化 を行い、それを各事業へ提供することで会社のMissionとVisionを具現化しようとしています。
３つの非機能要件の共通化とは
- Provisioning(DBのパラメータセッティング、ユーザ設計等)
- Monitoring(定量モニタリング⇒人材の横断的な移動を可能に)
- Backup(開発環境の構築、定期的バックアップ、マスキングによる安全な開発)
なるほど、DBREとは安心してDBを使えるように積極的に活動することだな！(雑な理解)
そして面白いのはBizreach社のDBREは守備(結局DBA的なことも全部やってる)時もやはりオフェンシブで、例えば
- リストア時に監査ログを全出力
- リストアをする時点でランダムパスワード
- 必要な処理が終わったらインスタンスもスナップショット(バックアップファイル)も全て削除
と言った守備的なところもイケイケ。
- ダンプもパラレル処理(テーブル単位でダンプする)
とか、
- 事業側にマスキングルールを決めさせて、そのルールとなる設定ファイルをcommitしてもらって、
- 欲しい形でデータをTSV形式で作る仕組みを作った。
- これにより責任範囲を明確にして自分たちを守る
とか、
かっこよすぎます！
少しマネさせてもらいます。
テーブル定義から見積もるストレージサイズと8.0以降のベンチマーク自動化について
今回のトークの中で一番みんなが楽しんだのがtom__boさんの話だったと思うｗ
2年目の子がMySQLのパーサー作るという偉業にチャレンジするもんだから、おじさんたちの目はキラキラしちゃって、見えないはずのマサカリが具現化してた気すらしましたｗ
テーブルサイズを見積もるためにここまでやろうということすら思わない凡人の自分には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さんの影響受けてるのはさすがｗ
MySQLのリアルタイムモニタリングツールを作った話
keny_lalaさんのモニタリングツールの話。
Go製のMySQLのリアルタイムモニタリングツールですが、最後に
「これって需要あります？」
とあったんですが、
めっちゃほしいです！
MySQLと令和
最後の締めはACEのtmtmsさんの文字コードのお話。
これについては既に先日のOracleで聴いてたので知ってはいましたがやはり濃いなぁ…。
まとめ
MySQL Casual Talks、２回目の参加(前回はVol.10)でしたが、今回も非常に面白かったです。
特に@_awacheさんの話は今後の自分の仕事の方向にも影響を与えてくれたいいお話でした。
あとは若い人たちが本当に活気というか才能があって、羨ましいというか頑張らねばという気持ちになりました。
yoku0825さんの幻のLT聞けなかったのはちょっぴり残念でした。
最後に
開場・飲食物を提供してくれたBizreach社と運営を手伝ってくださってた社員の方々と@_awacheさん、 トークしていただいた皆様、 開催してくれた管理人のお二人、 ありがとうございました。
Vol.12も楽しみにしています。
AWS Loft TokyoのMiddlewares Deep Talks行ってきました
これもあんまりまとめる感じでは無いですが、とりあえず後から追記できる程度には雑記します。
iddlewares Deep Talks（AWS Loft Tokyo）
Amazonさんがありがたいことにミドルウェア関連の話≒DB系の話やってくれたんで、目黒のビルに行ってきた。
ぼくらが8.0に至ったみちのり（踏破）
https://speakerdeck.com/yoku0825/bokuraga8-dot-0nizhi-tutamitifalseri-ta-po
遅刻したので半分聞けず…(´;ω;｀)
道に迷ったり、3階のエレベーター乗り場で別の会社の人に違う場所に案内されたり、入り口で登録したはずのメールアドレスが無いよーと言われたり…。
(着いたときは汗だく…)
でも、こないだのOracle Code2019とその辺は話が重複してたので結果オーライ。
後半の話は実際にMySQL8使っての今のところの感想ということで、とても興味深いものだった。
(スライド見るともしかすると微妙そうに見えちゃうかもしれないけど、新規に立てるならMySQL8.0は超おススメだと俺も思う)
PostgreSQL 12の話
https://www.slideshare.net/masahikosawada98/postgresql-12
一番気になったのはパーティションの話。
プルーニングでパフォーマンス超上がったとのこと。
休憩時間に
気になったんで間の休憩時間に澤田さん捕まえて聞いてみたら、パーティションした場合別のところ(複数あるらしい)でメモリ食うので数千レベルのテーブルで使うのはまだ危険とのこと。
(そこにYahoo! の三谷さんも来たので巻き込んで3人でMySQLとPostgreSQLの話で「へー」「ほー」と言い合う) (三谷さん、ACEポイントは6月かららしい！5月はタダ働き…。mjsk)
そのあと、
- MySQLの良さはクエリからコストが予想できること。
という温かいMySQLとPostgreSQLの交流会がTwitter上で行われた。(sh2さんのスライド、メッチャためになった！)
PostgreSQLのパーティションについては13で更に改良する(澤田さんも参加)ので、お楽しみに！とのこと。(12がまだRC出てないのにｗ)
What's new in Slastic Stack 7.0?
https://noti.st/johtani/psVhfT/whats-new-in-elastic-stack-7-1
- Elasticsearchのインデックスはお前(RDB使い)のインデックスじゃない
- 今のElastic Searchは本当に何もしなくてもいい感じの設定になってる
- 可用性めっちゃ高い
- むしろ設定触るな
- seed node触るな
- なんかあったらログを見ろ！
- PainlessでPainfull
というメッセージが印象に残った。
(ちなみに、p37のnumber_indicesってのはnumber_of_shardsの間違い)
Cassandra vs ScyllaDB 性能比較
資料がまだアップされてないのでメモを乗せとく。
資料がアップされました→こちら
要するにCassandra使うんなら、ScyllaDBスゲー早いよおススメ、Yahoo!では切り替え始めてるって話。
Yahoo! JapanでのCassandra
Cassandraの限界
特定サイズを超えたデータにアクセスが集中すると、クラスタが不安定になる
Cassandra VS ScyllaDB
- 99.9％読み書きレイテンシ
- Cassandraは早い段階で跳ね上がり
- ScyllaDBは2倍程度のPF
- IO waitがScyllaDBではほとんどでない
- ScyllaDBはSATA3の性能限界に到達したが、Cassandraは使いきれず
https://www.scylladb.com/2019/05/22/yahoo-japan-using-scylla-and-cassandra-at-scale/
S3 整合性モデルと Hadoop/Spark の話
https://www.slideshare.net/ssuserca76a5/s3-hadoopspark
分かったこと。
『俺はまだS3を知らない』
でも、S3の使い方ちょっと知れて雰囲気だけ感じました。 S3にログとか置いて遊ぼうかな。
Introducing Algolia with Demo
https://speakerdeck.com/shinodogg/introducing-algolia-with-demo
すみません、俺本当に何もわからないおバカさんです。 俺には難しかったです…。
Middlewares Deep Talks 楽しかった！
軽食(サンドイッチ)もドリンク(俺はコーラばっかりだけど、みんなはビール)も旨かった。
スピーカーの方々の軽妙なトークに笑い声も何度も上がり、壇上のスピーカーと聞いてる人たちとのやり取りなんかもあって和気あいあいとしてました。
最後の懇親会までいたかったんですが、妻のご機嫌も気にしてたので昨日は早々に帰宅。
開催者の皆様、場所と食事を提供してくださったAmazon様、そしてスピーカーの皆様
ありがとうございました
次回もあればぜひ行きたいです！
Oracle Code 2019最高でした！ありがとうございました！
※勢いで書いて、まとめようとしてなかったので読みにくいと思います。(伝えたいことはタイトルの一行)
今年は参加できたOracle Code。
https://www.oracle.co.jp/events/code/2019/
毎年この時期なんやかんやあったんだけど、今年は時間取れたし、聞きたい話も盛りだくさんだったので。
場所
家から近いので自転車で行っちゃいました。(良かったのかな？)
あの辺、何もないので自転車があって本当に助かった。
(お昼食べずに行ったから、20分の休憩時間で何か食べようと思ったときコンビニが近くにないのでセッションを無駄にしかねない)
以下セッションについての感想等
Oracle ACEが語る MySQL 8
資料はこちら
Oracle ACE から見た、MySQL 8の便利な新機能、ハマりどころを紹介します！ ・降順インデックスによるSQLチューニング方法 ・InnoDB Cluster / Group Replication における一貫性のコントロール方法とその使い分け ・スロークエリログの拡張 ・MySQL 8のクエリキャッシュ・・・など アプリケーション開発者の方にとって有益な機能を紹介予定です。 【講演者紹介】 ヤフー株式会社 サービスプラットフォーム本部 データベース部 MySQL 三谷 智史 氏 Yahoo JAPAN! におけるRDBの第一人者として活動。日本MySQLユーザ会のメンバーとしてコミュニティ活動にも従事。
MySQL ACEとして初の登壇。
しかし登壇慣れしてるからか緊張は見られない。
裏でやってた @t_wada さんの「過去を知り、未来に備える - 技術選定の審美眼2019」も聞きたかったけど、体は一つだし、何より最初のセッションはMySQLの話が聞きたかったｗ
三谷さん(右)と目次
今回のは8.0.15までの話らしく、CHECK制約の話はここにはない(残念！)
三谷 さんのセッション、すべて良かったんですが特に良かったのが、
これ、凄いです。本当によく調べたなあ、と。
最後にyoku0825さんから
「実際導入するとして、consistencyってどれを選びます？」
という質問があり(俺も質問出なかったら聞こうと思ってたのでありがたす！)、
三谷さん：「EVENTUALかなぁ……特定の、古いデータを読みたくない処理だけ、セッション単位でConsistencyを設定するように案内するかなあと思います」
という回答。この辺は地雷キュアことyoku0825さんか運用キュアの三谷さんにおススメパターンを導いてほしい！(お前がやれ)
まあ、MySQLっぽいのはEVENTUALなんだけど、BEFORE_ON_PRIMARY_FAILOVERとかBEFORE_AND_AFTERあたりも場合によっては使われそうな気がするなー、と個人的には思いました。
(AFTERはキツそうなんだが、デフォじゃないんだ？と今までのMySQLの感じからすると意外？)
- 上記Consistency Levelのデモ動画が超分かりやすかった
デモ動画、あった場合と無い場合で上のまとめの理解が全然違う。 いずれ公開されるらしいんですが、早く見たい！
Kubernetesで実現する運用自動化の新しいアプローチとは
Kubernetesというと、小規模コンテナ群で構成されたマイクロサービスのための基盤というイメージをお持ちかもしれません。しかし、Kubernetesが元来備えている拡張性と、コンテナ自動管理機能を利用することによって、Enterpriseの重量級ワークロードでも運用の自動化・効率化の恩恵を受けることが可能です。 このセッションでは、そんなKubernetesの可能性を活かした、Enterpriseでのコンテナ活用の手法について、デモを交えて解説致します。 【講演者紹介】 日本オラクル株式会社 ソリューションエンジニアリング統括 クラウドプラットフォーム本部 茂(しげる) こと 新卒で日本オラクルに入社後、Oracle Databaseのプリセールスエンジニアを経て、現在はアプリケーション開発を支援するクラウドサービスの提案やContainer、KubernetesといったCloud Nativeテクノロジーの活用を日本のお客様に広めるため日々模索し奔走しています。
この時間は本当にどれを選ぶか迷った。
ここを選んだのは
というからであった。
ちなみに資料はこちら
helmでワンライナーで立っちゃうMySQL InnoDB Clusterとかもうヤバい。
ちなみにk8sでコンテナがデプロイされるまでの話は本人曰くこの資料をデフォルメしたものとのこと。
MySQL Operator使いてえ！試してえ！って勝手にほざいてましたが、その前提となる話のKubernetes Operatorのことが知れて本当に聞けて良かった！
茂 こと(@cotoc)さん、スゲーっす！
世界はグラフ構造でできている？ 〜 超高速クエリから機械学習まで
資料はこちら
データベースの中でもとりわけ柔軟で直感的なデータの管理を実現するため、グラフ構造を用いた「グラフ・データベース」の発展が長らく期待されてきました。ここ最近になって、ユーザー行動などの関係性に着目した分析のニーズが高まり、新たなクエリ言語の標準化の取り組みが活発化し、更にはグラフそのものを学習するという AI 技術が生まれ、 金融不正検知から製造における部品表に至るあらゆる分野で、グラフというビッグデータを活用する機が熟しつつあります。このセッションでは「世界」を記述するグラフの検索から機械学習まで、オラクルの最新のデータベース技術を用いて、デモを交えながら解説します。 【講演者紹介】 Oracle Corporation Thailand Solutions Consultant, Big Data and Analytics 山中 遼太 オラクルのコンサルティング部門にてデータベースのエンジニアとして従事した後、退職してバイオインフォマティクスとゲノム科学の学位を取得。その後、オラクルに復帰し、機械学習やグラフ分析の製品担当として、ビッグデータ活用ソリューションの提案をリードしている。2018年よりバンコクに在住。
このセッション直前に食事買いに出かけたため、セッション開始直前に入ることになり、席が埋まってて予約したにもかかわらず立ち見。
さらにはモニターの故障により、セッションが10分程度中断するアクシデント。
でも山中さん、それにも明るい感じで、「アハハ、どうしましょう？」と言いながら機器トラブルを笑いに変える大胆さとトークのうまさ。それでいてスタッフへの気遣いもしてて、この人マジ素敵やな！と男ながらに惚れてしまいました。
トラブル解消後、とてつもないスピードでグラフDBについて説明してましたが、
(こういうのって自社でも使えそうだなー)
グラフDB、少しずつ勉強してたけどもう少し触る機会を自分に作ったほうがいいかも。
GraphPipe and TensorFlow, Serverless and Neural Networks with Fn Project
GraphPipeとは、Oracleがオープンソースとして公開する、機械学習およびディープラーニングのモデルのデプロイを単純化し標準化するツールです。このセッションでは、GraphPipe概要、GraphPipeおよびTensorFlowを使用した学習済みモデルのデプロイと推論の実装についてご紹介します。さらに、OSSのサーバーレスプラットフォームであるFn Projectと組み合わせたデプロイについてもご紹介予定です。 【講演者紹介：ABeam Consulting Ltd. 澤田 哲史 氏】 SIerを経て、現在アビームコンサルティングに所属。 アプリケーション開発からインフラ領域まで幅広いレイヤーに精通したアーキテクトとして、 様々な領域の基幹システム構築や、エンタープライズITインフラ整備に数多く従事。 企業のDigital Transformationを支える、未来のITアーキテクチャの在り方を模索すべく、活動中。 【講演者紹介：日本オラクル株式会社 河内 美樹】 日本オラクル クラウド・プラットフォーム本部で、データ分析・機械学習・Deep Learningに関わる製品とお客様への提案活動を担当。 データ蓄積については、特にOracle DatabaseとHadoopの世界を繋ぐBig Data SQLや、Oracle Exadataの性能検証などを過去に担当していた。日本オラクルのBig Data & Data Integration BLOGで情報発信を行っている。
今回、一番自分になじみのない話をここでは聞いてみた。
こういう複合セッション系で一つは全く知らない話を聞きに行くと、後で「あぁ、そういえば！」となることが多いので面白い。
このセッションの資料については https://blogs.oracle.com/bigdata-dataintegration-jp/graphpipe_intro にすべてアップされているという事前準備の良さ！(ありがたい)
- 機械学習って何？
- GraphPipeって何？
オジサンからすると凄いありがたいお話だった。
あと、もう一つオジサンにはたまらなかったのが、もう一人の登壇者 澤田 哲史さんのGundam Face 色塗りアプリケーションの話。
このソースがgithubにあるので、誰でも試せますｗ
https://github.com/scpepper69/ml-image-generator
ここがへんだよMySQL ここが凄いよMySQL
そして、メインディッシュ！これを聞かずには帰れない。
以下5人の資料がまとめてここに上がってる （それぞれのサイズが違うのでちょっと見づらい・・・）
それにしても豪華！
そのうち、Facebookの松信さん以外がすべて集まってMySQLについての思い出等を話してくれたのがこのセッション。
sh2さんのここがヘンだったよMySQL
さすがMySQLを4から触ってるだけあって、それは変だなと思いましたｗ
- CPUコア数を増やしても性能が上がらなかった > 5.5で改善
- バイナリログ形式のデフォルトがSTATEMENTだった > 5.7で改善
- トランザクションログの同期書き込みをサボっていた > 5.7で改善
結論：MySQL5.7以降良いですね
kamipoさんのMySQLとActive Recordの話
kamipoさんの資料だけ外だし
基本、sh2さんと同じで、変なところはなくなってる！って話なんですが、一番変なのは、Maintenance Releaseといいつつ、
- GROUP BY ... DESCの削除 8.0.13
- デフォルト式 8.0.13
- 関数インデックス 8.0.13
- LATERAL句 8.0.14
- CHECK制約 8.0.16
と全然メンテナンスじゃねー！というところだと。（ですよねー）
yoku0825さんのHUGっと！Oracle ACE(MySQL)
- すごいプリ〇ュア＝キュア松信さん
- InnoDBのプリ〇ュア＝キュアSH2さん
- Active Recordのプリ〇ュア＝キュアkamipoさん
- 運用のプリ〇ュア＝キュアmita2さん
- 文字化けのプリ〇ュア＝キュアとみたさん
- 地雷のプリ〇ュア＝キュアyoku0825さん
強いわ、このプリ〇ュア達ｗ
この人たちに加えて、Oracle ACEじゃないけどMySQLに関しては戦闘力53万みたいな人がまだまだいるので、
MySQLの未来は安泰！
ちなみに、「罠、トラウマとなるほどのものはMySQL8にはない」と話されてますが、
スライド見ると、十分に踏んでますね・・・(感謝の意)
三谷さんのここがヘンだよMySQL＆ここがスゴイよMySQL
データベースの一番重要な要素・・・Durability/耐久性
それに対し、
- 壊れるデータファイル（ver <= 5.1）
- クラッシュセーフでないスレーブ（ver <= 5.5）
- 非同期レプリケーション（ver <= 5.6）
- クラッシュセーフでないDDL（ver <= 5.7）
バージョンが上がるごとに良くなったね！（MySQL8.0最強）
とみたさんのMySQLと令和
https://speakerdeck.com/tmtms/mysql-and-reiwa
やはり文字化けのプリ〇ュアｗ
読むとわかりますが、マニアック！（でも面白い）
ちなみに合字の㋿と令和は明治〜平成までとは違って＝（イコール）じゃなくなってるそうです。
今回のセッションの資料
https://www.oracle.co.jp/campaign/code/2019/ に聞けなかったセッションの資料も上がってるんですが、どれも興味深い。
これらをすべて読んでたら、また積読が増える・・・。（でも読みたい）
今回の戦利品
タオルとMyNAクリアフォルダーと@hmatsu47さんによるMySQL 8.0の薄い本の物理本！
@hmatsu47さんありがとうございました！
Oracle Code2019 最高だった！
来年も行きたい！！
登壇した方々、お疲れさまでした。
DB設計したいNight #4 そーだいさんと失敗から学びながらDB設計したいnight参加してきました
募集内容
| 枠名 | 参加条件 |
|---|---|
| 通常参加枠 | 300円(会場払い) |
| 本購入枠 | 無料。但し本を持参する |
| 絶対来る枠 | 300円(会場払い) |
| ブログ枠 | 無料 |
最後のブログ枠って、参加報告ブログを書いて資料としてアップするってことかな？
とにかく、自分は本購入してる(フフフ、サインも入ってるぞ！)ので本購入枠で参加してきました。
スケジュール
開場
19時開場、19時半開始ということでなるべく早く行って良い席とろうと思ったが、当日定時で上がれず、 参加枠も本購入枠もまあまあ当日までいい感じで埋まってて、増席すらあったので
「これは微妙な席になっても仕方ないかも…」
と覚悟してましたが、まだ19時5分時点でそこまで混んでおらず、前から2列目の正面席を取れて自分的にはベストポジションでした。
(すでに@kaibaさん、@Nakunaruさん、@yuyasatさん、@bringer1092さん達が楽しそうに雑談されてましたが)
ゴザ席というなかなか初心者には 座りにくい 勇気のいる席があり、誰もそこには座れずｗ
あれはもしやるのであれば映画館形式の席の並べ方じゃなく、コロシアムというかスタジアムのようにメインの人を囲むような感じにしたほうが良かったのかなあ？なんて思ったりしました。
ちなみに会場はピクスタ株式会社から提供していただきました。ありがとうございました。
始めて来ましたが、とても綺麗なオフィスで羨ましいです。(うちも引越ししたい)
そーだいさん到着
19:25頃、本日のメインご登場。
本当に「ワタシ"ポスグレ"チョットデキル」 Tシャツが眩しいです。
イントロダクション
開場説明と今回の進め方について簡単にお話。
あとで懇親会で知ったが、過去の回とは今回の回の進め方全然違ったらしく、過去のやり方はお題があってそれに対してみんなでERDとか書きながら発表し合い、ゴールを探すやり方だったらしいけど、今回はお題の失敗談をいくつか用意しておき、それについてそーだいさんとNakunaruさんが答えていくというディスカッション形式でやりますよー、とのこと。
でも、イベントページの概要をもう一回よく見たら
迷えるDB設計初心者達のための勉強会です。 普段はハンズオン形式ですが、今回は そーだいさん と nakunaruさんのパネルディスカッション形式です。
って書いてあって、うん、なるほどｗ
一つ目のお悩み(お題①)
Kさんという匿名の方からのお悩みだそうでｗ
- 電話帳のような企業向けアプリのお話
- 支店、部署、人名のように絞り込みをする
- 支店番号は数値か昇順にしてほしい
- それなのに東京支店は30aと30bがあって文字列
- 対応として支店コードを36進数にした
型変換に悩んでいる様子
一つ目の悩みへの回答
- 支店名が入るマスターを作ればよかったのでは？
- テーブル追加で対応できる
- テクニックで逃げるのではなく、基本を大事に
といった回答がありました。
自分だったらどうしてただろう？
少なくとも36進数は思いつかないｗ
自分は正規化推進派(一回小さく、少なくとも第三正規化まではしておきたい)なので、おそらくテーブルを作って対応するだろうな、と思いました。
もちろん、それによりDBMSによっては結合回数が多くなって遅くなることも考えられるのですが、これはそーだいさんも言ってた通り、テーブルを合わせるのは分割するよりも簡単なので、その時は合体すればいいので、マスターテーブル化がベターなんだと思われます。
(そうすればあとはマスターみたいな情報なんだから、速度云々みたいな話になるんならAWSならS3みたいなところに入れといて、DB使わずにそこからキャッシュに入れるんでもいいんじゃとかもある)
二つ目のお悩み(お題②)
なんとこちらもKさんからのお悩みだそうでｗ
- 賃貸物件と売買物件の両方を扱うサービス
- 数多くの項目があるのだが、異なるのは一部
- 現在は全く別のテーブル
- 別のソースコードだが、処理はほぼ同じ
- だがそれぞれ別のサービスなので、テーブルは分割されていたほうが使い勝手はよさそう
- というわけでテーブル構造もSTI(単一テーブル継承)構造にした
- そうしたら賃貸されてるのに売買されているという変なデータができた
というお話。
二つ目の悩みへの回答
- 賃貸・売買物件を親にしてしまうのはどうか？
- その二つの親から共通テーブルが見える形にすれば
- そこで親テーブルのIDの排他を担保するためのCHECK制約(MySQLだと8.0.16から)を使う
- もしくは共通テーブルのIDを親が持つ
- この時、共通テーブルにフラグを持たせがちだが、１つのテーブルに複数のステータスや状態を持たせないほうがいい
- そうなるのなら別テーブルに分割
- 共通項目は本当に共通かはちゃんと考えたほうがいい
自分だったらどうしてただろう？
これ、うちも業種が同じなのでわかるんですが、基本的には元々設計した人がしっかりDB分かってる人だったんで既にそーだいさんが言ったようなことが自社のDBではなされててます。
それでも後から新規に作られるテーブルやカラムは上記のような基本を考えていないことがあるので、その辺に目を見張らせるのが今の自分の仕事だったりします。 (数が多すぎて見れてないこと多々ありますが・・・。)
まあ、Check制約については無い場合がMySQLの場合ほとんどだと思うので、API側にやらせるんでしょうね。
あとはJOINで速度が出ない場合はこの共通テーブルに色々入れていきたくなり、遅くなりがちになるので注意です。
三つ目のお悩み(お題③)
こちらはNさんからのお悩みだそうですｗ
KとかNとか、あれー、管理者さんのイニシャル…
- 元々はこんな感じだった
- 飲食店向け求人サイト
- 店舗テーブル
- 店舗情報、掲載期間、審査ステータス、編集ステータス
- 現行、エリア、路線、駅
- 店舗テーブルとJOINして検索
- 店舗ビュー
- 店舗テーブルと関連があるすべてのテーブルをJOINする
- パフォーマンスが悪い！
- というわけでなんでも取れるビューはダメだ、分割しよう！と考えた
- 画面上のブロックで必要なデータだけを取るビューを作成
- その結果ビュー同士の依存が4階層になり、ビューの数が200以上に
- どのビューを変更するとどこが壊れるかわからない！！！
- 開発速度が遅くなってしまった
三つ目の悩みへの回答
- サマリテーブルやマテリアライズドビューを作ろう
- キャッシュも使おう
- 更新頻度が少ないマスター系データはキャッシュに入れたり、S3にファイルを置いといてそこから見よう
- とはいえ、キャッシュ中毒の章(16章)はよく読んで使いましょう
- ビューの多段は絶対ダメ(2階層以上)
- ビューは1段構成(Not 多段)であれば作る順番は気にしなくて済む
- ビューでビューを作ったりすると、更新順序を守らないと古いキャッシュが残り、ビューのデータがおかしくなる
- 分けたものをくっつけるのは楽だけど、くっついたものを分けるのはツライ
- 論理設計を最初にちゃんとやって、細かく割ってから、とりあえず動かしてチューニングするのがいい
- ちなみにビューやマテビューを使いたくなったら、それは設計をミスってて、それをDBMSで直す飛び道具としてビューやMビューを考える
- あと、ビューの使いどころとしては、以下の３つがある
- テーブルを分けたいときに、その分割前の状態をビューにしておくパターン
- ビューに参照権限付与して、元のテーブルを見せない
- 設計が悪いパターンで変えづらいやつに対し、結合した結果を見せたビューを作る(前述のやつ)
自分だったらどうしてただろう？
まあ、やっぱり正規化して細かくテーブル分割して、見たかったらJOINしたり、パフォーマンス出ないなら結合テーブルっていうのでいいんじゃないかな？
ビューをそもそもアプリ側が吸収してくれるならそれで良くて、それがツライっていうんなら仕方なくビューを用意するって意識なので、それを多段にするってのは考えない。
MySQLここ２年半ほど触ってきて、思った以上にちゃんと作ったりちゃんとSQL組まないとすぐ遅くなるので(Oracleとは大違い)、その辺は全然意識が変わった。
それでもビューを多段にするのは20代で一回失敗してからOracleでもやらないようにしてるけど。
ライトな質問①
ここからはお悩みというか、質問タイム。 まずは、
不要になったカラムは消すか？
これに対してはいらないという判断がつきづらいので消せないという話が多かったけど、そういう人も要らないのが判ってたら消すんでしょ？と思いきやそうでもなかった。
怖いから念のため取っておくという人が結構いた。
OracleやMariaDBではinvisible columnができるから、そういうので試したらいいと思うし、インデックスでも同様の話があるのでそれも確認する方法を使って消せばいい。
ログテーブルって作ってる？
作ってる人はほとんどいなかった。
RDBに入れておくと便利だけど、そのメンテがめんどくさい。
不要になったログデータをS3などにファイル化して退避させてから削除する仕組みを作ればDBに入れとくのもありでは？という話。
懇親会
フード・ドリンク等の費用サポートのForkwell様ありがとうございました。
お酒飲めないんですが、コーラをたくさん飲みましたｗ
同じテーブルにいた人達が結構個性的で、その人たちとも交流できて面白かったです。
本当はそーだいさんや最近DBREという言葉を教えてくれた@_awacheさんとお話したかったんですが、あまり動き回るのもアレかな～、と思ってるうちに家族都合のタイムアップ。
次回は積極的に動こうかな？と思ってます。
あ、でも帰りにそーだいさんがぐーぜんエレベーターホールまで一緒になって、帰りに色々温かい言葉かけてくれたり、握手までしてもらったりしたし、
@_awacheさんからも
僕もご挨拶させていただきたかったので是非次回よろしくお願いしますmm
— _awache (@_awache) May 16, 2019
こんな優しい言葉かけてもらって、
行って良かったDB設計したいnight！でした。
Changes in MySQL 8.0.16 (2019-04-25, General Availability) を読む(1回目)
リリースノートを読んでみる
英語の勉強もかねてちょっとずつ読んでみる。
Account Management Notes
DROP ROLE権限について
> Previously, users who had the DROP ROLE privilege could use the DROP ROLE statement to drop locked or unlocked accounts. 以前は、DROP ROLE権限を持っていたユーザーはこのDROP ROLEステートメントを使用してロックまたはロックされていないアカウントを削除できました。 > Now, users who have the DROP ROLE privilege can use DROP ROLE only to drop accounts that are locked 現在、DROP ROLE 権限を持つユーザーは、ロックされているアカウントを削除するためだけに使用できます > (unlocked accounts are presumably user accounts used to log in to the server and not just as roles). （ロック解除されたアカウントは、おそらくロールとしてではなく、サーバーへのログインに使用されるユーザーアカウントです）。 > Users who have the CREATE USER privilege can use DROP ROLE to drop accounts that are locked or unlocked. CREATE USER権限を持つユーザーは、ロックされているまたはロックされていないアカウントを削除できます。
8.0.16からはDROP ROLE権限だとロックされているアカウントだけを削除できるように制限され、 それ以前のDROP ROLE権限と同じようにロックされていないユーザを削除するにはCREATE USER権限が必要ということですね。
ユーザーアカウントカテゴリ
> Several changes have been made to MySQL account-management capabilities: MySQLのアカウント管理機能にいくつかの変更が加えられました。 > MySQL now incorporates the concept of user account categories, with system and regular users distinguished according to whether they have the new SYSTEM_USER privilege: MySQLは現在、ユーザーアカウントカテゴリの概念を取り入れており、システムユーザーと一般ユーザーは新しいSYSTEM_USER権限を持っているかどうかによって区別されます 。 > System users are users who possess the SYSTEM_USER privilege. A system user can perform operations on both system and regular accounts. システムユーザーは、SYSTEM_USER権限を持つユーザーです 。システムユーザーは、システムアカウントと通常のアカウントの両方で操作を実行できます。 > Regular users are ordinary users who do not possess the SYSTEM_USER privilege. A regular user can perform operations on regular accounts, but not system accounts. 一般ユーザーは、SYSTEM_USER権限を持たない一般ユーザーです 。通常のユーザーは通常のアカウントに対して操作を実行できますが、システムアカウントに対しては実行できません。
とりあえず分けたということは分かるが、ここまでの説明だといまいち権限の差が見えにくい。
もう少し読み進める。
> Other operational implications of the SYSTEM_USER privilege: SYSTEM_USER権限の その他の運用上の影響 > A session that has the SYSTEM_USER privilege can be killed only by users who have the SYSTEM_USER privilege, in addition to any other required privileges. SYSTEM_USER権限 を持つセッションは、必要とされる権限に加え、SYSTEM_USER権限を持つユーザーだけが強制終了できます 。 > An account that has the SYSTEM_USER privilege can be specified as the DEFINER for a stored object only by users who have the SYSTEM_USER privilege, in addition to any other required privileges. SYSTEM_USER権限 を持つアカウントは、必要とされる権限に加え、SYSTEM_USER権限を持つユーザーによってのみストアドオブジェクトのDEFINERとして指定できます。 > A role that has the SYSTEM_USER privilege cannot be listed in the value of the mandatory_roles system variable. SYSTEM_USER権限 を持つ役割 は、mandatory_rolesシステム変数の値にリストすることはできません 。
mandatory_rolesってなんじゃ？と思う方もいると思う。(自分も使ったことないのでよくは知らない)
要するにサーバで必須のロールとして設定できるようになってる(8.0.2～)のだが、それにはSYSTEM_USERは入れられないよということっぽい。
あんまりちゃんと理解できていないものの、SYSTEM_USER権限は他のユーザ用権限とは一線を画しておく管理者ユーザ用にのみ与えるものってことでいいのかしら？
続きは後日。
【祝】MySQL8.0.16登場！MySQLはその先に向かう。
とうとう来ました、待望のバージョンが！
僕はdocker-composeで遊んでるのでYAMLに
mysql_8.0:
image: mysql:8.0.16
と書いて再起動しただけでできましたが、中の人が
— 🐬🍣🍻 (@RKajiyama) April 25, 2019
と教えてくれたリンク先にも上がっていますので、公式が8.0.16になるまではリンクのほうで試してみると良いかと思います。
(⇒4/25 21:30時点で確認したら公式にも上がってました)
(リリースノートも更新されてますね。) dev.mysql.com
さて、さっそく遊んでみよう
何はともあれCHECK制約を触ってみる
MySQL :: MySQL 8.0 Reference Manual :: 13.1.20.7 CHECK Constraints
に書かれているテーブルをそのまま使ってみる。
おお、とうとうMySQLにもCHECK制約が入ったんやなあ！
(ちなみに過去のバージョンはそもそもcreate tableできない)
ほかの機能も遊びたい
8.0.16の機能についてはhmatsu47さんの
を読みながらこれから遊んでみようかと思う。 (その前にyoku0825さんがガンガン濃厚な実験＋記事書いてくれそうな気はしてるけど)
追記（NOT ENFORCEDは誰がためにある）
↑これを見て、「なるほど？」
試す
挿入できたし、データも入ってる。
ちなみに間のところで見えてますが、
select * from information_schema.CHECK_CONSTRAINTS;
でCHECK制約一覧見れます。
NOT ENFORCED 使いたくなる場面が知りたいなあ。
『失敗から学ぶ RDBの正しい歩き方』発刊記念！そーだいさんから直接学ぶ会 に参加してきました
行ってきました
先日、『失敗から学ぶ RDBの正しい歩き方』発刊記念！そーだいさんから直接学ぶ会 に参加してきたのでそのレポートというか雑記です。
https://mixi.connpass.com/event/124948/
3部構成で、最初にこの会を開いてくれたミクシィの担当者(しょっさん)さんから会社説明と会場説明、そしてこの会を開くきっかけが5分ほど話され、 次にミクシィの2年目のエンジニアであるさのひろゆきさんから今年の新人研修資料の発表が同じく5分ほどあり、 最後に1時間ほどそーだいさんの話という流れでした。
内容についてはありがたいことに動画をミクシィさんがアップしてくれているのでそちらを見たほうが 自分が書くよりも確実なものが得られると思うので大半は割愛しますが、メモ的な感じでとった感想等を 書いておきたいと思います。
1部
開催小話
そーだいさんが本を出されて、それがいい本だったので社内のSlackで話題に挙がった ⇒しょっさんがTwitterで今回の会についてつぶやいてみたら本人が快諾してくれた
奇跡の上に成り立った会！
引き受けてくれたそーだいさんにしょっさんさんが感謝してましたが、それを実現したしょっさんさんとミクシィ社にも感謝です。
2部
新卒DB研修
さのひろゆきさん 出てきた瞬間、ベテラン感あふれる風貌なのに、プロフィールで「2017年度新卒」ってマジか！(失礼)
2年目に研修資料作らせてるのはまあいいとして、その内容が
- SQLチュートリアル
- Jupyter Notebookを用いてSQLの機能確認 ⇒わかる
- インデックスの演習
- ISUCONの過去問題を題材にpt-query-digest/EXPLAIN/インデックスの使い方を学ぶ …うん、まあわかる。(ISUCONの過去問題を題材にするところとpt-query-digestはちょっと早い気もするが)
- ストレージエンジンの実装
- MySQLのストレージエンジンの実装を通してデータベースの基本機能を自作してみる
ミクシィの新人研修、新人のレベルが凄すぎる気がするの自分だけ？ 俺もストレージエンジンの実装なんてしたことないわ…。
3部
そーだいさんのお話
序 なぜこの本を書いたか
https://soudai.hatenablog.com/entry/2019/03/06/080000
『失敗から学ぶ RDBの正しい歩き方』 この本、とてもわかりやすいし『SQLアンチパターン』を参考にしつつも内容が被らないように気を付けてていい本だなあと思ってましたが 作るのに「2年くらいかかった」というコメントからもこういう良書を作るにはやはりそれだけの労力が必要なのには納得でした。
何のためにこの本を書いたかという目的として「知識をつないでいくため」というフレーズはハッとさせられました。
- インターネットに置いておくと、古い話や失敗事例なんかは色々なパターンで消えていく
- サイトがなくなったり
- 著者がなくなるとクレジットカードを止めてサイトがとまるとか
言われてみると確かにそうです。 (ネット上の情報は生き物じゃないから永遠に残ってそうだと思ってたけど、それを管理するのは生身の人間なので永遠じゃない)
先日Microsoft Storeで電子書籍の終了があったが、書籍という形であれば書店はもちろん、電子書籍も複数のメディアで販売できるのでブログという形よりは確実に次につなげられる。
データベースのノウハウは10年レベルで使えるし、必要であれば改定すればいい。
今回のこの本はSQLアンチパターンと同じように定期的に読んで、自分の血肉にしていかなければ意味がないなと思いました。
本題
https://speakerdeck.com/soudai/learn-from-failure-1
今回は『失敗から学ぶ RDBの正しい歩き方』の中の2章、15章、7章についての話でしたが、Q&Aではそこ以外の章とも絡んだ話がされました。(8章 JSONの甘い罠)
失われた事実
- 履歴の保存をすることで過去の情報が失われることを防ぐ
- But、履歴の保持はパフォーマンスに影響する
- 設計時に事実の履歴をしっかり検討することが大事
簡単すぎる不整合
- 正しく正規化することが大事
隠された状態
アンチパターンのポイント
- データに複数の意味を持たせない
- 削除フラグ・・・フラグなのに0,1,2,...99,NULLってあったことがある。
例
- 友人のyoku0825さんがTwitterでこんなことをつぶやいてました
SQL> SELECT COUNT(*) FROM t1 WHERE c1 = 'null'; COUNT(*) ---------- 1231 SQL> SELECT COUNT(*) FROM t1 WHERE c1 IS NULL; COUNT(*) ---------- 3531
(これはよく見るｗ)
- テーブルやレコードを分ければシンプルになります。
- 一つのデータの責務を小さくする
- 正規化すると自然とそうなる。パフォーマンスも上がる。
- 常に状態が見えるようにするために事実のみを保存する
- こちらを参考にしてください⇒https://speakerdeck.com/soudai/rdb-the-right-way
Q&A
Q:JSONについての章と隠された状態の話ってつながりがありますか？
A:あります
Q:隠された状態でユーザテーブルが作られていた場合ユーザごとにカラムを分解した方が良いのか？それとも管理者と普通のユーザのようにテーブルを分けたほうがいいのか？
A:結論ケースバイケースです。
- ユーザを設計するときに、というブログを書きました。
- https://soudai.hatenablog.com/entry/2018/05/01/204442
そこでは - ステータス,フラグごとにカラムを二つ、三つ作って管理するのは絶対にダメ。 - ステータスカラムを持つべきだが、その場合はテーブルが肥大化しやすい。 - テーブルを分解すると肥大化が抑えられるが、同じユーザが存在するテーブルが複数存在する形になる - 会員はどれくらいで考えているか？を元に最初に設計しましょう。 - テーブルを増やすのは楽だけど、分けるのはしんどいです。
追加で自分が質問した内容
本にサインをもらいに行ったんですが、その際に以下の質問をしてみました。
Q:正規化した場合のパフォーマンスはどのように上げられるのか？
MySQLで正規化を進めていくとJOIN結合が発生した場合に遅くなりがちと言われるが、それでも正規化はすべきで、それ以上のパフォーマンス劣化はRDBの責務の範囲外に来ているから別の対応をした方が良いといわれましたが、具体的にはどのような方法がありますか？
A:レプリケーション・必要な情報を集めたテーブル作成・NoSQLを活用してみてください
- レプリケーションで必要なデータだけを特定のスレーブに集める
- 必要なデータを結合したビューテーブルを作る
- NoSQL上にキャッシュしておく
最後に
懇親会に家族都合で最後までいられませんでしたが、非常に有意義な時間を過ごせました。(そーだいさんに追加質問できたり、懇親会で知人ができたり) 現場を提供してくださったミクシィ様、スピーチに立ったミクシィのさのさん、この会を企画してくださったしょっさんさん、そして10年物のノウハウを残してくれたそーだいさんには本当に感謝しています。
