PostgreSQLの実行計画の推定行数と実行数の乖離改善の考え方
はじめに 以前こんなツイートをしました。 すると、リプライで色々とコメントを頂きました。（疑問を投げかけたら答えてくれる方々、本当にいつもありがたいです🙇♂️） ということで、本記事では推定行数と実際の行数の乖離を減らすために何をやったのかを備忘として書きます。 ただ、実際のSQLや実行計画を書くことはできないので、あくまでどんな考え方をしたのか、ということを書きます。 対処法①（対象のテーブルのautovacuum頻度を変更） 対象のテーブルはかなり更新の激しいテーブルだと聞いていたので、まずは統計情報が最新化されているかを考えました。 更新が激しくてautovacuum時の自動ANALYZEが追い付いていないんじゃないかと考え、対象のテーブルだけ自動ANALYZEの頻度が上がるように設定を変更しました。 PostgreSQLの設定パラメータは基本的にはpostgresql.conf
PostgreSQL チューニングよもやま話 - エムスリーテックブログ
【Unit4 ブログリレー3日目】 こんにちは，エムスリーエンジニアリンググループの榎田です．数学とテレビゲームが好きです． 今回は，Unit4 で運用している "Docpedia" というサービスで実施した SQL チューニングの実例を2つご紹介します．普段の私が意識していなかった， RDBMS の内部機構に関する話が登場して面白かったので，今回の記事を書きました． なお，本稿で扱う議論はすべて PostgreSQL 11.x 以上を対象としており，特にその他の RDBMS で同様の動作をするかは確認していません．定性的な挙動に共通するものはあるかもしれませんが，ここで述べた話はそのままは通らないであろうことをお断りさせてください*1． プロダクトについて index なしで意外と耐えたが，耐えきれなかった話 実際の SQL とテーブル定義 原因の分析 対応策 SELECT DISTIN
TimescaleDB 雑感
TimescaleDB を自社サービスに採用して 1 年以上過ぎたので振り返ってみます。 前提 著者は SQL に関して TimescaleDB を採用を決めたタイミングから勉強した初心者です Managed Service for TimescaleDB を採用しています まとめ TimescaleDB の利用で不満は今のところない sqlc との組み合わせは最高 開発会社が提供するマネージドサービスは最高 なぜ TimescaleDB を採用したのか 統計情報のため込みと集計 自社製品であるミドルウェアパッケージソフトウェアのクラウド版を提供するにあたり、何よりも重視したのは統計情報の提供です。それもサーバーの統計情報ではなく接続単位での接続情報を顧客に提供することです。 自社製品はリアルタイムに音声や映像を配信する製品ということもあり、一定間隔での統計情報の収集が重要になります。ネッ
Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
PostgreSQLのMVCCとガベージコレクション（Vacuum）
同時実行制御とトランザクションID コミットログ スナップショット ガベージコレクション（VACUUM） ロングトランザクション”扱い”となるもの テーブルのVacuum インデックスのVacuum 最後に このエントリはPostgreSQL Advent Calender 2021の22日目の記事です。 shallow1729さんのMVCCとInnoDBでの実装についてという記事を読んで、これのPostgreSQL版を書きたいなと思い書いてみました。 同時実行制御とトランザクションID PostgreSQLは複数のクライアントがトランザクションを同時に実行することが可能で、各トランザクションは他のトランザクションの影響を受けずに処理します。これはトランザクションのACID特性の隔離性（Isolation）の特性です。 以下に簡単な例を挙げます。 -- トランザクションA 開始 BEGIN
Google、大規模分散DB「Spanner」にPostgreSQL互換インターフェイスを実装。強い一貫性で秒間10億以上のリクエストを処理可能。Google Cloud Next '21
GoogleはGoogle Cloudで提供している大規模分散データベース「Cloud Spanner」に、PostgreSQL互換のインターフェイスを実装したと発表しました。 At #GoogleCloudNext, we've announced the preview of Cloud Spanner’s PostgreSQL interface—combining the scalability & reliability of Spanner that enterprises trust with the familiarity & portability of PostgreSQL that dev teams . Take a deeper dive ↓ https://t.co/Y3xD1lDPLg — Google Cloud Tech (@GoogleCloudTech
PostgreSQLの行レベルセキュリティと SpringAOPでマルチテナントの ユーザー間情報漏洩を防止する (JJUG CCC 2021 Spring)
PostgreSQLの行レベルセキュリティと SpringAOPでマルチテナントの ユーザー間情報漏洩を防止する (JJUG CCC 2021 Spring) Webアプリケーションにおいて、マルチテナント型、つまり複数のユーザー組織がアプリケーションとデータベースを共有する構成にすることがあります。この構成の持つリスクとして、万が一バグにより他テナントの情報が見えてしまうとそれは情報漏洩となり、重大なインシデントとなってしまうことがあります。この重要性を考えると、「気を付けて実装する」だけではなく、仕組みで漏洩を防ぐような対策には価値があります。 そこで、今回はPostgresSQLの行レベルセキュリティと、SpringAOPによる処理を組み合わせて、ログインしているテナントのデータにしかアクセスできなくする仕組みを実現しました。 導入にあたり考慮した複数の選択肢、乗り越えたいくつかの壁
スケールアウトするPostgreSQLを目指して！その第一歩！
スケールアウトするPostgreSQLを目指して！その第一歩！ ▼講演者 NTTデータ 技術開発本部 データベーステクニカルリード 藤井 雅雄 ▼講演概要 スケールアウトは、今、PostgreSQLで最もユーザが実現を期待している機能のひとつです。 NTTデータでは、スケールアウトするPostgreSQLを目指し、その第１弾として複数台のPostgreSQLをまたがる 分散トランザクション(グローバルトランザクション)機能の実現に取り組んでいます。 本セッションでは、PostgreSQLコミュニティで提案・議論されているスケールアウト機能を紹介するとともに、 NTTデータのスケールアウト実現に向けたビジョンについてPostgreSQLコミッタが語ります。 ▼イベントページ NTTデータ テクノロジーカンファレンス 2020 https://oss.nttdata.com/techco
JSONPathインジェクション
(Last Updated On: 2021年6月17日) JSONPathはCSSのセレクタやXPathのクエリのような形でJSON形式のデータを選択／クエリする仕様です。最近のRDBMSはJSONPathクエリをサポートしているので、SQLインジェクション対策の一種として必要となる場合もあります。 JSONPathの説明はしないので仕様などはオンラインの評価環境で確認してください。 https://jsonpath.com/ JSONPathクエリは上記のような”意味を持つ文字”を使ってクエリを実行します。インジェクション攻撃は一文字でも意味がある文字があると攻撃される、と思って構わないです。JSONPathクエリもインジェクション攻撃が可能です。 典型的なJSONPathインジェクション 典型的なJSONPathインジェクションはSQLインジェクションやXPathインジェクションと同
SQLからC言語を呼ぶ方法 ～MeCab編～ - astamuse Lab
前書き お久しぶりでございます。Scalaでバックエンドを開発しているaxtstar(@axtstart)です。 ずいぶん昔になりますが、OracleDBでアプリ開発をしていたころ、DBの中でデータが（なぜか）バイナリで格納されていて、そのビット演算を行いながら検索するみたいな案件をやったことがあります。はじめはアプリサイドからSQLで頑張って演算していたのですが、あまりにも遅くて、結局OCI(Oracle Call Interface)を利用して、C++でバイナリを扱うように書き換えたら激的に速度が改善したことがありました。 今回ふと思い立ち、Postgresqlってそういうことができるのかしら？と思い至り今回のブログ担当を利用して検証してみることにしました。 なので、（確実に）プロダクション環境で実施するのははばかられるような内容ですのでご注意下さい。 使用できる言語は... ちなみに
最強データベース（RDB）設計とは？アンチパターンの見極め方法も - FLEXY（フレキシー）
※2020年6月に公開された記事です。 日本PostgreSQLユーザ会の理事を務める合同会社Have Fun Techを起業した曽根壮大（@soudai1025）と申します。元株式会社オミカレ副社長兼CTOです。直近では、『失敗から学ぶ RDBの正しい歩き方』を執筆しました。 今回はデータベースをテーマとして、魅力やMySQLとPostgreSQLの違い、アンチパターンの見極めなどの基礎知識に加え、勉強法などもご紹介します。 RDB関連の求人検索はこちら データベースを学ぶ魅力をエンジニア目線で考察 1.知識の費用対効果が高い エンジニアがデータベースを学ぶ利点という観点から言うと、データベースの特徴は寿命が長いことと私は考えています。 Webアプリケーションの界隈では1年単位でバージョンアップしたり流行っている言語が変わってしまうことがザラにありますが、データベースは10年、20年とい
PostgreSQLのJSONのIndexの張り方 - Qiita
10秒弱で終わりました。早いですね。あ、cloud9上です。 さて検索してみます。jのvalが10のものを探してみましょう。 @>演算子でJSONにそれを含むものを検索できます。今回は'{ "j": { "val": 10 }}'::jsonbを含むレコードを検索しています。 test=# select * from test where val @> '{ "j": { "val": 10 }}'::jsonb; id | val --------+------------------------------------------------- 1001 | {"j": {"k": {"val": 0}, "val": 10}, "val": 0} 1002 | {"j": {"k": {"val": 1}, "val": 10}, "val": 0} 1003 | {"j": {"k
PostgreSQL configureオプション(8.3～12) - Qiita
はじめに なんとなくPostgreSQLのconfigureオプションの変遷について調べてみた。 PostgreSQL 12情報も追加した(2019-12-29) 調査のきっかけ 先日、とある案件でPostgreSQL 8.3からAurora PostgreSQL 10への移行したい、みたいな話を聞いて、互換性に関する下調べをしてた。 で、リリースノートを見ると、configureオプションの変更についても記載されているバージョンがあったので、この際、configureのオプションの歴史を調べてみようかなと。 （configureを使ってソースビルドからインストールするユーザはそんなにいないような気もするけど） だいたい、普段もprefixとか、beta版フェーズで--enable-debugを使うくらいだしなあ。 バージョン毎の変更点 configureオプションの変更なんて、そんなにな
SELECT文で本番環境を落としたお話 - Qiita
（この記事は 地平線に行く とのマルチポストです） 本番環境でやらかしちゃった人 Advent Calendarで、このパターンのやらかしはなかったのでキーボードを叩くことにしました。 番外編のつもりでお楽しみください。 この記事が、新たな障害発生を防ぐことにつながれば幸いです。 何をやったのか ある日、ちょっとした調査のために本番データベースのデータを確認することになりました。 （個人情報が格納されているようなシステムではなかったので、必要であれば本番データベースへのアクセスが許されていました） もしメンテナンスがあればそのタイミングでやればよかったのですが、直近では特に予定はないとのことでした。そのため、システムが動いている状態のまま作業をすることにしました。 ごく単純な SELECT を実行するだけのつもりだったので、システムに影響がないと判断したためです。 その際、万が一コピペをミ
autovacuumのチューニング要素について考えてみる - Qiita
この記事はPostgreSQLアドベントカレンダーの21日目の記事です。 昨日は @kasa_zip さんの PostgreSQLのバックトレースレポート機能 というPostgreSQLの新機能についての記事でした。 サーバログにバックトレースを残せる機能がPG13で追加されるかもということです。たしかにレアケースを踏んでSEGVになったときは再現が難しいのでこういう機能があると良さそうですね。（まだ、試作段階で用途は少なそうということらしいですが。） はじめに 突然ですが、autovacuumってちゃんとチューニングしていますか？ 正直自分はあまり意識したことがなかったですが、最近、お仕事の中で設定値について考える機会が多かったので、せっかくなので整理してみようと思い、アドベントカレンダーのテーマとして選びました。 裏付けのための検証をもとに まとめ を最後に書いていますので、お忙しいか
[レポート] PostgreSQL互換のRDSとAuroraの違いが分かるセッション DAT328 Deep dive on Amazon Aurora with PostgreSQL compatibility #reinvent | DevelopersIO
[レポート] PostgreSQL互換のRDSとAuroraの違いが分かるセッション DAT328 Deep dive on Amazon Aurora with PostgreSQL compatibility #reinvent CX事業本部@大阪の岩田です。 re:invent2019一発目のセッションはDAT328 Deep dive on Amazon Aurora with PostgreSQL compatibilityでした。 早速レポートです！ セッション概要 Amazon Aurora with PostgreSQL compatibility is a relational database service that combines the speed and availability of high-end commercial databases with th
![[レポート] PostgreSQL互換のRDSとAuroraの違いが分かるセッション DAT328 Deep dive on Amazon Aurora with PostgreSQL compatibility #reinvent | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/9419c6cf4ac1d0e1323fa1560dfc995d191622f5/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F12%2Freinvent2019_report_eyecatch.jpg)
ロジカルレプリケーションのレプリケーション衝突を解決する
ざっくりまとめると、 PostgreSQLのロジカルレプリケーションでレプリケーション衝突が起こった場合、衝突が（手動で）回避されるまでスタンバイでの反映が止まる 衝突を回避するための一つの方法として、pg_replication_origin_advance()関数を使って衝突の原因となるWAL（を送信する事）をスキップできるけど、スキップ先のLSNを指定するので他の必要なデータもスキップしてしまうかもしれないよ ということ。 レプリケーション衝突というのは、データの受信側（Subscriber）でのデータを適用と、テーブル内のデータや受信側で実行中の変更内容が衝突する事を指しています。 試してみる 実施にやってみる。まずは、テーブルを作成して、ロジカルレプリケーションを開始。 -- 上流側（Publisher) =# CREATE TABLE test (c int primary k
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostgreSQL Built in Sharding
PostgreSQL 14 - Improve psql
垂直スケールの果ての db.r4.16xlarge で得た教訓 / What happened on vertically scaled 16xlarge DB
