MySQLのパフォーマンスを改善するうえで、「インデックス」は重要な要素の一つです。しかし、MySQLの内部でオプティマイザがどのようにインデックスを選択し、データを処理しているのかを正確に理解しているエンジニアは多くありません。どうすれば、インデックスを適切に使いこなせるのでしょうか。今回は、MySQL運用のスペシャリストとして知られるyoku0825さんに、インデックスの活用方法について解説していただきました。 B-treeインデックスの基本構造― 今回のインタビューでは、MySQLのインデックスの知見を詳細に伺っていきます。 インデックスを適切に活用するためには、その仕組みを理解することが重要です。そこでまずは、MySQLのInnoDBで最も基本となるB-treeインデックスの構造からお話しします。内部的にどのような構造になっているか、イメージを掴んでいきましょう。 今回は、MySQ
こんにちは。ソフトウェアエンジニアの古屋です。データベースのメトリクス、見てますか？私のチームが開発運用を担当する『カミナシ レポート』では Amazon Aurora MySQL をメインのRDBMSとして利用しています。この Aurora MySQL について少し課題がありました。 課題1. 増え続けるコスト 昨年の12月以降くらいでコスト、とくに Aurora:StorageIOUsage が右肩上がりで増えています（図の青色）。 課題2. 悪化するパフォーマンス （実際に運用されているのを初めて見たのですが）『カミナシ レポート』で利用している Aurora クラスターはCPU利用率（しきい値：60%）に基づいたオートスケールの設定がされており、アクセスのピーク帯になると負荷に応じて自動的にスケールアウトするようになっています。ただ、スケールアウトしてもパフォーマンスがよくなってい
database/sqlを触ってますが、いまいちしっかり説明してくれるリソースがないなあと思ってたら、goのwikiにGo database/sql tutorialがありました！ ということで試しながらポイントを整理してきます。 Overview DBへのアクセスには sql.DB を利用 sql.DB は指定したDriverへアクセスを抽象化した存在 これによってDriverがPostgresでも、MySQLでも統一した操作を提供 Importing a Database Driver 利用には database/sql とDriverパッケージの二つが必要 一般的にDriverパッケージは依存するため使わない database/sql を介してアクセス Dirver自体は次のようにすることでDriverとして登録(Go import _ ってなんだみてね) wikiではmysqlです
こんにちは、Service Reliability Group(SRG)の鬼海 雄太(@fat47)です。 SRGは主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事では2025年度のサイバーエージェントの新卒研修で「100分で学ぶ サイバーエージェントのデータベース活用事例とMySQLパフォーマンス調査」という研修を実施した話と、その内容について簡単に紹介しています。 例年の新卒技術研修について サイバーエージェントでは毎年、新卒のエンジニア全員を対象にした技術研修が実施されており、 セキュリティ研修やAWSなどのクラウド実習、ハッカソン形式のチーム開発研修 などの研修が実施されています。 しかし、データベースに関する内容は新卒のエンジニア全員を対象にした研修では実施されておらず、各部署（子
これはなに ども、LT開発部のもりたです。 今回はMySQLのスキーマ変更（DDL）について調べました。 DDLってなんとなく使うことは可能なんですが、データ量が増えていくにつれて障害の要因になったりもしますよね。もりたも障害が起きてDDLを調べたクチなんですが、調べれば調べるほどDDLに関する断片知識が絡まり合い、整理をつけるのが大変でした。今回はその断片を撚り合わせ、綺麗に縫合することで、この１記事だけで大体全てがわかるようにしました。もしDDLでお困りの方がいらっしゃいましたら、この記事（と、そこから辿れる諸記事）を足がかりに基礎と応用を身につけていただければと思います。 また、有識者の方々は是非まさかりを構えながら読んでください。技術的な間違いや現場的にはこうだよという事項がありましたら、コメント欄に記載いただけると幸いです。 構成 構成 まず構成ですが、以下の通り進めます。 前提
これはなに この記事は米シリコンバレーでデータベースコンサルや教育事業を展開するKloudDB社がポストした『Understanding How ONLINE DDL (INPLACE) works in MySQL』の翻訳記事です。 この記事ではDDL（スキーマ変更クエリ）の内部処理について詳細に解説しています。DDLはシンプルに利用できるものの、一歩踏み込むと複雑怪奇で理解の難易度は高いものでした。この記事はそこに焦点を当てたものになります。 翻訳するにあたり、技術的な正確性を担保しつつ、日本語表現として自然になるよう努めました。もし記事の中で技術的な観点で不正確な箇所があれば訳者の責任ですので、コメント欄などでご指摘いただけると幸いです。 また、翻訳について許可を下さったSrinivasa R Inaganti氏（同社CEO）に感謝します。 以下、訳者による前書き的なものを挟んで、翻
こんにちは。カミナシで「カミナシレポート」の開発を担当しているソフトウェアエンジニアの佐藤です。 カミナシレポートのバックエンドは Go で開発しており、データベースには Amazon Aurora MySQL を使用しています。また、データベースアクセスには ORM ライブラリの GORM を採用しています。 ほとんどのテーブルでは、プライマリキー（ID列）に AUTO INCREMENT を利用しています。これらのテーブルに GORM の Create メソッドなどを使って新しいレコードを挿入すると、AUTO INCREMENT で採番された値が自動的に対応する Struct のフィールドに反映されます。 AUTO INCREMENT による値の採番は MySQL 側で実行されているため、Go 側の Struct のフィールドに反映させるためには、Go アプリケーション側が何らかの方法
はじめに 過去の古いMySQLのバージョンでは、テーブル定義の変更を伴うようなDDLを実行する際には、元のテーブルとは別に新しいテーブルを作成し、元のテーブルデータを新テーブルにコピーした後に元のテーブルと入れ替えるといった手法で行われていました。 また、その間の対象テーブルへの更新はブロックされるといった挙動であった為、アプリケーションサービスを稼働中にDDLを実行するというのが、かなり敷居が高いものでした。 それが、MySQL5.5 より Fast Index Creation が採用され、InnoDBのセカンダリインデックスの作成、削除にはテーブルコピーを伴わないで実行できるようになり、処理の高速化が図られています。 その後、MySQL5.6 ではオンラインDDLが使用できるようになり一部のDDLでは、テーブルコピーを伴わずに、更新もブロックしないということが可能となり、更に MyS
例えば次のようなテーブルがあったとする。 -- PostgreSQL CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); -- MySQL CREATE TABLE history ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, data TEXT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First
はじめに こんにちは、SRE部プラットフォームSREブロックの石田です。普段はZOZOTOWNのSREを担当しています。 Amazon Aurora MySQL（以降、Aurora MySQL）のv2系の標準サポートが2024年10月31日に終了しました。私たちのチームではZOZOTOWNのID基盤で使用するAurora MySQLをv2系からv3系へアップグレードしました。ユーザ影響を抑えたアップグレードの実現のため、Amazon Aurora Blue/Green Deployments（以降、Blue/Green Deployment）を社内で初めて採用しました。 本記事では、Blue/Green Deploymentを採用する上で直面した課題や、検証方法について具体的な内容をご紹介します。なお、本記事の内容は2024年10月9日時点の情報に基づいています。 目次 はじめに 目次 A
あいさつ こんにちは！ 技術本部 技術戦略Div. リードエンジニアの関根です！ 2024年9月にジョインして、コツコツSRE活動を進めておりますっ エンジニア3年目ながらSREにゴリゴリ関われているのは、アドウェイズにオープンなコミュニケーションの文化があるおかげです。SREに少しでも興味がある人は、お待ちしておりますよ！ 最近、Netflix、アマプラ、U-NEXTに加えてAppleTVも契約してしまいました笑 映画やドラマの話しましょうね！ あとお酒が大好きなので、社内外問わず飲みに行きましょうね！！ この記事はなに？ この記事は、MySQLメジャーバージョンアップグレード時にアップグレードチェッカーユーティリティ(以下、アップグレードチェッカー)を理解して活用することで、効率的にアップグレードを進めるための情報を記載しています。 SREとして、EOL対応屋さん的な動きをコツコツやっ
BASE も Aurora MySQL v3 となりました SRE Groupの ngsw です。 2024/10/14〜10/15の深夜メンテナンスにて、BASEで利用しているAmazon Aurora MySQLのバージョンは、v2系からv3系となりました。 アップグレードの前提条件で大きなつまずきがありましたが、gh-ost を利用することで、乗り越えることができました。 この記事では当該アップグレードの中で gh-ost をどのように利用し、どういう恩恵を受けたかについて述べていきます。 おさらい : v3 対応しないとどうなるの？ Aurora MySQL v2は標準サポート終了が発表されており、v3への移行を終えていないDBクラスターには自動的に有償の延長サポートが適用される流れです。 Amazon RDS 延長サポートの使用 - Amazon Aurora 2024/10/3
こんにちは、Platform Team の荒引 (@a_bicky) です。前回は続・何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜という話を書いたんですが、今回は Repro の運用に 7 年以上携わる中で私が遭遇して印象的だった Aurora MySQL 絡みのトラブルについて紹介します。 Aurora MySQL が詰まってデータ処理のスループットが下がるとか、API のレスポンスが遅くなるとか、ALTER TABLE する度にアプリケーションエラーが発生するとか、胃が痛くなる胸が熱くなる話が多いので、Aurora MySQL を利用していなくても楽しんでいただけるのではないかと思います。Aurora MySQL を利用している方であれば参考になる情報もあるでしょうし、通常の MySQL にも適用可能な話もあります
こんにちは。スマートバンクのサーバーサイドエンジニアをやっておりますid:moznionです。 すっかり秋めいてきましたね。秋といえばMySQL*1、ということで今回は先日解消した「MySQLのロックに起因するブロックタイムアウト」のトラブルシューティングついて記していきたいと思います。 事の発端 ある時を境にSentryに ActiveRecord::LockWaitTimeout というエラーがしばしば報告されるようになっていました。 SentryにActiveRecord::LockWaitTimeoutが上がってきている様子 Mysql2::Error::TimeoutError: Lock wait timeout exceeded という文言から、MySQL上でロックを取っている他のクエリにブロックされ、そのブロックが長時間に渡ったため自クエリがタイムアウトしてabortしてし
こんにちは。LINEヤフー株式会社でデータベースエンジニアをしている、松浦、中園、大塚、曽根、笠井です。 データベースはLINEヤフーのさまざまなサービスを支える重要なソフトウエアですが、その安定的な運用やトラブルシューティングには、データベースに関する専門的な知識が必要です。 一方で、データベース部門に配属される新卒のエンジニアは、全員が学生時代にデータベースを専門的に勉強しているわけではありません。このような新卒エンジニアは、データベース部門へ配属後、OJTや実際のデータベースの運用業務に携わりながら、データベースに関する専門知識を深めていきます。 今回のブログ記事では、データベースエンジニアとしての専門性を高めるために、部門内で実施している専門書の輪読会、そして、MySQLを題材としたデータベースカーネルのモブプログラミング（以下、モブプロ）の取り組みについてご紹介します。 1. 輪
はじめに こんにちは。calloc134 です。 前のハッカソンイベントで、UUID をプライマリキーに利用するかどうかの議論がありました。 結果的にはあまりパフォーマンス要件の高くないアプリケーションであったため、プライマリキーとして UUID を採用することにしたのですが、イベント終了後に気になったため、調査を行いました。 今回は、この調査の結果を元に、MySQL と PostgreSQL におけるインデックスの内部構造の違いと、UUID をプライマリキーにする際の問題についてまとめてみたいと思います。 インデックスの概要 インデックスとは インデックスとは、データベースのテーブルに対して、アクセスを高速に行うための指標となる構造のことです。 インデックスとは日本語で索引ですが、まさに辞書の索引のように、アクセスにおいての手助けをしてくれます。 より具体的に解説すると、データベースにお
MySQL 8.0 は遅くなってきてる？何故？（１）
いろいろありますが、今後のことを考える前にまずは、バージョン8.0.xの現状を一旦整理・理解してから決めようと思います。 念を押しておきますが、このブログの「内容は個人の考えであって、所属組織とは方針が異なる」と考えてください。 MySQL内部の人は、クラウドとか最新のサーバーとかしか利用していないのかも知れず、MySQL 8.0 が日に日に遅くなっていることに気づいていない人しかいないのでしょう。しかし、数年前のローカルPCで動かすと年々動作が鈍くなっているのを感じます。マイナーバージョンアップで単スレッド性能が下がり続けるなんて商用システムではリスキーです。 証明が難しく、ずっと放置せざるを得なかったのですが、非常に重要な事柄ですので今一度、オープンになっているソースを基に分析をしてみます。 まず、測るモノサシを決めましょう。以前のエントリ「MySQLバージョンアップによるInnoDB
これはなに ども、レバテック開発部のもりたです。 今回はMySQLでのスロークエリログについて調査してまとめました。 スロークエリログといえば古くからパフォーマンスチューニングの力強い味方といったふうに語られることも多いですが、最近はクラウドで使える便利なツールも生まれています。この記事ではスロークエリログの一般的な使い方を紹介するとともに、他のツールとの比較や、どんな場面でスロークエリログが役に立つのか、また役に立たない場合はどんなツールを利用することができるのかについてまとめました。 足りないところなどあればおおいにマサカリ投げていただけると幸いです。 記事の流れ 記事の流れ この記事はそこそこ長いので、初めに記事の流れを解説します。適宜読み飛ばしてください。 なぜスロークエリログなのか ここではそもそもスロークエリログをなぜ確認したいのかみたいなところを説明します スロークエリログの
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
Aurora MySQL Zero ETL Integrations クラウドワークスのSREチームに所属しています@ciloholicです。 2023年11月にAurora MySQLとRedshiftのゼロETL統合がGAされました。この度、ゼロETL統合が本番導入可能かを検証する機会があったので、その検証結果を記載します。 aws.amazon.com 2024年7月時点での検証結果ですので、時間経過によって内容が変わっている可能性があります。その点は十分ご注意ください。 背景 まず、ゼロETL統合の検証しようと考えた背景について軽く説明したいと思います。クラウドワークスでは、MySQLのテーブルをDMS経由でRedshiftにニアリアルタイムで同期し、データ分析を行なっています。3年前は約30億レコードでしたが、現在では古いレコードの削減を行なったため、約25億レコードになりました
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
