次期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処理が完了
PostgreSQLで時間枠を適切に扱う設計 - そーだいなるらくがき帳
はじめに Googleカレンダーのような時間枠を扱うシステムを設計する際、開始・終了時刻を管理するロジックは容易ではない。 しかし、PostgreSQLには 範囲型 があり、この機能を活用することで、開始時刻（begin_at）と終了時刻（end_at）を1つのカラムで扱えるようになる。 そこで本稿では、範囲型を用いた設計と、その利点を紹介する。 時間枠を扱う難しさ まず前提として時間枠の扱いがなぜ難しいかを紹介する。 ソフトウェアデザインでやっている連載、実戦データベースリファクタリングの 【12】厄介な時間枠に向き合う でも紹介したが、時間の範囲を比較するときが難しい。 範囲の重なりには以下の種類がある。 包含：範囲Aが範囲Bを完全に含む 重複：範囲Aと範囲Bに共通点がある 隣接：範囲Aと範囲Bが隣り合う 時間枠の扱いはSQLに限らず、プログラミングの題材として難易度が高い。 特に重複
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
PostgreSQLは20年間どのようにfsyncを間違って使っていたか - 聴講メモ -
TL;DR 聴講メモ Intro into durability PostgreSQLのCHECKPIONT CHECKPOINT中にエラーが発生したら？ fsyncへの2つの間違った期待 なぜ今になって問題が明らかになってきた？ そもそもなぜBufferd I/Oなのか？ どうやって直すかか 参考リンク 質疑 最後に 先日PostgreSQLの新しいマイナーバージョンがリリースされました。このマイナーリリースでメインとなる修正は「fsync周りのバグ修正」で、このバグは間違ったfsyncに対する間違った認識から約20年間存在してたバグということで注目されていました。 このバグについてPostgreSQLのコミッタ(Tomas Vondra氏)が解説しているセッションが、先々週開催されたFOSDEM 2019でありました。私もFOSDEM 2019に参加していたのですがその際は裏セッション
DBリファクタリングをやっているって話 - そーだいなるらくがき帳
言語の勉強会でその言語の話をしない人ランキング堂々の第一位、そーだいです（当社比 控えめに言っても最高な毎度おなじみ #kichijojipm で今日LTする話の補足です。 kichijojipm.connpass.com speakerdeck.com タイトルは出落ちです。 全然最強じゃなくて頑張ってやってるよって話です。 資料がかなり薄いので補足します。 DBリファクタリングについて 26Pは現状です。 MySQLって書いてますが本番はAurora1を使っています。 以降、このDBを 現行DB と呼びます。 ここではオミカレとみんなの婚活はWebサービス名です。 つまり2つのサービスから現行DBを見ていますし、機能によっては現行DBの同じテーブルを参照・更新・削除などを行います。 この2つ以外にも社内システムなどでこの現行DBは利用されており、メインのテーブルを変更すると影響範囲が広
Postgres 10の開発者向け機能
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！｜ハイクラス転職・求人情報サイト AMBI（アンビ）
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey
果たしてGitLab.comで何が起きたのでしょうか？ これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時（世界協定時。日本時間2月1日午前8時）、YP氏（Yorick Peterse氏と思われる）はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時
第7回 UberエンジニアがブログでPostgreSQLにダメ出し、PostgreSQLコミッター石井達夫氏に反論を聞く | gihyo.jp
IT Cutting Edge ─世界を変えるテクノロジの最前線 第7回UberエンジニアがブログでPostgreSQLにダメ出し、PostgreSQLコミッター石井達夫氏に反論を聞く デジタルディスラプションを象徴する企業として、いまこの瞬間も破竹の勢いで成長を続け、交通サービスの世界を大胆に塗り替えているUber。未上場ながらすでに企業価値は6兆円を超えているとも言われており、世界最大のユニコーン企業として、その動向はつねに注目されつづけています。 クラウドやビッグデータ分析、オープンソースなど、最先端のITをフル活用し、ごく短期間で劇的にビジネスを拡大させたUberに対しては、やはり技術者からの強い関心があつまります。現在、1200名を超えると言われるUberのエンジニアたちは何をどんな環境で使い、どう動かしているのか ―Uberのエンジニアリングチームが公開している技術ブログ「Ub
そーだいなるらくがき帳: 2大OSSデータベースのMySQLとPostgreSQLの違いについて話してきた
第32回 PostgreSQL 勉強会(2015年10月10日)で登壇してきました。 内容は前に書いたエントリーの MySQL使いが知るべきPostgreSQLとの違いと変わらない一つのこと MySQL使いの人がPostgreSQLを始めるときの罠をまとめてみた を元に発表してきました。 と言っても今回は参加者がPostgresSQLに詳しい前提だったのでMySQLを中心に話をしました。 実際の資料は下記のとおりです。 当日はビデオ撮影があったのでそのうち動画が上がると思います。 第32回 PostgreSQL 勉強会まとめ ~ togetter ~ 流石に２時間は疲れました。 内容としては眠くならないように面白おかしく伝えようと思ったのですがなかなか難しかったです。 前半はMySQLとPostgreSQLの方向性の違いをメインにしました。 後半はMySQLは僕が実際にハマった事などをメイ
PipelineDBをProductionに導入してみました。 How SmartNews Utilizes PipelineDB - SmartNews Engineering Blog
ENGLISH FOLLOWS BELOW こんにちは、たむたむ(@tamtam180)です。 SmartNewsでは主に広告の配信サーバを書いています。 最近、PipelineDBというContinuous Queryをサポートする製品を導入したのでそのレポートを書きます。 なお、セットアップ方法は本家のサイトを見れば誰でも出来るので、そのあたりは割愛します。 競合にあたる製品としては、NorikraやAzureのStream Analyticsがあり、日本のエンジニア界隈ではNorikraを好んで使用していると思います。 私がPipelineDBを導入した理由は、PipelineDBがPostgreSQL(9.4)をベースにしているため、弊社が導入しているダッシュボードツール、Chartioとの相性が良かったからです。 PipelineDBとは PipelineDBは、PostgreS
Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLとMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ
PostgreSQLのアンチパターン : 何でもかんでもjsonに入れる | Yakst
PostgreSQL 9.2より追加されたJSON型だが、特徴を理解して適切に使わないと色々な副作用に悩まされることになる。その問題点を挙げると共に、どのような場合に使うべきかの指針を示す。 PostgreSQLは、データ型としてjsonをサポートしています。しかし、やりたいことがある時に何でもかんでもjson型を使ってしまうというのはやめるべきです。これは、hstoreや新しく登場したjsonb型にも同じことが言えます。これらの型は必要な時には便利なツールになりますが、PostgreSQLでデータのモデリングを行う際に最初に検討すべきものではありません。 なぜなら、データを呼び出したり操作したりするのが難しくなってしまうためです。 何もかも同じところに入れてしまおうとすることによるアンチパターンをご存知の読者もいるでしょう。EAVアンチパターンは、長らくデータベーススキーマにおける必要悪
我々(主語が大きい)は何故MySQLで外部キーを使わないのか
外部キー便利!!! MackerelではPostgreSQLで外部キーあり そのレコードがあることが保証される 各テーブルのidにアプリケーションレベル(Mackerelの場合Scala)で型付けをするとなお便利 MemberID型、MonitorID型 → idで誤ったテーブルを引くとかがない 本日のスキーマ CREATE TABLE `member` ( `id` INTEGER unsigned NOT NULL auto_increment, `earned_item_count` INTEGER unsigned NOT NULL DEFAULT 0, `name` VARCHAR(191) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARACTER SET utf8mb4; CREATE TABLE `item`
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
いまふたたびのJDBC - Qiita
つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側 / builderscon 2018
GitHub - MasahikoSawada/pg_simula: A database system failure simulation tool for PostgreSQL
RDBアンチパターン // Speaker Deck
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い
PostgreSQL 9.5 新機能紹介
