SlideShare a Scribd company logo
MySQL クラウド向け InnoDB チューニング
波多野 信広
株式会社インフィニットループ
2015/09/10
ver. 0.9.3
自己紹介
●
波多野 信広 (twitter @nobuHatano)
●
1969年札幌生まれ
●
東京で商用DBサーバーのサポートエンジニアを十数年
●
2012年にUターン
●
(株)インフィニットループのインフラエンジニア
●
ソーシャルゲームやWebサービスのMySQLと格闘して三年
MySQL クラウド向け InnoDB チューニング
アジェンダ
●
オンプレミスな物理サーバーとクラウドの仮想サーバーとの違い
●
クラウドでの MySQL サーバー構成例
●
Linux や MySQL InnoDB の設定解説
●
Cacti グラフを使っての実践的パフォーマンスチューニング
●
まとめ
オンプレミスな物理サーバー
●
スペックが高い部品を使って自由に構成出来る
●
電源、ディスク、等ハードウェアの障害確率高い
●
ハードウェアの性能は一定している
●
コンスタントな負荷も、バースト的な負荷も、両方可能
●
占有しているリソース(CPU,ストレージ)はコンスタントに負荷をか
けるのが高スループットへ至る道
●
他者と共有しているリソース(ネットワーク)はバーストが得策
クラウドの仮想サーバー
●
データセンター内に集積され耐障害性のあるPCサーバーがホストサーバー
●
ゲストから見ると、電源停止など単純障害の確率は低い
●
ハードウェアが低速になったりハングする等物理では見ない障害に遭遇
●
仮想は共有、つまりタイムシェアリングなので、I/O負荷はバーストが得
意、コンスタントだと性能低下
●
ディスクはエンタープライズな SAN (Storage Area Network) の
RAID ストレージ
Linuxで SAN を使う課題:Write バリア
●
Write I/O (fsync) はHDD内キャッシュへ書き込みで更新終了
– DBには問題、Writeを毎回永続化するように指示する Write バリア
●
Writeバリア有効だと低速
– HDDはWriteスルーで毎回磁気メディアに書き込み
– 素のランダムWriteになり大幅に低速
●
SSDの寿命を伸ばす必要性 (+高速化)に反する
– RAIDコントローラーは冗長化しキャッシュはバッテリー保護
– Writeを溜めることでSSD書き込み約半分にして長寿命化
– 高速化も兼ねる
– Writeバリア無効化が必要
●
ではゲストの仮想サーバーなら Write バリアは?
物理と仮想の違い
●
ストレージは物理と仮想で負荷のかけ方の戦略(バースト/コンスタン
ト)から異なる
●
障害の発生頻度と種類が異なる
– 物理:高頻度の単純障害 - ACID の (D) が試される
– 仮想:低頻度だがハングアップなど特殊な障害 – 積極的な
Failoverが必要
●
ホスト側でのWriteバリア無効化 (データ保護を追及できない)
●
仮想サーバーを想定した割り切りが必要
●
これらをふまえてシステムを構築
クラウドでの MySQL サーバー構成例
DBマスタ
スレーブ1 スレーブ2 スレーブ3
予備
スレーブ
レプリケーション
アプリケーション
(Haproxy)
(MySQL proxy)
dbmへ
更新クエリ
dbsへ
参照クエリ
●
アプリケーションロジックでの
参照と更新の分離
●
MySQL proxy によるクエ
リ文型での参照と更新の
分離+スレーブ分散
●
Haproxy によるスレーブ
分散
●
内部DNS (mydns,
bind, etc..) によるスレー
ブ分散
●
/etc/hosts によるスレー
ブ・ラウンドロビン
●
意図的に低性能のスレーブを予備に
●
アプリからの参照に含めた場合は「坑道のカナリア」に
●
スレーブを動的に追加する際の種に使える
●
mysqldump取得に最適
●
別クラウド、別ゾーンを使うなど高信頼性追求
●
KPI調査など高負荷OLAPなクエリも本番中実行可能
ホスト名:dbm
ホスト名:dbs
クラウドでの InnoDB チューニングとは
●
前述のような構成で MySQL のサーバー群を構成しチューニング
– Read負荷はスレーブでスケールアウト可能
– DBマスタの負荷、つまりWrite負荷はスケールアウト不可
●
WriteWriteの性能をいかに高めるかの性能をいかに高めるか
Linux や MySQL InnoDB の設定解説
●
Linuxの設定
– vm.swappiness
– /proc/[pid]/limits
●
MySQLの設定
– max_connections
– innodb_flush_method, innodb_buffer_pool_size
– innodb_log_file_size, innodb_adaptive_flushing
– innodb_double_write
●
他の設定値は一般的なので割愛
vm.swappiness=1
●
Kernel はあればあるだけメモリをバッファに使います (free での表示)
●
メモリが不足で返却されますが、バッファに更新データがあるとすぐ返せません
●
(従来は)ユーザープロセスは Kernel とのメモリの取り合いに負けてスワップア
ウトされたくないので vm.swappiness=0
●
Kernel 2.6.32-303 (CentOS 6.4+) から動作が変わり、0 にすると一切
スワップされなくなりました。不足すると OOM Killer によってユーザープロセス、つ
まり MySQL が kill されます
●
スワップは出来るだけ避けたいが、OOMは困るので、sysctl の設定では
vm.swappiness=1 を使いましょう
# free -m
total used free
Mem: 7517 4451 3065
-/+ buffers/cache: 277 7239
# vmstat -a
procs -----------memory---------- -
r b swpd free inact active
0 0 0 3125888 2614436 1684840
オープン数 /proc/[pid]/limits
●
ulimit や /etc/security/limits.conf は PAM経由でのログイン処理で適用
●
デーモンプロセスは起動スクリプトで ulimit の設定が必要
●
稼働プロセスの実際の値は cat /proc/[pid]/limits で確認可能
●
Max open files (ulimit -n 相当)
– ファイル+ソケットの最大数。デフォルト 1024 は足りない。65535 など最大化
– my.cnf の [mysqld_safe] open-files-limit で設定
●
Max processes (ulmit -u 相当)
– プロセス/スレッドの最大数。MySQL はコネクション毎に1スレッド生成するので
max_connections の分が必要
– デフォルトの 1024 で足りている(理由は後述)
心を強く保って max_connections<1000
●
InnoDB のロールバックセグメント上のUndoスロットの上限1023
(MySQL5.1)、拡張され130944 (MySQL5.5+)
●
クラウドの普通のサーバーでは InnoDBの同時実行トランザクション
は1000が実用的な上限
●
厳密にはコネクション ≠ トランザクション、DBマスタへのアクセスなの
で コネクション数 ≒ トランザクション数
●
デフォルトの max_connections=151 で十分実用的
●
では、何故、そしていつ増やしてしまうのか?
Connection 不足の原因
●
“Too Many Connections” 接続エラーが出ると、 max_connections が
少な過ぎるので引き上げるべき、とインフラエンジニアは集中砲火を浴びますが
●
Connectionが不足する原因
– 問題クエリの実行やプラットフォーム(ホスト)障害で MySQL が遅延また
はハング状態になったとき
– スクリプト言語で持続的接続を使う場合、明示的にはcloseさせないので、
プロセスの寿命とのバランス次第で Idle なコネクションが滞留する
●
(PHPの場合)LBの特性、Apache の KeepAlive, MaxClients,
RequestsPerChild, PDO の Timeout, MySQL の wait_timeout で
バランス調整
– 同時に長時間トランザクションを多数実行で >1000
●
いずれも max_connections だけ >1000 にしても解決にならない
●
max_connections を決めたのでメモリの見積りに入ります
MySQL のメモリ見積り
●
物理メモリ = OS(ntp,cron) 基本部として64M + MySQL分
●
MySQL = スレッドバッファ * max_connections + グローバルバッファ + tmp テーブル
●
スレッドのバッファ
sort_buffer_size 256K
read_buffer_size 128K
join_buffer_size 256K
read_rnd_buffer_size 256K
デフォルト約1MB。実戦では sort_buffer_size と join_buffer_size の増量が必要
●
グローバルなバッファ
key_buffer_size 8M
innodb_buffer_pool_size 128M ⇒??? (指定より約10%多く取得される)
innodb_log_buffer_size 8M
innodb_additional_mem_pool_size 8M
●
ソートやJoinで使われる内部のMEMORYテーブル
●
max_heap_table_size = tmp_table_size = 16M (増やす時も同じ値にすること)
デフォルトだと 約255MB + バッファープール +Kernel バッファ分の配慮
innodb_buffer_pool_size を見積るための長い旅
同期 I/O の O_SYNC をブロックデバイスで
アプリケーション
バッファ
カーネル(ファイルシステム)
バッファ
ディスク
キャッシュ
不揮発メディア
HDDMemory
innodb_buffer_pool_size を見積るための長い旅
同期 I/O の O_SYNC をファイルに対して
アプリケーション
バッファ
カーネル(ファイルシステム)
バッファ
ディスク
キャッシュ
不揮発メディア
HDDMemory
innodb_buffer_pool_size を見積るための長い旅
非同期な write と fsync をファイルに対して
アプリケーション
バッファ
カーネル(ファイルシステム)
バッファ
ディスク
キャッシュ
不揮発メディア
HDDMemory
innodb_buffer_pool_size を見積るための長い旅
非同期 O_DIRECT と fsync をファイルに対して
アプリケーション
バッファ
ディスク
キャッシュ
不揮発メディア
HDDMemory
カーネル(ファイルシステム)
バッファ
innodb_buffer_pool_size を見積るための長い旅
●
MySQL 5.6.7+ での innodb_flush_method 対応表
データ ログ メリット デメリット
fsync
(デフォルト)
fsync fsync ●
カーネルのキャッシュで2段
キャッシュ
●
fsyncは汎用なので仮想
との親和性が高い
●
二重にキャッシュされ
無駄
●
カーネルの分考慮し
てバッファプールやや
小さめに
O_DSYNC fsync O_SYNC ログの書き込みで信頼性が
高くなる
ログの書き込み速度が
落ちる
O_DIRECT O_DIRECT
+
fsync
fsync ●
バッファプールを目一杯大
きく出来る
●
ホスト直づけの物理ディス
クなら速い
●
SANだと低速
●
ジャーナルFSだと
O_DSYNC に変更
●
バッファプールに収まらな
いとディスク直利用で低
速
innodb_buffer_pool_size を見積るための長い旅
●
物理メモリの80%をバッファープールで O_DIRECT が鉄板?
– クラウドではSANの可能性が高く O_DIRECT 低速
– 実戦では InnoDB のテーブルスペースは、物理メモリを上回る
事が多い
●
総合的に判断してデフォルト(fsync)が得策
innodb_buffer_pool_size を見積るための長い旅
●
innodb_flush_method=fsync (default)
●
innodb_buffer_pool_size
= (バッファープールに使ってよいメモリ)* 3/4 で始める
●
例: 1G メモリのマシンでデフォルトのスレッドバッファ設定で
 ((1024M – 255M) * 0.9 ) * 3/4 = 525M
