PostgreSQLには、用途や環境に応じて様々な構成を組み、最適なパフォーマンスで動作させられるよう、設定ファイルpostgresql.confに多くのパラメーターが存在します。そのパラメーターを正しく設定し調整を行うためには、PostgreSQLのアーキテクチャーを理解する必要があります。ここでは、押さえておきたい、PostgreSQLの基本的なアーキテクチャーについて説明します。なお、この記事で対象にしているPostgreSQLのバージョンは9.5以降です。 1. PostgreSQLの基本構成 PostgreSQLの基本的な構成について説明します。はじめに、主なプロセス、メモリー、および、ファイルについての構成図を示します。 図1 PostgreSQLの基本構成 PostgreSQLを構成する主なプロセス、メモリー、ファイルについて、その用語と概要を説明します。 リスナープロセス
PostgreSQLではデータベースを作成すると、デフォルトで public スキーマが作成され、任意のユーザーがこのスキーマにオブジェクトを作成できました。 CVE-2018-1058 でpublicスキーマのこの仕様とsearch_pathを使ったトロイの木馬攻撃の脆弱性(仕様の潜在リスク)が報告されました。 この攻撃から守るために、以下のような方法が推奨されています。 public スキーマの CREATE 権限を REVOKE ユーザーごとにスキーマを割り振る search_path に public スキーマが含まれないように調整 PostgreSQL 15からは、1つ目の回避策がデフォルトで有効になり、データベースのオーナーだけがpublicスキーマにオブジェクトを作成できるようになります。 Remove PUBLIC creation permission on the pu
This article was written in collaboration with Bohan Zhang and originally appeared on the OtterTune website. There are a lot of choices in databases (897 as of April 2023). With so many systems, it’s hard to know what to pick! But there is an interesting phenomenon where the Internet collectively decides on the default choice for new applications. In the 2000s, the conventional wisdom selected MyS
そーだいなる DBRE Nightでの登壇資料です https://connpass.com/event/138437/ # 紹介資料 - https://speakerdeck.com/soudai/shi-xing-ji-hua-falsehua - https://www.yout…
Amazon Web Services ブログ Oracle から PostgreSQL へ移行する際に、よく直面する課題を解決する方法 企業は年々データが急激に増加するのを目の当たりにしています。データベースとハードウェアインフラストラクチャをスケーリングし続けることは、ますます困難になっています。ワークロードが非リレーショナルデータストアに適していない場合に、基盤となるインフラストラクチャの管理に膨大な費用を費やすことなく、スケーリングの課題をどのように克服したらいいでしょうか? Amazon RDS for PostgreSQL と Amazon Aurora with PostgreSQL により、コスト効率の高い方法で PostgreSQL クラウドのデプロイを簡単にセットアップ、運用、拡張することができます。昨年、私たちは (数百 GB から数 TB に及ぶ) 100 を超える
関連リンク： スライド（Rabbit Slide Show） スライド（SlideShare） リポジトリー 内容 去年は「MySQL・PostgreSQLだけで作る高速でリッチな全文検索システム」というタイトルで話しました。去年はMySQL（Mroonga）・PostgreSQL（PGroonga）で次のことを実現するための具体的なSQLを紹介しました。 全文検索 キーワードハイライト 周辺テキスト表示 入力補完 同義語展開 関連文書の表示 構造化データ（オフィス文書・HTML・PDFなど）対応 今年は「MySQL・PostgreSQLだけで作る高速あいまい全文検索システム」というタイトルで話しました。今年も話の流れは同じにしました。あることを実現する具体的なSQLを紹介するというスタイルです。今年はMySQL（Mroonga）・PostgreSQL（PGroonga）で次のことを実現す
O/Rマッパーなどによってデータベースを意識せずに開発できるようになっています。しかしデータベースは設計次第でシステムのボトルネックになることも多く、やはり適切な設計能力は重要です。 今回紹介するpgModelerはPostgreSQLに特化したデータベースモデリングソフトウェアになります。 pgModelerの使い方 起動しました。 デザイン画面です。 サンプルを開いたところです。グループ化やコメントも付けられるのでビジュアル的にも分かりやすいです。 テーブルの設計画面です。 アウトプットはSQLや画像、さらに直接データベースへの実行もできます。 pgModelerはデータベースを設計するだけでなく、ビジュアルにも気が配られています。これならば仕様書として使うこともできるでしょう。ここまでのビジュアル化はデータベースからインポートするタイプのソフトウェアでは難しいでしょう。なお、pgMo
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: How to scale PostgreSQL 10 using table inheritance and declarative partitioning 原文公開日: 2017/11/09 著者: Matvey Arye サイト: http://www.timescale.com/ -- オープンソースの大規模時系列データベース「timescaledb」を開発する企業です。 timescale.comより PostgreSQL 10がついにお披露目されました（原注: 本記事執筆後間もなく10.1がリリースされました）。PostgreSQL 10のリリースは、論理レプリケーション、JSONやJSONBでの全文検索サポート、クロスカラム統計、並列クエリのサポート強化といった根本的な新機能を含んでおり、いろいろな意味でエキサイティ
最近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
ある機能が重いなどといった理由で、DBのどのクエリが遅いか把握したいことはよくあります。そんな時、PostgreSQLのauto_explainが便利だったので紹介。 auto_explainを使うと、指定した実行時間以上を利用しているクエリに対して、自動で実行計画をログファイルに出力してくれるというもの。詳細はこちら。 https://www.postgresql.jp/document/9.6/html/auto-explain.html https://www.postgresql.jp/document/9.6/html/using-explain.html 最近便利に使えたのは以下の設定。 # 自動でEXPLAIN ANALYZEしてパフォーマンス解析したい時用 session_preload_libraries = 'auto_explain' auto_explain.log
1. メタコマンドとSQLを一緒に使う 実行例 2. SELECT結果の値だけを取得する 実行例 3. SQLでSQLを作り実行 (9.6~) 実行例 4. サーバに応じて実行するSQLを変える (10~) 実行例 5. 忘れたDDLのシンタックスを確認する 実行例 6. SQLファイルの内容を一行ずつ確認しながら実行する 実行例 7. 特定のコマンドを定期的に実行したい 実行例 8. psqlを起動した時に実行されるコマンドを設定する 実行例 9. .psqlrcを一時的に使わない 実行例 10. SELECTの結果をCSV形式で出力 実行例 普段よく使っているpsqlで便利だと思う使い方を10個紹介します。運用で使うシェルスクリプトとかでもpsqlは使う事があると思うので、psql派でない人にも多少は役に立つはず。 特に最近のバージョンで追加された機能は、利用できるバージョンを記載して
PostgreSQL 10のICUコレーションを使うと日本語を普通にソートでき、更に文字順序までカスタマイズできる (Last Updated On: )PostgreSQL 10からICU（International Components for Unicode）のロケール/コレーションがサポートされました。 これまでサポートされてきた、libcのja_JPロケールの貧弱な日本語ソート機能とは比べ物にならないくらい高機能な文字比較をサポートしています。日本語や他の言語での照合順序を柔軟に変更できます。 マトモな日本語ソート順でソートする（かなり重要） 数字を後にソートする 大文字を先にソートする 仮名を先にソートする 自然ソートする これらをまとめて特別なソート順にする といったことがPostgreSQL 10から行えます。 基本的な使い方 ja-x-icuはICUサポートが組み込まれて
先日、「How a single PostgreSQL config change improved slow query performance by 50x」というPostgreSQLのSSD環境でのチューニングの記事を見つけたのですが、これをTweetしたらRTやLikeを比較的たくさん頂きました。 How a single PostgreSQL config change improved slow query performance by 50x https://amplitude.engineering/how-a-single-postgresql-config-change-improved-slow-query-performance-by-50x-85593b8991b0 How a single PostgreSQL config change improved sl
PostgreSQL Conference Japan 2017の前にPGroonga 2のリリースアナウンスを出せた須藤です。間に合ってよかった。 PostgreSQL Conference Japan 2017でPGroonga 2を紹介しました。PGroongaを使ったことがない人向けの内容です。実際、聞いてくれた人たちはほとんど使ったことがない人ばかりでした。 関連リンク： スライド（Rabbit Slide Show） スライド（SlideShare） リポジトリー 内容 PostgreSQLをバックエンドに「今っぽい」全文検索システムを作るためのPGroongaの使い方を紹介するという内容になっています。具体的には次の機能を実現する方法を紹介しています。 高速全文検索 それっぽい順でのソート 検索結果表示画面で検索キーワードをハイライト 検索結果表示画面で検索キーワード周辺テキ
Geeks Who DrinkとPostgreSQL Conference Japan 2017での資料です。 nulab.connpass.com PostgreSQL Conference Japan 2017 (2017-11-03) | 日本PostgreSQLユーザ会 詳しく知りたい人は下記の本がおすすめです。 ただし注意点は9.3相当なのでプロセスの仕組みがちょっと違います。 待望の新刊出ました！10系ベースなのでぜひ読んでみてください。 ※2018/10/07 追記 読み応えのある内容になったかなと思います。レベル感で言えばOSS DB Goldの試験出る範囲です。特に内部構造は覚えて置いて損は無いでしょう。 speakerdeck.com 内部構造の中で取り扱っていないところにAUTOVACUUM、TOASTとレプリケーションがあります。AUTOVACUUMはPostgre
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く