はじめに Uberの初期のアーキテクチャは、Pythonで書かれたモノリシックなバックエンドアプリで構成されており、データの永続性のために Postgres を使っていました。当時から比べて今のUberのアーキテクチャはかなり変わっており、 マイクロサービス のモデルや新しいデータプラットフォームになりました。特に、以前Postgresを使っていたケースの多くで、今は Schemaless 、つまりMySQLの上で構築された新しいデータベースのシャーディングレイヤを使います。今回の投稿では、私たちが見つけたPostgresの欠点を探り、MySQLの上でSchemalessと他のバックエンドサービスを構築するに至った経緯について説明していきます。 Postgresのアーキテクチャ 私たちはPostgresで以下のような多くの制約に直面しました。 書き込みでの非能率的なアーキテクチャ 非能率的

こんにちは。Cacooチームのイニエスタこと、とおのぶです。CacooはデータベースのPostgreSQLのバージョンアップを実施しました。基本的には公式のpg_upgradeの手順に従っています。ここではドキュメントには記載の少ない具体的な作業内容の流れを紹介したいと思います。 理由 ユーザアンケートからみる Cacoo のコア・バリューで記されたとおり、全体的なパフォーマンスの向上については重要度の高い課題の一つです。PostgreSQL 9.5ではソート性能の大幅な改善が強化点の一つで、パフォーマンスの改善が見込まれます。またフェイルオーバ後、新しいマスターに追従するスタンバイとして、古いマスターサーバをオンラインに戻すことができるpg_rewindも、PostgreSQL 9.5の魅力の一つです。 バージョンアップ前の構成 構成は、マスタとスレーブのストリーミング・レプリケーション

以前投稿したbgwokerで超簡易クラスタ管理を進化させたpg_keeperについて投稿。 コンセプト このツールのコンセプトは「PostgreSQLの自動フェイルオーバーを簡単に設定する」です。 Pacemaker/corosyncやrepmgrを使えばより細かく、柔軟に設定することが出来ますが、その一方設定が面倒だったり、多くのケースではそこまで柔軟な設定は必要ないと思ったので、「マスタ、スレーブ2台構成でもっと簡単に可用性を向上させたい」と思い作りました。 監視プロセスはPostgreSQLのプロセスの一つとして動作するので、高機能なクラスタリングミドルウェアによくある監視プロセス自体の起動・停止・監視等の作業は発生しません。 ただし、pg_keeperが対応しているのはマスタ1台、スタンバイ1台で同期レプリケーションを使用した場合のみです。 スタンバイを2台以上使用するケースには対

先月、弊社にデータベース系の研究をしていた中国人留学生がインターンに来ており、その彼にお願いしてPostgreSQLのパラレルクエリのスケーラビリティの調査と、プロファイリング＋可視化のツールとしてFlameGraphを使ってもらいました。 大学のスケジュールの関係上、インターンの期間が急遽、3週間から2週間に短縮されてしまったため、結果をきちんとまとめたり追試をしたりといったところまでは到達できなかったのですが、個人的にもそれなりに面白いアウトプットになったと思いますので、簡単にご紹介したいと思います。 なお、細かい手順の詳細などは、インターンに参加していた学生さんのGithubにまとまっています。参考文献に載せておきますので、興味のある方はそちらも参照してください。（本テストと直接関係のない内容も含まれています） ■テストの背景 PostgreSQLの9.6develにパラレルシーケン

今年もこの季節になりました。PostgreSQL Advent Calendar 2015のDay1の記事です。 今回は、現在開発中のPostgreSQL 9.6に実装されたパラレルシーケンシャルスキャンについて、動作確認とフラッシュストレージでの簡単な性能検証をしてみようと思います。 なお、現在開発中の機能ですので、正式リリースされる時には仕様や動作などが変わっている可能性があることをご了承ください。 ■「パラレルシーケンシャルスキャン」とは 「パラレルシーケンシャルスキャン」は、その名の通り、シーケンシャルスキャンを並列処理する機能です。 今まで、PostgreSQLでは1つのCPUを使ってシングルスレッド（というかプロセス）でしか処理をすることができませんでした。 しかし、直近のPostgreSQLのメジャーバージョンの拡張を見ていた方はご存じの通り、PostgreSQLではパラレル