●
バッファープールのサイズが決まったら次はログのサイズです
物理Write量を支配する innodb_log_file_size
InnoDB ディスクI/O のしくみ (InnoDB ログファイル)
123
更新データ
MySQLのメモリ InnoDB ログファイル
●
連続データをシリアルにディスクに書き込むので非常に高速
●
HDDの SAN で SSD 並に速い
●
ログファイルに書く≒更新トランザクション終了
●
最大 4GB (MySQL 5.5), 512GB (MySQL 5.6+)
物理Write量を支配する innodb_log_file_size
InnoDB ディスクI/O のしくみ (InnoDB データファイル)
23
更新データ
MySQLのメモリ InnoDB データファイルバッファープール
1 テーブル インデックス
23 1
23 121 3
●
バッファープールに格納するところまでで更新クエリ終了
●
後続クエリの更新はメモリ上で完結する
●
まとめてディスクに書き出す(チェックポイント)
●
データ量も多く、ランダムWriteなチェックポイントは重い処理
物理Write量を支配する innodb_log_file_size
InnoDB ディスクI/O のしくみ (InnoDB データファイル)
ログファイル バッファープール
今、更新がここ
メモリのみに更新データ
ログファイルで消えないデータ確保
データファイル
というのは許されない
全ての更新トランザクショ
ンを止めてでもディスクへ
の書き出しを行う
この量が Checkpoint Age
物理Write量を支配する innodb_log_file_size
Fuzzy Checkpoint
●
アイドル時に定期的に発動しバッファープール上の古いダーティページから1回あたりは少量の
書き出しを行う
●
負荷低く影響低いのでチューニング不要
Sharp Checkpoint
●
ログファイルサイズの閾値(75~90%)を超えると発動し全てのダーティページを書き出す
●
ログファイルサイズが大きいとディスクのWrite量が多くなり高負荷
●
Write 中でも更新は入ってくるので、排出(書き出し)速度が負けて使用率100%が続
くと新規トランザクションは実行不可に
●
バーストI/Oなのでクラウドに合っていて高パフォーマンス出せる場合も
Adaptive Flushing (MySQL5.6+)
●
更新量に応じた書き出しを innodb_io_capacity_max に従って、常時行う
●
ディスクの IOPS がプロビジョニングで保証されているなら Sharp Checkpoint の回避に
●
IOPSプロビジョニングが無いクラウドでコンスタントに負荷をかけると、遅延の元にも
●
デフォルトON
物理Write量を支配する innodb_log_file_size
●
MySQL 5.6+ の Adaptive Flushing を使うかどうかで MySQL のWriteの性格が
ガラッと変わる
●
デフォルト値
– innodb_adaptive_flushing=ON
– innodb_io_capacitiy=200
– innodb_io_capacity_max=2000
– innodb_log_file_size=50M, innodb_log_files_in_group=2
– 100MBのCheckpointが溜まらないよう常時I/Oがかかる
●
1TB SSD で 3000 iops が目安。Adaptive Flushing のデフォルト値はクラウドだと
70Gの IOPS プロビジョニングSSD相当(210 iops)
●
物理の場合の参考 1.5K RPM HDD で 200 iops 相当
●
クラウドでHDDモデルなら 100 iops/1000 iops 以下に設定
物理Write量を支配する innodb_log_file_size
●
クラウドでのディスクI/Oはそもそもバーストなら高性能、コンスタ
ントだと低性能なので、たまった更新量に応じて常時I/Oが発
生する Adaptive Flushing を上手く使うのは難しい
●
もしSSDモデルなら ⇒ デフォルト設定のまま log_file_size
をチューニングしていく
●
もしHDDモデルなら ⇒ Adaptive Flushing は OFF にし
て、log_file_size をチューニングしていく
物理Write量を支配する innodb_log_file_size
log_file_size * log_files_in_group  
バッファープール (サーバーのメモリの6割)
ハイリスクハイリターン法:  ログファイルサイズはバッファープールと同等に
利点:
●
Adaptive Flushing OFFかつ1日分の更新が上手くおさまれば、InnoDBがシーケンシャルな
ログ書き込みとメモリ上だけで動作出来る
欠点:
●
クラッシュ時の処理が長大に
●
Adaptive Flushing ON で、プロビジョニングiopsじゃないHDD/SSDだとコンスタントに負荷に
●
1日の更新量 の見積りを誤ると、長いトランザクション停止(数分〜数時間)が発生して絶大
なダメージ
物理Write量を支配する innodb_log_file_size
log_file_size * log_files_in_group  100MB〜1GB未満
バッファープール (サーバーのメモリの6割)
安全第一法:クラッシュ時の処理も考慮してログファイルサイズほどほど
利点:
●
クラッシュ時のリカバリも問題なし
●
ときどき Sharp Checkpoint が発生するが量が少ないので処理のインパクトが小さい
●
1日の更新量を正確に予測しなくてよい
欠点:
●
ディスクへの書き込みが脈動的に発生しMySQLの性能も脈動的に変化する
●
プロビジョニングiops の高性能SSDを使っている場合、性能を使い切れていない可能性
使うか使わないか、それが問題だ Double Write
●
InnoDB のテーブルスペースのフラッシュは 16KB のページ単位、一方
Kernel は4KB、ディスクのセクタは 512B 単位なので、OSやハードウェ
アのクラッシュ時、アプリ側の fsync では書き込み終了なのに、そのページ
が実際には部分的にしか書かれていないというパーシャルWriteが発生
●
先に Double Write バッファに書いてから、次に同じデータのWriteを行
う仕組みが考案された
●
HDD内キャッシュ(4MB〜)での効果もあり、2倍はかからず 1.05〜
1.1 倍程度のオーバーヘッドだった
使うか使わないか、それが問題だ Double Write
●
I/Oを高速化する技術
– プリフェッチ:read 時の連続ブロックの先読み
– Writeマージ:順序を入れ替えてでも1回の書き込み量をまとめる 
(これを止めさせるのがWriteバリア)
– Kernel ⇒ RAID コントローラー ⇒ SSD/HDD のあらゆる段階
でこの手法が使われている
●
特定の小領域(Double Write) ばかりを高頻度で書くと、全体の
Writeマージやプリフェッチによる高速化に悪影響となる
– ext4 だと 1.5倍+に遅延する
– Double Write でパフォーマンスが低下しないのは物理HDD1本の
とき
使うか使わないか、それが問題だ Double Write
●
ext4 data=jornal マウントや XFS などジャーナリングFSを使えば
Double Write と同様の保護が可能でオーバーヘッドも1.1程度
●
クラウドでは積極的にFailoverさせる構成をとっているので、落ちたサー
バーは棄てるだけでよい
●
Failover が通用しないクラウド全体障害、ゾーン(データーセンター)
障害に備えるには、予備サーバーなど特定のサーバーを手厚く保護する
●
全体障害の確率を考えると、支払っているオーバーヘッドに見合わないの
で、負荷のかかる主力サーバーは、思い切って Double Write は OFF
にしましょう
グラフを使っての実践的パフォーマンスチューニング
●
負荷試験や本番でのデータを元に絶え間なく改善するのが
チューニング
●
威力を発揮するのが、Cacti グラフ
●
Percona MySQL Monitoring Template for Cacti
●
Percona 社提供の Cacti のグラフテンプレート
●
MySQL の詳細なグラフ
●
Cacti の Thold プラグインを使えば監視アラートとしてメール
を発信、Cacti を監視インフラにすることもできる
Percona のグラフでのチューニング
●
クエリのチューニング
●
MySQL Select Types
●
MySQL Handlers
●
システム、I/O廻りのチューニング
●
InnoDB Checkpoint Age
MySQL Select Types でアプリのSELECTの書き方を判定
テーブルまたはイン
デックスで
●
Select Scan
全件検索
●
Select Range
where で範囲を
制限してselect
Select Range の割合 >> Select Scan の割合  が望ましい   これは NG
m(ミリ) なのでグラフ
では見えませんが
●
「JOIN するときはインデックスを使って行う」 という鉄則
●
鉄則を破ったクエリが存在
MySQL Select Types でアプリのSELECTの書き方を判定
MySQL Handlers グラフでI/O量を把握
MySQL
セッション管理
クエリをHandler命令に
コンパイル
KVS的
Handler 命令
ストレージエンジンデータ
操作
Handler のタイプ詳細
●
Handler Read First テーブルやインデックスの全件検索スキャンで最初に先頭レコードの取得を
行います。その回数。少ないほうが良い
●
Handler Read Key インデックスのキー値に基づいて行を読んだ回数。
●
Handler Read Next キー値に基づいて行を特定した後、後続の行を読んだ回数。
●
Handler Read Prev キー値で行を決めた後、その前の行を取得した回数。
●
Handler Read Rnd InnoDB でプライマリキーの値を指定して1行読んだ回数。
ディスクへのアクセス方法がシーケンシャルアクセスではなくランダムアクセスということで、MySQL の世界では歴史的にピンポイント
で1行読み込む動作に Random Read という用語
●
Handler Read Rnd Next Read Rnd によって行を読んだ後、後続行を読み取った回数。
●
Read Key < Read Next インデックス使っていても範囲で読み込みしている
●
Read Rnd < Read Rnd Next Rnd Next の比率が高いと、プライマリキーを使っていても広
範に読んでいるのでやはりよくない傾向
グラフの形で観察できます!!!
前出の MySQL Handlers グラフだと
Read Next で読み込ん
だ回数が圧倒的なので、
インデックスを使った範囲
読み込みの割合が多いこ
とがわかります
システム、I/O廻りのチューニング
●
InnoDB Checkpoint Age
 
