SlideShare a Scribd company logo
MySQLステータスモニタリング
〜それ、Perlで(も)できるよ〜
2017/07/14
yoku0825
吉祥寺.pm 11
Chiba.pmの
⽅から来まし
た
1/54
Chiba.pm
の “m” は
2/54
MySQL
の”M” :)
3/54
※諸説あ
ります
4/54
Ichikawa.pm
まだ⾏ってなく
てごめんなさい
5/54
\こんに千葉/ (c)hokke̲mirin
yoku0825
オラクれない-
ポスグれない-
マイエスキューエる-
⽣息域
Twitter: @yoku0825-
Blog: ⽇々の覚書-
MyNA ML: ⽇本MySQLユーザ会-
MySQL Casual: Slack-
6/54
MySQLステー
タスモニタリ
ング #とは
7/54
MySQLステータスモニタリング #とは
ZabbixとかCloudWatch的な⾔い回しで “メトリクス監視”
と呼んでるやつのつもり
俺はCactiスキー(単に他のを知らないとも)
おや、そういえば今⽇はMackerelの中の⼈が…︖
8/54
ステータスモニタリングで思うこと
有意義な 情報がほしい
なるべく ⼿間はかけたくない
平たく⾔うとデータソース取得メソッドは⾃分で書きたくない
もっと⾔うと SHOW ENGINE INNODB STATUS を正規表現でパースしたくない
-
ビバ エコシステム-
しなくていいなら 運⽤したくない
どうせなら フロントエンドはイケてる⽅がいい
9/54
PMP for Cacti
10/54
PMM
11/54
Mackerel
12/54
話変わるけど、中国地⽅にい る ないエンジニアのそーだ
いさんという⽅は凄く優秀そうな⽅だし、
13/54
家族思いだし、
14/54
尊敬するエンジニアの⼀⼈です。
15/54
閑話休題
16/54
ステータスモニタリングで思うこと(again)
有意義な 情報がほしい
なるべく ⼿間はかけたくない
平たく⾔うとデータソース取得メソッドは⾃分で書きたくない
もっと⾔うと SHOW ENGINE INNODB STATUS を正規表現でパースしたくない
-
ビバ エコシステム-
しなくていいなら 運⽤したくない
どうせなら フロントエンドはイケてる⽅がいい
17/54
だがしか
し
18/54
気に⼊るもの
がなかったら
19/54
我々はどうや
って戦えばい
いんだろう
20/54
MySQLのステータスはどこで⾒る︖
SHOW ステートメント派
SHOW GLOBAL STATUS-
SHOW PROCESSLIST-
SHOW ENGINE INNODB STATUS-
SHOW SLAVE STATUS-
SHOW TABLE STATUS-
information_schema, performance_schema 派
i̲s.tables, i̲s.innodb̲metrics, i̲s.global̲status, ..-
p̲s.table̲io̲waits̲summary̲by̲table, p̲s.threads,
p̲s.events̲statements̲summary̲by̲digest, ..
-
21/54
SHOW ステートメント
⼀応SQL
結果セットはカラムと⾏から成るフツーのSQLと同じ結果セ
ット
フツーに⽣DBIでもORMでもアクセスできる-
ただし SHOW ENGINE INNODB STATUS は 1⾏3カラムの結果セットで、
“Status” カラムの中にテキストで⼊ってるからパース地獄
-
細かいことを⾔うと information̲schema の仲間
22/54
SHOW vs i̲s / p̲s
i̲s, p̲sへのアクセスは完全なSQL
SHOW にも LIKE や WHERE が書けるけど、 ORDER BY, GROUP BY には対
応していない
-
SELECTアクセスが基本な奴らだから(︖)変にパースを要
求するものが あんまり ない
たまにある-
23/54
SHOW vs i̲s / p̲s
SHOW GLOBAL STATUS
information̲schema.GLOBAL̲STATUS(*),
performance̲schema.global̲status
SHOW PROCESSLIST
information̲schema.PROCESSLIST, performance̲schema.threads
SHOW ENGINE INNODB STATUS
information̲schema.INNODB̲METRICS
SHOW SLAVE STATUS
performance̲schema.replication̲connection̲configuration,
replication̲applier̲status̲by̲coordinator, ..
SHOW TABLE STATUS
information̲schema.TABLES
24/54
information̲schema vs performance̲schema
information̲schema
SQLでアクセスする時に情報が集められる。運が悪いと刺さる
performance̲schema
既に情報は蓄積されていて、SQLでアクセスする時は引っ張り出すだけ。少
しずつオーバーヘッドが載る
25/54
SHOW GLOBAL STATUS
information̲schema.GLOBAL̲STATUS
グローバルのステータスカウンターと、今⽣きている全てのthdのステータ
スカウンターを ⾜し合わせて 表⽰する
performance̲schema.global̲status
各thdがステータスカウンターをインクリメントする時ついでにp̲sがインク
リメントされる
26/54
SHOW PROCESSSLIST
information̲schema.PROCESSLIST
各thdを1個ずつロックしてステータスを表⽰する
performance̲schema.threads
各thdがStateを変更するたびにp̲sが更新される
27/54
performance̲schema #とは
イベントベースのプロファイラー
インストゥルメントを通過するたびに performance_schema
スキーマのテーブルに情報が蓄積される
機能の名前としての「パフォーマンススキーマ」、スキーマ
の名前空間として「performance̲schemaスキーマ(データ
ベース)」、パフォーマンススキーマの情報を格納する専⽤
の「performance̲schemaストレージエンジン」があるの
がややこしい
オンメモリーストレージエンジンなので永続化はしない-
記録に特化しているので参照は地味に遅い(MySQL 8.0で良くなるら
しい)
-
i̲sだったら「刺さったか︕︖」と思うくらい待たされても、p̲sは刺
さってなくて単に重いだけの場合が多い
-
28/54
information̲schema vs performance̲schema
i̲sはMySQL 5.1のInnoDB Plugin以降だんだん便利に
INNODB̲TRXとかINNODB̲LOCK̲WAITSとかべんり-
地味にMySQL 5.6とそれ以降で追加されているものは⾊々楽しい-
p̲sは5.6で急に開花した
実装としてはMySQL 5.5からあったけど5.5のp̲sは(我々目線で
は)使いようがなかった
-
5.6から低オーベーヘッド、省メモリーで「ジャンキー向け機能」か
ら「⼀般的なモニタリングに使えるように」
MySQL 5.5まではエージェント型だったMySQL Enterprise Monitorも5.6とそれ以
降はp̲sを使ってエージェントレスになったことだし
-
29/54
たとえばテーブルサイズ
innodb_stats_on_metadata= 0 にすること︕ (5.6とそれ以
降はデフォルトで0)
LIMITはお好みで。⼤概、トップ20とか30とか取って置け
ば⾜りると思う
i̲sだからもちろん誤差はある。リアルタイムな値じゃなく
てデイリーやウィークリーで⼗分
30/54
たとえばテーブルサイズ
mysql> SELECT CONCAT(table_schema, '.', table_name) AS table_name,
-> table_rows, data_length + index_length AS table_size,
-> data_free, COALESCE(auto_increment, 0) AS auto_increment
-> FROM information_schema.tables
-> ORDER BY table_size DESC
-> LIMIT 10;
+-------------+------------+------------+-----------+----------------+
| table_name | table_rows | table_size | data_free | auto_increment |
+-------------+------------+------------+-----------+----------------+
| fe.bbb18c90 | 25224307 | 4578082816 | 7340032 | 27979876 |
| fe.34579d37 | 18991963 | 2065661952 | 4194304 | 19482172 |
| fe.61c622dc | 21195791 | 1474297856 | 7340032 | 21744792 |
| fe.78e73102 | 4285220 | 1121239040 | 5242880 | 4179815 |
| fe.4b581bb9 | 4167617 | 706543616 | 5242880 | 4179816 |
| fe.faaafde9 | 4588106 | 538378240 | 5242880 | 4598839 |
| fe.5ae66d4a | 4117296 | 501055488 | 4194304 | 4127825 |
| fe.652f200b | 4169485 | 453672960 | 5242880 | 0 |
| fe.8363482f | 4169357 | 432095232 | 6291456 | 0 |
| fe.9287128c | 2127303 | 265158656 | 7340032 | 2132172 |
+-------------+------------+------------+-----------+----------------+
10 rows in set (0.04 sec)
31/54
たとえばテーブルサイズ
32/54
たとえばspin̲rounds
mysql> SELECT name, count
-> FROM information_schema.innodb_metrics
-> WHERE name LIKE '%spin%';
+------------------------------+------------+
| name | count |
+------------------------------+------------+
| innodb_rwlock_s_spin_waits | 0 |
| innodb_rwlock_x_spin_waits | 0 |
| innodb_rwlock_sx_spin_waits | 381205234 |
| innodb_rwlock_s_spin_rounds | 1865126843 |
| innodb_rwlock_x_spin_rounds | 9173666588 |
| innodb_rwlock_sx_spin_rounds | 6758611710 |
+------------------------------+------------+
6 rows in set (0.00 sec)
33/54
たとえばspin̲rounds
34/54
たとえばInnoDBバッファプールの内訳
information̲schema.innodb̲buffer̲page,
innodb̲buffer̲page̲lruで⾒られるけれど
このクエリーInnoDBバッファプールが⼤きければ⼤きいほ
ど負荷⾼いので、流⾏ってるところでは常⽤には向かないと
思う
sys.innodb̲buffer̲stats̲by̲schema,
innodb̲buffer̲stats̲by̲table,
schema̲table̲statistics̲with̲bufferあたりもこのテーブ
ルに触るので注意だ
35/54
たとえばInnoDBバッファプールの内訳
mysql> SELECT table_name, index_name,
-> SUM(number_records) AS records, SUM(data_size) AS data_size
-> FROM information_schema.innodb_buffer_page
-> WHERE table_name NOT LIKE 'mysql%'
-> GROUP BY table_name, index_name
-> ORDER BY data_size DESC
-> LIMIT 10;
+-----------------+------------+---------+-----------+
| table_name | index_name | records | data_size |
+-----------------+------------+---------+-----------+
| `7f`.`c3bc5a32` | e428d370 | 9841761 | 226620867 |
| `7f`.`c3bc5a32` | 54c2815f | 8066893 | 104999661 |
| `7f`.`c3bc5a32` | 88540e9a | 6926166 | 131772542 |
| `7f`.`c3bc5a32` | 462a1d8a | 4406127 | 83872645 |
| `7f`.`5af9ce85` | d52e82c1 | 3528078 | 60115390 |
| `7f`.`c3bc5a32` | PRIMARY | 3213476 | 115271756 |
| `7f`.`c3bc5a32` | 44c576bb | 3148514 | 59895974 |
| `7f`.`303a176f` | 1cbc573f | 2307297 | 43961563 |
| `7f`.`303a176f` | 25b1bd38 | 2067966 | 43606310 |
| `7f`.`dd50ab9f` | 88f49848 | 1816568 | 34545024 |
+-----------------+------------+---------+-----------+
10 rows in set (2.44 sec)
36/54
たとえばテーブルアクセスの読み書きレイテンシー
これ累計なので、累計のままストアするか差分にしてストア
するかは好み
Mackerelは累計値で投げてもグラフ側で差分描写にできて
いいなあ
37/54
たとえばテーブルアクセスの読み書きレイテンシー
mysql> SELECT CONCAT(object_schema, '.', object_name) AS object,
-> count_read, count_write, avg_timer_read, avg_timer_write
-> FROM performance_schema.table_io_waits_summary_by_table
-> WHERE object_schema NOT IN ('mysql', 'performance_schema', 'sys')
-> ORDER BY count_star DESC
-> LIMIT 10;
+-------------+------------+-------------+----------------+-----------------+
| object | count_read | count_write | avg_timer_read | avg_timer_write |
+-------------+------------+-------------+----------------+-----------------+
| fe.3dbf1566 | 18869612 | 17539638 | 13651880 | 20003808 |
| fe.5cf383d7 | 6068739 | 6069827 | 23701018 | 62976298 |
| fe.61c622dc | 0 | 3632649 | 0 | 41433832 |
| fe.34579d37 | 0 | 3328275 | 0 | 116323548 |
| fe.3b92ebab | 1071450 | 1089281 | 22963248 | 66586982 |
| fe.8363482f | 671311 | 1122995 | 41658716 | 97360142 |
| fe.5ae66d4a | 467985 | 1095348 | 48890534 | 102864366 |
| fe.bbb18c90 | 6 | 1153540 | 31729962 | 143108570 |
| fe.ee11cbb1 | 466088 | 468043 | 45651870 | 49815150 |
| fe.faaafde9 | 0 | 769627 | 0 | 125484436 |
+-------------+------------+-------------+----------------+-----------------+
10 rows in set (0.01 sec)
38/54
たとえばテーブルアクセスの読み書きレイテンシー
39/54
たとえばテーブルごとのRead/Write回数
Perlでも⼗分マカレる
40/54
たとえばクエリーダイジェスト
mysql> SELECT SUBSTR(digest_text, 1, 20) AS digest_text,
-> count_star, sum_timer_wait, sum_rows_examined, sum_rows_sent
-> FROM performance_schema.events_statements_summary_by_digest
-> WHERE DIGEST IS NOT NULL AND
-> count_star > 500
-> LIMIT 10;
+----------------------+------------+------------------+-------------------+---------------+
| digest_text | count_star | sum_timer_wait | sum_rows_examined | sum_rows_sent |
+----------------------+------------+------------------+-------------------+---------------+
| SELECT @@`version_co | 137289 | 25436857660000 | 0 | 137289 |
| SHOW SLAVE STATUS | 366546 | 112342782225000 | 0 | 0 |
| BEGIN | 13485295 | 575528569805000 | 0 | 0 |
| INSERT INTO `user_el | 627445 | 89789157785000 | 0 | 0 |
| SHOW MASTER LOGS | 229235 | 27056745066000 | 0 | 0 |
| SHOW PROCESSLIST | 229243 | 14607003138000 | 0 | 0 |
| SHOW ENGINE `INNODB` | 229239 | 123289626548000 | 0 | 0 |
| INSERT INTO `history | 525090 | 158209504507000 | 0 | 0 |
| INSERT INTO `user_di | 338137 | 121445307222000 | 0 | 0 |
| INSERT INTO `history | 3328275 | 1085911891224000 | 0 | 0 |
+----------------------+------------+------------------+-------------------+---------------+
10 rows in set (0.00 sec)
41/54
たとえばクエリーダイジェストごとのrows̲examined
42/54
たとえば更新系のクエリーダイジェストごとの発⾏数推移
43/54
SQLで引ける
ということは
44/54
Perlで(も)引
けるというこ
と
45/54
今使ってるヤーツ
46/54
今のヘーシャのステータスモニタリング(?)
メインはPMP for Cacti
深く監視するにはお⼿製スクリプト(Perl)
データはそれ⽤のMySQLに格納してあるので、必要に応じてre:dash
でグラフにする
-
⼀周回って「これをCactiに⾷わせればいいんじゃないか」とか「パー
ジするデータはrrdtoolに⼊れちゃえばいいんじゃないか」とか思って
きた
-
ショットでモニタリングしたい時はPMM
PMM ServerはDocker image-
PMM Agentはrpmで⼊れる-
47/54
それぞれに思うこと
PMP for Cacti
フロントエンドとデータソースメソッドが両⼊りなので⼿間のかからなさと
網羅率はいい。拡張が⾯倒
お⼿製Perl
フロントエンドを別に⽤意しなければいけないのがちょっと⾯倒。おとなし
くre:dashを真⾯目に運⽤すればいいのかも知れない
anemo eat er
ステータス監視じゃないけどスローログを⾷って可視化するヤーツ
PMM
ワンショットで使う分には最⾼。容量効率とPMM Serverがブラックボック
ス過ぎるのがネック
余談だけどお⼿製Perlの記録⽤MySQLは8.0にしたくて、8.0にして窓関数使えれば⾃分で差を取らなくてもSQL(re:dash側)だけで捗りそう
48/54
気に⼊っているところ
どれも吊るしのMySQLから情報が取れる
performance̲schemaはMySQL 5.6以降デフォルトでON
パラメーター何もいじらなくてもそれなりに情報が取れる-
innodb̲metricsをガリガリ使いたいなら
innodb_monitor_enable = all
だがしかしどちらも実質5.6から
49/54
おかげさまで
+---------+-------+
| version | count |
+---------+-------+
| 4.0 | 2 |
| 5.0 | 38 |
| 5.1 | 17 |
| 5.5 | 22 |
| 5.6 | 126 |
| 5.7 | 106 |
+---------+-------+
50/54
ほら
51/54
それ、Perlで
(も)できるで
しょ
52/54
みんな楽しいス
テータスモニタ
リングライフを
53/54
Questions
and/or
Suggestions?
54/54

More Related Content

What's hot

What's hot (20)

Galera cluster for high availability
Galera cluster for high availability Galera cluster for high availability
Galera cluster for high availability
 
MySQL8.0_performance_schema.pptx
MySQL8.0_performance_schema.pptxMySQL8.0_performance_schema.pptx
MySQL8.0_performance_schema.pptx
 
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
 
MariaDB 마이그레이션 - 네오클로바
MariaDB 마이그레이션 - 네오클로바MariaDB 마이그레이션 - 네오클로바
MariaDB 마이그레이션 - 네오클로바
 
MySQL Fabricでぼっこぼこにされたはなし
MySQL FabricでぼっこぼこにされたはなしMySQL Fabricでぼっこぼこにされたはなし
MySQL Fabricでぼっこぼこにされたはなし
 
MySQL8.0 SYS スキーマ概要
MySQL8.0 SYS スキーマ概要MySQL8.0 SYS スキーマ概要
MySQL8.0 SYS スキーマ概要
 
MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法
 
Innodb Deep Talk #2 でお話したスライド
Innodb Deep Talk #2 でお話したスライドInnodb Deep Talk #2 でお話したスライド
Innodb Deep Talk #2 でお話したスライド
 
Keepalived+MaxScale+MariaDB_운영매뉴얼_1.0.docx
Keepalived+MaxScale+MariaDB_운영매뉴얼_1.0.docxKeepalived+MaxScale+MariaDB_운영매뉴얼_1.0.docx
Keepalived+MaxScale+MariaDB_운영매뉴얼_1.0.docx
 
HandsOn ProxySQL Tutorial - PLSC18
HandsOn ProxySQL Tutorial - PLSC18HandsOn ProxySQL Tutorial - PLSC18
HandsOn ProxySQL Tutorial - PLSC18
 
MySQL SYSスキーマのご紹介
MySQL SYSスキーマのご紹介MySQL SYSスキーマのご紹介
MySQL SYSスキーマのご紹介
 
ProxySQL for MySQL
ProxySQL for MySQLProxySQL for MySQL
ProxySQL for MySQL
 
MySQL Timeout Variables Explained
MySQL Timeout Variables Explained MySQL Timeout Variables Explained
MySQL Timeout Variables Explained
 
雑なMySQLパフォーマンスチューニング
雑なMySQLパフォーマンスチューニング雑なMySQLパフォーマンスチューニング
雑なMySQLパフォーマンスチューニング
 
MySQLトラブル解析入門
MySQLトラブル解析入門MySQLトラブル解析入門
MySQLトラブル解析入門
 
イルカさんチームからゾウさんチームに教えたいMySQLレプリケーション
イルカさんチームからゾウさんチームに教えたいMySQLレプリケーションイルカさんチームからゾウさんチームに教えたいMySQLレプリケーション
イルカさんチームからゾウさんチームに教えたいMySQLレプリケーション
 
What's New in MySQL 5.7 Optimizer @MySQL User Conference Tokyo 2015
What's New in MySQL 5.7 Optimizer @MySQL User Conference Tokyo 2015What's New in MySQL 5.7 Optimizer @MySQL User Conference Tokyo 2015
What's New in MySQL 5.7 Optimizer @MySQL User Conference Tokyo 2015
 
MySQL 5.7が魅せる新しい運用の形
MySQL 5.7が魅せる新しい運用の形MySQL 5.7が魅せる新しい運用の形
MySQL 5.7が魅せる新しい運用の形
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
 
MySQL Performance Schema in Action: the Complete Tutorial
MySQL Performance Schema in Action: the Complete TutorialMySQL Performance Schema in Action: the Complete Tutorial
MySQL Performance Schema in Action: the Complete Tutorial
 

Similar to MySQLステータスモニタリング

ftp.jaist.ac.jpの低レイヤーの話 on 第九回 カーネル/VM探検隊
ftp.jaist.ac.jpの低レイヤーの話 on 第九回 カーネル/VM探検隊ftp.jaist.ac.jpの低レイヤーの話 on 第九回 カーネル/VM探検隊
ftp.jaist.ac.jpの低レイヤーの話 on 第九回 カーネル/VM探検隊
Kazuhiro Fujieda
 
Maatkit で MySQL チューニング
Maatkit で MySQL チューニングMaatkit で MySQL チューニング
Maatkit で MySQL チューニング
Kensuke Nagae
 
MySQL勉強会 インデックス編.2013 08-02
MySQL勉強会 インデックス編.2013 08-02MySQL勉強会 インデックス編.2013 08-02
MySQL勉強会 インデックス編.2013 08-02
CROOZ, inc.
 

Similar to MySQLステータスモニタリング (20)

Index shotgun on mysql5.6
Index shotgun on mysql5.6Index shotgun on mysql5.6
Index shotgun on mysql5.6
 
MySQLのGIS機能とか超入門 ~MyNA会2018年7月
MySQLのGIS機能とか超入門 ~MyNA会2018年7月MySQLのGIS機能とか超入門 ~MyNA会2018年7月
MySQLのGIS機能とか超入門 ~MyNA会2018年7月
 
ftp.jaist.ac.jpの低レイヤーの話 on 第九回 カーネル/VM探検隊
ftp.jaist.ac.jpの低レイヤーの話 on 第九回 カーネル/VM探検隊ftp.jaist.ac.jpの低レイヤーの話 on 第九回 カーネル/VM探検隊
ftp.jaist.ac.jpの低レイヤーの話 on 第九回 カーネル/VM探検隊
 
MySQL 5.7の次のMySQL 8.0はどんなものになるだろう
MySQL 5.7の次のMySQL 8.0はどんなものになるだろうMySQL 5.7の次のMySQL 8.0はどんなものになるだろう
MySQL 5.7の次のMySQL 8.0はどんなものになるだろう
 
道具を磨くことのススメ
道具を磨くことのススメ道具を磨くことのススメ
道具を磨くことのススメ
 
MySQL clients
MySQL clientsMySQL clients
MySQL clients
 
A Hacking Toolset for Big Tabular Files -- JAPAN.PM 2021
A Hacking Toolset for Big Tabular Files -- JAPAN.PM 2021A Hacking Toolset for Big Tabular Files -- JAPAN.PM 2021
A Hacking Toolset for Big Tabular Files -- JAPAN.PM 2021
 
Maatkit で MySQL チューニング
Maatkit で MySQL チューニングMaatkit で MySQL チューニング
Maatkit で MySQL チューニング
 
ペパボ de MySQL
ペパボ de MySQLペパボ de MySQL
ペパボ de MySQL
 
MySQL勉強会 インデックス編.2013 08-02
MySQL勉強会 インデックス編.2013 08-02MySQL勉強会 インデックス編.2013 08-02
MySQL勉強会 インデックス編.2013 08-02
 
Oracle Database Standard Editionでの運用いろいろ
Oracle Database Standard Editionでの運用いろいろOracle Database Standard Editionでの運用いろいろ
Oracle Database Standard Editionでの運用いろいろ
 
20160929_InnoDBの全文検索を使ってみた by 株式会社インサイトテクノロジー 中村範夫
20160929_InnoDBの全文検索を使ってみた by 株式会社インサイトテクノロジー 中村範夫20160929_InnoDBの全文検索を使ってみた by 株式会社インサイトテクノロジー 中村範夫
20160929_InnoDBの全文検索を使ってみた by 株式会社インサイトテクノロジー 中村範夫
 
[db tech showcase Tokyo 2015] A14:Amazon Redshiftの元となったスケールアウト型カラムナーDB徹底解説 その...
[db tech showcase Tokyo 2015] A14:Amazon Redshiftの元となったスケールアウト型カラムナーDB徹底解説 その...[db tech showcase Tokyo 2015] A14:Amazon Redshiftの元となったスケールアウト型カラムナーDB徹底解説 その...
[db tech showcase Tokyo 2015] A14:Amazon Redshiftの元となったスケールアウト型カラムナーDB徹底解説 その...
 
MySQLに本格GIS機能がやってきた~MySQL8.0最新情報~@OSC2018北海道
MySQLに本格GIS機能がやってきた~MySQL8.0最新情報~@OSC2018北海道MySQLに本格GIS機能がやってきた~MySQL8.0最新情報~@OSC2018北海道
MySQLに本格GIS機能がやってきた~MySQL8.0最新情報~@OSC2018北海道
 
2016/12/15 SQLチューニングと対戦格闘ゲームの類似性について語る。 JPOUG Advent Calendar 2016 Day 15
2016/12/15 SQLチューニングと対戦格闘ゲームの類似性について語る。 JPOUG Advent Calendar 2016 Day 152016/12/15 SQLチューニングと対戦格闘ゲームの類似性について語る。 JPOUG Advent Calendar 2016 Day 15
2016/12/15 SQLチューニングと対戦格闘ゲームの類似性について語る。 JPOUG Advent Calendar 2016 Day 15
 
まだ統計固定で消耗してるの? - Bind Peek をもっと使おうぜ! 2015 Edition -
まだ統計固定で消耗してるの? - Bind Peek をもっと使おうぜ! 2015 Edition -まだ統計固定で消耗してるの? - Bind Peek をもっと使おうぜ! 2015 Edition -
まだ統計固定で消耗してるの? - Bind Peek をもっと使おうぜ! 2015 Edition -
 
寿司blogが書けなくて嵌った話(MySQL/絵文字対応)
寿司blogが書けなくて嵌った話(MySQL/絵文字対応)寿司blogが書けなくて嵌った話(MySQL/絵文字対応)
寿司blogが書けなくて嵌った話(MySQL/絵文字対応)
 
DB tech showcase_tokyo2018_LOCONDO
DB tech showcase_tokyo2018_LOCONDODB tech showcase_tokyo2018_LOCONDO
DB tech showcase_tokyo2018_LOCONDO
 
MySQLerの7つ道具
MySQLerの7つ道具MySQLerの7つ道具
MySQLerの7つ道具
 
5 古雷my sql源碼與資料庫規範
5 古雷my sql源碼與資料庫規範5 古雷my sql源碼與資料庫規範
5 古雷my sql源碼與資料庫規範
 

More from yoku0825

More from yoku0825 (19)

逝くぞ最新版、罠の貯蔵は十分か
逝くぞ最新版、罠の貯蔵は十分か逝くぞ最新版、罠の貯蔵は十分か
逝くぞ最新版、罠の貯蔵は十分か
 
MySQLレプリケーションあれやこれや
MySQLレプリケーションあれやこれやMySQLレプリケーションあれやこれや
MySQLレプリケーションあれやこれや
 
片手間MySQLチューニング戦略
片手間MySQLチューニング戦略片手間MySQLチューニング戦略
片手間MySQLチューニング戦略
 
MySQLを割と一人で300台管理する技術
MySQLを割と一人で300台管理する技術MySQLを割と一人で300台管理する技術
MySQLを割と一人で300台管理する技術
 
わたしを支える技術
わたしを支える技術わたしを支える技術
わたしを支える技術
 
Dockerイメージで誰でも気軽にMroonga体験
Dockerイメージで誰でも気軽にMroonga体験Dockerイメージで誰でも気軽にMroonga体験
Dockerイメージで誰でも気軽にMroonga体験
 
MySQLアンチパターン
MySQLアンチパターンMySQLアンチパターン
MySQLアンチパターン
 
MySQLerの7つ道具 plus
MySQLerの7つ道具 plusMySQLerの7つ道具 plus
MySQLerの7つ道具 plus
 
MySQL 5.7の次のMySQLは
MySQL 5.7の次のMySQLはMySQL 5.7の次のMySQLは
MySQL 5.7の次のMySQLは
 
MHAの次を目指す mikasafabric for MySQL
MHAの次を目指す mikasafabric for MySQLMHAの次を目指す mikasafabric for MySQL
MHAの次を目指す mikasafabric for MySQL
 
5.7の次のMySQL
5.7の次のMySQL5.7の次のMySQL
5.7の次のMySQL
 
mikasafabric for MySQL
mikasafabric for MySQLmikasafabric for MySQL
mikasafabric for MySQL
 
とあるイルカの近況報告
とあるイルカの近況報告とあるイルカの近況報告
とあるイルカの近況報告
 
MySQLと正規形のはなし
MySQLと正規形のはなしMySQLと正規形のはなし
MySQLと正規形のはなし
 
MySQLおじさんの逆襲
MySQLおじさんの逆襲MySQLおじさんの逆襲
MySQLおじさんの逆襲
 
地雷職人の朝は早い
地雷職人の朝は早い地雷職人の朝は早い
地雷職人の朝は早い
 
紹介 of Anemometer
紹介 of Anemometer紹介 of Anemometer
紹介 of Anemometer
 
MySQL5.7で遊んでみよう
MySQL5.7で遊んでみようMySQL5.7で遊んでみよう
MySQL5.7で遊んでみよう
 
光のMySQL 5.7
光のMySQL 5.7光のMySQL 5.7
光のMySQL 5.7
 

Recently uploaded

2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
ssuserbefd24
 

Recently uploaded (11)

YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
 
【AI論文解説】Consistency ModelとRectified Flow
【AI論文解説】Consistency ModelとRectified Flow【AI論文解説】Consistency ModelとRectified Flow
【AI論文解説】Consistency ModelとRectified Flow
 
2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx
2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx
2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx
 
論文紹介: Exploiting semantic segmentation to boost reinforcement learning in vid...
論文紹介: Exploiting semantic segmentation to boost reinforcement learning in vid...論文紹介: Exploiting semantic segmentation to boost reinforcement learning in vid...
論文紹介: Exploiting semantic segmentation to boost reinforcement learning in vid...
 
20240523_IoTLT_vol111_kitazaki_v1___.pdf
20240523_IoTLT_vol111_kitazaki_v1___.pdf20240523_IoTLT_vol111_kitazaki_v1___.pdf
20240523_IoTLT_vol111_kitazaki_v1___.pdf
 
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
 
5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一
5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一
5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一
 
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
 
MPAなWebフレームワーク、Astroの紹介 (その2) 2024/05/24の勉強会で発表されたものです。
MPAなWebフレームワーク、Astroの紹介 (その2) 2024/05/24の勉強会で発表されたものです。MPAなWebフレームワーク、Astroの紹介 (その2) 2024/05/24の勉強会で発表されたものです。
MPAなWebフレームワーク、Astroの紹介 (その2) 2024/05/24の勉強会で発表されたものです。
 
論文紹介: Offline Q-Learning on diverse Multi-Task data both scales and generalizes
論文紹介: Offline Q-Learning on diverse Multi-Task data both scales and generalizes論文紹介: Offline Q-Learning on diverse Multi-Task data both scales and generalizes
論文紹介: Offline Q-Learning on diverse Multi-Task data both scales and generalizes
 
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアルLoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
 

MySQLステータスモニタリング