Tweet
Tweet

Slide 1

Slide 1 text

とあるイルカのデータベース コイツ、案外よくできてる 2018/07/06 yoku0825 GMOテクノロジーブートキャンプ

Slide 2

Slide 2 text

おことわり この資料で述べられる見解はyoku0825の中の人のノリによ るものであり、所属する組織または所属しない組織の意見を 一切合切代表するわけがありません この資料を読んだりセッションを聞いたりしてもたぶんSQL を書けるようにはなりません ざっくりわかりやすくするために、いくつか簡単なモデルで 説明しているところがあります。鵜呑みにはできません 1/119

Slide 3

Slide 3 text

なので 2/119

Slide 4

Slide 4 text

テキトーに聞 いといてくだ さい 3/119

Slide 5

Slide 5 text

MySQL触った ことある人？ 4/119

Slide 6

Slide 6 text

MySQL で きる 人？ 5/119

Slide 7

Slide 7 text

MySQL知 らない人？ 6/119

Slide 8

Slide 8 text

MySQLより 年下の人？ 7/119

Slide 9

Slide 9 text

こんな画面触ったことある人？ 8/119

Slide 10

Slide 10 text

こういうやつの方が好きな人？ 9/119

Slide 11

Slide 11 text

MySQL好 きな人？ 10/119

Slide 12

Slide 12 text

三度の飯より MySQLが好き な人？ 11/119

Slide 13

Slide 13 text

( ´∀｀)ﾉ お れはごはんの ほうがすき 12/119

Slide 14

Slide 14 text

MySQL #とは 世界でもっとも普及している、オープン ソース データ ベース https://www.mysql.com/jp/ 13/119

Slide 15

Slide 15 text

我々の生活の中でのMySQL #とは 永続化可能な サーバーまたいでアクセスできる 排他・共有ロック機能付きの グローバル変数のすごいやつ 異論は認める MySQLおじさんの逆襲 14/119

Slide 16

Slide 16 text

MySQL #とは グローバル変数のすごいやつ 異論は認める の 保管 と 取り出し に 特化 した アプリケーション 特化している以上、それ以外のことは（できなくはなかった としても）性能が落ちる ただしトーストは焼ける 15/119

Slide 17

Slide 17 text

ただしトーストは焼ける Fixing MySQL Bug#2: now MySQL makes toast! - Percona Database Performance Blog 16/119

Slide 18

Slide 18 text

この番組（？）では グローバル変数のすごいやつを自前で実装しようと思ったら アプリケーション側で何をしなければならないのか InnoDBがどんなことをしているのか を説明できたらいいなと思う 合言葉は「コイツ、案外よくできてる」 17/119

Slide 19

Slide 19 text

＼こんにちわ／ yoku0825＠GMOメディア株式会社 オラクれない ‐ ポスグれない ‐ マイエスキューエる ‐ 生息域 Twitter: @yoku0825 ‐ Blog: 日々の覚書 ‐ 日本MySQLユーザ会副代表 ←new!! ‐ MySQL Casual ‐ 18/119

Slide 20

Slide 20 text

(知らないうちに ) MySQLがやっ てくれていること 19/119

Slide 21

Slide 21 text

MySQLと上手く付き合うには 知らないうちにMySQLがやってくれていること MySQLはやってくれないこと それぞれを知り、やってくれることは任せて、やってくれな いところをアプリケーション側で実装する 20/119

Slide 22

Slide 22 text

