スロークエリログをどう使えばいいのかって疑問、全て解決
これはなに ども、レバテック開発部のもりたです。 今回はMySQLでのスロークエリログについて調査してまとめました。 スロークエリログといえば古くからパフォーマンスチューニングの力強い味方といったふうに語られることも多いですが、最近はクラウドで使える便利なツールも生まれています。この記事ではスロークエリログの一般的な使い方を紹介するとともに、他のツールとの比較や、どんな場面でスロークエリログが役に立つのか、また役に立たない場合はどんなツールを利用することができるのかについてまとめました。 足りないところなどあればおおいにマサカリ投げていただけると幸いです。 記事の流れ 記事の流れ この記事はそこそこ長いので、初めに記事の流れを解説します。適宜読み飛ばしてください。 なぜスロークエリログなのか ここではそもそもスロークエリログをなぜ確認したいのかみたいなところを説明します スロークエリログの
TiDBにおけるパフォーマンス検証の進め方とつまづきポイント
TL;DR TiDBにおけるパフォーマンス検証をどうやって行ったか パフォーマンス検証を行ったときにつまづいた問題とその対応策 TiDBの仕様やアーキテクチャなどの話はありません 前提 対象のDBはAmazon Auroraで稼働中 DBエンジンはMySQL TiDBに移行できないかPoCを実施 DB周りにいろんな課題があり、TiDBで解決できないか検証 TiDB Cloudで検証 本番運用を想定してTiDB Dedicatedを利用 先にお伝えしたいこと TiDB導入したいとか言う前に、今使っているRDBで発生しているスロークエリとかIndex設計を見直した方が良いです笑 理由はこの記事を見てもらえるとわかると思いますｗ パフォーマンス検証の進め方 1. パフォーマンス検証に利用するクエリを洗い出す 観点としては以下の2つ 実行される頻度が高いSQL 実行速度が遅いSQL（スロークエリ）
ORM のポリモーフィック関連は使うべきか？
データベースにおけるポリモーフィックは、子テーブルが複数ある親テーブルのうちどれか 1 つと関連することです。 この記事では、 images が users と posts のどちらかを親テーブルとして持つポリモーフィック関連を例に話を進めていきます。 データベースから見た問題点 ポリモーフィックの 1 番の問題としてテーブル間の関連がなくなることが挙げられます。これは外部キーを設定することができないからです。 外部キーは 2 つのテーブルを関連づけるキーですが、ポリモーフィックの子テーブルでは、行ごとに関連づけられる親テーブルが変わるために外部キーを一意に設定できません。 これにより以下の問題が発生します。 参照整合性がなくなる 外部キーを設定できないので、データベース上では参照整合性を保証できません。 そのためアプリケーションコードで制御する必要があります。 参照整合性 関連づけられて
RDS for MySQL・Auroraの機能を改めて学び直す #AWSreInvent | DevelopersIO
RDS for MySQLやAurora（MySQL）の基本的な話から、主要な機能紹介があったセッションでした。MySQLやAuroraの新機能をつまみ食い程度で情報取得していたので、改めて情報を得るのによい機会でした。 こんにちは。ゲームソリューション部の出村です。 AWS re:Invent 2023のセッションである「Why AWS is the place to build and grow your MySQL workloads」のレポートをお届けします。 概要 AWS has a rich tradition of innovating in the MySQL space. AWS built Amazon Aurora, a cloud-native managed database with MySQL compatibility. AWS also offers Am
Troubleshoot low freeable memory in Amazon RDS for MySQL
How do I troubleshoot low freeable memory in an Amazon RDS for MySQL database? I'm running an Amazon Relational Database Service (Amazon RDS) for MySQL instance. My available memory is low, my database is out of memory, or low memory is causing latency issues in my application. Short description To troubleshoot low memory issues, first check how Amazon RDS for MySQL uses memory. For more informati
PostgreSQLの仕組みから学ぶために必要な資料 - そーだいなるらくがき帳
質問されることが多いのでPostgreSQL初学者が運用を行うためにしっておく知識に必要な内容をまとめる。 PostgreSQLの基本的なアーキテクチャ PostgreSQLのアーキテクチャを知らないと自分がやっている作業が危険な作業かどうかわからないし、パラメータの意味もわからない。 そこで以下のリンクを読むと良い。 富士通が後述の資料を参考にまとめたのだろうなと思われる記事。 非常によくまとまっているのでわかりやすい。 www.fujitsu.com もっと細かく知りたいならPostgreSQL Internalsがおすすめ。 富士通の資料と重複するところがあるがこっちが本家。 Githubで管理されているので誤字脱字などあったら気軽にPRを出してほしい。 www.postgresqlinternals.org PostgreSQL Internalsが少し古いので最新事情で知りたい場
MySQLでUUIDv4をプライマリキーにするとパフォーマンス問題が起きるのはなぜ？（N回目）
はじめに こんにちは、令和トラベルでバックエンドエンジニアをしている飯沼です。 MySQLでは、UUID (v4)などのランダム性の高いIDをプライマリキーに設定すると、パフォーマンスが低下すると言われています。私自身もこの問題については認識しておりアンチパターンとして避けて来ましたが、イマイチ理由を理解できず何度も調べていたので自分の理解を整理しました。 ※ この記事は令和トラベルのTech LT会で共有した内容を記事にしたものです。社外の方にもご参加いただけるTech LT会は connpass にて告知しています。 UUIDをプライマリキーにするユースケース そもそもUUIDをプライマリキーにするユースケースはどのようなものがあるのでしょうか？ いくつかの観点から考えてみます。 パフォーマンス観点 大量の同時書き込みが発生するような状況でauto incrementを利用してIDを発
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い | コーソルDatabaseエンジニアのBlog
TOP BLOG 技術ブログバックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い コーソルDatabaseエンジニアのブログ 技術ブログ JPOUGMySQLOracle DatabasePostgreSQL対外講演まとめ 2020.05.07 渡部 亮太 バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い 渡部です。Oracle DatabaseだけではなくMySQLやPostgreSQLを含めた複数のRDBMS製品の使用経験があるエンジニアがとても増えているように感じます。 以前は、エンタープライズIT業界におけるRDBMSといえばOracle Database一択でしたが、オープンソースDBの高機能化・高信頼性化と、ライセンスコスト削減圧力の高まりにより、MySQLやPost
MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか？ | mond
MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか？ 端的に言うと性能が良いからです。 これを理解するにはバッファプールへの理解が必要です。ディスク指向のデータベースの上では有限のメモリを最大限活用することでメモリに入り切らない巨大なデータ群に対して良好な参照性能を出す必要があります。バッファプールとはディスク上のデータの羅列を固定サイズのページ（InnoDBの場合16KB）の羅列であるとして読み書きに必要な分だけをメモリに移し取り複数の書き込みをできる限りメモリ内で受け止めて後でまとめてディスクに書き戻すという、ライトバック型のキャッシュのような機構です。 この中においてバッファプールは有限のサイズしか無いので適宜プール内のデータを書き戻して入れ替えながら上手くやっていく必要があります。 さてB+treeとB-treeの最大の違いは木のリ
pt-online-schema-changeの導入時に検討したこと、およびRailsアプリとの併用について - freee Developers Hub
おはこんばんちは、Database Reliability Engineer (DBRE) の橋本です。今回は、pt-online-schema-changeというデータベースのスキーマ変更ツールを社内の運用に持っていくための過程や、freeeにおける運用上の工夫を紹介します。pt-online-schema-changeはある程度枯れた技術なので、いくつか事例が紹介されており、すでに運用に乗せている組織もあるかと思われますが、これから新規に導入する方などの参考になると幸いです。 背景 freeeではほぼ毎月ペースで深夜に定期メンテナンスを行なっており、おもにインフラの更新作業やアプリケーションの機能追加に伴うデータベースのスキーマ変更が行なわれます。 ここで少し寄り道をして、スキーマ変更を行なうためのMySQL（ストレージエンジンにInnoDBを使っている前提で進めます）のDDLのパター
PlanetScaleというサーバレスDBが凄く勢いのあるサービスらしいのでQuick Startやってみた - Qiita
PlanetScaleというサーバレスDBが凄く勢いのあるサービスと聞いて、公式にクイックスタートがあったのでやってみました。 環境 PC: MacBook Pro (Intel Core 2016) OS: macOS Montery12.2.1 では概要から確認していきます。 サーバーレスDBとは サーバがない、のではなく、サーバ管理や検討が不要 AWS Lambda(NoSQL)など PlanetScaleとは PlanetScale年表 2010年頃 YouTubeが急激に成長し、データベースが爆発しそうになっていたので、Sugu氏ともう一人のYouTubeのエンジニアがオープンソースプロジェクト「Vitess.io」（ヴィテス）を立ち上げる 2016年頃 MySQLでバイナリプロトコルを扱えるようにしたことで、VitessはYouTube以外の企業にとっても魅力的なシステムになり
次世代データベース TiDB の検証とその評価 [DeNA インフラ SRE] | BLOG - DeNA Engineering
※こちらは先日実施された DeNA インフラエンジニア / SRE MEETUP で話した内容を Blog 記事化したものです！ こんにちは！IT基盤部の熊谷です。IT基盤部にて大規模ゲームのインフラを見ている 新卒２年目のインフラエンジニアです。この記事では “DeNA でのデータベース運用とそのツラミ” と、“TiDB導入への検証・検討” をご紹介させていただきます。 データベースの最適解 DeNA のデータベース構成は最適解を求めて改良を積み重ねてきました。最初期の構成、(便宜上、第１世代と呼びます) では VM Instance 上に MySQL を構築し管理する MySQL on EC2 構成。続く第２世代では、マネージドサービスを駆使した Aurora MySQL 構成。この２世代の中で生じた “ツラミ” を解消する次の世代、言わば 第３世代に該当する新しいデータベース構成を現
![次世代データベース TiDB の検証とその評価 [DeNA インフラ SRE] | BLOG - DeNA Engineering](https://cdn-ak-scissors.b.st-hatena.com/image/square/a7a9ef2e383cbfc8885ee9e5572b0b143267e771/height=288;version=1;width=512/https%3A%2F%2Fengineering.dena.com%2Fblog%2F2022%2F01%2Finfra-meetup-tidb%2Fcover.png)
DBスキーマ変更管理ツール sqldef を試してみた - Qiita
1. sqldef とは sqldef は "The easiest idempotent MySQL/PostgreSQL/SQLite3/SQL Server schema management by SQL." と謳っているDBスキーマ変更管理ツールです。 通常の開発において DDL 文を管理する場合、環境を１から作るように CREATE TABLE 文など新規作成 DDL 文を準備すると共に、既に作成済みの環境でテーブルを変更するために ALTER TABLE 文など差分適用 DDL 文を準備する必要があります。この２種類の DDL 文を二重管理しないといけないというのは DBA にとっては頭の悩ましい問題でした。（差分適用 DDL 文のみ準備し、１から環境を作る場合も全ての変更を適用するという手もありますが…） sqldef を利用すると、変更適用先 DB の現在の状況と新規作成
MySQLとインデックスと私
2021/05/24 サイボウズ開運研修 動画が以下のサイトからリンクされています - https://blog.cybozu.io/entry/2021/07/20/100000 - これに矢印を書きながらぐりぐりやっていたわけなので、資料単体だとわかりづらいと思います…
サイボウズさんの開運研修(データベース)で話してきました
2024 ( 30 ) 12月 ( 5 ) 11月 ( 1 ) 9月 ( 4 ) 8月 ( 2 ) 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 ) 東京都オープンデータカタログサイトのCSVを使ってLOAD DATA LOCAL INFIL
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
Load Balanced ProxySQL in Google Cloud
There are three different ways ProxySQL can direct traffic between your application and the backend MySQL services. Locally, on the MySQL servers. Between the MySQL servers and the application. Colocated on the application servers themselves.Without going through too much detail – each has its own limitations. In the first form, the application needs to know about all MySQL servers at any given po
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostgreSQLとMySQLのメジャーバージョンアップのためのチートシート作った - そーだいなるらくがき帳
GitHub - ariga/atlas: Manage your database schema as code
MySQLが得意なこと、不得意なこと(仮)