●
バッファプール上に更新が溜まる速度に対して、fuzzy checkpoint
や adaptive flushing が打ち勝っている状態
●
I/O の能力を使い切っていないのでまだ更新増やせそう
システム、I/O廻りのチューニング
●
InnoDB Checkpoint Age
 
Sharp checkpoint がおこ
なわれているがすぐ更新をは
けているので問題なし
●
Sharp Checkpoint が断続的に発生
●
Adaptive Flushing がOFFか弱め
●
ディスク能力を使い切っているある意味で理想的なバランス
●
I/O 負荷による微小な遅延がアプリに影響出ていないか確
認しましょう
システム、I/O廻りのチューニング
●
InnoDB Checkpoint Age
 
●
水平線になった場合 sharp checkpoint が途切れることなく走っている状態
●
Checkpoint Age 100%到達時のトランザクション停止が微小で済んでいるか、長時
間に及んでいるか、グラフでは区別がつきません
●
必ずアプリケーションのログで確認しましょう
まとめ
 
●
使っているハードウェア、クラウドの環境、実行されてい
るクエリ、サーバーの構成によって最適な設定は異
なってきます
●
MySQL や Linux のバージョンが変わることでも設
定の内容や意味も刻々と変わります
●
あなたの MySQL もきっとまだチューニングの余地が
あります、ノウハウを共有して MySQL を盛り上げま
しょう!!

