90秒かかるDELETE文の原因を探る【PostgreSQL】 - エムスリーテックブログ
こんにちは！ デジスマチームの山田です。これはデジスマチームのブログリレー4日目の投稿です。 事業が成長してユーザー数やトランザクションが増加すると、それに比例して扱うデータの量やバリエーションも増加します。サービス規模の拡大に伴い発生する課題の1つにスロークエリがありますが、デジスマ診療においてもサービスの成長とシステムの健全性を維持するためにクエリの改善に日々向き合っています。 データベースの気持ちを知りたい 本稿ではそうした取り組みの1つとして、とあるDELETE文の改善の過程と、改善に至るまでに得られた調査のTipsを共有できればと思います。なお今回の事象は内部運用における特定のプロセスを最適化するための取り組みであり、利用いただいている方々の体験やサービス品質に影響を及ぼしたものではないことを申し添えておきます。 前提としてデジスマ診療はPostgreSQL互換のAmazon A
[アップデート] Amazon Aurora PostgreSQL でも遂にリードレプリカのローカル書き込み転送機能がサポートされました | DevelopersIO
[アップデート] Amazon Aurora PostgreSQL でも遂にリードレプリカのローカル書き込み転送機能がサポートされました いわさです。 Amazon Aurora MySQL にはリードレプリカの書き込み転送機能というものがあります。 通常データベースでリードレプリカを導入する場合はアプリケーション側がライターとリーダーのどちらへクエリを送信するのか意識する必要があります。 またライターへの書き込み直後にリーダーから読み込みを行おうとすると、レプリケーションラグによってまだ書き込み内容が反映されていない場合があり、一貫性のある読み取りが必要な場合はライターから読み取りを行わなければいけない場合などがアプリケーション側で色々と考慮が必要です。 Aurora MySQL の書き込み転送機能を有効化すると、リーダーに対して書き込み操作を行うことが出来ます。 これによってアプリケー
![[アップデート] Amazon Aurora PostgreSQL でも遂にリードレプリカのローカル書き込み転送機能がサポートされました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/1351034e80b27cf97625802dbb9e17683eba0783/height=288;version=1;width=512/https%3A%2F%2Fimages.ctfassets.net%2Fct0aopd36mqt%2Fwp-thumbnail-7e1a533ff5b5a6a8eb5d4ae82bacdcd6%2F5845157a3c941213d245ec7cdf7358e8%2Famazon-aurora)
次期PostgreSQL 18では非同期I/Oの採用により性能が2～3倍向上する見通し
PostgreSQL開発チームは先月（2025年5月）にリリースした「PostgreSQL 18 Beta 1」で非同期I/O処理を実装したことを明らかにしています。 同チームのテストによると、シーケンシャルスキャンやビットマップヒープスキャン、バキュームといった処理において2～3倍の性能向上が見られたとのことです。 同期処理はシンプルだが待ち時間が発生する これまでのPostgreSQLは同期I/O処理を採用していました。これは例えばOSにファイルリードのようなI/O処理を依頼すると、処理が終了して結果が返ってくるまで、すべてのPostgreSQLの内部処理が一時停止することを意味します。 同期I/O処理の利点はすべてのI/O処理が同期的に行われるため、実装が比較的シンプルで容易だというメリットがあります。これはバグを引き起こしにくいとも言えます。 一方で、ひとつひとつのI/O処理が完了
AWS、事実上無制限にスケールするPostgreSQL互換の大規模分散DB「Amazon Aurora DSQL」正式版を提供開始
Amazon Web Services（AWS）は、事実上無制限にスケールするPostgreSQL互換の大規模分散データベース「Amazon Aurora DSQL」の正式版を提供開始したと発表しました。 Amazon Aurora DSQLは昨年（2024年）12月のイベント「AWS re:Invent 2024」で発表された、サーバレスな大規模分散データベースです。 1つのリージョン内で3つのアベイラビリティゾーンにまたがる構成、もしくは複数のリージョンにまたがる構成において、自動スケーリングと自動障害復旧機能を備えたActive-Activeなクラスタを実現できます。 分散処理による高いスケーラビリティおよび複数のアベイラビリティゾーンやリージョンによる冗長構成による高可用性の両方を実現するだけでなく、複数リージョンのような広域での分散データベースにおいてトランザクション処理による強
PostgreSQL設計ガイドライン | Future Enterprise Arch Guidelines
本規約は、世の中のシステム開発プロジェクトのために無償で提供致します。 ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。 また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。 はじめに 本規約はPostgreSQLを使用する開発者向けに、DBのテーブルやカラムの命名・型桁・制約などのスキーマ管理に加え、履歴・排他制御・マルチテナント対応などアプリケーション設計を含む内容についての設計標準を紹介する。 以下の目的・意図で作成するものとする。 DB設計の主な論点／設計項目／設計観点を提供することで、開発者の考慮漏れを防ぐとともに、チームでの設計上の合意形成を手助けするシステム開発における標準ラインとなる設計手法を提供することでナレッジやツールの横展開を容易にする適用範囲 作成
Databricks、サーバレスPostgresを提供する「Neon」の買収を発表
データ分析プラットフォームを提供するDatabricksは、サーバレスのPostgresを提供することで知られるスタートアップ「Neon」の買収を発表しました。 Databricks + Neon 開発者ファーストのサーバーレスPostgres企業『Neon』がDatabricksに参画します！@neondatabase Neonは革新的なデータベースで開発者、そしてAIエージェントにも最適な基盤です。開発者とAIのためのオープンでサーバーレスな基盤をともに目指しますhttps://t.co/hxK3oolUiZ — Databricks Japan | DATA + AI Company (@DatabricksJP) May 14, 2025 DatabricksはApache Sparkの生みの親であり米カリフォルニア大学バークレー校准教授でもあるMatei Zaharia（マテイ・
マルチテナントなWebサービスでデータベースをBigQueryからPostgreSQLに移行してRow Level Securityを導入した - エムスリーテックブログ
こんにちは。AI・機械学習チームの高田です。 マルチテナント構成のWebサービスでは、データの分離とセキュリティを確保することが非常に重要です。マルチテナント構成とは、1つのシステムやアプリケーションを複数の顧客（テナント）で共有する設計アプローチを指します。 今回は、当社のあるプロダクトで行った2つの改善施策について紹介します。 BigQueryからPostgreSQLへの移行: より効率的なデータアクセスとコスト削減 Row Level Security（RLS）の導入: データベースレベルでのセキュリティ強化 これらの施策により、セキュリティ向上とコスト削減の両方を実現できた事例を解説していきます。 なぜ移行したのか テナントID分離型を採用 移行前のアーキテクチャ 移行後のアーキテクチャ PostgreSQLテーブル構築のためのバッチ処理の実装 PostgreSQLクエリの最適化
PostgreSQL 9.4 GINインデックスの評価、JSONBデータ型の使い方
PostgreSQL 9.4 GINインデックスの評価、JSONBデータ型の使い方：PostgreSQLガイダンス（1）（1/2 ページ） PostgreSQL 9.4は実務ニーズに即した機能追加が豊富 PostgreSQLは、その名の通りSQL言語で問い合わせをするリレーショナルデータベースマネジメントシステム（RDBMS）です。近年、NoSQLと総称されるスケールアウト拡張の容易さに強みのあるキーバリューストア型のデータベースが注目されていますが、汎用性、データ整合性、データ保全性、蓄積されたデータ設計技法との親和性、などの強みから、システム中核要素としてのリレーショナルデータベースの地位は揺らぎそうにありません。 PostgreSQLは長い歴史を持つオープンソースソフトウェアです。組織立ったコミュニティによって開発とメンテナンスが活発に継続されており、年に数度のバグ修正リリースの他、
Aurora PostgreSQLのロケールをデフォルトから変更してみた | DevelopersIO
Aurora PostgreSQLのパラメータグループからはlc_collate、lc_ctypeの設定はできません。CREATE DATABASEコマンドを使い、変更する必要があることに注意しましょう。 こんにちは！AWS事業本部のおつまみです。 みなさん、Aurora PostgreSQLのロケールをデフォルトから変更思ったことはありますか？私はあります。 PostgreSQLからAurora PostgreSQLへの移行に伴い、ロケールをデフォルトから変更する必要がありました。 変更際に留意するポイントがあったため、方法を共有したいと思います！ いきなり結論 Aurora PostgreSQLのパラメータグループでは全てのロケール設定を変更することができない。 パラメータグループでは、lc_messages,lc_monetary,lc_numeric,lc_timeのみ変更できる。
PostgreSQLのRow Level Securityが有効でポリシーが付いているのかを調べるリンター postgrls を作った - 風に吹かれても
3行まとめ PostgreSQLのRLSはテーブル定義と共にポリシー定義をする必要があるが、別に定義する必要があるので忘れがち 人間が気をつけるのは不可能なので仕組みで解決するべくリンターを作った Cline + Claude 3.7 sonnetですぐ作れたけど楽しくなかった GitHub - Azuki-bar/postgrls: PostgreSQL RLS linter 背景 PostgreSQLのRow Level Security(以下RLS)を使ったことがありますか。 PostgreSQLではテーブル定義と共にAlter TableをしてRLSを有効にする必要があります。しかもこれだけではまだ不十分でそこからポリシーを有効にする必要があります。 -- https://www.postgresql.jp/document/16/html/ddl-rowsecurity.html
PostgreSQLにあるSQLインジェクションの脆弱性が9年以上発見されずアメリカ財務省への侵入に使用されてしまう
2024年12月30日、「中国政府が支援する高度で持続的な脅威攻撃者」がアメリカ財務省の機密データを管理するシステムを侵害しました。この侵入にはPostgreSQLに9年以上存在していたのに誰も気付いていなかったSQLインジェクションの脆弱(ぜいじゃく)性が使用されたことが判明しており、ソフトウェアエンジニアのニック・アグリアーノ氏が記事にまとめています。 Hidden Messages in Emojis and Hacking the US Treasury https://slamdunksoftware.substack.com/p/hidden-messages-in-emojis-and-hacking SQLインジェクションは多くのセキュリティの教科書の冒頭に載っているような非常に有名な攻撃手法で、SQLインジェクションを通して攻撃者はSQL文を書き換えられるためシステムに重
bmf-tech.com - PostgreSQLのCOLLATEとglibcのバージョン差によるソート順の違い
PostgreSQLのCOLLATEとglibcのバージョン差によるソート順の違い データベース 2025年3月5日 作成2025年3月5日 更新 PostgreSQLのCOLLATEとglibcのバージョン差によるソート順の違い 同じCOLLATE設定を指定しているにもかかわらず、環境によってソート順が異なる問題に遭遇したので、その時の調査記録をメモしておく。 事象 Cloud SQLとローカル環境のPostgreSQLコンテナでCOLLATEが同じでもソート結果が違う Cloud SQL for PostgreSQL 17上でテーブルの文字列カラムをORDER BY カラム名 COLLATE "en_US.utf8"でソートしたところ、ローカルで動かしているPostgreSQLコンテナの結果と並びが異なる問題に遭遇した。 同じバージョンのPostgreSQL・同じCOLLATE設定（デ
PostgreSQL Contributorになった - そーだいなるらくがき帳
表題のとおり、PostgreSQL Contributorになりました。 グローバルでの貢献が認められたということで、素直に嬉しいです。 コントリビュータに名前が載ることになりました！ https://t.co/vzqCPmRQV0— そーだい@初代ALF (@soudai1025) 2025年1月28日 PostgreSQL: Contributor Profiles 認められた貢献 PostgreSQLのコミュニティでは、今までコードやドキュメントに対する直接的な貢献が評価されていました。 しかし今回はPostgreSQLのコミュニティに対する貢献が評価された結果となっています。 私は、コードやドキュメントに対する貢献はほとんどしていませんが、PostgreSQLのコミュニティに対しては以下のような行動をしてきました。 PostgreSQLユーザ会の運営*1 PostgreSQLの勉強
マルチテナントSaaSのテナント分離をRow-Level Securityに移行した - Sansan Tech Blog
こんにちは、クラウド請求書受領サービス「Bill One」の開発に携わっているソフトウェアエンジニアの加藤です。Bill OneはB2BのマルチテナントSaaSであり、データベースとして Cloud SQL 上のPostgreSQLを利用しています。従来はマルチテナントのデータを分離するために、テナントごとにPostgreSQLのスキーマを分けていましたが、2020年12月にRow-Level Securty（行レベルセキュリティ。以降RLSと表記）による分離に移行しました。 本稿では、移行の背景とRLS組み込みにあたって考慮したポイントをご紹介します。 マルチテナントSaaSのテナント分離 マルチテナントSaaSにおけるテナント分離方法はいくつか知られており、大きく次の3つに分けられます。 アプリケーションの実行環境ごと完全に分離する データベースのみをインスタンスやスキーマで分離する
Re: 履歴テーブルから最新の1件を取ってくる方法
そーだいさんが執筆された記事で、履歴テーブルから最新の1件を取ってくる方法について解説している。PostgreSQLの例だと以下のようなユーザーの履歴データに対し: CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First entry of user1', '2024-01-01 10:00:00'), (1, 'Second entry of user1', '2024-01-02 09:30:00'), (2, 'First entr
PostgreSQLで時間枠を適切に扱う設計 - そーだいなるらくがき帳
はじめに Googleカレンダーのような時間枠を扱うシステムを設計する際、開始・終了時刻を管理するロジックは容易ではない。 しかし、PostgreSQLには 範囲型 があり、この機能を活用することで、開始時刻（begin_at）と終了時刻（end_at）を1つのカラムで扱えるようになる。 そこで本稿では、範囲型を用いた設計と、その利点を紹介する。 時間枠を扱う難しさ まず前提として時間枠の扱いがなぜ難しいかを紹介する。 ソフトウェアデザインでやっている連載、実戦データベースリファクタリングの 【12】厄介な時間枠に向き合う でも紹介したが、時間の範囲を比較するときが難しい。 範囲の重なりには以下の種類がある。 包含：範囲Aが範囲Bを完全に含む 重複：範囲Aと範囲Bに共通点がある 隣接：範囲Aと範囲Bが隣り合う 時間枠の扱いはSQLに限らず、プログラミングの題材として難易度が高い。 特に重複
履歴テーブルから最新の1件を取ってくる方法 - そーだいなるらくがき帳
例えば次のようなテーブルがあったとする。 -- PostgreSQL CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); -- MySQL CREATE TABLE history ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, data TEXT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First
目的別データベースの実践: PostgreSQL 行レベルセキュリティと DynamoDB Outboxパターン - KAKEHASHI Tech Blog
カケハシのプラットフォームチームのテックリードとして組織管理サービスと認証基盤を開発している kosui (id:kosui_me) です。今回は、目的別データベースをプラットフォームチームではどのように実践しているかご紹介します。 この記事は秋の技術特集 2024の 13 記事目です。 背景 目的 事例1: PostgreSQL の行レベルセキュリティを活用する組織管理サービス 組織管理サービスとは PostgreSQL の行レベルセキュリティ 行レベルセキュリティを用いたトランザクションマネージャー 行レベルセキュリティの運用上の注意点 事例2: DynamoDB を活用する認証基盤と Outbox パターンの活用 カケハシの認証基盤刷新 DynamoDB で実現する高稼働率の認証基盤 DynamoDB の特性を考慮する CDC と Outbox パターン まとめ 背景 医療の分野で様
Amazon Aurora PostgreSQLを16.1へアップグレードしたらANALYZEを忘れてCPUが高騰しました - Oisix ra daichi Creator's Blog（オイシックス・ラ・大地クリエイターズブログ）
SREの林 aka もりはやです。 タイトルの通りですし、PostgreSQL界隈の皆さんには当たり前のことですが”失敗事例の共有はいくらあってもいいはず”の気持ちで本記事を書いています。*1 TL;DR 詳細 最新バージョンでアプリを移行した矢先にAurora PostgreSQLのv16.1対応が発表 これを受けて、意気揚々とAurora PostgreSQLのバージョンアップを実施 またしてもCPU高騰、そして504多発 調査開始 ZabbixにはSlow queryを出力する機能がデフォルトである クエリチューニングするならEXPLAINを使う ANALYZEを実行することで解決 仕上げのDB全体へのANALYZE まとめ TL;DR 何よりもまず、アップグレードガイドを読みましょう！！！！！！ AWS公式ドキュメント _ Amazon Aurora PostgreSQL DB ク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[Package Request] - PostgreSQL 16 · Issue #516 · amazonlinux/amazon-linux-2023