Making Aurora Write Latency 15x Higher (or More!) by Choosing a Bad Primary Key
Primary Key design is an important thing for InnoDB performance, and choosing a poor PK definition will have an impact on performance and also write propagation in databases. When this comes to Aurora, this impact is even worse than you may notice. In short, we consider a poor definition of a Primary Key in InnoDB as “anything but quasi sequential values”, which may cause very random access to dat
InnoDB, fsync and fdatasync - reducing commit latency
InnoDB, fsync and fdatasync - reducing commit latency MySQL has an commit penalty compared to Postgres and MongoDB. If you want commit to be durable with the binlog enabled then MySQL does two fsyncs per commit -- one for the binlog, one for the InnoDB redo log. But Postgres and MongoDB only need one fsync per commit in the same setup. Note that I am ignoring the benefit of group commit for now, a
ソシャゲエンジニアの自分が開発に必須だなと思った知識（MySQL編） - Qiita
この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC
innodb_thread_concurrencyに関する話 | GREE Engineering
こんにちわ。せじまです。今回の話は軽く書こうと思っていたのですが、長くなりました。まぁInnoDBの話なのでしょうがないですね。 はじめ 今回はinnodb_thread_concurrencyについてお話しようと思います。できれば、事前にInnoDB の mutex の話（入門編）を読んでいただいた方が、より深く理解していただけるのではないかと思います。 長いので、最初に五行でまとめます 現代において、ほとんどのケースでは、innodb_thread_concurrencyはデフォルトの0のままで問題ないと思います。なぜなら、最近のInnoDBはかなり良くなってきたからです。 それでもinnodb_thread_concurrencyをチューニングするとしたら、「高負荷状態になったときでもスレッド間の公平性をなるべく担保し、安定稼働させるため」と割り切って使うのが良いでしょう。 inno
MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
InnoDB の mutex の話（入門編） | GREE Engineering
このエントリは GREE Advent Calendar 2015 22日目の記事です。 こんにちわ。せじまです。久々に 10inch の Android Tablet 買いかえたところ、USBがキャップレス防水になってるわお風呂で使っても内蔵スピーカーでそこそこ音量取れるわ水滴ついた状態でもタッチパネルの精度が高いわと、この分野に於ける技術の進歩ハンパないなと感心させられました。 はじめに 最近、 InnoDB の mutex 周りの実装に関心があるのですが、ちょっと調べてみたところ、自分が読みたいような内容の入門記事が、英語や日本語の blog などでは見つけられなかった、あるいは最近の記事ではなかったので、備忘録を兼ねて自分で書いてみることにしました。今回のゴールは、 SHOW ENGINE INNODB STATUS\G での次のセクションを読み解くところまでです。 -------
InnoDB vs TokuDB in LinkBench benchmark
Previously I tested Tokutek’s Fractal Trees (TokuMX & TokuMXse) as MongoDB storage engines – today let’s look into the MySQL area. I am going to use modified LinkBench in a heavy IO-load. I compared InnoDB without compression, InnoDB with 8k compression, TokuDB with quicklz compression. Uncompressed datasize is 115GiB, and cachesize is 12GiB for InnoDB and 8GiB + 4GiB OS cache for TokuDB. Importan
OSC2015北海道で「これだけみれば大丈夫ーCactiによるMySQLパフォーマンス監視のツボ」という発表をしてきました｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
OSC2015北海道で「これだけみれば大丈夫ーCactiによるMySQLパフォーマンス監視のツボ」という発表をしてきました こんにちは nobuh です。 昨年の 第四回札幌MySQL勉強会 以降、多忙のためなかなか勉強会を開けていない札幌MySQL勉強会ですが、各メンバーはこつこつとスキルアップを続けていました。 そして今回、日本MySQLユーザー会 様からお話を頂き、OSC2015北海道 にて札幌MySQL勉強会から発表させて頂きました。こちらがそのスライドです。 InnoDB の I/O のしくみについての解説部分 グラフを見てパフォーマンスの状況を知るには、MySQL や InnoDB がどういう動作をしているのか知っている必要がありますが、InnoDB のデータをディスクに書き込む checkpoint の仕組みはとても複雑で資料も少ないです。発表当日のプレゼンでは少しでもわかり
InnoDBのChange Buffer(MySQL Server Blogより) | Yakst
レコードの挿入時などに発生するセカンダリインデックスの更新は一般的にI/Oコストが高いことで知られる。InnoDBではこれを軽減する為に変更バッファという仕組みがある。MySQL Server Blogから変更バッファ概要の解説記事を紹介する(2015/6/4, Annamalai Gurusami) 免責事項 この記事はMySQL Server Blogの投稿をユーザが翻訳したものであり、Oracle公式の文書ではありません。 THU, 2015/6/4 by Annamalai Gurusami ストレージエンジンを設計するとき、最大の課題となるのは書込み操作の途中のランダムI/Oである。 InnoDBでは、テーブルは1つのクラスタインデックスを持ち、0またはそれ以上のセカンダリインデックスを持つ。インデックスはいずれも、B-treeである。 レコードがテーブルに挿入されるとき、レコー
TransactdでInnoDBロックを自在に操る - BizStationブログ
前回の MySQL/MariaDBとTransactdのInnoDBロック制御詳細 その1 - BizStationブログ では、InnoDBのロックの詳細について説明しました。 今回は、TransactdのトランザクションにおいてInnoDBのロックをどう扱うかを説明します。Transactdは、InnoDBロックを自在に操って同時実行性を高めることができます。 ロック制御は、マルチスレッドプログラミングとmutex lockなどの制御とよく似ています。これらを扱ったことがあるようでしたら、Transactdのロック制御はとてもやり易く感じると思います。 書き込みにおけるパフォーマンスの確保には、ロックを最小限にし同時実行性を高めることが不可欠です。ミッションクリティカルなアプリケーションもパフォーマンスの良いものにしましょう。 Transactdのロック制御 TransactdのAPI
InnoDB Deep Talks #2 (仮) でちっともディープじゃない話をしてきました
2024 ( 18 ) 5月 ( 1 ) 4月 ( 3 ) 3月 ( 6 ) 2月 ( 1 ) 1月 ( 7 ) 2023 ( 20 ) 12月 ( 3 ) 11月 ( 3 ) 10月 ( 1 ) 8月 ( 1 ) 5月 ( 2 ) 4月 ( 2 ) 3月 ( 3 ) 2月 ( 5 ) 2022 ( 27 ) 12月 ( 5 ) 10月 ( 1 ) 9月 ( 1 ) 8月 ( 5 ) 7月 ( 4 ) 6月 ( 3 ) 4月 ( 1 ) 3月 ( 3 ) 2月 ( 2 ) 1月 ( 2 ) 2021 ( 22 ) 12月 ( 4 ) 10月 ( 2 ) 9月 ( 6 ) 7月 ( 1 ) 6月 ( 3 ) 5月 ( 3 ) 4月 ( 1 ) 3月 ( 2 ) 2020 ( 42 ) 12月 ( 3 ) 10月 ( 2 ) 9月 ( 4 ) 8月 ( 3 ) 7月 ( 4 ) 6月 ( 6
InnoDB Deep Talk #2 (仮) に引っ張りだされました。
先日、「InnoDB Deep Talk #2 (仮)」というイベントでお話ししてきました。 「事前情報は講演者の名前のみ(内容未定)」という、振り返ってみると異常な状況にも関わらずお集まりいただきありがとうございました。 今回は、前回とは違って少しだけ公開を意識して作ったあったので公開してみます。 これで手持ちのネタは出し尽くしたので、また暫くブログの更新は無いかもしれませんがご容赦を。。。
innodb_stats_on_metadata=1でディスク容量激増とCPU負荷が発生
phpmyadminでinformation_schemaをクリックするのが危険過ぎる – K52.NIKKI ver3.0というのが添えられていました。 よくわからなかったので現象を呟いたところ、親切なMySQLのACE（えーす）のyoku0825さんがinnodb_stats_on_metadata=1があやしいんじゃないかと教えてくれました。 ググってみたところ、innodb_stats_on_metadata に要注意 – TAKUMI SAKAMOTO’S BLOGというページを見かけて何が起きたかわかった気になったのでした。 起きたことの予測： ・テーブルの更新状況が統計情報更新の発生条件に達している状態だった ・information_schemaのリンクをクリックすることでshow table status相当の統計情報更新のきっかけになるクエリが走った ・統計情報更新のた
Home
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
【増枠120名】InnoDB Deep Talk #2（仮） (2015/03/07 14:00〜)
お知らせ 【重要なお知らせ】iOSアプリの運用および提供を2024年6月3日(月)を以て終了いたします。詳細は お知らせをご覧ください。 お知らせ connpassではさらなる価値のあるデータを提供するため、イベントサーチAPIの提供方法の見直しを決定しました。2024年5月23日(木)より 「企業・法人」「コミュニティ及び個人」向けの2プランを提供開始いたします。ご利用にあたっては利用申請及び審査がございます。詳細はヘルプページをご確認ください。
InnoDBの制限とファイルフォーマットAntelopeとBarracudaの違い - かみぽわーる
この投稿はMySQL Casual Advent Calendar 2014の5日目の記事です。 @kamipo 質問させてください。このエントリーで COMPRESSED ではなく DYNAMIC を選んでいる理由はなぜですか？あまりDB詳しくないので参考リンクなどポインタを教えていただけるだけでも構いません http://t.co/9sC4lzLjXr— kiyoshi nomo (@kysnm) November 27, 2014 先週ツイッターでInnoDBのことを質問されまして、せっかくなのでアドカレのネタにしようと思いますってことでInnoDBのファイルフォーマット毎の違いをカジュアルに説明しようと思います。 InnoDBのファイルフォーマットBarracudaと新機能 InnoDBにはファイルフォーマットとして昔からあるAntelopeと新しいフォーマット(5年も前からあるの
InnoDBの正しい発音とは - rkajiyama’s diary
12/11(土)のMySQL Casual Talks vol.1で突如熱い話題となったInnoDBの発音。 営業部門のトップ(ロンドン在住英国人)や自分の部門のボス(ニューヨーク在住米国人)にも聞いてみたけど、共通した答えは「英語の発音だとイノ・ディー・ビーっぽいけど、作ったヤツに聞くのが良いんじゃない？」と。 ちょうどMySQL 5.5のリリース前だったので聞きづらかったけど、予定通りMySQL 5.5がGAリリースとなったのでInnoDBの制作者のHeikkiに直接聞いてみました。真面目なHeikkiはきっちり教えてくれました。 Heikkiによる説明を以下にまとめています。 InnoDBの最初の名前はInnobaseだった。MySQL創業者の一人David AxmarkがInnoDBという名前を付けた。 フィンランド語での一般的な発音としては IN - no - dee - bee
innodb_rubyでfast index creationとそうでないのを比べてみる
や、MyNA会でデモした時にむしろこれをやれよって話なんですが。 InnoDB Plugin以降で加わったInnoDBのfast index creationと、それまでのインデックス作成について、innodb_rubyを使って比べてみました。 まずは最初にロードを済ませてから、後からfast index creationでインデックスを作るパターン。 master [localhost] {msandbox} (d1) > CREATE TABLE t1 (num int unsigned primary key, val varchar(32) not null); Query OK, 0 rows affected (0.02 sec) master [localhost] {msandbox} (d1) > LOAD DATA INFILE '/tmp/md5_10000' INT
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://github.com/ichirin2501/doc/blob/master/innodb.md
GitHub - jeremycole/innodb_ruby: A parser for InnoDB file formats, in Ruby