More Related Content

What's hot

MySQL5.6でGTIDを試してそっと閉じた
MySQL5.6でGTIDを試してそっと閉じたMySQL5.6でGTIDを試してそっと閉じた
MySQL5.6でGTIDを試してそっと閉じた
Emma Haruka Iwao
 
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
Hironobu Suzuki
 
MySQL 5.7とレプリケーションにおける改良
MySQL 5.7とレプリケーションにおける改良MySQL 5.7とレプリケーションにおける改良
MySQL 5.7とレプリケーションにおける改良
Shinya Sugiyama
 
MySQLの運用でありがちなこと
MySQLの運用でありがちなことMySQLの運用でありがちなこと
MySQLの運用でありがちなこと
Hiroaki Sano
 
MySQL SYSスキーマのご紹介
MySQL SYSスキーマのご紹介MySQL SYSスキーマのご紹介
MySQL SYSスキーマのご紹介
Shinya Sugiyama
 
もしOracleDBAがMySQLを管理することになったときの注意点など
もしOracleDBAがMySQLを管理することになったときの注意点などもしOracleDBAがMySQLを管理することになったときの注意点など
もしOracleDBAがMySQLを管理することになったときの注意点など
Kentaro Kitagawa
 
Snowflake Architecture and Performance
Snowflake Architecture and PerformanceSnowflake Architecture and Performance
Snowflake Architecture and Performance
Mineaki Motohashi
 
外部キー制約に伴うロックの小話
外部キー制約に伴うロックの小話外部キー制約に伴うロックの小話
外部キー制約に伴うロックの小話
ichirin2501
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
 
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
NTT DATA OSS Professional Services
 
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
NTT DATA Technology & Innovation
 
PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)
PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)
PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)
Uptime Technologies LLC (JP)
 
SQL Server コンテナ入門(Kubernetes編)
SQL Server コンテナ入門(Kubernetes編)SQL Server コンテナ入門(Kubernetes編)
SQL Server コンテナ入門(Kubernetes編)
Tomoyuki Oota
 
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
Yahoo!デベロッパーネットワーク
 
Amazon Aurora - Auroraの止まらない進化とその中身
Amazon Aurora - Auroraの止まらない進化とその中身Amazon Aurora - Auroraの止まらない進化とその中身
Amazon Aurora - Auroraの止まらない進化とその中身
Amazon Web Services Japan
 
binary log と 2PC と Group Commit
binary log と 2PC と Group Commitbinary log と 2PC と Group Commit
binary log と 2PC と Group Commit
Takanori Sejima
 
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
yoku0825
 
Azure Database for PostgreSQL 入門 (PostgreSQL Conference Japan 2021)
Azure Database for PostgreSQL 入門 (PostgreSQL Conference Japan 2021)Azure Database for PostgreSQL 入門 (PostgreSQL Conference Japan 2021)
Azure Database for PostgreSQL 入門 (PostgreSQL Conference Japan 2021)
Keisuke Takahashi
 
PostgreSQLでスケールアウト
PostgreSQLでスケールアウトPostgreSQLでスケールアウト
PostgreSQLでスケールアウト
Masahiko Sawada
 
MySQL 8.0で憶えておいてほしいこと
MySQL 8.0で憶えておいてほしいことMySQL 8.0で憶えておいてほしいこと
MySQL 8.0で憶えておいてほしいこと
yoku0825
 

What's hot (20)

MySQL5.6でGTIDを試してそっと閉じた
MySQL5.6でGTIDを試してそっと閉じたMySQL5.6でGTIDを試してそっと閉じた
MySQL5.6でGTIDを試してそっと閉じた
 
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
 