(知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 21/119

Slide 23

Slide 23 text

(知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 22/119

Slide 24

Slide 24 text

データの永続化 コミットされたデータは（ストレージが吹っ飛ばない限り） 必ずそこに残ることを保証する これを自前で実装するとしたらどうすればいい？ 23/119

Slide 25

Slide 25 text

データの永続化 24/119

Slide 26

Slide 26 text

データの永続化 コミットの成功応答を遅延させることで「成功=必ず残って いる」を表現する これ単体だとまあなんとかなる 原子化と分離が絡んでくるとややこしくなる ‐ 25/119

Slide 27

Slide 27 text

(知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 26/119

Slide 28

Slide 28 text

操作の原子化 トランザクションといえば「2つ以上のステートメントをあ たかも1つの操作として…」と表現されることが多いけれど 実際は1ステートメントの処理内容でも原子性を意識しない といけない 27/119

Slide 29

Slide 29 text

操作の原子化 28/119

Slide 30

Slide 30 text

操作の原子化 書き込みに失敗してエラー応答を返すなら、書き込み途中の ものが見えてはいけない INSERTが失敗したなら空の行を ‐ UPDATE/DELETEが失敗したなら更新前の行を ‐ 返さないといけない ‐ とはいえワンアクションで1カラム1GBのデータを書くこと はできない 29/119

Slide 31

Slide 31 text

操作の原子化 30/119

Slide 32

Slide 32 text

操作の原子化 1レコード = 1ファイルならこれで何とかなるかも？ 「あるいはレコードが固定長なら…」 ‐ 正気に戻れ！ ‐ 31/119

Slide 33

Slide 33 text

(知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 32/119

Slide 34

Slide 34 text

トランザクションの分離/一貫性の保証 たとえば100行の結果セットがあって 先頭から50行読み込んだところで 51行目を更新するトランザクションがコミットされたとし たら何が起こる？ もちろん、更新が適用される前の行を返すんだけれども、ど うやってそれを表現する？ 33/119

Slide 35

Slide 35 text

トランザクションの分離/一貫性の保証 結果セットを読み込んでいる最中は当該の範囲に対する更新 をブロックする たとえば transaction_isolation = SERIALIZABLE はそんな動きにな る ‐ MyISAMという古いストレージエンジンもテーブル単位でロックする ことでこれを防ぐ ‐ 34/119

Slide 36

Slide 36 text

トランザクションの分離/一貫性の保証 更新前の値を捨てずに取っておいて、必要なら読み取り側が 更新前の値を参照しにいく 「現在の行」が「自分の1つ前のバージョン」に対する参照を持つ ‐ たとえばPostgreSQLは追記型アーキテクチャーなので、新しく追加 した側の行にそれを持たせればいい ‐ MySQLのInnoDBはインプレースなアーキテクチャーなので、元のデ ータをUNDO領域にコピーしている ‐ 35/119

Slide 37

Slide 37 text

トランザクションの分離/一貫性の保証 auto row= get_row(); switch (isolation_level) { case READ-COMMITTED: while (row) { if (row.has_committed) return row; else row->prev_version(); } case REPEATABLE-READ: while (row) { if (row.has_committed && row.commit_time < transaction_started) return row; else row->prev_version(); } ...; } 36/119

Slide 38

Slide 38 text

トランザクションの分離/一貫性の保証 READ-COMMITTED ステートメント が開始された時点でコミット済みの行を読み込む ‐ REPEATABLE-READ トランザクション が開始された時点でコミット済みの行を読み込む ‐ トランザクションの先頭で重い集計クエリーを流している間に更新が あっても、その間の更新を後続の集計クエリーは読まずに済む ‐ 論理バックアップでも使われる ‐ 37/119

Slide 39

Slide 39 text

(知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 38/119

Slide 40

Slide 40 text

インデックスのメンテナンス インデックスとは「構造化されたデータの部分集合」 辞書とその索引に例えた時に 辞書本文のページが増減したら、索引もそれに合わせて作り直さなけ ればならない ‐ 場合によっては「構造」の中でのメンテナンスが必要 B-Treeで中間のリーフノードを追加し続けると…？ ‐ しかも「永続性」「原子性」「分離性/一貫性」を保ちつつ ‐ 39/119

Slide 41

Slide 41 text

(知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 40/119

Slide 42

Slide 42 text

I/O量の削減 ここまでのものを愚直に再発明したとしたら、1行更新する だけで一体何回のfsyncが必要になるんだ？ fsyncはストレージI/Oの中でも最も遅い類 ‐ 特にハードディスクでは致命的に遅い ‐ 100GBのテーブルから1行探すために、100GBをスキャンす る訳にはいかない I/O効率、キャッシュ効率、局所性… ‐ 圧縮、展開、暗号化とかまで考え出すと…？ ‐ 41/119

Slide 43

Slide 43 text

I/O量の削減 効率を高めるための理論、実装がそれぞれ議論されている アカデミックな場から市場に降りてくるまでの時間差はあるけれども ‐ 自前でやるとしたらメモリー管理やI/O管理まで手を伸ばせ る言語に縛られることになる 我々はRDBMSという巨人の肩に乗っかって仕事をすること ができる 42/119

Slide 44

Slide 44 text

(知らないうちに) MySQLがやってくれていること 自分で再発明するとなるとかなり大変 「MySQLはSQLをしゃべるKVS」？ ‐ 「最近のKVSはずいぶん色んな機能を求められるんですね」 MongoDBもマルチドキュメントトランザクションサポートしたらしいし ‐ やってくれるとはいえ要らない機能があるなら、それを持た ない代わりに高速化された何かを選ぶことができる 命題: トランザクションの分離性は要らないからredisを使う ‐ 命題の逆: redisを使うからトランザクションの分離性は捨てるか別 のところで担保しないといけない ‐ 43/119

Slide 45

Slide 45 text

MySQLができること、できないこと、苦手なことを知る 任せた方が楽なものはMySQLに任せて再発明を避ける できないこと、苦手なことを無理矢理MySQLに押し付けて も幸せにはなれない MySQLを捨てて得られるものと得られないものを知ってデ ータストアを楽しく使う 44/119

Slide 46

Slide 46 text

ひとやす み 45/119

Slide 47

Slide 47 text

InnoDB #とは 46/119

Slide 48

Slide 48 text

MySQLの内部処理 47/119

Slide 49

Slide 49 text

MySQLの内部処理 コネクションを扱う部分 SQLをパースする部分 実行計画を作る部分 結果セットを組み立てる部分 ストレージエンジンを抽象化する部分 実ファイル, バッファ, トランザクションなどを管理する部 分 48/119

Slide 50

Slide 50 text

MySQLの内部処理 コネクションを扱う部分 SQLをパースする部分 実行計画を作る部分 結果セットを組み立てる部分 ストレージエンジンを抽象化する部分 実ファイル, バッファ, トランザクションなどを管理する部 分 49/119

Slide 51

Slide 51 text

InnoDB #とは InnoDBストレージエンジン MySQL 5.5とそれ以降でデフォルトのストレージエンジン 50/119

Slide 52

Slide 52 text

InnoDBのサポートする機能 MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.1 InnoDB 入 門 51/119

Slide 53

Slide 53 text

(比較用) MyISAMのサポートする機能 MySQL :: MySQL 5.6 リファレンスマニュアル :: 15.2 MyISAM ス トレージエンジン 52/119

Slide 54

Slide 54 text

ストレージエンジンが違うと サポートされる機能が変わる 性能特性もガラっと変わる 迷ったらInnoDB というか迷わずInnoDB その他のストレージエンジンを正しく扱えるのはMySQLニ ンジャだけだと心得る 裏を返すとその他のストレージエンジンも正しく扱えるようになれば MySQLニンジャだ ‐ 53/119

Slide 55

Slide 55 text

取り敢えず押さえておきたいInnoDBのコンポーネント バッファプール InnoDBログファイル テーブルスペースファイル UNDOログ 54/119

Slide 56

Slide 56 text

InnoDBの読み取り バッファプールの中から読み取り対象の行が含まれているペ ージを探す バッファプール上になければテーブルスペースファイルから 読み取り対象のページを読み出してバッファプールに載せる バッファプールに載ったページのバージョンはトランザクシ ョン分離レベルを満たすか？ 満たさない場合はUNDOログから以前のバージョンのページをバッフ ァプールに転送し、再評価する ‐ トランザクション分離レベルを満たすバージョンのページが 手に入ったら対象の行を上位のレイヤーに返す 55/119

Slide 57

Slide 57 text

InnoDBの書き込み バッファプールの中から更新対象の行が含まれている （INSERTした時に含まれるようになる）ページを探す バッファプール上になければテーブルスペースファイルから 書き込み対象のページを読み出してバッファプールに載せる UNDOログに更新前の行の情報を書き込む バッファプール上のページを更新する InnoDBログに更新情報を書き込む 56/119

Slide 58

Slide 58 text

InnoDBの書き込み バッファプールからテーブルスペースファイルへの反映は 非同期 InnoDBログはシーケンシャルライトになるように最適化されている が、 ‐ テーブルスペースファイルへの書き込みはランダムライトになりがち ‐ デフォルトでダブルライトするので、同期でランダムライト x 2だと レイテンシーが ‐ 57/119

Slide 59

Slide 59 text

InnoDBの書き込み InnoDBログへのシーケンシャルライト + オンメモリーのバ ッファプール更新を同期、ランダムライト（かつダブルライ ト）のテーブルスペースファイルへの書き込みを非同期化す ることでパフォーマンスとI/Oの節約 読むときは優先的にバッファプールから読むので、バッファプールか ら追い出される(=その後のアクセスはテーブルスペースファイルか ら読まれるようになる)時までランダムライトを遅延させられる ‐ ダーティーページが更に更新された場合、フラッシュが必要なのは 「最後の更新後のページ」なので、フラッシュ回数が更に減らせる ‐ 書き込みとクラッシュの話についてはもう数ページ先で 58/119

Slide 60

Slide 60 text

読み込み中の書き込み 読み取り中に次にフェッチする行が更新された場合、UNDO ログから以前のバージョンをバッファプールに転送して読み 続けられる ロックを取ることなく読み取りと書き込みが共存できる ‐ 流石にバッファプールのページを書き換える一瞬はラッチで排他制御 されるけれどメモリー上なので時間は非常に短い ‐ 読み取りに必要なのはバッファプール, テーブルスペースフ ァイル, UNDOログのみなので、InnoDBログは排他ロック を使って直列化できる 59/119

Slide 61

Slide 61 text

InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル SQL開始 まだ Synced Copying Synced SQL実行 まだ Updating Copied Synced COMMIT待ち Writing/ Syncing Updated Copied Synced COMMIT完了 Synced Synced Copied Outdated (非同期) Synced Synced Copied/ Purged Synced 60/119

Slide 62

Slide 62 text

InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル SQL開始 まだ Synced Copying Synced この時点で他のトランザクションがSELECTした場合、バッ ファプールの情報を読むため問題ない この時点で他のトランザクションが書き込もうとした場合は ロック待ちになる この時点でクラッシュした場合、中途半端なUNDOログを捨 てればステートメントはなかったことにできるので問題ない 61/119

Slide 63

Slide 63 text

InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル SQL実行 まだ Updating Copied Synced この時から他のトランザクションはバッファプールの更新後 のページに書かれた ロールバックポインター を読んで、 UNDOログから前のバージョンを取り出すようになる この時点でクラッシュした場合、UNDOログの消し込みだけ でいい（バッファプールはオンメモリーなのでクラッシュし たら消える） 62/119

Slide 64

Slide 64 text

InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル COMMIT待ち Writing/ Syncing Updated Copied Synced 他のトランザクションからのSELECTは同じ クラッシュも書きかけのInnoDBログを捨てれば操作前の状 態に戻れる 63/119

Slide 65

Slide 65 text

InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル COMMIT完了 Synced Synced Copied Outdated ここでコミットが終了するので、他のトランザクションは更 新された新しいバッファプールのデータを読む（またはトラ ンザクション分離レベルに応じてUNDOを読む） コミットされた時点でロックが外れるので、他の書き込みト ランザクションも動き始められる バッファプールとInnoDBログさえ排他にロックできればいいので、 テーブルスペースファイルが同期されるのを待つ必要はない ‐ ここでクラッシュした場合、更新前のテーブルスペースファ イルの値と、更新差分であるInnoDBログを使って、クラッ シュ前にバッファプールに載っていたページを再計算する 64/119

Slide 66

Slide 66 text

InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル (非同期) Synced Synced Copied/ Purged Synced コミット完了以後、他のトランザクションからの参照, 書き 込みと永続性に関しては変化はない クラッシュリカバリーの時間を短縮するため、バッファプー ルの値をテーブルスペースファイルにフラッシュして、再計 算が必要なページの数を減らす 65/119

Slide 67

Slide 67 text

テーブルスペースファイルとInnoDBログの関係 コードとパッチみたいな感じ？ ある時点のコードと、それ以降の全てのパッチがあれば最新のコード に復元できる ‐ パッチの数が多すぎると復元に時間がかかるので、ある程度のところ でマージして復元にかかる時間を短縮する ‐ 66/119

Slide 68

Slide 68 text

InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル SQL開始 まだ Synced Copying Synced SQL実行 まだ Updating Copied Synced COMMIT待ち Writing/ Syncing Updated Copied Synced COMMIT完了 Synced Updated Copied Outdated (非同期) Synced Synced Copied/ Purged Synced 67/119

Slide 69

Slide 69 text

InnoDBのクラスターインデックス (セカンダリー) インデックスが二重構造になっている セカンダリーキーが示す先はプライマリーキーの値 ‐ セカンダリーキーで検索する => プライマリーキーの値を得る => プライマリーキーで検索する => 結果が返る ‐ 68/119

Slide 70

Slide 70 text

MyISAMのインデックス方式 INSERT INTO t1 VALUES (1, 'one', 'ichi'); |1|:|o|n|e|:|i|c|h|i| PRIMARY 1 => offset 1 SECONDARY one => offset 1 69/119

Slide 71

Slide 71 text

MyISAMのインデックス方式 INSERT INTO t1 VALUES (2, 'two', 'ni'); |1|:|o|n|e|:|i|c|h|i|2|:|t|w|o| |:|n|i| PRIMARY 1 => offset 1 2 => offset 11 SECONDARY one => offset 1 two => offset 11 70/119

Slide 72

Slide 72 text

MyISAMのインデックス方式 INSERT INTO t1 VALUES (3, 'three', 'san'); |1|:|o|n|e|:|i|c|h|i|2|:|t|w|o| |:|n|i|3|:|t|h|r|e|e|:|s|a|n| PRIMARY 1 => offset 1 2 => offset 11 3 => offset 19 SECONDARY one => offset 1 three => offset 19 two => offset 11 71/119

Slide 73

Slide 73 text

MyISAMのインデックス方式 UPDATE t1 SET val = 'nii' WHERE num = 2; |1|:|o|n|e|:|i|c|h|i| | | | | | | | | |3|:|t|h|r|e|e|:|s|a|n|2| |:|t|w|o|:|n|i|i| PRIMARY 1 => offset 1 ---- 2 => offset 30 3 => offset 19 SECONDARY one => offset 1 three => offset 19 ---- two => offset 30 72/119

Slide 74

Slide 74 text

MyISAMのインデックス方式 関係ないカラムをいじっただけでも、物理的な行配置が変わ るとインデックスを更新しないといけない 73/119

Slide 75

Slide 75 text

InnoDBのクラスターインデックス INSERT INTO t1 VALUES (1, 'one', 'ichi'); |1|:|o|n|e|:|i|c|h|i| PRIMARY 1 => offset 1 SECONDARY one => 1 74/119

Slide 76

Slide 76 text

InnoDBのクラスターインデックス INSERT INTO t1 VALUES (2, 'two', 'ni'); |1|:|o|n|e|:|i|c|h|i|2|:|t|w|o| |:|n|i| PRIMARY 1 => offset 1 2 => offset 11 SECONDARY one => 1 two => 2 75/119

Slide 77

Slide 77 text

InnoDBのクラスターインデックス INSERT INTO t1 VALUES (3, 'three', 'san'); |1|:|o|n|e|:|i|c|h|i|2|:|t|w|o| |:|n|i|3|:|t|h|r|e|e|:|s|a|n| PRIMARY 1 => offset 1 2 => offset 11 3 => offset 19 SECONDARY one => 1 three => 3 two => 2 76/119

Slide 78

Slide 78 text

InnoDBのクラスターインデックス UPDATE t1 SET val = 'nii' WHERE num = 2; |1|:|o|n|e|:|i|c|h|i| | | | | | | | | |3|:|t|h|r|e|e|:|s|a|n|2| |:|t|w|o|:|n|i|i| PRIMARY 1 => offset 1 ---- 2 => offset 30 3 => offset 19 SECONDARY one => 1 three => 3 two => 2 77/119

Slide 79

Slide 79 text

InnoDBのクラスターインデックス インデックスに関係ないカラムの更新に影響を受けなくなる インデックスの更新回数が減る = I/O回数が減る ‐ インデックスが増えれば増えるほど顕著に ‐ 78/119

Slide 80

Slide 80 text

MySQLの面白いところ 実ファイル, バッファ, トランザクションなどを管理する部 分 がコンポーネントとして切り離されている トランザクション非対応なストレージエンジンを選んで性能を上げ る, 新しい機能を追加する ‐ レイテンシーよりも容量や書き込み回数を重視したストレージエンジ ンを選べる ‐ Be a MySQLニンジャ 79/119

Slide 81

Slide 81 text

MySQLの面白いところ コネクションを扱う部分 SQLをパースする部分 実行計画を作る部分 結果セットを組み立てる部分 ストレージエンジンを抽象化する部分 実ファイル, バッファ, トランザクションなどを管理する部 分 80/119

Slide 82

Slide 82 text

MySQLの面白いところ しかもなんかこれらの部品を組み替えたりしてなんかできた りする 81/119

Slide 83

Slide 83 text

MySQLの面白いところ 82/119

Slide 84

Slide 84 text

MySQLの面白いところ 83/119

Slide 85

Slide 85 text

MySQLの面白いところ 84/119

Slide 86

Slide 86 text

MySQLの面白いところ 85/119

Slide 87

Slide 87 text

MySQLの面白いところ yoku0825/bogus_redis_storage_engine yoku0825/zundoko_storage_engine: ズンドコキヨシ用 MySQLストレージエンジン 86/119

Slide 88

Slide 88 text

MySQLプロトコル でSQL以外の何か を語り掛けても結果 が戻ってくる 87/119

Slide 89

Slide 89 text

Query Rewrite Plugin Parserの手前を取るPre-parse Query Rewriteと Parserの後ろ(Optimizerの手前)を取るPost-parse Query Rewriteがある 88/119

Slide 90

Slide 90 text

クエリーリライト mysqlコマンドラインクライアントを起動してるのに、うっ かりlsとか叩いちゃったことありませんか？ mysql57> ls; +--------------+ | Tables_in_d1 | +--------------+ | t1 | +--------------+ 1 row in set, 1 warning (0.01 sec) mysql57> SHOW WARNINGS; +-------+------+-------------------------------------------------------------------+ | Level | Code | Message | +-------+------+-------------------------------------------------------------------+ | Note | 1105 | Query 'ls' rewritten to 'SHOW TABLES' by plugin: rewrite_example. | +-------+------+-------------------------------------------------------------------+ 1 row in set (0.00 sec) 89/119

Slide 91

Slide 91 text

クエリーリライト catとかお好きですか？ mysql57> cat t1; +-----+-------+ | num | val | +-----+-------+ | 1 | one | | 2 | two | | 3 | three | +-----+-------+ 3 rows in set, 1 warning (0.02 sec) 90/119

Slide 92

Slide 92 text

クエリーリライト サーバーサイドで書き換えているので、クライアントを選ばな い。 91/119

Slide 93

Slide 93 text

MySQLの面白いところ MySQLに格納されたデータを別のプロトコルでアクセスす る SQLをしゃべっているように見せかけて裏側は別のデータス トアを使う 書き込み効率重視のRocksDBをバックエンドにしたFacebook MySQLとか ‐ カラムナーでデータを格納するMariaDB Column Store(旧InfiniDB) とか ‐ 92/119

Slide 94

Slide 94 text

MySQLの面白いところ RDBMSの一つのポイントは「データの物理的な格納からの 抽象化」 オープンソースであることを差し引いても、「そこに敢えて手を入れ る」やり方がそもそも用意されている ‐ それどころかSQLである必要すらなくなったり 「さすが変態」 ©tmtms ‐ 93/119

Slide 95

Slide 95 text

夢は無限大 94/119

Slide 96

Slide 96 text

MySQLで 楽しもう 95/119

Slide 97

Slide 97 text

　 96/119

Slide 98

Slide 98 text

(ﾟдﾟ ) 97/119

Slide 99

Slide 99 text

( ﾟдﾟ ) 98/119

Slide 100

Slide 100 text

( ﾟдﾟ) 99/119

Slide 101

Slide 101 text

時間余ってると思 うのでMySQLのト リビアを話します 100/119

Slide 102

Slide 102 text

MySQLの 正しい発音 101/119

Slide 103

Slide 103 text

マイエスキューエル The official way to pronounce “MySQL” is “My Ess Que Ell” (not “my sequel”), but we do not mind if you pronounce it as “my sequel” or in some other localized way. http://dev.mysql.com/doc/refman/5.7/en/what-is- mysql.html 102/119

Slide 104

Slide 104 text

MySQLの 名前の由来 103/119

Slide 105

Slide 105 text

Myちゃん MySQL is named after co-founder Monty Widenius’s daughter, My. http://dev.mysql.com/doc/refman/5.7/en/history.html ただしMyちゃんの名前の発音は ミィ 104/119

Slide 106

Slide 106 text

MariaDBの 名前の由来 105/119

Slide 107

Slide 107 text

Mariaちゃん MariaDB continues this tradition by being named after his younger daughter, Maria. https://mariadb.com/kb/en/mariadb/why-is-the- project-called-mariadb/ 106/119

Slide 108

Slide 108 text

宿命のライバル（？）のツーショット http://www.slideshare.net/Codemotion/my-sql- 107/119

Slide 109

Slide 109 text

MySQLのロゴ 自重 https://www.mysql.com/jp/about/legal/logos.html 108/119

Slide 110

Slide 110 text

このイル カの名前 109/119

Slide 111

Slide 111 text

サキラまたはサキーラ The name of the MySQL Dolphin (our logo) is “Sakila,” http://dev.mysql.com/doc/refman/5.7/en/history.html 110/119

Slide 112

Slide 112 text

MySQLのロゴ 実は利用規定が厳しい というかまず使えない MySQL :: Logo Usage Guidelines 111/119

Slide 113

Slide 113 text

MySQL 5.0.96 なんて読む？ 112/119

Slide 114

Slide 114 text

MySQL 5.0.96 ごー てん ぜろ（れい） てん きゅーろく（きゅーじゅーろ く） ごー ぜろ きゅーろく（きゅーじゅーろく） あるいは他に 113/119

Slide 115

Slide 115 text

5.0.96の意味 5 メジャーバージョン番号 0 リリースレベル 96 リリースシリーズ(メジャーバージョン番号とリリースレベル)内でのバージ ョン番号 http://dev.mysql.com/doc/refman/5.7/en/which- version.html 114/119

Slide 116

Slide 116 text

オレオレ認識 5.0 メジャーバージョン（正しくはリリースシリーズ） 96 マイナーバージョン 115/119

Slide 117

Slide 117 text

さっきから（？） 背景にいる この子 ⇒ 116/119

Slide 118

Slide 118 text

日本MySQLユーザ会のロゴのマイナくん（仮） 日本MySQLユーザ会（略称: MyNA = MySQL Nippon Association） まいな、と読みます。 ‐ http://mysql.gr.jp/ 117/119

Slide 119

Slide 119 text

クラ〇ドワークスで発注して擬人化してもらった（真顔） 今でもなんであんなにムキになって舞奈たんを擬人化し たかったのか良くわかりません。 なお、舞奈たんは「マイナくん（仮）」の擬人化であっ てMySQLの擬人化ではないので、緑色です。 (snip) ちなみに「どこからその予算出てるの？」と聞か れることが何度かありましたが、俺のお小遣いです 日々の覚書: 舞奈たんとは何なのか 118/119

Slide 120

Slide 120 text

MySQL楽 しいよ！ 119/119