中国地方DB勉強会 in 岡山の登壇資料です。 そのうちここで登壇動画が公開されることでしょう。 肝心なチートシートは以下のとおり。 PostgreSQL gist.github.com MySQL gist.github.com チートシートだけじゃわからない！困ってる！ Have Fun Techがバージョンアップのサポートしますのでお気軽にご相談ください。 have-fun.tech まとめ やっぱ中国地方DB勉強会は最高だぜ！

SELECT table_a.id, table_a.name FROM table_a INNER JOIN table_b ON table_a.id = table_b.id; メリットとしては、 どちらかのテーブルのid列のインデックスを使用可能 サブクエリがないことで中間テーブルが作成されない しかし、インデックスがない場合はEXISTSの方が良い場合があります ソートの回避 SQLでは暗黙的にソートが発生する演算が存在するので、 パフォーマンスにも影響するため、ソートが必要ない場合は考慮する必要があります ソートが発生する演算 GROUP BY句 ORDER BY 句 集約関数（SUM, COUNT, AVG） DISTINCT 集合演算子（UNION, INTERSECT, EXCEPT） ウィンドウ関数（RANK, ROW_NUMBER 等） メモリ上でのソートだけではなく

今回の記事は、パフォーマンスチューニングの観点と仕組みを理解することに主眼を置いています。具体的な対処方法についてはシステムによって異なるため、マニュアルの確認や、各種チューニングサービスのご利用をご検討ください。なお、この記事で対象にしているPostgreSQLのバージョンは9.5以降です。 本記事の構成 本記事「パフォーマンスチューニング9つの技」は以下4つの記事から構成されています。他の記事も併せてご覧ください。 パフォーマンスチューニング9つの技 ～はじめに～ パフォーマンスチューニング9つの技 ～「書き」について～（本記事） パフォーマンスチューニング9つの技 ～「探し」について～ パフォーマンスチューニング9つの技 ～「基盤」について～ 1. パフォーマンスチューニングの「書き」とは 一般的にデータベースは、大量データを扱い、大量の問い合わせや更新を高速に処理し、さらに障害発生

はじめに タイトルのとおり、RDBのデータモデリング・テーブル設計を行う際に参考にしている考え方と関連資料をまとめました。 P.S. なんと本記事内でいくつか参考として挙げさせてもらっている増田さん・かとじゅんさん・奥野さん・そーだいさんからコメントいただくことができました。 本当にありがとうございます。 前提 RDBを採用するのは事実を無駄なく正しく記録するため 正規化、トランザクション、制約とデータ整合性 基本的には始めに理想として集合論・リレーショナルモデルに基づいて正規化を考え(論理設計)、パフォーマンスなどの現実問題に対して折り合いをつけていく(物理設計) 制約を最大限利用する cf: ↑P91〜 ↑P.29,41 ↑P56〜 ↑5章 ↑P347～ 情報とデータ データ：単なる事実の値→これを永続化して蓄えるものがRDB 情報：データから生み出される意味や目的のあるもの→RDBか

この記事は、慶應理工アドベントカレンダー2021の20日目の記事です。 カレンダー全日埋まってすごい 🎉🎉 adventar.org 「Database Design and Implementation」という簡素なDBをスクラッチで作っていく本に取り組んだので、その読了エントリです。 Database Design and Implementation: Second Edition (Data-Centric Systems and Applications) (English Edition) 作者:Sciore, EdwardSpringerAmazon こんな人におすすめ MySQLやPostgreSQLを使った経験はあるが、DBの理論やその実装はあまり詳しくない人に特におすすめです。特に自作〇〇*1に興味がある人は間違いなく楽しめると思います。単純に本に紹介されている理論

軽量な時系列データベースエンジンをスクラッチで開発する機会があったので、どのように実装したのかを必要知識の解説を交えながらまとめていきます。 実装はGo言語によるものですが、本記事のほとんどは言語非依存な内容となっています。 モチベーション 筆者は時系列データを扱うツールをいくつか開発しています。その中の一つであるAliは負荷テスト用のcliツールで、メトリクスをクライアント側でリアルタイム描画できるのが特徴です。リクエスト毎にレイテンシーなどの計測結果が際限なく書き込まれてくる中、同時に一定のクエリパフォーマンスが求められます。 これは言ってしまえば、簡易クエリ機能付きのpush型モニタリングシステムを単一ホストで実現するようなものです。 以前までの実装ではヒープ上の可変長配列にデータポイントを追加していくだけだったので、当然ながら時間の経過とともにメモリ使用量が増加していく問題を抱えて

エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト

SQLのチューニング方法 昔Qiitaで書いたものをzennにうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく（自分の経験則）、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。（例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話） また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加

はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。 プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。 自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。 大量の逐次コミットをする バッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが１時間越えに化けることもザラにあるので原