MySQL 5.7とレプリケーションにおける改良
MySQL 5.7とレプリケーションにおける改良MySQL 5.7とレプリケーションにおける改良
MySQL 5.7とレプリケーションにおける改良
 
MySQLの運用でありがちなこと
MySQLの運用でありがちなことMySQLの運用でありがちなこと
MySQLの運用でありがちなこと
 
MySQL SYSスキーマのご紹介
MySQL SYSスキーマのご紹介MySQL SYSスキーマのご紹介
MySQL SYSスキーマのご紹介
 
もしOracleDBAがMySQLを管理することになったときの注意点など
もしOracleDBAがMySQLを管理することになったときの注意点などもしOracleDBAがMySQLを管理することになったときの注意点など
もしOracleDBAがMySQLを管理することになったときの注意点など
 
Snowflake Architecture and Performance
Snowflake Architecture and PerformanceSnowflake Architecture and Performance
Snowflake Architecture and Performance
 
外部キー制約に伴うロックの小話
外部キー制約に伴うロックの小話外部キー制約に伴うロックの小話
外部キー制約に伴うロックの小話
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法について
 
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
 
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
 
PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)
PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)
PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)
 
SQL Server コンテナ入門(Kubernetes編)
SQL Server コンテナ入門(Kubernetes編)SQL Server コンテナ入門(Kubernetes編)
SQL Server コンテナ入門(Kubernetes編)
 
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
 
Amazon Aurora - Auroraの止まらない進化とその中身
Amazon Aurora - Auroraの止まらない進化とその中身Amazon Aurora - Auroraの止まらない進化とその中身
Amazon Aurora - Auroraの止まらない進化とその中身
 
binary log と 2PC と Group Commit
binary log と 2PC と Group Commitbinary log と 2PC と Group Commit
binary log と 2PC と Group Commit
 
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
 
Azure Database for PostgreSQL 入門 (PostgreSQL Conference Japan 2021)
Azure Database for PostgreSQL 入門 (PostgreSQL Conference Japan 2021)Azure Database for PostgreSQL 入門 (PostgreSQL Conference Japan 2021)
Azure Database for PostgreSQL 入門 (PostgreSQL Conference Japan 2021)
 
PostgreSQLでスケールアウト
PostgreSQLでスケールアウトPostgreSQLでスケールアウト
PostgreSQLでスケールアウト
 
MySQL 8.0で憶えておいてほしいこと
MySQL 8.0で憶えておいてほしいことMySQL 8.0で憶えておいてほしいこと
MySQL 8.0で憶えておいてほしいこと
 

Similar to Dbtechshowcasesapporo mysql-turing-for-cloud-0.9.3

PHP on Windows Azure in Open Source Conference
PHP on Windows Azure in Open Source ConferencePHP on Windows Azure in Open Source Conference
PHP on Windows Azure in Open Source Conference
Microsoft
 
Windows Server 2012 のストレージ強化とエンタープライズへの活用
Windows Server 2012 のストレージ強化とエンタープライズへの活用Windows Server 2012 のストレージ強化とエンタープライズへの活用
Windows Server 2012 のストレージ強化とエンタープライズへの活用
Daichi Ogawa
 
Windows azureって何
Windows azureって何Windows azureって何
Windows azureって何
Kana SUZUKI
 
C32 DB Performance on Cloud by 安藤賀章
C32 DB Performance on Cloud by 安藤賀章C32 DB Performance on Cloud by 安藤賀章
C32 DB Performance on Cloud by 安藤賀章
Insight Technology, Inc.
 
既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~
じゅん なかざ
 
Awsのクラウドデザインパターンをwindows azureに持ってきてみた
Awsのクラウドデザインパターンをwindows azureに持ってきてみたAwsのクラウドデザインパターンをwindows azureに持ってきてみた
Awsのクラウドデザインパターンをwindows azureに持ってきてみた
Sunao Tomita
 
A 1-3 awsのクラウドデザインパターンをwindows-azureに持ってきてみた
A 1-3 awsのクラウドデザインパターンをwindows-azureに持ってきてみたA 1-3 awsのクラウドデザインパターンをwindows-azureに持ってきてみた
A 1-3 awsのクラウドデザインパターンをwindows-azureに持ってきてみた
GoAzure
 
Moot2013 moca ver0.3
Moot2013 moca ver0.3Moot2013 moca ver0.3
Moot2013 moca ver0.3
科 黄
 
de:code 2019 Cloud トラック 総まとめ! 完全版
de:code 2019 Cloud トラック 総まとめ! 完全版de:code 2019 Cloud トラック 総まとめ! 完全版
de:code 2019 Cloud トラック 総まとめ! 完全版
Minoru Naito
 
OSC2012 Nagoya - OpenStack - Storage System; Overview
OSC2012 Nagoya - OpenStack - Storage System; OverviewOSC2012 Nagoya - OpenStack - Storage System; Overview
OSC2012 Nagoya - OpenStack - Storage System; Overview
irix_jp
 
20121205 nosql(okuyama fs)セミナー資料
20121205 nosql(okuyama fs)セミナー資料20121205 nosql(okuyama fs)セミナー資料
20121205 nosql(okuyama fs)セミナー資料
Takahiro Iwase
 
【Interop Tokyo 2016】 エコシステムですすめる レノボのSDIソリューション
【Interop Tokyo 2016】 エコシステムですすめる レノボのSDIソリューション【Interop Tokyo 2016】 エコシステムですすめる レノボのSDIソリューション
【Interop Tokyo 2016】 エコシステムですすめる レノボのSDIソリューション
Juniper Networks (日本)
 
サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~
サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~
サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~
griddb
 
Sql database managed instance overview and internals
Sql database managed instance overview and internalsSql database managed instance overview and internals
Sql database managed instance overview and internals
Masayuki Ozawa
 
B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明
B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明
B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明
Insight Technology, Inc.
 
東北クラウド実践カンファレンス2011
東北クラウド実践カンファレンス2011東北クラウド実践カンファレンス2011
東北クラウド実践カンファレンス2011
Shinichiro Isago
 
Docomo Cloud Package
Docomo Cloud PackageDocomo Cloud Package
Docomo Cloud Package
Osaka University
 
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
Yahoo!デベロッパーネットワーク
 
[大図解]ピグライフはこう動いている
[大図解]ピグライフはこう動いている[大図解]ピグライフはこう動いている
[大図解]ピグライフはこう動いている
Akihiro Kuwano
 
PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門
じゅん なかざ
 

