MySQL8.0のWindow関数を分かりやすく紹介する（５．謎多きフレーム句を使うと良いことはあるのか？） | スマートスタイル TECH BLOG
はじめに MySQL8.0がリリースされたことにより、Window関数の利用が可能になりました。 Oracle、PostgreSQL、SQL Server等でも利用できる関数ですが、「難しそう」、「どういう場合に使えば良いか分からない」というイメージを持たれている方もいると思いますので、この記事ではシンプルにどのようなことができるのかを紹介していきます。 過去の記事でもWindow関数について分かりやすく記載しておりますので、確認されていない方は是非こちらの記事もご参照ください。 ・MySQL8.0のWindow関数を分かりやすく紹介する（１.「集計関数×Window関数」のコラボ） ・MySQL8.0のWindow関数を分かりやすく紹介する（２．順位・連番の付け方（基本編）） ・MySQL8.0のWindow関数を分かりやすく紹介する（３．順位・連番の付け方（発展編）） ・MySQL8.
MySQLでオンラインでDDLを実行する際の注意点について | スマートスタイル TECH BLOG
はじめに 過去の古いMySQLのバージョンでは、テーブル定義の変更を伴うようなDDLを実行する際には、元のテーブルとは別に新しいテーブルを作成し、元のテーブルデータを新テーブルにコピーした後に元のテーブルと入れ替えるといった手法で行われていました。 また、その間の対象テーブルへの更新はブロックされるといった挙動であった為、アプリケーションサービスを稼働中にDDLを実行するというのが、かなり敷居が高いものでした。 それが、MySQL5.5 より Fast Index Creation が採用され、InnoDBのセカンダリインデックスの作成、削除にはテーブルコピーを伴わないで実行できるようになり、処理の高速化が図られています。 その後、MySQL5.6 ではオンラインDDLが使用できるようになり一部のDDLでは、テーブルコピーを伴わずに、更新もブロックしないということが可能となり、更に MyS
Repro で遭遇した Aurora MySQL にまつわるトラブル 5 選 - Repro Tech Blog
こんにちは、Platform Team の荒引 (@a_bicky) です。前回は続・何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜という話を書いたんですが、今回は Repro の運用に 7 年以上携わる中で私が遭遇して印象的だった Aurora MySQL 絡みのトラブルについて紹介します。 Aurora MySQL が詰まってデータ処理のスループットが下がるとか、API のレスポンスが遅くなるとか、ALTER TABLE する度にアプリケーションエラーが発生するとか、胃が痛くなる胸が熱くなる話が多いので、Aurora MySQL を利用していなくても楽しんでいただけるのではないかと思います。Aurora MySQL を利用している方であれば参考になる情報もあるでしょうし、通常の MySQL にも適用可能な話もあります
MySQLの ALTER TABLE ステートメントの実行形式について学んだメモ✍ - 継続は力なり
タダです. DB マイグレーションなどで ALTER TABLE ステートメントを実行する機会は多いと思いますが,自分は ALGORITHM 指定した実行形式を意識して使ったことがこれまでありませんでした.今回実行形式に触れる機会があったので学んだメモをまとめます. ALTER TABLE ステートメントにおける実行形式 MySQL において ALTER TABLE ステートメントの実行形式は3つあります. COPY INPLACE INSTANT COPY COPY は新しいテーブル定義で一時テーブルを作成し,既存データをコピーして入れ替えます.ALTER TABLE ステートメント実行中テーブルをロックするため,実行中は書き込みがブロックされます.大規模テーブルへのロックがかかると,サービス利用に影響も出てしまうのでメンテナンスも必要になります.利用するケースとして主キーの削除やデータ
スロークエリログをどう使えばいいのかって疑問、全て解決
これはなに ども、レバテック開発部のもりたです。 今回はMySQLでのスロークエリログについて調査してまとめました。 スロークエリログといえば古くからパフォーマンスチューニングの力強い味方といったふうに語られることも多いですが、最近はクラウドで使える便利なツールも生まれています。この記事ではスロークエリログの一般的な使い方を紹介するとともに、他のツールとの比較や、どんな場面でスロークエリログが役に立つのか、また役に立たない場合はどんなツールを利用することができるのかについてまとめました。 足りないところなどあればおおいにマサカリ投げていただけると幸いです。 記事の流れ 記事の流れ この記事はそこそこ長いので、初めに記事の流れを解説します。適宜読み飛ばしてください。 なぜスロークエリログなのか ここではそもそもスロークエリログをなぜ確認したいのかみたいなところを説明します スロークエリログの
SQLBoilerのちょっとしたTips集
はじめに SQLBoilerは、スキーマに合わせたORMを生成するツールです。 READMEにも書かれていますが、意外と気づきづらい部分があったりするので、使い方から、ちょっとしたTips、ハマりポイントをまとめます。 少しでも参考になれば幸いです。 前提 MySQL SQLBoiler v4.16.1 生成したコードはmodelパッケージに配置されているとします テーブルは以下を想定 CREATE TABLE `teams` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `users` ( `id` int(11) NOT NULL AUTO_
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（スロークエリ）
Dive into InnoDB from redo logs
あの日俺達が夢見たサーバレスアーキテクチャ/the-serverless-architecture-we-dreamed-of
どのレイヤー（層）でトランザクションを実装すべきか
このように、層ごとに関心事の分離を行うことで、保守性の高い（変更容易性や再利用性等）アプリケーションを実現できます。 しかし、「トランザクション」においてはどうでしょうか。 トランザクションはビジネス領域においても、技術領域においても関心事がある内容です。 そういう曖昧なものは「ひとまず usecase 層に入れてしまえ」という方針になりがちです。 ですが、DB 固有の知識を usecase 層の関心事にしてしまっては、関心事の分離をするメリットが得られません。 そのため、関心事の分離を実現しつつトランザクション実装をする方法を模索してみました。 前提 1. クリーンアーキテクチャを採用している（オニオンアーキテクチャやレイヤードアーキテクチャも含む） そもそもビジネス知識と技術知識を分離していないアーキテクチャを採用している場合、メリットは得られません。 そのため、オニオンアーキテクチャ
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を発
原因不明だったRDS負荷のスパイクを改善できた話 - Qiita
概要 当時数ヶ月間誰も原因がわからなかった一時的にRDSの負荷（CPU使用率）がスパイクする現象の原因を調査できる環境を整えて、原因分析〜改善まで実施したときの話です。 1つ1つの取り組み自体は大きなことはやっていませんが、一連の動きで得られたものも多かったのでアウトプットしようと思い記事にまとめました。 取り組んだ課題 原因を特定するためのツールがない そもそも何が原因でRDSのCPU負荷が高まっているのかを調べるための情報がCPU使用率以外に全くない状況でした。 そこでRDSの負荷原因を探る方法を調べると、Performance InsightsやCloudWatch Logsへのスロークエリログ出力を使う記事をいくつか見つけたのでこの2つについて調べることにしました。 Performance Insights データベース負荷をSQLなどの単位で時系列で可視化したり、トップSQLやD
MySQL(InnoDB)における各種ロックの挙動を調べてみた
はじめに みなさんこんにちはメリークリスマス🎄 ついにアドベントカレンダー最終日！！！ 現在SODAでwebエンジニアをしているtoshikiです。(3記事目で謎の自己紹介) CTOからflexispotのデスクを譲り受ける代わりにテックブログ3記事執筆するという約束を果たすべく、SODAのAdvent Calendar 2023で3枠担当することになり、この記事をもって無事プレゼントの配達が完了しました🎅(sorenani) 今日はクリスマス当日ということで、自分自身理解が曖昧だったMySQLのストレージエンジンであるInnoDBのロック周りの挙動をMySQLの公式ドキュメントを読みつつ調査してまとめてみました。 この記事でわかるInnoDBのロックの種類 共有ロックと排他ロック インテンションロック ギャップロック ネクストキーロック 検証環境 MySQLのVersion mysq
バックアップと障害復旧から考える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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
大テーブルと小テーブルのJOINのコスト計算の話
A Simple Guide to Compare MySQL vs PostgreSQL
【追記有り】Amazon Aurora MySQL Version3でのOnline DDLの落とし穴とその回避方法 - CyberAgent SRG #ca_srg