初めに こんにちは。ビジネスチャットサービスTypetalkを開発・運用している吉田です。Typetalkではデータの永続化ストレージとしてPostgreSQLを利用しています。扱うデータ量は多く、チャットというサービスの性質上書込み頻度はとても高いです。PostgreSQLを使い日々開発を進めていると、追加する機能によってはスキーマを変更する必要があります。メンテナンスを計画・告知してサービスを止めてしまえば、時間はかかるかもしれませんがスキーマの変更はそう難しくありません。しかしTypetalkはユーザーが日々の業務を進めるために利用しており、サービスが止まるとコミュニケーションが取れなくなります。業務を円滑に進めるためのビジネスチャットツールですので、極力サービスは止めたくありません（最後の計画メンテナンスは2019年6月30日で1年以上前となっています。）。本記事では以下の3つのケ

アプリをリリースできる状態に保ったまま 段階的にリファクタリングするための 戦略と戦術 / Strategies and tactics for incremental refactoring

本記事は、『Software Design 2019年8月号』の第2特集「ゲームを題材に学ぶ 内部構造から理解するMySQL」をWeb掲載用に再編集したものです。 本記事のテーマを、より基本的なところから丁寧に解説した『SQLの苦手を克服する本　データの操作がイメージできれば誰でもできる』が2019年8月26日に発売予定です。本記事と併せてご活用ください。 ゲーム開発におけるRDBMSの役割 RDBMS（Relational DataBase Management System）は業務システム（以下、業務系）で多くの実績を作ってきました。一方でゲーム分野（以下、ゲーム系）では、RDBMSはほとんど使われていませんでした。ネットゲームではなく、スタンドアローンのゲームが中心だったので、プレーンなテキストやバイナリ形式でデータを保存していたからです（スタンドアローン環境向けのSQLiteもまだ

2019年7月10日に開催された「WEBエンジニア MeetUp＠札幌 #6 MySQL Special」での発表資料です。 発表時の資料に少し説明を加筆・修正してから公開しています。 ※追加で以下の更新をしました。(2019年7月19日) - MTSを効率化するための設定に関して、WRITE…

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 名著SQLアンチパターンを読み終えたので、それの復習のために悍ましいデータベースを作ろうと思った。 まず前半では、SQLアンチパターンを意図的に盛り込み、目も当てられない酷い設計をします。 そのあとリファクタリングを行なったER図に書き直していきます。 なお、真面目に書くと参考書の丸写しになってしまうので、この記事は アンチパターンもりもりのER図を見て嫌悪感を学習し、設計に役立てようという趣向のもと、詳しい説明は省きます。 とても良い本なので読んでください。 想定するシステムの概要と状況 目的において適切かはわかりませんが、とり

はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録

最近PostgreSQLでSQLチューニングや、DBが詰まった時の状況調査をいろいろやった。その時に便利だったクエリ達をまとめていく。PostgreSQLのバージョンは9.6系です。 SQLチューニングなどに便利だったクエリ達 それ以降に実行するSQLの実行時間を表示する。参考 https://morumoru00.wordpress.com/2011/05/08/postgresql-sql%E5%87%A6%E7%90%86%E6%99%82%E9%96%93%E3%82%92%E8%AA%BF%E3%81%B9%E3%82%8B%EF%BC%88timing/ \timing 実際にクエリを実行して実行計画や実行時間を表示する。クエリが実行されるので破壊的な操作も実行されてしまうことに注意。トランザクション張って最後にROLLBACKしましょう。参考 https://www.post

どうも！アプリケーション基盤チームの横田(@yokotaso)です！ kintoneなどで利用していたJavaフレームワークのSeasarのEOLに伴い、S2Daoからの脱却を試みたのですが、パフォーマンス問題や障害を発生させてしまうなど問題を多々発生させてしまいました。 同じ過ちを繰り返さないという強い決意のもと、今回の失敗をブログで公開いたします。 失敗をあえて公開する点で斬新かつ濃いブログ記事となっております！ 失敗体験の公開は恥だが役に立つ！ 移行先の選定の失敗 移行先として選定したプロダクトは Hibernate*1です。 Hibernateを選んだ理由としては Spring Framework を選定した Spring Frameworkで Interface + アノテーションでプログラミングするならSpring Data JPA が有力 JPAに準拠したのORMの中でも、H

SQL、書いてますか？ こと大規模データ処理の分野においてはSQLはもはや標準インターフェイスであり、 分析やらバッチやらに関わっている皆様は日々大量のSQLクエリーを生産していることと思います。 そこでちょっと気になるのが、 SQLのコーディングスタイルってどうするのが一般的なんだっけ……？ という点です。 イマドキはSQLなんてO/R mapperに吐かせることが多いからなのか、 それともコードを広い範囲で共有することがそもそもないからか、 SQLのコーディングスタイルについて見聞きすることは他のプログラミング言語に比べるとだいぶ少なく、 いまいち決定版と言えるスタイルがないなと感じています。 そんなわけで本日は、SQLのコーディングスタイルについての意識を活発化させるべく、 クックパッドでわたし（青木）が使っているコーディングスタイルから特徴的な点を紹介したいと思います。 特に、分析

37. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users ON users.id = blog.user_id AND users.delete_flag = 0 WHERE blog.delete_flag = 0 38. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users ON users.id = blog.user_id AND users.delete_flag = 0 WHERE blog.delete_flag = 0 ユーザの削除フラグを見る 39. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users