弊社では、RDBMSにPostgreSQLを利用して数年間サービスを運営しています。 PostgreSQLはMySQLと違って、Webサービスでの運用事例をあまり見かけないので、今回は弊社サービスの「夜行バス比較なび 」でどのように運用しているかを紹介いたします。 システムの特徴 ユーザからのアクセスは、9割が参照処理。 データはバッチ処理で、随時 ( 毎分 ) 更新されている。 参照SQLの結果はmemcachedを利用してキャッシュをしているが、データの更新頻度が高いため長時間のキャッシュはしていない。 参照SQLは、集計処理が多いため比較的重いSQL。 参照対象となるテーブルのデータ量は、最大で数100万レコードと比較的少ない。 24/7で稼働。 構成 AWSのEC2上に、PostgreSQL 9.3を導入しています。c4系のインスタンスを使いたいので、RDSは使っていません。インス

さて、前回の続きです。 前回はPostgreSQLのバックアップ手法を紹介・比較しました。 前回述べなかったのですが、物理バックアップには大きな利点があります。それは、データベースのバックアップとWALファイルのバックアップを組み合わせることで、リカバリする時点を自由にコントロールできるという点です。 リカバリの違い 論理バックアップは特定の時点のデータをSQLの形で抜き出してくる方法でした。そのため、論理バックアップからデータを復旧した場合、バックアップを取得した時点のデータの状態に戻ります。当たり前ですね。 一方、物理バックアップはデータベースの実体のファイル自体をバックアップするものでした。オンライン・バックアップを行った場合は、これだけだとバックアップ中の変更が把握できないので、バックアップ中に発生したWALファイルから変更情報を読みだして反映することで、バックアップが完了した時点

サーバー側でクエリの実行を中断するには SIGINT を当該プロセス（ ps や pg_stat_activity から探す）に送ります（kill -INT PID）が、これではセッションは切断されません。メンテナンスなどで切断して欲しい場合には pg_terminate_backend(procpid) を使います。 当該の PID がわかっている場合には

This document summarizes an organization's journey to creating a highly available PostgreSQL cluster using etcd for consensus and automation. They initially used MongoDB but required more data exploration capabilities. They investigated tools like repmgr with pgpool II and PostgreSQL streaming replication but these did not meet their requirements for automated failover without human interaction. T

このブログに限り完全に著作権を放棄します(あくまでこのブログだけ。他のブログ、および下の英語文書は範囲外)。勝手に使ってよし。2016.12.20 公開した文書のごく一部を、翻訳して公開。(BLOGにするにあたり、構成は変えた。) http://www.interdb.jp/pg 概要 checkpoint_segmentsが廃止され、WALファイル数の上限下限をmax_wal_sizeとmin_wal_sizeで指定できるようになった。 WALファイル数は(これらの制限内で)サーバの活動状況=WALファイルの消費量に合わせて変化する。あまり書き込みがなければWAL数は減少し、活発になればWAL数が増える。 保存するWAL数は基本的にリカバリに必要不可欠なものに限られ、無駄なWALファイルを溜め込む事は無くなった。 理解のための前提条件 CHECKPOINTの起動タイミング CHECKPO

フックを使ったPostgreSQLの拡張機能を作ってみよう！（第33回PostgreSQLアンカンファレンス@オンライン 発表資料）

— そーだい＠初代ALF (@soudai1025) 2015, 8月 24 とブーメラン投げて見事に刺さってるので今から記事書く。 両サイドにはかなり厳しい話もするが俺の本音を聴いておけ（関白宣言） まぁ歴史の長いRDBなのでお互いの比較記事は沢山ある。 なのでマルチスレッド(MySQL)とマルチプロセス(PostgreSQL)だとかVACUUMだって話はしない。 むしろ実際に使ってみた際の違いをにフォーカスする。 1. SQLの違い 基本的にMySQLでやっていたことはPostgreSQL出来る。 しかし関数の挙動の違いは幾つかある。 例えば時間から曜日に該当する数字に変換した場合に MySQL　→　date_format(time,"%w")　0から始まり、日曜日に該当する PostgreSQL　→　to_char(time,'D')　1から始まり、日曜日に該当する など挙動に互換性

