pixivのブックマークに関する負荷対策をしました - pixiv inside
10/22(金) 追記 この記事で解説している内容について解説する勉強会を開催することとなりました。以下のconnpassよりお申し込みください。 pixiv.connpass.com 10/22(金) 追記 pixivのブックマークについて ブックマークDBの問題について 具体的な対策内容 論理削除廃止・index追加・ブックマークタグのテーブル分割 適応ハッシュインデックスの無効化 アプリケーションコードのリファクタリング・全発行クエリの列挙と見直し 大きな更新処理の非同期化 結果 あわせてよみたい pixivではサービスの成長に伴い、気に入った作品に対して付けることができるブックマークの総数が急速に増加しており、ユーザーの皆様に滞りなくサービスを提供し続けるためブックマークに関するデータベース(以後DB)の負荷対策が必要になりました。 2021年2月より対策を行うプロジェクトを発足し
InnoDBのMVCCのガベージコレクションについて - shallowな暮らし
こんにちは、shallow1729:detailです。今回は先日MyNA会というイベントで発表したMySQLの標準のストレージエンジンであるInnoDBのMVCCのガベージコレクションについて書こうと思います。発表自体もアーカイブされているので以下から見る事ができます。 「日本MySQLユーザ会会(MyNA会) 2021年07月 -下位レイヤ勉強会-」 公開版 - YouTube まず前半ではMVCCに関連するデータ構造を見ながらガベージコレクションの重要性やlong-running transactionの問題点について解説します。後半では実際のガベージコレクション(purge)の処理をソースコードレベルで追いながら、ユーザーに提供されているパラメーターを解説をします。 これまでに比べると踏み込んだ話題なのであまり基礎的な事は解説しません。知らない単語が多いかもしれないですが、適宜調べな
MySQLとインデックスと私
2021/05/24 サイボウズ開運研修 動画が以下のサイトからリンクされています - https://blog.cybozu.io/entry/2021/07/20/100000 - これに矢印を書きながらぐりぐりやっていたわけなので、資料単体だとわかりづらいと思います…
MySQLのquery review helperを作ってみた - tom__bo’s Blog
せっかくのGWなので、おもちゃを作りました。 Query Review Helperです。 github.com 背景 最近MySQLで実行されるクエリをレビューするタスクが異常に多くなってきました。 開発者の全員がindexやjoin, partition, limit offsetなどなどのハマりどころを知っているというのが理想ではありますが、そうも行きません。 大体EXPLAINをかけてtable scanになっていないか、sortやlimit offsetで劇的に重いクエリがないか確認すれば、すぐに問題になるようなことはありませんがいくつか問題があります。 複数のサービスを横串に見ていると各サービスのテーブル設計の詳細を知らない 大きいサービスだとテーブル数やカラム数が異常に多い(数百テーブル, 各テーブルに数十カラムとFKが、、、とか) tableやcolumn, subquer
MySQLバージョンアップによるInnoDB性能劣化可能性事件簿
一般論ですが、どんな基盤ソフトでもCPUスケールを上げようとすれば、何らかの排他制御を細かく行うことになるのでCPUのパイプライン処理にブレーキをかけるアトミックな処理が増えて、バージョンが上がるとある程度はシングルスレッドの処理は重くなっていきます。前エントリのような言語の高度化により遅くなる事情もあります。（中には、Redisのように並列を捨てて排他処理を完全排除する潔い逆振りプロダクトもありますが。） とはいえ、「これは（条件付きとはいえ）急に遅くなりすぎだろ！」と私も思うバージョン（回避策はある＆一開発者の一存ではどうにもできない）があるので遡って何点か挙げて注意喚起したいと思います。 これらはある程度限られた条件で発生するので世間では怪奇現象扱いされている可能性もあります。 何故こんなことになるのかというと、基盤となるmysqld側の変更に上手くついていけなくなってるか、性能上メ
InnoDB はどうやってファイルにデータを保持するのか
Extended outer memory module for my poor native memory. Posts: 2022/02/13 クラビスの CTO になりました 2020/09/28 gendoc という YAML からドキュメントを生成するコマンドを作った 2020/09/13 ISUCON10 の予選を 7 位で通過した 2019/12/01 Puma の内部構造やアーキテクチャを追う 2019/05/27 Golang の正規表現ライブラリの処理の流れをざっくり掴む 2019/04/29 InnoDB の B+Tree Index について 2019/04/29 InnoDB における index page のデータ構造 2019/04/28 InnoDB はどうやってファイルにデータを保持するのか 2019/01/06 Designing Data-Intens
MySQL 8.0.14でSELECT COUNT(*)が加速する！- 「innodb_parallel_read_threads」検証その１ - なからなLife
それは突然やってきた MySQL 8.0.14がGAされました。 dev.mysql.com まあ、MySQLは結構な頻度でリリースがありますし、「GAとはなんぞや」との名言が生まれる程度に、マイナーリリースでも機能が増える、パラメータが増える、既存パラメータのデフォルト値が変わる、といったことが発生するかわいいヤツです。 まあ、あとでリリースノート読んでみるか、と思いつつ、ビールを飲みながらYoutube垂れ流してボケーっとしているところに、新しいものが出てくるとリリースノートとソースコードを読み漁る某APIの人のツイートが深夜に流れてきて、ふと気になったのが、今回のテーマである「innodb_parallel_read_threads」です。 InnoDB: InnoDB now supports parallel clustered index reads, which can im
InnoDBのプライマリキーとセカンダリキー | Yakst
InnoDBのテーブルから、プライマリキーを取得するクエリを書いたのに、なぜかセカンダリインデックスが使われることがある。この仕組みを、InnoDBのインデックスの格納方法から解説する。 今日、EXPLAINの結果を色々と試してみている時に、興味深い問題にぶち当たったので、ドキュメントには載っていないこの現象をここで共有しておこう。 とても単純なInnoDBのテーブルを考えるところから始めよう。2つのINT型のカラムを持ち、最初のカラムがプライマリキーで、2番目のカラムに普通のインデックスが張ってある。 CREATE TABLE `t1` ( `id1` int(10) unsigned NOT NULL, `id2` int(10) unsigned DEFAULT NULL, PRIMARY KEY (`id1`), KEY `id2` (`id2`) ) ENGINE=InnoDB;
MySQLの大きなテーブルでのパフォーマンスを改善する10の方法 | Yakst
MySQLコミュニティマネージャのMorgan Tocker氏による、テーブルサイズが大きくなるにつれてINSERTのパフォーマンスが落ちてきてしまうことを防ぐ様々な方法についてのまとめ。 今日は、パフォーマンス問題を引き起こす原因になる、サイズの大きいテーブルのパフォーマンスを改善することについて書いてみようと思う。このアドバイスのうちのいくつかは、たくさんのテーブルをまとめて大きくなっているデータベースにも適用できるが、大抵の場合、独立した大きなテーブルというのは特に問題になりやすいものだ。 一般的に知られていると思われるのは、テーブルを変更する時のスピードは、そのサイズが大きくなるにつれて遅くなることだ。以下の図は、一般的なB+ツリーインデックスのパフォーマンスを時系列で見たものだ。 このグラフは、MySQL@Facebookの記事から拝借したものだ。これは、insert buffe
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLとインデックスとPHPer
PostgreSQLのtext型に対するINDEX
Level up your MySQL query tuning