『アメーバピグにおけるDB構成&対応記』
2ヶ月前にインフルエンザとウィルス性胃腸炎でひどくダメージを受けた増田(@masudaK)です。アメーバピグは2009年2月に始まったサービスで、FLASH・Javaで作られています。そして、データストアにMySQLを用いてます。本記事では、わたくしが2年ほど見続けているアメーバピグのDB環境について構成や、日々どのようにして問題と向き合っているかを紹介したいと思います。インフラ寄りの内容が多いため、アプリ寄りの話は弊社生沼の資料を御覧ください。 1. 構成と規模 1.1. 構成 まず構成ですが、読み書きはすべてマスターへ行うようにしています。そのため、スレーブには参照を向けず、ホットスタンバイとして使っています。バージョンに関しては2012年中旬までは5.0を使ってましたが、DC移転にあわせて5.5にあげました。ロック機能を用いたシャード構成をしてまして、2014年3月現在6シャードにな
MySQLのALTER TABLEをモニタリングする | Yakst
MySQL Performance Blogの翻訳。ALTER TABLEによるテーブル変更の進捗状況を確認するには、いくつかの方法がある。それぞれの方法と利点、欠点を紹介する。 February 26, 2014 By Nilnandan Joshi Percona Supportのエンジニアとして現在関わっている案件の中で、ALTER TABLEの進捗状況を確認する方法について顧客から尋ねられた。実は、MySQL 5.5以前は、テーブルに対するALTERの実行状況を本番環境で確認するのは少々難しく、(数百万行もあるような)巨大なテーブルではなおさらだった。これは、リビルドとテーブルのロックを伴うため、パフォーマンス低下だけでなくユーザ影響もあったためだ。とはいえ、ALTERを始めてしまえば、それがいつ終わるのかを知るのはとても重要なことだ。インデックスを作成している間、fast_ind
MySQLのパラメーターチューニング at OSC 2014 Tokyo/Spring
去る2014/03/01(土)の OSC 2014 Tokyo/Spring でMyNAとしてセミナーの枠をいただいたので、おはなしししてきました。 雨の中たくさんの方に足を運んでいただきました。本当にどうもありがとうございました。 "MySQLパラメーターチューニングの理屈と定石"と銘打って、普段アプリを書いているような人向けに、俺が普段やってるパラメーターチューニングと同じくらいのことが誰にでもできるように…とか思って資料を作っていたんですが(社内のDB勉強会に使うネタのうち、パラメーター調整の部分だけを切り出した、というのがもともとのコンセプトです)、作れば作るほど、いかに自分が「考えるな。感じるんだ」でチューニングしているのかをむしろ思い知らされました。 「これとこれ見るでしょ？ そうするとなんか変な感じがするじゃない？ で、こことここだからこれかなって。いじってみたら違うから、近
YouTube & Go言語: MySQLをパワーアップするVitess - ワザノバ | wazanova
http://www.youtube.com/watch?v=qATTTSg6zXk 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約3時間前 YouTubeのシステムアーキテクトであるSugu SououmaraneのFOSDEM 2014での講演です。スライドはこちらからダウンロードできます。 1) Vitessとは Vitessは大規模な本番環境でMySQL DBを効率的に利用するためのオープンソースプロジェクトです。概要はプロジェクトゴールのページ にまとまってます。 MySQLは機能が豊富だがスケールさせるときは苦労する。一方、NoSQLはスケーラビリティには問題がないが、アプリケーションが複雑になるとできることに限界があるのがネックになる。セカンダリインデックス、joinsなどがサポートされていない。
Making full table scan 10x faster in InnoDB
At MySQL Connect 2013, I talked about how we used MySQL 5.6 at Facebook, and explained some of new features we added to our Facebook MySQL 5.6 source tree. In this post, I'm going to talk about how we made full table scan faster in InnoDB. Faster full table scan in InnoDB In general, almost all queries from applications are using indexes, and reading very few rows (0..1 on primary key lookups and
Pythonで作られた便利なコマンドラインツール MySQL Utilities
MySQL Utilitiesならではの注意点 MySQL Utilitiesは従来のコマンドラインツール群とは違い、以下のような記述で接続先を指定します。 これは、従来のコマンドラインツール群が主に1つのMySQLサーバーを対象として動作するものなのに対して、MySQL Utilitiesは2つ以上のMySQLサーバーを対象として動作するものが多いため、このような記法になっています。 [MySQL Utilitiesの記法] --server=ユーザ名:パスワード@ホスト名:ポート番号 [MySQL コマンドラインツール群の記法] --user=ユーザ名 --password=パスワード --host=ホスト名 --port=ポート番号 なおWindows環境ではローカルホストとしてlocalhostと127.0.0.1のどちらを指定しても同じですが、LinuxやUNIXではホスト名に対
Index Condition Pushdown
That way, the value Handler_icp_attempts - Handler_icp_match shows the number records that the server did not have to read because of Index Condition Pushdown. Limitations Currently, virtual column indexes can't be used for index condition pushdown. Instead, a generated column can be made declared STORED. Then, index condition pushdown will be possible. Index Condition Pushdown can't be used with
MySQL 5.6で追加されたICPを追ってみました。 - Qiita
この記事はMySQL Casual Advent Calendar 2013 on Zusaarの19日目です。 yokuさんの記事「日々の覚書: あなたのMySQL 5.6トレンド力をチェックする15の質問」を見て、新しく加わったオプティマイザのことをちゃんと調べていなかったと思いまして、改めて調べてみました。 まず、どういう種類があるでしょうか。例として、ひとまず5つあるようです。 Index Condition Pushdown(ICP)の追加 BKA-Joinの追加 Multi-Range Read(MRR)の追加 FROM句サブクエリーの最適化 Optimizer Traceの追加 これら、Block Nested-Loop(BNLJ)やBKA、ICP etcに関して、nippondanjiさんの記事がわかりやすく説明してくださっています。 ここでは、第一弾(?)としてICPを改
MySQL 5.6での、マルチカラムインデックスとカラムごとのインデックスの比較 | Yakst
MySQL Performance Blogの翻訳。複数のカラムを指定したマルチカラムインデックスを使うべきか、カラムごとに別々にインデックスを作るべきかは悩ましい問題だ。しかし、MySQL 5.6で導入されたIndex condition pushdownの仕組みを理解すれば、マルチカラムインデックスを効率的に使うことができるようになる。 インデックスに関する話をしている時によく出てくる質問と言えば…マルチカラムインデックスを使うべきか、カラムそれぞれにインデックスを張るべきか、ということだ。Peter Zaitevがこれについて2008年に書いていて、その時の結論としては、マルチカラムインデックスが多くの場合においてベストな解決策だ、というこだった。しかし、最近のオプティマイザの進化によって、MySQL 5.6では事情は違ってきてはいないだろうか？ 準備 テストのため、以下のような2つ
快適mysqlコマンド★カスタマイズの決定版 - （ひ）メモ
この記事は MySQL Casual Advent Calendar 2013 の25日目の記事です。 自分の過去のブログも含めて、mysqlコマンドのカスタマイズについていろいろな情報がありますが、わたしがオススメの秘伝のタレをまとめたいと思います。是非、ご参考に。 定型文(SQL)のショートカット入力 「show create table TABLENAME\G」とか「select user,host,password from mysql.user order by user,host;」とか、よく実行するけど長くて入力するのがめんどうなのがありますよね。それをショートカットで入力できるようにする方法です。 mysqlコマンドで行編集ができるのは、readlineやlibeditをリンクしているおかげです。 従来の公式バイナリ配布物に含まれるmysqlコマンドはreadlineでした
InnoDBのREPEATABLE READにおけるLocking Readについての注意点
本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up
ナチュラルキーとサロゲートキーについての議論
とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。 リレーショナルモデルにあるのはナチュラルキーだけリレーショナルモデルには「サロゲートキー（代理キー）」という概念はない。まずこの点に注意して頂きたい。サロゲートキーとは、データベースアプリケーション開発において実用上必要とされる機能であって、本質的には不要のものである。リレーショナルモデルでは、いわゆるナチュラルキーというものがあれば機能的には十分だからだ。 そのためにはまず「キー」という概念が何を指し示すかということについて正しく理解しなければならない。リレーショナルモデルではキーと呼ばれるものは候補キーとスーパーキーという2つの概念だけである。「タプル（≒行）の値を一意に決定することができる属性（≒カラム）の集合」の
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
DBエンジニアのための技術勉強会で発表したスライドを公開しました。
DBエンジニアのための技術勉強会というイベントで、リレーショナルモデルにおけるDB設計について話す機会を頂いた。リレーショナルモデルは非常に重要であるにも関わらず、現場ではないがしろにされてしまっている。その結果、アプリケーションのロジックを上手くクエリで表現できず、開発現場では非効率な開発が行われ、多くの人がデスマ的な状況に追い込まれている。そういう危機意識について、これまで何度か本ブログでも書いてきたし、WEB+DB Pressで連載している動機もその点にある。リレーショナルデータベースはやはりリレーショナルデータベースとして使うべきだ。そのための鍵となるのが、DB設計である。 今回はなんと約2時間の持ち時間を頂いた。リレーショナルモデルについてはこれまで何度か話す機会を頂いたが、2時間というのは最長記録である。それに合わせてスライドもボリュームたっぷりのものになった。過去のスライドと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL :: MySQL 8.4 Reference Manual :: 10.2.1.6 Index Condition Pushdown Optimization
Can you automatically create a mysqldump file that doesn't enforce foreign key constraints?
MySQL :: MySQL 8.4 Reference Manual :: 17.7.5.2 Deadlock Detection
Level up your MySQL query tuning
MySQL :: MySQL 5.6 Reference Manual :: 14.13.2 Online DDL Performance and Concurrency
http://www.zusaar.com/event/1847003