Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
とあるイルカのデータベース
Search
yoku0825
July 06, 2018
Technology
3
1.3k
とあるイルカのデータベース
2018/07/06 GMOテクノロジーブートキャンプ
yoku0825
July 06, 2018
Tweet
Share
More Decks by yoku0825
See All by yoku0825
MySQLのロックの種類とその競合
yoku0825
7
2.3k
MySQL 8.4 LTS が あらわれた
yoku0825
2
640
ぼくたちはMySQL 8.1とどう生きるか
yoku0825
6
2.4k
2022年のMySQLerが20年前のMySQL 4.0に触ると何が起きるか
yoku0825
0
370
テストデータが偏るということについて
yoku0825
3
8.6k
MySQLが得意なこと、不得意なこと(仮)
yoku0825
12
13k
MySQLとインデックスとPHPer
yoku0825
8
8k
MySQLとインデックスと私
yoku0825
76
56k
DavidとJackとMySQLのセキュリティと
yoku0825
0
780
Other Decks in Technology
See All in Technology
サイバーセキュリティと認知バイアス:対策の隙を埋める心理学的アプローチ
shumei_ito
0
380
iOSチームとAndroidチームでブランチ運用が違ったので整理してます
sansantech
PRO
0
130
Why does continuous profiling matter to developers? #appdevelopercon
salaboy
0
190
TypeScript、上達の瞬間
sadnessojisan
46
13k
初心者向けAWS Securityの勉強会mini Security-JAWSを9ヶ月ぐらい実施してきての近況
cmusudakeisuke
0
120
Security-JAWS【第35回】勉強会クラウドにおけるマルウェアやコンテンツ改ざんへの対策
4su_para
0
180
SSMRunbook作成の勘所_20241120
koichiotomo
2
130
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
190
RubyのWebアプリケーションを50倍速くする方法 / How to Make a Ruby Web Application 50 Times Faster
hogelog
3
940
AWS Lambda のトラブルシュートをしていて思うこと
kazzpapa3
2
170
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
3.8k
第1回 国土交通省 データコンペ参加者向け勉強会③- Snowflake x estie編 -
estie
0
130
Featured
See All Featured
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Music & Morning Musume
bryan
46
6.2k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Practical Orchestrator
shlominoach
186
10k
We Have a Design System, Now What?
morganepeng
50
7.2k
Being A Developer After 40
akosma
86
590k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Side Projects
sachag
452
42k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Designing for humans not robots
tammielis
250
25k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
BBQ
matthewcrist
85
9.3k
Transcript
とあるイルカのデータベース コイツ、案外よくできてる 2018/07/06 yoku0825 GMOテクノロジーブートキャンプ
おことわり この資料で述べられる見解はyoku0825の中の人のノリによ るものであり、所属する組織または所属しない組織の意見を 一切合切代表するわけがありません この資料を読んだりセッションを聞いたりしてもたぶんSQL を書けるようにはなりません ざっくりわかりやすくするために、いくつか簡単なモデルで 説明しているところがあります。鵜呑みにはできません 1/119
なので 2/119
テキトーに聞 いといてくだ さい 3/119
MySQL触った ことある人? 4/119
MySQL で きる 人? 5/119
MySQL知 らない人? 6/119
MySQLより 年下の人? 7/119
こんな画面触ったことある人? 8/119
こういうやつの方が好きな人? 9/119
MySQL好 きな人? 10/119
三度の飯より MySQLが好き な人? 11/119
( ´∀`)ノ お れはごはんの ほうがすき 12/119
MySQL #とは 世界でもっとも普及している、オープン ソース データ ベース https://www.mysql.com/jp/ 13/119
我々の生活の中でのMySQL #とは 永続化可能な サーバーまたいでアクセスできる 排他・共有ロック機能付きの グローバル変数のすごいやつ 異論は認める MySQLおじさんの逆襲 14/119
MySQL #とは グローバル変数のすごいやつ 異論は認める の 保管 と 取り出し に 特化
した アプリケーション 特化している以上、それ以外のことは(できなくはなかった としても)性能が落ちる ただしトーストは焼ける 15/119
ただしトーストは焼ける Fixing MySQL Bug#2: now MySQL makes toast! - Percona
Database Performance Blog 16/119
この番組(?)では グローバル変数のすごいやつを自前で実装しようと思ったら アプリケーション側で何をしなければならないのか InnoDBがどんなことをしているのか を説明できたらいいなと思う 合言葉は「コイツ、案外よくできてる」 17/119
\こんにちわ/ yoku0825@GMOメディア株式会社 オラクれない ‐ ポスグれない ‐ マイエスキューエる ‐ 生息域 Twitter:
@yoku0825 ‐ Blog: 日々の覚書 ‐ 日本MySQLユーザ会副代表 ←new!! ‐ MySQL Casual ‐ 18/119
(知らないうちに ) MySQLがやっ てくれていること 19/119
MySQLと上手く付き合うには 知らないうちにMySQLがやってくれていること MySQLはやってくれないこと それぞれを知り、やってくれることは任せて、やってくれな いところをアプリケーション側で実装する 20/119
(知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 21/119
(知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 22/119
データの永続化 コミットされたデータは(ストレージが吹っ飛ばない限り) 必ずそこに残ることを保証する これを自前で実装するとしたらどうすればいい? 23/119
データの永続化 24/119
データの永続化 コミットの成功応答を遅延させることで「成功=必ず残って いる」を表現する これ単体だとまあなんとかなる 原子化と分離が絡んでくるとややこしくなる ‐ 25/119
(知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 26/119
操作の原子化 トランザクションといえば「2つ以上のステートメントをあ たかも1つの操作として…」と表現されることが多いけれど 実際は1ステートメントの処理内容でも原子性を意識しない といけない 27/119
操作の原子化 28/119
操作の原子化 書き込みに失敗してエラー応答を返すなら、書き込み途中の ものが見えてはいけない INSERTが失敗したなら空の行を ‐ UPDATE/DELETEが失敗したなら更新前の行を ‐ 返さないといけない ‐ とはいえワンアクションで1カラム1GBのデータを書くこと
はできない 29/119
操作の原子化 30/119
操作の原子化 1レコード = 1ファイルならこれで何とかなるかも? 「あるいはレコードが固定長なら…」 ‐ 正気に戻れ! ‐ 31/119
(知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 32/119
トランザクションの分離/一貫性の保証 たとえば100行の結果セットがあって 先頭から50行読み込んだところで 51行目を更新するトランザクションがコミットされたとし たら何が起こる? もちろん、更新が適用される前の行を返すんだけれども、ど うやってそれを表現する? 33/119
トランザクションの分離/一貫性の保証 結果セットを読み込んでいる最中は当該の範囲に対する更新 をブロックする たとえば transaction_isolation = SERIALIZABLE はそんな動きにな る ‐
MyISAMという古いストレージエンジンもテーブル単位でロックする ことでこれを防ぐ ‐ 34/119
トランザクションの分離/一貫性の保証 更新前の値を捨てずに取っておいて、必要なら読み取り側が 更新前の値を参照しにいく 「現在の行」が「自分の1つ前のバージョン」に対する参照を持つ ‐ たとえばPostgreSQLは追記型アーキテクチャーなので、新しく追加 した側の行にそれを持たせればいい ‐ MySQLのInnoDBはインプレースなアーキテクチャーなので、元のデ ータをUNDO領域にコピーしている
‐ 35/119
トランザクションの分離/一貫性の保証 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
トランザクションの分離/一貫性の保証 READ-COMMITTED ステートメント が開始された時点でコミット済みの行を読み込む ‐ REPEATABLE-READ トランザクション が開始された時点でコミット済みの行を読み込む ‐ トランザクションの先頭で重い集計クエリーを流している間に更新が
あっても、その間の更新を後続の集計クエリーは読まずに済む ‐ 論理バックアップでも使われる ‐ 37/119
(知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 38/119
インデックスのメンテナンス インデックスとは「構造化されたデータの部分集合」 辞書とその索引に例えた時に 辞書本文のページが増減したら、索引もそれに合わせて作り直さなけ ればならない ‐ 場合によっては「構造」の中でのメンテナンスが必要 B-Treeで中間のリーフノードを追加し続けると…? ‐ しかも「永続性」「原子性」「分離性/一貫性」を保ちつつ
‐ 39/119
(知らないうちに) MySQLがやってくれていること データの永続化 操作の原子化 トランザクションの分離/一貫性の保証 インデックスのメンテナンス I/O量の削減 40/119
I/O量の削減 ここまでのものを愚直に再発明したとしたら、1行更新する だけで一体何回のfsyncが必要になるんだ? fsyncはストレージI/Oの中でも最も遅い類 ‐ 特にハードディスクでは致命的に遅い ‐ 100GBのテーブルから1行探すために、100GBをスキャンす る訳にはいかない I/O効率、キャッシュ効率、局所性…
‐ 圧縮、展開、暗号化とかまで考え出すと…? ‐ 41/119
I/O量の削減 効率を高めるための理論、実装がそれぞれ議論されている アカデミックな場から市場に降りてくるまでの時間差はあるけれども ‐ 自前でやるとしたらメモリー管理やI/O管理まで手を伸ばせ る言語に縛られることになる 我々はRDBMSという巨人の肩に乗っかって仕事をすること ができる 42/119
(知らないうちに) MySQLがやってくれていること 自分で再発明するとなるとかなり大変 「MySQLはSQLをしゃべるKVS」? ‐ 「最近のKVSはずいぶん色んな機能を求められるんですね」 MongoDBもマルチドキュメントトランザクションサポートしたらしいし ‐ やってくれるとはいえ要らない機能があるなら、それを持た ない代わりに高速化された何かを選ぶことができる
命題: トランザクションの分離性は要らないからredisを使う ‐ 命題の逆: redisを使うからトランザクションの分離性は捨てるか別 のところで担保しないといけない ‐ 43/119
MySQLができること、できないこと、苦手なことを知る 任せた方が楽なものはMySQLに任せて再発明を避ける できないこと、苦手なことを無理矢理MySQLに押し付けて も幸せにはなれない MySQLを捨てて得られるものと得られないものを知ってデ ータストアを楽しく使う 44/119
ひとやす み 45/119
InnoDB #とは 46/119
MySQLの内部処理 47/119
MySQLの内部処理 コネクションを扱う部分 SQLをパースする部分 実行計画を作る部分 結果セットを組み立てる部分 ストレージエンジンを抽象化する部分 実ファイル, バッファ, トランザクションなどを管理する部 分
48/119
MySQLの内部処理 コネクションを扱う部分 SQLをパースする部分 実行計画を作る部分 結果セットを組み立てる部分 ストレージエンジンを抽象化する部分 実ファイル, バッファ, トランザクションなどを管理する部 分
49/119
InnoDB #とは InnoDBストレージエンジン MySQL 5.5とそれ以降でデフォルトのストレージエンジン 50/119
InnoDBのサポートする機能 MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.1 InnoDB 入
門 51/119
(比較用) MyISAMのサポートする機能 MySQL :: MySQL 5.6 リファレンスマニュアル :: 15.2 MyISAM
ス トレージエンジン 52/119
ストレージエンジンが違うと サポートされる機能が変わる 性能特性もガラっと変わる 迷ったらInnoDB というか迷わずInnoDB その他のストレージエンジンを正しく扱えるのはMySQLニ ンジャだけだと心得る 裏を返すとその他のストレージエンジンも正しく扱えるようになれば MySQLニンジャだ ‐
53/119
取り敢えず押さえておきたいInnoDBのコンポーネント バッファプール InnoDBログファイル テーブルスペースファイル UNDOログ 54/119
InnoDBの読み取り バッファプールの中から読み取り対象の行が含まれているペ ージを探す バッファプール上になければテーブルスペースファイルから 読み取り対象のページを読み出してバッファプールに載せる バッファプールに載ったページのバージョンはトランザクシ ョン分離レベルを満たすか? 満たさない場合はUNDOログから以前のバージョンのページをバッフ ァプールに転送し、再評価する ‐
トランザクション分離レベルを満たすバージョンのページが 手に入ったら対象の行を上位のレイヤーに返す 55/119
InnoDBの書き込み バッファプールの中から更新対象の行が含まれている (INSERTした時に含まれるようになる)ページを探す バッファプール上になければテーブルスペースファイルから 書き込み対象のページを読み出してバッファプールに載せる UNDOログに更新前の行の情報を書き込む バッファプール上のページを更新する InnoDBログに更新情報を書き込む 56/119
InnoDBの書き込み バッファプールからテーブルスペースファイルへの反映は 非同期 InnoDBログはシーケンシャルライトになるように最適化されている が、 ‐ テーブルスペースファイルへの書き込みはランダムライトになりがち ‐ デフォルトでダブルライトするので、同期でランダムライト x
2だと レイテンシーが ‐ 57/119
InnoDBの書き込み InnoDBログへのシーケンシャルライト + オンメモリーのバ ッファプール更新を同期、ランダムライト(かつダブルライ ト)のテーブルスペースファイルへの書き込みを非同期化す ることでパフォーマンスとI/Oの節約 読むときは優先的にバッファプールから読むので、バッファプールか ら追い出される(=その後のアクセスはテーブルスペースファイルか ら読まれるようになる)時までランダムライトを遅延させられる
‐ ダーティーページが更に更新された場合、フラッシュが必要なのは 「最後の更新後のページ」なので、フラッシュ回数が更に減らせる ‐ 書き込みとクラッシュの話についてはもう数ページ先で 58/119
読み込み中の書き込み 読み取り中に次にフェッチする行が更新された場合、UNDO ログから以前のバージョンをバッファプールに転送して読み 続けられる ロックを取ることなく読み取りと書き込みが共存できる ‐ 流石にバッファプールのページを書き換える一瞬はラッチで排他制御 されるけれどメモリー上なので時間は非常に短い ‐ 読み取りに必要なのはバッファプール,
テーブルスペースフ ァイル, UNDOログのみなので、InnoDBログは排他ロック を使って直列化できる 59/119
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
InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル SQL開始 まだ Synced
Copying Synced この時点で他のトランザクションがSELECTした場合、バッ ファプールの情報を読むため問題ない この時点で他のトランザクションが書き込もうとした場合は ロック待ちになる この時点でクラッシュした場合、中途半端なUNDOログを捨 てればステートメントはなかったことにできるので問題ない 61/119
InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル SQL実行 まだ Updating
Copied Synced この時から他のトランザクションはバッファプールの更新後 のページに書かれた ロールバックポインター を読んで、 UNDOログから前のバージョンを取り出すようになる この時点でクラッシュした場合、UNDOログの消し込みだけ でいい(バッファプールはオンメモリーなのでクラッシュし たら消える) 62/119
InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル COMMIT待ち Writing/ Syncing
Updated Copied Synced 他のトランザクションからのSELECTは同じ クラッシュも書きかけのInnoDBログを捨てれば操作前の状 態に戻れる 63/119
InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル COMMIT完了 Synced Synced
Copied Outdated ここでコミットが終了するので、他のトランザクションは更 新された新しいバッファプールのデータを読む(またはトラ ンザクション分離レベルに応じてUNDOを読む) コミットされた時点でロックが外れるので、他の書き込みト ランザクションも動き始められる バッファプールとInnoDBログさえ排他にロックできればいいので、 テーブルスペースファイルが同期されるのを待つ必要はない ‐ ここでクラッシュした場合、更新前のテーブルスペースファ イルの値と、更新差分であるInnoDBログを使って、クラッ シュ前にバッファプールに載っていたページを再計算する 64/119
InnoDBの書き込み trx InnoDBログ バッファプール UNDOログ テーブルスペース ファイル (非同期) Synced Synced
Copied/ Purged Synced コミット完了以後、他のトランザクションからの参照, 書き 込みと永続性に関しては変化はない クラッシュリカバリーの時間を短縮するため、バッファプー ルの値をテーブルスペースファイルにフラッシュして、再計 算が必要なページの数を減らす 65/119
テーブルスペースファイルとInnoDBログの関係 コードとパッチみたいな感じ? ある時点のコードと、それ以降の全てのパッチがあれば最新のコード に復元できる ‐ パッチの数が多すぎると復元に時間がかかるので、ある程度のところ でマージして復元にかかる時間を短縮する ‐ 66/119
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
InnoDBのクラスターインデックス (セカンダリー) インデックスが二重構造になっている セカンダリーキーが示す先はプライマリーキーの値 ‐ セカンダリーキーで検索する => プライマリーキーの値を得る => プライマリーキーで検索する
=> 結果が返る ‐ 68/119
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
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
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
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
MyISAMのインデックス方式 関係ないカラムをいじっただけでも、物理的な行配置が変わ るとインデックスを更新しないといけない 73/119
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
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
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
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
InnoDBのクラスターインデックス インデックスに関係ないカラムの更新に影響を受けなくなる インデックスの更新回数が減る = I/O回数が減る ‐ インデックスが増えれば増えるほど顕著に ‐ 78/119
MySQLの面白いところ 実ファイル, バッファ, トランザクションなどを管理する部 分 がコンポーネントとして切り離されている トランザクション非対応なストレージエンジンを選んで性能を上げ る, 新しい機能を追加する ‐
レイテンシーよりも容量や書き込み回数を重視したストレージエンジ ンを選べる ‐ Be a MySQLニンジャ 79/119
MySQLの面白いところ コネクションを扱う部分 SQLをパースする部分 実行計画を作る部分 結果セットを組み立てる部分 ストレージエンジンを抽象化する部分 実ファイル, バッファ, トランザクションなどを管理する部 分
80/119
MySQLの面白いところ しかもなんかこれらの部品を組み替えたりしてなんかできた りする 81/119
MySQLの面白いところ 82/119
MySQLの面白いところ 83/119
MySQLの面白いところ 84/119
MySQLの面白いところ 85/119
MySQLの面白いところ yoku0825/bogus_redis_storage_engine yoku0825/zundoko_storage_engine: ズンドコキヨシ用 MySQLストレージエンジン 86/119
MySQLプロトコル でSQL以外の何か を語り掛けても結果 が戻ってくる 87/119
Query Rewrite Plugin Parserの手前を取るPre-parse Query Rewriteと Parserの後ろ(Optimizerの手前)を取るPost-parse Query Rewriteがある 88/119
クエリーリライト 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
クエリーリライト catとかお好きですか? mysql57> cat t1; +-----+-------+ | num | val
| +-----+-------+ | 1 | one | | 2 | two | | 3 | three | +-----+-------+ 3 rows in set, 1 warning (0.02 sec) 90/119
クエリーリライト サーバーサイドで書き換えているので、クライアントを選ばな い。 91/119
MySQLの面白いところ MySQLに格納されたデータを別のプロトコルでアクセスす る SQLをしゃべっているように見せかけて裏側は別のデータス トアを使う 書き込み効率重視のRocksDBをバックエンドにしたFacebook MySQLとか ‐ カラムナーでデータを格納するMariaDB Column
Store(旧InfiniDB) とか ‐ 92/119
MySQLの面白いところ RDBMSの一つのポイントは「データの物理的な格納からの 抽象化」 オープンソースであることを差し引いても、「そこに敢えて手を入れ る」やり方がそもそも用意されている ‐ それどころかSQLである必要すらなくなったり 「さすが変態」 ©tmtms ‐
93/119
夢は無限大 94/119
MySQLで 楽しもう 95/119
96/119
(゚д゚ ) 97/119
( ゚д゚ ) 98/119
( ゚д゚) 99/119
時間余ってると思 うのでMySQLのト リビアを話します 100/119
MySQLの 正しい発音 101/119
マイエスキューエル 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
MySQLの 名前の由来 103/119
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
MariaDBの 名前の由来 105/119
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
宿命のライバル(?)のツーショット http://www.slideshare.net/Codemotion/my-sql- 107/119
MySQLのロゴ 自重 https://www.mysql.com/jp/about/legal/logos.html 108/119
このイル カの名前 109/119
サキラまたはサキーラ The name of the MySQL Dolphin (our logo) is
“Sakila,” http://dev.mysql.com/doc/refman/5.7/en/history.html 110/119
MySQLのロゴ 実は利用規定が厳しい というかまず使えない MySQL :: Logo Usage Guidelines 111/119
MySQL 5.0.96 なんて読む? 112/119
MySQL 5.0.96 ごー てん ぜろ(れい) てん きゅーろく(きゅーじゅーろ く) ごー ぜろ
きゅーろく(きゅーじゅーろく) あるいは他に 113/119
5.0.96の意味 5 メジャーバージョン番号 0 リリースレベル 96 リリースシリーズ(メジャーバージョン番号とリリースレベル)内でのバージ ョン番号 http://dev.mysql.com/doc/refman/5.7/en/which- version.html
114/119
オレオレ認識 5.0 メジャーバージョン(正しくはリリースシリーズ) 96 マイナーバージョン 115/119
さっきから(?) 背景にいる この子 ⇒ 116/119
日本MySQLユーザ会のロゴのマイナくん(仮) 日本MySQLユーザ会(略称: MyNA = MySQL Nippon Association) まいな、と読みます。 ‐ http://mysql.gr.jp/
117/119
クラ〇ドワークスで発注して擬人化してもらった(真顔) 今でもなんであんなにムキになって舞奈たんを擬人化し たかったのか良くわかりません。 なお、舞奈たんは「マイナくん(仮)」の擬人化であっ てMySQLの擬人化ではないので、緑色です。 (snip) ちなみに「どこからその予算出てるの?」と聞か れることが何度かありましたが、俺のお小遣いです 日々の覚書: 舞奈たんとは何なのか
118/119
MySQL楽 しいよ! 119/119