Similar to Dbtechshowcasesapporo mysql-turing-for-cloud-0.9.3 (20)

PHP on Windows Azure in Open Source Conference
PHP on Windows Azure in Open Source ConferencePHP on Windows Azure in Open Source Conference
PHP on Windows Azure in Open Source Conference
 
Windows Server 2012 のストレージ強化とエンタープライズへの活用
Windows Server 2012 のストレージ強化とエンタープライズへの活用Windows Server 2012 のストレージ強化とエンタープライズへの活用
Windows Server 2012 のストレージ強化とエンタープライズへの活用
 
Windows azureって何
Windows azureって何Windows azureって何
Windows azureって何
 
C32 DB Performance on Cloud by 安藤賀章
C32 DB Performance on Cloud by 安藤賀章C32 DB Performance on Cloud by 安藤賀章
C32 DB Performance on Cloud by 安藤賀章
 
既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~
 
Awsのクラウドデザインパターンをwindows azureに持ってきてみた
Awsのクラウドデザインパターンをwindows azureに持ってきてみたAwsのクラウドデザインパターンをwindows azureに持ってきてみた
Awsのクラウドデザインパターンをwindows azureに持ってきてみた
 
A 1-3 awsのクラウドデザインパターンをwindows-azureに持ってきてみた
A 1-3 awsのクラウドデザインパターンをwindows-azureに持ってきてみたA 1-3 awsのクラウドデザインパターンをwindows-azureに持ってきてみた
A 1-3 awsのクラウドデザインパターンをwindows-azureに持ってきてみた
 
Moot2013 moca ver0.3
Moot2013 moca ver0.3Moot2013 moca ver0.3
Moot2013 moca ver0.3
 
de:code 2019 Cloud トラック 総まとめ! 完全版
de:code 2019 Cloud トラック 総まとめ! 完全版de:code 2019 Cloud トラック 総まとめ! 完全版
de:code 2019 Cloud トラック 総まとめ! 完全版
 
OSC2012 Nagoya - OpenStack - Storage System; Overview
OSC2012 Nagoya - OpenStack - Storage System; OverviewOSC2012 Nagoya - OpenStack - Storage System; Overview
OSC2012 Nagoya - OpenStack - Storage System; Overview
 
20121205 nosql(okuyama fs)セミナー資料
20121205 nosql(okuyama fs)セミナー資料20121205 nosql(okuyama fs)セミナー資料
20121205 nosql(okuyama fs)セミナー資料
 
【Interop Tokyo 2016】 エコシステムですすめる レノボのSDIソリューション
【Interop Tokyo 2016】 エコシステムですすめる レノボのSDIソリューション【Interop Tokyo 2016】 エコシステムですすめる レノボのSDIソリューション
【Interop Tokyo 2016】 エコシステムですすめる レノボのSDIソリューション
 
サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~
サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~
サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~
 
Sql database managed instance overview and internals
Sql database managed instance overview and internalsSql database managed instance overview and internals
Sql database managed instance overview and internals
 
B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明
B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明
B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明
 
東北クラウド実践カンファレンス2011
東北クラウド実践カンファレンス2011東北クラウド実践カンファレンス2011
東北クラウド実践カンファレンス2011
 
Docomo Cloud Package
Docomo Cloud PackageDocomo Cloud Package
Docomo Cloud Package
 
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
 
[大図解]ピグライフはこう動いている
[大図解]ピグライフはこう動いている[大図解]ピグライフはこう動いている
[大図解]ピグライフはこう動いている
 
PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門
 

More from infinite_loop

ChatGPT触ってみた
ChatGPT触ってみたChatGPT触ってみた
ChatGPT触ってみた
infinite_loop
 
社内ソフトスキルを考える
社内ソフトスキルを考える社内ソフトスキルを考える
社内ソフトスキルを考える
infinite_loop
 
3Dプリンタって いいね
3Dプリンタって いいね3Dプリンタって いいね
3Dプリンタって いいね
infinite_loop
 
VRChatでお酒が注げる飲み物アセットの紹介
VRChatでお酒が注げる飲み物アセットの紹介VRChatでお酒が注げる飲み物アセットの紹介
VRChatでお酒が注げる飲み物アセットの紹介
infinite_loop
 
アニメーションとスキニングをBurstで独自実装する.pdf
アニメーションとスキニングをBurstで独自実装する.pdfアニメーションとスキニングをBurstで独自実装する.pdf
アニメーションとスキニングをBurstで独自実装する.pdf
infinite_loop
 
I ❤ Virtual Machines 仮想環境をより便利に使うツールたち
I ❤ Virtual Machines 仮想環境をより便利に使うツールたちI ❤ Virtual Machines 仮想環境をより便利に使うツールたち
I ❤ Virtual Machines 仮想環境をより便利に使うツールたち
infinite_loop
 
500万行のPHPプロジェクトにおけるログ出力の歩み
500万行のPHPプロジェクトにおけるログ出力の歩み500万行のPHPプロジェクトにおけるログ出力の歩み
500万行のPHPプロジェクトにおけるログ出力の歩み
infinite_loop
 
ADRという考えを取り入れてみて
ADRという考えを取り入れてみてADRという考えを取り入れてみて
ADRという考えを取り入れてみて
infinite_loop
 
リファクタリングで実装が○○分短縮した話
リファクタリングで実装が○○分短縮した話リファクタリングで実装が○○分短縮した話
リファクタリングで実装が○○分短縮した話
infinite_loop
 
ゲームのインフラをAwsで実戦tips全て見せます
ゲームのインフラをAwsで実戦tips全て見せますゲームのインフラをAwsで実戦tips全て見せます
ゲームのインフラをAwsで実戦tips全て見せます
infinite_loop
 
楽しいVR空間を作る技術と支える技術 #osc19do
楽しいVR空間を作る技術と支える技術 #osc19do楽しいVR空間を作る技術と支える技術 #osc19do
楽しいVR空間を作る技術と支える技術 #osc19do
infinite_loop
 
Start rl with_unity_machine_learning_agents
Start rl with_unity_machine_learning_agentsStart rl with_unity_machine_learning_agents
Start rl with_unity_machine_learning_agents
infinite_loop
 
UniRx の1歩目
UniRx の1歩目UniRx の1歩目
UniRx の1歩目
infinite_loop
 
がんばれ PHP Fiber
がんばれ PHP Fiberがんばれ PHP Fiber
がんばれ PHP Fiber
infinite_loop
 
