第14回 中国地方DB勉強会 in 福山の登壇資料です。 https://dbstudychugoku.github.io/events/event-014.html 合わせてこちらのYouTube動画を見ることをオススメします。 PGCon 2014 Tokyo【D3】PostgreSQ…
この記事は DeNA 20 新卒 Advent Calendar 2020 19日目の記事です。 はじめに MySQLやPostgreSQLに代表されるRDBMSではトランザクションと呼ばれる仕組みが提供されています。多くのWebアプリケーションエンジニアはこのトランザクションを駆使してDBとやりとりをするロジックを組み立てることになります。 しかし不整合を起こしたくない処理があるからといって闇雲にトランザクションを張ったり、トランザクションが張られているからと安心してアプリケーション側で闇雲にロジックを組み立ててしまうと思わぬバグを生むことになってしまいます。 このエントリでは、「トランザクションを張っておけば大丈夫」という考え方は危険な場合もあるということを、ありがちな実装例を交えて紹介していきます。 並列に処理されるトランザクション そもそも、トランザクションは全て直列に処理されるわ
MySQL/Postgres におけるトランザクション分離レベルと発生するアノマリーを整理する https://zenn.dev/mpyw/articles/rdb-transaction-isolations 上記のスライドの具体的な結論に至るまでの導入として,知識があまりない状態でも段階的に読み込んでいけるように心がけたスライドで,株式会社ゆめみの社内勉強会にて発表しました。 スライドの途中の URL などは PDF としてダウンロードするとクリックできると思います。 事前のレビュー協力者 - https://twitter.com/neko_han25 - https://twitter.com/KentarouTakeda
このチュートリアルでは、Kubernetesクラスター上に、node.js、MySQLを使ったアプリケーション(koa-sample)をデプロイします。外部からのリクエストを受けるロードバランサーとして、KubernetesのIngressの機能を利用します。1 前提条件 Kubernetesクラスターがセットアップ済みであること 上記のクラスターに対してkubectlコマンドが実行可能であること 0 . 準備作業 アプリケーションの一連のmanifestファイルがこのリポジトリに保存されています。まずはこのリポジトリを適当なディレクトリにcloneして下さい。 以下は、コマンドラインツールのgitを使う例です。
WHERE 句内のテーブル、カラム、インデックス、および条件の詳細に応じて、MySQL オプティマイザは SQL クエリーに含まれるルックアップを効率的に実行するための多くの技法を考慮します。 巨大なテーブルに対するクエリーは、すべての行を読み取らなくても実行でき、複数のテーブルを含む結合は、行のすべての組み合わせを比較しなくても実行できます。 オプティマイザがもっとも効率的なクエリーを実行するために選択する操作のセットは、「クエリー実行プラン」と呼ばれ、EXPLAIN プランとも呼ばれます。 目的は、クエリーが適切に最適化されていることを示す EXPLAIN プランの側面を認識し、非効率的な操作が見られた場合に、プランを改善するための SQL 構文とインデックス設定技法を学ぶことです。
Lookup: where col = 1 のような等価比較 VISUAL EXPLAIN でインデックスの挙動を確かめる(本題) 本題です。青→赤の順にコストが大きいことだけ分かっていれば、詳細に見方を覚えなくても使えます。 今回使うのは下の2つのテーブルです。どのユーザがコンバージョンしたかを持っておく cv テーブルと、それが紐付く広告の ad テーブルです。 今回実験のためにざっくり作成したデータについて下に列挙します。 インデックスは簡単のためこの時点で PRIMARY KEY のみ cv は約100万件、 ad は約4000件 cv の status と ad の type はそれぞれ10種類で偏りなし 時刻を保存するカラムは UNIX TIME でここ一ヶ月のデータを格納 ER 図はせっかくなので MySQL Workbench で出力しました。 Workbench は外部キ
EXPLAIN ステートメントは、MySQL がステートメントを実行する方法に関する情報を提供します。 EXPLAIN は、SELECT, DELETE, INSERT, REPLACE および UPDATE ステートメントで動作します。 EXPLAIN は SELECT ステートメントで使用される各テーブルに関する情報の行を返します。 これは、MySQL がステートメントの処理中にテーブルを読み取る順番で、出力にテーブルを一覧表示します。 これは、MySQL が最初のテーブルから行を読み取り、次に 2 番目のテーブル、3 番目のテーブルなどで一致する行を検索することを意味します。 すべてのテーブルが処理されると、MySQL は選択したカラムを出力し、さらに一致する行があるテーブルが見つかるまで、テーブルリストを逆戻りします。 次の行がテーブルから読み取られ、プロセスは次のテーブルに進みま
本稿では MySQL のデータベースを論理バックアップ/復元する方法について説明します。MySQL データベースのバックアップ/復元には、mysqldump コマンドを利用します。 mysqldump コマンドは、MySQL をインストールすれば含まれています。 バックアップ ここでは2通りのバックアップ方法を説明します。 特定のデータベースのみバックアップする方法 全てのデータベースをバックアップする方法 バックアップのコマンドを解説する前に知っておいて欲しい mysqldump コマンドのオプションがあります。 –single-transaction オプションです。 このオプションは InnoDB のトランザクションを利用してバックアップを取得します。 例えばバックアップの対象となるデータが膨大で、バックアップに1時間かかるとしましょう。 そうした場合でもトランザクションを利用してく
MySQL EXPLAINとは EXPLAINとは、MySQLがどのような実行計画でクエリ実行するかを表示するコマンド。EXPLAINの結果を見ることで効率の悪いクエリを見つけたり、改善結果を確認できる。 EXPLAIN ( SELECT f.film_id, f.title, f.release_year, a.first_name, a.last_name FROM film f INNER JOIN film_actor fa ON fa.film_id = f.film_id INNER JOIN actor a ON a.actor_id = fa.actor_id ); JOIN時のEXPLAINの見方 JOINする場合は、駆動表が一番最初に表示される。 先程の例だと、actorテーブルが駆動表になっているということになる。 駆動表を固定したい場合は、MySQL 8.0からはJ
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
2012年12月03日16:20 MySQL MySQLでDateTime型のカラムをDate型で検索するときに気をつけること 例えばこんなテーブルがあったとして、 DESC products; +---------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------------+--------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | name | varchar(255) | NO | MUL | NULL | | | created_at
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約?を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか?そのためにはまず現在どのようにクエリが実行さ
「JOIN」と「SELECT列のサブクエリー」は、他のテーブル情報をキーを使って取得するという点においての効用としては似ています。 私の場合は、JOINで取れるものは、サブクエリーは基本使いませんが、その理由は「可読性」もありますが「性能的」にもサブクエリーは劣っているという印象もあります。 しかし、昨今のオプティマイザや処理の最適化が行われている、RDBではどのような結果になるのか気になったので、単純なサンプルを使って代表的なデータベースそれぞれの性能的な違いを検証してみました。 (PC環境やデータベースのバージョンやドライバやデータ件数、使用ツールの違いで結果が異なる場合があるので、あくまで参考として頂ければと思います。) 検証用テーブル ※リレーションは、[M_PRODUCT.PRODUCT_ID] 1 – 0..N [T_ORDER.PRODUCT_ID]
MySQLのロック ロックとはトランザクションの並列度を上げる為の並列スケジューリング方法の一つ トランザクションをサポートしているデータベースにおいては、トランザクションの並列数を上げる事が性能アップの一つの方法。 他のトランザクションに更新して欲しくないデータだけにロックをかけて、ロックされたデータ以外を更新するトランザクションは並列で実行される。 Innodbは行ロック? Innodbは更新対象の行だけをロックする。と思っていると、意外な落とし穴にハマる。 その一つがギャップロック。 ギャップロックを実際に起こしてみる サンプルテーブル idとstrがあるだけのシンプルなテーブル。idがPKで1~5までは順番に、その後、10,20と飛んで行が入っている。 通常の行ロック トランザクション1 select for updateでid=2の行を明示的にロック トランザクション2 id=1
Photo by Kat Stokes on Unsplashこんにちは。仮想通貨の損益計算ツール「Gtax」、仮想通貨の確定申告サポート「Guaridan」を提供するAerial Partnersのエンジニアインターンの伊藤です。 今回は、Aerial Partnersのチームが実際にどのような技術を用いてブロックチェーンの社会実装を進めているかをお伝えするために、僕が最近取り組んでいた、大量のレコードを捌くDB処理の実装において直面した問題についてお話させていただきます。 InnoDBのロックアーキテクチャはややこしい!例題です。以下のような操作において、一体どのような原因でデッドロックが発生してしまうのでしょうか。 テーブル内容 > SHOW COLUMNS FROM t1;+-------+---------+------+-----+---------+-------+| Fie
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
自分の浅はかな理解だと、Deadlock が起こる理由が説明できないケースに遭遇したので、InnoDB の行レベルロックについて調べてまとめてみました。 「行レベルロックだと、同じ行を更新する場合にしか Deadlock が起こらないんでしょ」と思っているような人が対象です。 また、主に InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる を参考にさせていただいたので、そちらの内容がすんなり理解できる方には冗長な内容だと思います。 MySQL のバージョンは 5.6.33 です。 サンプルデータ 次の SQL で作成したデータを扱うことにします。 CREATE TABLE `orders` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `product_id` int(10) unsigned NOT NULL, `us
2009年10月28日09:33 MySQL MySQLでインデックスを使って高速化するならCovering Indexが使えそう Linux-DB システム構築/運用入門 (DB Magazine SELECTION) 著者:松信 嘉範 販売元:翔泳社 発売日:2009-09-17 おすすめ度: クチコミを見る 最近、この本を読んでいます。非常に面白いし、参考になります〜。中でもインデックスについての記事が特に興味深かったので簡単にまとめてみます。 前提 ・インデックスは検索性能には効果があるが、更新性能は落ちてしまう ・MyISAM と InnoDB ではインデックスの構造が違う ・インデックスは B+Tree インデックスと呼ばれ、ルート、ブランチ、リーフの階層構造になっている ・インデックスはソートされた状態で作成されている まずは MyISAM と InnoDB でのインデックス
MySQLレベルでの話。 最近SQLの細かい挙動とか、しっかり把握しきれてないなーとか、 一度覚えたことが年が経ってあやふやになってるところが多くある。 また勉強し直したい。 RDBMSとうか、KVSだのNoSQLだのDBのシステムによって大きく違うと思うけれど、 私はMySQLとちょっとPostgreSQLとかSQLiteとか触ったくらいなしょっぱい男です(先の言い訳)。 主に扱うのはMySQLで、そのくらいしかついていけません(わかるとは言いません)。 「MySQLってそうなんだ〜。Oracleだとこうなんだよー、きゃははー」とか言われても、しょんぼりとしかしません。 本題。 Rails使ってると、マイグレーションファイルでDBのテーブル定義して、 rake db:migrateでマイグレーションファイルを元にテーブルが作成されちゃう。 ここで使うDBによって、うまいこと作られる型に差
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く