PostgreSQL 9.2より追加されたJSON型だが、特徴を理解して適切に使わないと色々な副作用に悩まされることになる。その問題点を挙げると共に、どのような場合に使うべきかの指針を示す。 PostgreSQLは、データ型としてjsonをサポートしています。しかし、やりたいことがある時に何でもかんでもjson型を使ってしまうというのはやめるべきです。これは、hstoreや新しく登場したjsonb型にも同じことが言えます。これらの型は必要な時には便利なツールになりますが、PostgreSQLでデータのモデリングを行う際に最初に検討すべきものではありません。 なぜなら、データを呼び出したり操作したりするのが難しくなってしまうためです。 何もかも同じところに入れてしまおうとすることによるアンチパターンをご存知の読者もいるでしょう。EAVアンチパターンは、長らくデータベーススキーマにおける必要悪

本日、Postgres ToolkitというPostgreSQLのDBA向けツールキットをリリースしました。 http://www.github.com/uptimejp/postgres-toolkit/ https://postgres-toolkit-ja.readthedocs.org/ ■「Postgres Toolkit」とは何か Postgres Toolkitは、PostgreSQLの運用管理を楽にするためのスクリプトやツールのコレクションで、DBA業務の品質や生産性を高めることを目的としたツールキットです。 Postgres Toolkitを使うことで、複雑なSQLを実行したり、自前のスクリプトをメンテする必要性が減少します。コンセプトとしては、「PostgreSQL DBA向けのVictorinox（スイスアーミーナイフ）」のようなイメージです。 もともとは、私がトラブ

PostgreSQLのインデックスがメモリに納まらない場合の挙動について PostgreSQL9.2を使用しています。 先日、インデックスがメモリに乗らないほど巨大な場合にはインデックスは使われないとの情報を頂いたのですが、 それを検証しようとshared_buffersを最小の値(128kb)にし、textカラムにインデックスを貼ったテーブル(レコード数1000万以上)で次のクエリを実行したところ、実行計画はIndex Only Scanとなり結果は一瞬で返りました。 explain analyze select count(*) from table1 where text like 'a%'; このときPostgreSQLプロセスの使用メモリは3MB程で、とてもインデックスが乗るサイズではないのですが、なぜIndex Only Scanになるのでしょうか。 ちなみにそのテーブルのイン

PostgreSQL Advent Calendar 2014 の 13日目です。 Advent Calendar を今年もやってみたいと思って、枠が空いていたので飛び込んでみました。 昨日は osapon さんの libpqxx を使ってみたでした。 概要 PostgreSQL のパフォーマンスチューニングは大きく下記に分かれます。 システムチューニング SQL チューニング ここでは Linux 上で動かしていることを前提に、それぞれ説明します。 システムチューニング システムチューニングの概要 システムチューニングとは、OS または PostgreSQL の設定を変更することです。 それぞれ順に説明します。 OS チューニング PostgreSQL では特にメモリ関連でOSパラメータを設定変更すると、高速化効果が得られます。 特に下記のカーネルパラメータに注意します。 vm.dirt

4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にした本で、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、本当は実行計画などという手続レベルの世界をユーザが覗き見るのは、本末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体本当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。

29回勉強会資料「PostgreSQLのリカバリ超入門」 See also http://www.interdb.jp/pgsql (Coming soon!) 初心者向け。PostgreSQLのWAL、CHECKPOINT、 オンラインバックアップの仕組み解説。 これを見たら、次は→　 http://www.slideshare.net/satock/29shikumi-backup Read less

NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは？（前編） NTTデータオープンソースDAY2015 現在のシステム構築では、オープンソースのソフトウェアを使うことは当たり前になってきています。PostgreSQLはそうした中で主にエンタープライズ向けのデータベースとして着実に事例を増やしてきています。 その中で、PostgreSQLを大規模なミッションクリティカルなシステムの中で使うには、どのようなノウハウが求められるのか。オープンソースの利用に積極的なNTTデータがその事例を、1月26日に開催されたイベント「NTTデータオープンソースDAY 2015」のセッション「NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは？」で紹介しています。講演内容をダイジェストにしまし