PostgreSQLで時間枠を適切に扱う設計 - そーだいなるらくがき帳
はじめに Googleカレンダーのような時間枠を扱うシステムを設計する際、開始・終了時刻を管理するロジックは容易ではない。 しかし、PostgreSQLには 範囲型 があり、この機能を活用することで、開始時刻（begin_at）と終了時刻（end_at）を1つのカラムで扱えるようになる。 そこで本稿では、範囲型を用いた設計と、その利点を紹介する。 時間枠を扱う難しさ まず前提として時間枠の扱いがなぜ難しいかを紹介する。 ソフトウェアデザインでやっている連載、実戦データベースリファクタリングの 【12】厄介な時間枠に向き合う でも紹介したが、時間の範囲を比較するときが難しい。 範囲の重なりには以下の種類がある。 包含：範囲Aが範囲Bを完全に含む 重複：範囲Aと範囲Bに共通点がある 隣接：範囲Aと範囲Bが隣り合う 時間枠の扱いはSQLに限らず、プログラミングの題材として難易度が高い。 特に重複
Aurora PostreSQLのログをCloudWatch Logsを経由せずに直接S3バケットにPUTしてみた | DevelopersIO
CloudWatch Logsを経由せずに直接S3バケットにログをPUTしたい こんにちは、のんピ(@non____97)です。 皆さんはAurora PostgreSQLのログをCloudWatch Logsを経由せずに直接S3バケットにログをPUTしたいと思ったことはあります? 私はあります。 CloudWatch LogsにDBのログを流すとそれなりに料金がかかります。特にlog_statementであればall、mod、pgaudit.logであればall、read、writeにすると大量のログが流れがちです。 Aurora PostgreSQL DB クラスターのクエリログ記録をオンにする - Amazon Aurora pgAudit 拡張機能のセットアップ - Amazon Aurora そのため、S3バケットにログを出力したいところでしょう。 S3バケットにログを出力する方
オンプレPostgreSQLをAmazon Aurora PostgreSQLへ移行しようとしてINDEX作成にハマりました - Oisix ra daichi Creator's Blog（オイシックス・ラ・大地クリエイターズブログ）
SREの林 aka もりはやです。 先日オンプレで稼働していたとあるPostgreSQLのDBを、Amazon Aurora PostgreSQL（以後はAurora）に移行を行ったところ CREATE INDEX が以下のエラーで作成できない問題に苦労させられたため、解決策と合わせて公開します。 これがベストな対応かは自信がないため、より良い方法をご存知の方はお気軽に教えてください。 以下はDBのリストア中に CREATE INDEX で発生したエラーです。 pg_restore: error: could not execute query: ERROR: could not write to file "base/pgsql_tmp/pgsql_tmp19647.47.fileset/1.2": No space left on device CONTEXT: parallel wo
「脱 Oracle」 速習ガイド （PostgreSQL 11〜15 対応版） - 株式会社インサイト
はじめに 本ガイドの目的と対象読者 本ガイドは Oracle から PostgreSQL へのデータベース移行リファレンスである。移行に要する工数の算定を容易化することを目的として、考慮すべき非互換情報をシンプルかつ具体的に整理してある。「脱 Oracle」を推進するマネジャーやリーダーのみならず、すべてのメンバーにとって必携のガイドとなることを目指した。本ガイドの情報の多くはインターネット上に公開されているが、それらが体系的、一元的に、かつ最新の PostgreSQL に対応しているものが見当たらなかった（2023年3月12日現在）。そのため、読者の便宜を図る点において本ガイドの果たす役割は大きいと考えている。 本ガイドの前提 本ガイドの内容は下記のデータベース間の移行を前提に記載してある。 移行元データベース
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（スロークエリ）
どのレイヤー（層）でトランザクションを実装すべきか
このように、層ごとに関心事の分離を行うことで、保守性の高い（変更容易性や再利用性等）アプリケーションを実現できます。 しかし、「トランザクション」においてはどうでしょうか。 トランザクションはビジネス領域においても、技術領域においても関心事がある内容です。 そういう曖昧なものは「ひとまず usecase 層に入れてしまえ」という方針になりがちです。 ですが、DB 固有の知識を usecase 層の関心事にしてしまっては、関心事の分離をするメリットが得られません。 そのため、関心事の分離を実現しつつトランザクション実装をする方法を模索してみました。 前提 1. クリーンアーキテクチャを採用している（オニオンアーキテクチャやレイヤードアーキテクチャも含む） そもそもビジネス知識と技術知識を分離していないアーキテクチャを採用している場合、メリットは得られません。 そのため、オニオンアーキテクチャ
PostgreSQLの実行計画の推定行数と実行数の乖離改善の考え方
はじめに 以前こんなツイートをしました。 すると、リプライで色々とコメントを頂きました。（疑問を投げかけたら答えてくれる方々、本当にいつもありがたいです🙇♂️） ということで、本記事では推定行数と実際の行数の乖離を減らすために何をやったのかを備忘として書きます。 ただ、実際のSQLや実行計画を書くことはできないので、あくまでどんな考え方をしたのか、ということを書きます。 対処法①（対象のテーブルのautovacuum頻度を変更） 対象のテーブルはかなり更新の激しいテーブルだと聞いていたので、まずは統計情報が最新化されているかを考えました。 更新が激しくてautovacuum時の自動ANALYZEが追い付いていないんじゃないかと考え、対象のテーブルだけ自動ANALYZEの頻度が上がるように設定を変更しました。 PostgreSQLの設定パラメータは基本的にはpostgresql.conf
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
PostgreSQLの仕組みから学ぶために必要な資料 - そーだいなるらくがき帳
質問されることが多いのでPostgreSQL初学者が運用を行うためにしっておく知識に必要な内容をまとめる。 PostgreSQLの基本的なアーキテクチャ PostgreSQLのアーキテクチャを知らないと自分がやっている作業が危険な作業かどうかわからないし、パラメータの意味もわからない。 そこで以下のリンクを読むと良い。 富士通が後述の資料を参考にまとめたのだろうなと思われる記事。 非常によくまとまっているのでわかりやすい。 www.fujitsu.com もっと細かく知りたいならPostgreSQL Internalsがおすすめ。 富士通の資料と重複するところがあるがこっちが本家。 Githubで管理されているので誤字脱字などあったら気軽にPRを出してほしい。 www.postgresqlinternals.org PostgreSQL Internalsが少し古いので最新事情で知りたい場
型キャストの場所のせいで、秒で終わっていたクエリに1時間超かかるようになってしまった話 - SmartHR Tech Blog
SmartHRで届出書類という機能を担当しているプロダクトエンジニアのsato-sと申します。 今日は、以前私が調査にとても苦労したパフォーマンス上の問題の話を紹介したいと思います。 TL;DR PostgreSQLのアップグレードを実施した アップグレード後、今までは問題のなかった特定のクエリの実行に1時間超かかり、DBのCPU使用率がピッタリ100%に張り付くようになった 色々調査した結果、PostgreSQL上の型キャストの場所のせいで、良くないクエリプランが選択されることが原因だった 型キャストの場所には気をつけよう PostgreSQLのアップグレードと挫折 SmartHRでは基本的にWebアプリケーションのデータベースとしてGoogle CloudのCloudSQLによって提供されるPostgreSQLを利用しています。 私の担当している届出書類機能では、利用中のPostgre
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で全文検索機能を使う際のパフォーマンスについて調査してみた - iimon TECH BLOG
こんにちは、CTOの森です。iimonは今回が初のアドベントカレンダー参加です！ 本記事はiimonアドベントカレンダー1日目の記事となります。 はじめに 検証した環境 MySQL/mecabのインストール 大量のデータを入れる 1レコードのINSERTにかかった時間 検索してみる 検索文字列が「出来事」の場合 インデックスなし N-gram(bi-gram) IN NATURAL LANGUAGE MODE IN BOOLEAN MODE MeCab IN NATURAL LANGUAGE MODE IN BOOLEAN MODE 検索文字列が「チューリングはロンドンのリッチモンドに住み」の場合 まとめ 参照したサイト 最後に はじめに 今回はMySQLで全文検索機能を使う際のパフォーマンスについて書こうと思います！ 全文検索をちゃんと使うのであればElasticsearchやSolrな
Choose Postgres queue technology
Introduction⌗ Postgres queue tech is a thing of beauty, but far from mainstream. Its relative obscurity is partially attributable to the cargo cult of “scale”. The scalability cult has decreed that there are several queue technologies with greater “scalability” than Postgres, and for that reason alone, Postgres isn’t suitably scalable for anyone’s queuing needs. The cult of scalability would rathe
PostgreSQLで最新の値を取得する
はじめに 最近PostgreSQLで最新の値を取得するためにいろいろと試行錯誤したので備忘録として残す。 バージョンはpostgresql 16.0です。 (出力結果は一部省略しています) やりたいこと 以下のようなテーブルから学生IDごとに最新のvalueを取得したい。 CREATE TABLE IF NOT EXISTS exam ( id UUID DEFAULT gen_random_uuid (), student_id UUID DEFAULT gen_random_uuid (), scoring_date TIMESTAMP NOT NULL, VALUE INT NOT NULL, CONSTRAINT pk_id PRIMARY KEY (id) ); WITH student AS ( SELECT gen_random_uuid () AS id FROM GENE
入門 B-link tree
概要 DBMS で広く利用されている B+ tree には様々な variant が存在するが、B-link tree もその1つ。 シンプルなラッチプロトコルで並行アクセスをさばけるよう、リーフノード以外のノードにも右の隣接ノードへのポインタを持たせた構造となっており、PostgreSQL で使われていることでも有名。 この記事では主にこの B-link tree に焦点を当てる。 B+ tree 全般やその他インデックス技術自体に興味がある場合は「最強DB講義 #10 いまどきのデータベース索引技術（石川佳治 教授）」の講義資料を読むのがおすすめ。 B-link tree 理解する上で必須な知識「ラッチ」 「ラッチ」というのはいわゆるロックのことだが、DB においては「ロック」というとトランザクション分離のための高価な(数千CPUサイクルを要する)処理を指すことが多く、「ラッチ」という
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
A Simple Guide to Compare MySQL vs PostgreSQL
PostgreSQLとMySQLのメジャーバージョンアップのためのチートシート作った - そーだいなるらくがき帳