心に残った名前ランキング
心に残った名前ランキング心に残った名前ランキング
心に残った名前ランキング
infinite_loop
 
プログラムと名前にまつわる座談会
プログラムと名前にまつわる座談会プログラムと名前にまつわる座談会
プログラムと名前にまつわる座談会
infinite_loop
 
名は体を表していますか
名は体を表していますか名は体を表していますか
名は体を表していますか
infinite_loop
 
名前の力
名前の力名前の力
名前の力
infinite_loop
 
大切な名前[Intro]公開版
大切な名前[Intro]公開版大切な名前[Intro]公開版
大切な名前[Intro]公開版
infinite_loop
 
JupyterNotebookとMySQLでゼロからはじめるデータサイエンス
JupyterNotebookとMySQLでゼロからはじめるデータサイエンスJupyterNotebookとMySQLでゼロからはじめるデータサイエンス
JupyterNotebookとMySQLでゼロからはじめるデータサイエンス
infinite_loop
 

More from infinite_loop (20)

ChatGPT触ってみた
ChatGPT触ってみたChatGPT触ってみた
ChatGPT触ってみた
 
社内ソフトスキルを考える
社内ソフトスキルを考える社内ソフトスキルを考える
社内ソフトスキルを考える
 
3Dプリンタって いいね
3Dプリンタって いいね3Dプリンタって いいね
3Dプリンタって いいね
 
VRChatでお酒が注げる飲み物アセットの紹介
VRChatでお酒が注げる飲み物アセットの紹介VRChatでお酒が注げる飲み物アセットの紹介
VRChatでお酒が注げる飲み物アセットの紹介
 
アニメーションとスキニングをBurstで独自実装する.pdf
アニメーションとスキニングをBurstで独自実装する.pdfアニメーションとスキニングをBurstで独自実装する.pdf
アニメーションとスキニングをBurstで独自実装する.pdf
 
I ❤ Virtual Machines 仮想環境をより便利に使うツールたち
I ❤ Virtual Machines 仮想環境をより便利に使うツールたちI ❤ Virtual Machines 仮想環境をより便利に使うツールたち
I ❤ Virtual Machines 仮想環境をより便利に使うツールたち
 
500万行のPHPプロジェクトにおけるログ出力の歩み
500万行のPHPプロジェクトにおけるログ出力の歩み500万行のPHPプロジェクトにおけるログ出力の歩み
500万行のPHPプロジェクトにおけるログ出力の歩み
 
ADRという考えを取り入れてみて
ADRという考えを取り入れてみてADRという考えを取り入れてみて
ADRという考えを取り入れてみて
 
リファクタリングで実装が○○分短縮した話
リファクタリングで実装が○○分短縮した話リファクタリングで実装が○○分短縮した話
リファクタリングで実装が○○分短縮した話
 
ゲームのインフラをAwsで実戦tips全て見せます
ゲームのインフラをAwsで実戦tips全て見せますゲームのインフラをAwsで実戦tips全て見せます
ゲームのインフラをAwsで実戦tips全て見せます
 
楽しいVR空間を作る技術と支える技術 #osc19do
楽しいVR空間を作る技術と支える技術 #osc19do楽しいVR空間を作る技術と支える技術 #osc19do
楽しいVR空間を作る技術と支える技術 #osc19do
 
Start rl with_unity_machine_learning_agents
Start rl with_unity_machine_learning_agentsStart rl with_unity_machine_learning_agents
Start rl with_unity_machine_learning_agents
 
UniRx の1歩目
UniRx の1歩目UniRx の1歩目
UniRx の1歩目
 
がんばれ PHP Fiber
がんばれ PHP Fiberがんばれ PHP Fiber
がんばれ PHP Fiber
 
心に残った名前ランキング
心に残った名前ランキング心に残った名前ランキング
心に残った名前ランキング
 
プログラムと名前にまつわる座談会
プログラムと名前にまつわる座談会プログラムと名前にまつわる座談会
プログラムと名前にまつわる座談会
 
名は体を表していますか
名は体を表していますか名は体を表していますか
名は体を表していますか
 
名前の力
名前の力名前の力
名前の力
 
大切な名前[Intro]公開版
大切な名前[Intro]公開版大切な名前[Intro]公開版
大切な名前[Intro]公開版
 
JupyterNotebookとMySQLでゼロからはじめるデータサイエンス
JupyterNotebookとMySQLでゼロからはじめるデータサイエンスJupyterNotebookとMySQLでゼロからはじめるデータサイエンス
JupyterNotebookとMySQLでゼロからはじめるデータサイエンス
 

Recently uploaded

Matsuo-Iwasawa lab. Research Unit Introduction
Matsuo-Iwasawa lab. Research Unit IntroductionMatsuo-Iwasawa lab. Research Unit Introduction
Matsuo-Iwasawa lab. Research Unit Introduction
Matsuo Lab
 
Matsuo-Iwasawa Lab. Research unit Introduction
Matsuo-Iwasawa Lab. Research unit IntroductionMatsuo-Iwasawa Lab. Research unit Introduction
Matsuo-Iwasawa Lab. Research unit Introduction
Matsuo Lab
 
20240717_IoTLT_vol113_kitazaki_v1___.pdf
20240717_IoTLT_vol113_kitazaki_v1___.pdf20240717_IoTLT_vol113_kitazaki_v1___.pdf
20240717_IoTLT_vol113_kitazaki_v1___.pdf
Ayachika Kitazaki
 
"ros2rapper", Hardware implimentation of ROS2 communication Protocol without ...
"ros2rapper", Hardware implimentation of ROS2 communication Protocol without ..."ros2rapper", Hardware implimentation of ROS2 communication Protocol without ...
"ros2rapper", Hardware implimentation of ROS2 communication Protocol without ...
たけおか しょうぞう
 
論文紹介:BAM-DETR: Boundary-Aligned Moment Detection Transformer for Temporal Sen...
論文紹介:BAM-DETR: Boundary-Aligned Moment Detection Transformer for Temporal Sen...論文紹介:BAM-DETR: Boundary-Aligned Moment Detection Transformer for Temporal Sen...
論文紹介:BAM-DETR: Boundary-Aligned Moment Detection Transformer for Temporal Sen...
Toru Tamaki
 
Matsuo-Iwasawa Lab. | Research unit Introduction
Matsuo-Iwasawa Lab. | Research unit IntroductionMatsuo-Iwasawa Lab. | Research unit Introduction
Matsuo-Iwasawa Lab. | Research unit Introduction
Matsuo Lab
 
【JSAI2024】J-NER大規模言語モデルのための固有表現認識における拡張固有表現階層を考慮したベンチマークデータセット.pdf
【JSAI2024】J-NER大規模言語モデルのための固有表現認識における拡張固有表現階層を考慮したベンチマークデータセット.pdf【JSAI2024】J-NER大規模言語モデルのための固有表現認識における拡張固有表現階層を考慮したベンチマークデータセット.pdf
【JSAI2024】J-NER大規模言語モデルのための固有表現認識における拡張固有表現階層を考慮したベンチマークデータセット.pdf
ARISE analytics
 
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
Sony - Neural Network Libraries
 
【AI論文解説】クラスタリングベースアプローチによる大規模データセット自動キュレーション
【AI論文解説】クラスタリングベースアプローチによる大規模データセット自動キュレーション【AI論文解説】クラスタリングベースアプローチによる大規模データセット自動キュレーション
【AI論文解説】クラスタリングベースアプローチによる大規模データセット自動キュレーション
Sony - Neural Network Libraries
 
Kyndryl Developer Services のご紹介 2024年7月
Kyndryl Developer Services のご紹介  2024年7月Kyndryl Developer Services のご紹介  2024年7月
Kyndryl Developer Services のご紹介 2024年7月
Takayuki Nakayama
 
Imitation learning for robotics 勉強会資料(20240701)
Imitation learning for robotics 勉強会資料(20240701)Imitation learning for robotics 勉強会資料(20240701)
Imitation learning for robotics 勉強会資料(20240701)
Natsutani Minoru
 
LoRaWAN AI Image Sensorエンドデバイス AIG01カタログ
LoRaWAN AI Image Sensorエンドデバイス AIG01カタログLoRaWAN AI Image Sensorエンドデバイス AIG01カタログ
LoRaWAN AI Image Sensorエンドデバイス AIG01カタログ
CRI Japan, Inc.
 
最速の組織を目指して全社で大規模スクラムを導入してみた話 #dxd2024 #medicalforce
最速の組織を目指して全社で大規模スクラムを導入してみた話 #dxd2024 #medicalforce最速の組織を目指して全社で大規模スクラムを導入してみた話 #dxd2024 #medicalforce
最速の組織を目指して全社で大規模スクラムを導入してみた話 #dxd2024 #medicalforce
chisatotakane
 
論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...
論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...
論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...
Toru Tamaki
 

Recently uploaded (14)

Matsuo-Iwasawa lab. Research Unit Introduction
Matsuo-Iwasawa lab. Research Unit IntroductionMatsuo-Iwasawa lab. Research Unit Introduction
Matsuo-Iwasawa lab. Research Unit Introduction
 
Matsuo-Iwasawa Lab. Research unit Introduction
Matsuo-Iwasawa Lab. Research unit IntroductionMatsuo-Iwasawa Lab. Research unit Introduction
Matsuo-Iwasawa Lab. Research unit Introduction
 
20240717_IoTLT_vol113_kitazaki_v1___.pdf
20240717_IoTLT_vol113_kitazaki_v1___.pdf20240717_IoTLT_vol113_kitazaki_v1___.pdf
20240717_IoTLT_vol113_kitazaki_v1___.pdf
 
"ros2rapper", Hardware implimentation of ROS2 communication Protocol without ...
"ros2rapper", Hardware implimentation of ROS2 communication Protocol without ..."ros2rapper", Hardware implimentation of ROS2 communication Protocol without ...
"ros2rapper", Hardware implimentation of ROS2 communication Protocol without ...
 
論文紹介:BAM-DETR: Boundary-Aligned Moment Detection Transformer for Temporal Sen...
論文紹介:BAM-DETR: Boundary-Aligned Moment Detection Transformer for Temporal Sen...論文紹介:BAM-DETR: Boundary-Aligned Moment Detection Transformer for Temporal Sen...
論文紹介:BAM-DETR: Boundary-Aligned Moment Detection Transformer for Temporal Sen...
 
Matsuo-Iwasawa Lab. | Research unit Introduction
Matsuo-Iwasawa Lab. | Research unit IntroductionMatsuo-Iwasawa Lab. | Research unit Introduction
Matsuo-Iwasawa Lab. | Research unit Introduction
 
【JSAI2024】J-NER大規模言語モデルのための固有表現認識における拡張固有表現階層を考慮したベンチマークデータセット.pdf
【JSAI2024】J-NER大規模言語モデルのための固有表現認識における拡張固有表現階層を考慮したベンチマークデータセット.pdf【JSAI2024】J-NER大規模言語モデルのための固有表現認識における拡張固有表現階層を考慮したベンチマークデータセット.pdf
【JSAI2024】J-NER大規模言語モデルのための固有表現認識における拡張固有表現階層を考慮したベンチマークデータセット.pdf
 
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
 
【AI論文解説】クラスタリングベースアプローチによる大規模データセット自動キュレーション
【AI論文解説】クラスタリングベースアプローチによる大規模データセット自動キュレーション【AI論文解説】クラスタリングベースアプローチによる大規模データセット自動キュレーション
【AI論文解説】クラスタリングベースアプローチによる大規模データセット自動キュレーション
 
Kyndryl Developer Services のご紹介 2024年7月
Kyndryl Developer Services のご紹介  2024年7月Kyndryl Developer Services のご紹介  2024年7月
Kyndryl Developer Services のご紹介 2024年7月
 
Imitation learning for robotics 勉強会資料(20240701)
Imitation learning for robotics 勉強会資料(20240701)Imitation learning for robotics 勉強会資料(20240701)
Imitation learning for robotics 勉強会資料(20240701)
 
LoRaWAN AI Image Sensorエンドデバイス AIG01カタログ
LoRaWAN AI Image Sensorエンドデバイス AIG01カタログLoRaWAN AI Image Sensorエンドデバイス AIG01カタログ
LoRaWAN AI Image Sensorエンドデバイス AIG01カタログ
 
最速の組織を目指して全社で大規模スクラムを導入してみた話 #dxd2024 #medicalforce
最速の組織を目指して全社で大規模スクラムを導入してみた話 #dxd2024 #medicalforce最速の組織を目指して全社で大規模スクラムを導入してみた話 #dxd2024 #medicalforce
最速の組織を目指して全社で大規模スクラムを導入してみた話 #dxd2024 #medicalforce
 
論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...
論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...
論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...
 

Dbtechshowcasesapporo mysql-turing-for-cloud-0.9.3