SlideShare ist ein Scribd-Unternehmen logo
1 von 43
Downloaden Sie, um offline zu lesen
PostgreSQLアーキテクチャ入門




 アップタイム・テクノロジーズ合同会社

                      永安 悟史

                      2011.2.25


  Copyright 2011 Uptime Technologies LLC, All rights reserved.   1
PostgreSQLアーキテクチャ入門
                        アジェンダ
•   アーキテクチャ概要                                          •     パフォーマンス管理
    –   PostgreSQLの構成要素                                        –    パフォーマンスは何で決まるか?
    –   PostgreSQLの基本的なアーキテクチャ                                 –    パフォーマンス改善の基本手順
    –   プロセス                                                   –    SQLパフォーマンス分析
    –   ファイル
    –   発生する3種類のI/O                                    •     可用性管理
    –   メモリ                                                    –    バックアップ
                                                               –    コールドバックアップ
•   クエリの処理                                                     –    ホットバックアップ
    –   SQL文の処理される流れ                                           –    アーカイブログとPITRを用いたバックアップ
    –   クエリとクエリプラン                                             –    アーカイブログとPITRを用いたリカバリ
    –   クエリプランの詳細                                              –    冗長化方式の選定
    –   クエリプランの確認方法
    –   データアクセスのパターン
    –   テーブルスキャン
    –   インデックスアクセス
    –   結合

•   I/O処理の詳細
    –   テーブルに対する更新処理
    –   タプルの更新とインデックスの更新
    –   VACUUM処理
    –   トランザクションロギング
                                                                     ※本資料の最新版は以下に掲載されています。
                                                                      http://www.uptime.jp/
                                                                      (ホーム→リソース→技術情報)

                     Copyright 2011 Uptime Technologies LLC, All rights reserved.            2
PostgreSQLの構成要素
   PostgreSQLは、さまざまなプロセス・メモリ領域・ファイル
  によって構成されている。

                                                   writer
          postmaster       logger                                            wal writer     autovacuum
                                                (バックグラウンド
        (リスナプロセス)        (サーバログ)                                            (WALライタ)       (自動vacuum)
                                                   ライタ)
プロセス群
           archiver stat collector postgres wal sender wal receiver
        (WALアーカイバ) (統計情報収集) (サーバプロセス) (レプリケーション) (レプリケーション)




                shared_buffers                       wal_buffers            freespacemap   トランザクション
メモリ群            (共有バッファ)                            (WALバッファ)              (空き領域情報)          制御情報




ファイル群                          テーブル                 インデックス                トランザクション         アーカイブ
           設定ファイル
                               ファイル                  ファイル                  ログファイル          ログファイル



                    Copyright 2011 Uptime Technologies LLC, All rights reserved.                     3
PostgreSQLの基本的なアーキテクチャ
 共有バッファを中心として、複数のプロセス間で連携し
ながら処理を行うマルチプロセス構造。

               postmaster
             (リスナプロセス)

                                                                                 (




                                                                                     shared_buffers
                                         postgres                                共
                                           postgres                              有
                                      (サーバプロセス)                                  バ
                                             postgres
                                       (サーバプロセス)
クライアント                                                                           ッ
                                        (サーバプロセス)                                フ
                                                                                 ァ
                                                                                 )
                                                       writer
                                                    (バックグラウンド
                                                       ライタ)


                            トランザクション
                             ログファイル
                                                      テーブル
                                                      ファイル

                                                                        インデックス
                                                                         ファイル

         Copyright 2011 Uptime Technologies LLC, All rights reserved.                                 4
プロセス
•   Postmasterプロセス
    – PostgreSQLを起動すると最初に開始されるプロセス。
    – クライアントからの接続を受け付け、認証処理を行う。
    – 認証されたクライアントに対して、Postgresプロセスを生成(fork)して処理
      を引き渡す。


•   Postgresプロセス
    – クライアントに対して1対1で存在する。
    – クライアントからSQL文を受け付け、構文解析、最適化、実行、結果返却
      を行う。
    – 共有バッファを介してデータを読み書きし、トランザクションログを書く。


•   Writerプロセス
    – 共有バッファの内容をディスク(テーブルファイル、インデックスファイル)
      に非同期的に書き戻す。



                 Copyright 2011 Uptime Technologies LLC, All rights reserved.   5
テーブルファイル
• 8kB単位のブロック単位で管理
• ブロックの中に実データのレコード(タプル)を配置
 – 基本的に追記のみ
 – 削除したら削除マーク(VACUUMで回収)
 – 更新時は「削除+追記」
                                                       DBT1=# SELECT * FROM
                                                       pgstattuple('customer');
                                                       -[ RECORD 1 ]------+-----------
    レコード1                                              table_len          | 1754857472
    レコード2                        ブロック1                 tuple_count        | 3456656
    レコード3
                                                       tuple_len          | 1703225491
    レコード4                                              tuple_percent      | 97.06
    レコード5                        ブロック2                 dead_tuple_count | 695
                                                       dead_tuple_len     | 350038
                                                       dead_tuple_percent | 0.02
                                                       free_space         | 31391624
                                 ブロック3
                                                       free_percent       | 1.79

                                                       DBT1=#

            Copyright 2011 Uptime Technologies LLC, All rights reserved.                 6
インデックス(B-Tree)ファイル
• ブロック(8kB単位)をノードとする論理的なツリー構造を持つ
 – ルート、インターナル、リーフの各ノードから構成
 – ルートノードから辿っていく
 – リーフノードは、インデックスのキーとレコードへのポインタを持つ
                                                                DBT1=# SELECT * FROM
       インデックスファイル                                               pgstatindex('customer_pkey');
                                                                -[ RECORD 1 ]------+----------
                                                                version            | 2
           root                                                 tree_level         | 2
                                                                index_size         | 108953600
                                                                root_block_no      | 217
                                                                internal_pages     | 66
                                                                leaf_pages         | 13233
                                                                empty_pages        | 0
                                                                deleted_pages      | 0
 1~5    6~10      11~17      18~25                              avg_leaf_density | 90.2
                                                                leaf_fragmentation | 0

                                                                DBT1=#
                    Copyright 2011 Uptime Technologies LLC, All rights reserved.                 7
トランザクションログ
• テーブルやインデックスの更新情報が記録(追記)される
 – 共有バッファのデータを更新する「前」に記録(Write-ahead)
 – 16MBずつのセグメント(ファイル)に分割されている。
 – リカバリの際に読み込まれる (pg_xlog/ 以下に配置)


           WAL 1                                                             WAL 2

     Aテーブルのレコード1をmに変更
     Bテーブルのレコード6をnに変更
     Aテーブルのレコード4をxに変更
     Aテーブルのレコード1をyに変更
     Bテーブルのレコード2をzに変更


        ファイルの先頭から
        順番に更新情報が
         追記されていく




              Copyright 2011 Uptime Technologies LLC, All rights reserved.           8
発生する3種類のI/O
• 例えば、主キーで検索して該当レコードを更新する場合
 –   プライマリーキーでインデックスエントリを探す
 –   インデックスのポインタを元に、テーブル内のレコードを探す
 –   テーブルレコードを更新する前にトランザクションログに記録する
 –   テーブルファイルを更新する

                                                                            物理ディスク
        テーブルファイル                       ②読む
         テーブルファイル
          テーブルファイル
                                 ④書く
                                                                             ディスク
                                                                             ヘッド
                                     ①読む
       インデックスファイル
        インデックスファイル
         インデックスファイル


                                         ③書く
         トランザクション
          ログファイル


             Copyright 2011 Uptime Technologies LLC, All rights reserved.            9
メモリ(共有バッファ)
•    ディスク上のブロックをキャッシュするメモリ領域
      – ディスク上のブロックのうち、アクセスするものだけを読み込む
      – すべてのバックエンドプロセスで共有
•    キャッシュすることで、ディスクI/Oを抑えて高速化
      – 更新の永続性はトランザクションログで担保する




    postgres
                                    9 17 5 14
      postgres

     postgres                           共有バッファ                                        1 2 3 4 5 6
                                                                                      7 8 9 10 11 12
バックエンド                                                                               13 14 15 16 17 18
                                                                                     19 ・・・・
               トランザクション
                ログファイル
                                                                        テーブル/インデックスファイル

                      Copyright 2011 Uptime Technologies LLC, All rights reserved.                       10
SQL文の処理される流れ
    クエリ受信

                               •SQL構文の解析、文法エラーの検出
  構文解析(parse)                  •構文木(parse tree)の生成


                               •VIEW / RULE に基づいた構文木の書き換え
 書き換え(rewrite)



実行計画生成 / 最適化                   •最適なクエリプラン(実行計画)の生成
 (plan / optimize)             •統計情報などを用いて実行コストを最小化
                                (コストベース最適化)

                               •クエリプランに沿ったデータアクセス、抽出/結合/
   実行(execute)                  並べ替えなどの演算処理
                               •(更新時)トランザクションログ追記、共有バッファ更新

     結果送信
                 Copyright 2011 Uptime Technologies LLC, All rights reserved.   11
クエリとクエリプラン




                                                             ネステッドループ
                                                               ジョイン


テーブル
スキャン




                                                                        集約 count()


インデックス
 スキャン


         Copyright 2011 Uptime Technologies LLC, All rights reserved.                12
クエリプランの詳細




Copyright 2011 Uptime Technologies LLC, All rights reserved.   13
クエリプランの確認方法
• EXPLAINコマンド
  – 最適であると判断された「実行計画」を表示。
  – 入力されたSQL文を、PostgreSQLがどのように解釈して処理しよう
    としているのかを表示。


• EXPLAIN ANALYZEコマンド
  – 「実行結果」を表示。
  – 実際に、どのアクセスにどの程度の時間がかかっているのか、何件
    のレコードを処理したのか、などを表示。



• その他(pgAdminIII)
  – 「クエリー解釈」、「アナライズ解釈」は、EXPLAIN、EXPLAIN
    ANALYZEと同等。

            Copyright 2011 Uptime Technologies LLC, All rights reserved.   14
データアクセスのパターン
• シーケンシャルアクセス
  – 全レコード、または多くのレコードを処理する必要がある場合
  – 集約処理、LIKE文の中間一致など
• ランダムアクセス
  – 特定のレコード(を含むブロック)だけにアクセスする必要がある場合
  – 主にインデックスを用いたアクセス




シーケンシャル                                                 ランダム
  アクセス                                                  アクセス

   ファイルの先頭から
   順番に読み込んでいく                                          必要なブロックだけ
                                                       ピンポイントで読み込む


            テーブルファイル                                                           テーブルファイル

                Copyright 2011 Uptime Technologies LLC, All rights reserved.          15
テーブルスキャン
SELECT count(*) FROM customer;
                                                                       Customer
                                                                     テーブルからの
                                                                      ブロック読込
                                                                      ×214,216




                                                                   Customer_pkey
                                                                    インデックスの
                                                                   ブロック読込×0




    Copyright 2011 Uptime Technologies LLC, All rights reserved.                   16
テーブルスキャン cont’d
• すべてのデータを確認する必要があるため、customerテー
  ブルファイルを構成するブロックを先頭から読み込む
 – よって、データが増えれば増えるほど時間がかかるようになる。
 – この例では、214,216 ブロック(約1.7GB)を読んでいる。


   Customer_pkeyインデックス                                                Customerテーブル

                                                                                  レコード1
          root                                                                    レコード2
                                                                                  レコード3

                                                                                  レコード4
                                                                                  レコード5




 1~5   6~10      11~17      18~25



                   Copyright 2011 Uptime Technologies LLC, All rights reserved.           17
インデックスアクセス
SELECT * FROM customer c WHERE c.c_id=7;
                                                                          Customer
                                                                        テーブルからの
                                                                        ブロック読込×1




                                                                        Customer_pkey
                                                                         インデックスの
                                                                        ブロック読込×3




         Copyright 2011 Uptime Technologies LLC, All rights reserved.                   18
インデックスアクセス cont’d
• “c_id=7” レコードの位置を探すため、customer_pkeyを辿っ
  てポインタを見つけ、レコードを含むテーブルファイルのブ
  ロックを読み込む。
  – この例では、customer_pkeyインデックスから3ブロック、customer
    テーブルから1ブロックを読んでいる。
  – レコードの量とディスクアクセス量が比例しない。
    Customer_pkeyインデックス                                               Customerテーブル

                                                                                  レコード1
           root                                                                   レコード2
                                                                                  レコード3

                                                                                  レコード4
                                                                                  レコード5




  1~5   6~10      11~17      18~25


                   Copyright 2011 Uptime Technologies LLC, All rights reserved.           19
結合(Nested Loop Join)
• SELECT count(*) FROM orders o, customer c
  WHERE o.o_c_id=c.c_id AND c.c_uname=‘UL’;
  – customer を c_uname=‘UL’ でインデックススキャン
  – customer のレコードの c_id を使って orders をインデックススキャン




  i_c_uname     customer                            i_o_c_id                 orders




              Copyright 2011 Uptime Technologies LLC, All rights reserved.            20
テーブルに対する更新処理
              レコード1                       「レコード5」を追加                                 レコード1
  レコード        レコード2                                                                  レコード2
 追加処理         レコード3                                                                  レコード3
              レコード4                                                                  レコード4
(INSERT)                                                                             レコード5
           ファイル中に4件のレコードが
           順番に並んでいる                                                  レコード5がファイル末尾に追加され、
                                                                     ファイルサイズが増える

                                          「レコード2」を削除
              レコード1                                                                   レコード1
 レコード         レコード2                                                                  (レコード2)
 削除処理         レコード3                                                                   レコード3
              レコード4                                                                   レコード4
(DELETE)
           ファイル中に4件のレコードが                                             レコード2に削除マークが付けられる
           順番に並んでいる

                                        「レコード2」を
              レコード1                     「レコード2’」として更新                                 レコード1
  レコード        レコード2                                                                  (レコード2)
 更新処理         レコード3                                                                   レコード3
              レコード4                                                                   レコード4
(UPDATE)
                                                                                      レコード2’
           ファイル中に4件のレコードが                                            レコード2に削除マークが付けられ、
           順番に並んでいる                                                  レコード2’が新たに追加、ファイルサイズ増加
                      Copyright 2011 Uptime Technologies LLC, All rights reserved.             21
タプルの更新とインデックスの更新
8.2以前
         インデックス付きカラム

ヒープタプル      レコード1                                                            レコード1
                                     インデックスのない
(テーブル)      レコード2                    カラムを更新すると・・・                           (レコード2)
                                                                             レコード2’


            エントリ1                                                            エントリ1      インデックスサイズも
インデックス
            エントリ2                                                           (エントリ2)     増える
                                                                             エントリ2’


8.3以降    インデックス付きカラム

ヒープタプル       レコード1                                                             レコード1
(テーブル)                                 インデックスのない
             レコード2                     カラムを更新すると・・・
                                                                              (レコード2)
                                                                               レコード2’


             エントリ1                                                             エントリ1    インデックスサイズは
インデックス
             エントリ2                                                             エントリ2    増えない



               インデックスの張られていないカラムを更新すると、
             ヒープのみの(インデックスエントリが無い)カラムができる。

                     これが、HOT(Heap Only Tuple)
                    Copyright 2011 Uptime Technologies LLC, All rights reserved.              22
VACUUM処理
            VACUUM前                                                                   VACUUM後
              レコード1                                                                    レコード1
             (レコード2)
                                            VACUUM処理
                                                                                       空き領域
VACUUM        レコード3                                                                    レコード3
処理            レコード4                                                                    レコード4
              レコード2’                                                                   レコード2’
         レコード2に削除マークが                                                      レコード2の領域が「空き領域」として
         付いている                                                             再利用可能になる。

            追記前                                                                       追記後
             レコード1                          レコード5を追記                                   レコード1
             空き領域                                                                      レコード5
VACUUM       レコード3                                                                     レコード3
してあると        レコード4                                                                     レコード4
             レコード2’                                                                    レコード2’
          「空き領域」がある                                                          ファイルサイズを変えずに追記できる

              レコード1                                                                    レコード1
                                            レコード5を追記
             (レコード2)                                                                  (レコード2)
VACUUM        レコード3                                                                    レコード3
してないと         レコード4                                                                    レコード4
              レコード2’                                                                   レコード2’
         レコード2の領域が埋まったまま                                                               レコード5
                                                                                ファイルサイズが増加
                       Copyright 2011 Uptime Technologies LLC, All rights reserved.             23
パフォーマンスは何で決まるか?
• 「単一クエリのレスポンス×クエリの同時実行数」
 – 単一クエリのレスポンス
   •   サーバ・クライアント間通信(ネットワーク)
   •   SQLの構文解析、最適化(CPU処理)
   •   ロックの競合(ロック待ち、デッドロックの発生)
   •   テーブル、インデックス、ログへのI/O量(ディスクI/O)
   •   ソート、結合などの演算処理(CPU処理)
 – クエリの同時実行数
   • 接続クライアント数(いわゆるWebユーザ)
   • コネクションプール接続数


• これらが全体としてハードウェアのキャパシティの範囲内で
  ある必要がある。
 – ネットワーク、ディスクI/O、メモリ、CPUなどがボトルネックとなり得る。
 – ただし、サーバリソースネック自体は「結果」であり、「原因」ではない。
 – 「なぜ、それがボトルネックになっているのか?」が重要。
             Copyright 2011 Uptime Technologies LLC, All rights reserved.   24
パフォーマンス改善の基本手順
• 遅いSQL文を特定する or 実行回数の多いSQLを特定する
 – log_min_durationオプション
 – pgFouine


• SQLの実行プランを確認する
 – EXPLAIN / EXPLAIN ANALYZE


• 対策をする
 –   SQL文を書き換える、インデックスを張る、テーブル設計を修正する
 –   アプリケーションを修正する
 –   ハードウェアを増強する
 –   他・・・



             Copyright 2011 Uptime Technologies LLC, All rights reserved.   25
SQLパフォーマンス分析
• pgFouineによる問題SQL文の抽出
  – 総実行時間=レスポンスタイム(実行時間)×実行回数
  – 最長レスポンスタイム
  – 他・・・




          Copyright 2011 Uptime Technologies LLC, All rights reserved.   26
バックアップ
• バックアップの難しさ
 –   データはファイルの中にだけあるのではない!
 –   通常は、共有バッファの内容が最新
 –   ファイルだけバックアップを取ってもダメ
 –   ミリ秒単位で処理が進む中、すべてを一貫性を保った状態で


• バックアップの種類
 – コールドバックアップ
 – ホットバックアップ
 – アーカイブログバックアップ


• バックアップ&リカバリはリハーサルをしよう!
 – 簡単な試験や手順書を作るだけで満足してはいけない・・・

           Copyright 2011 Uptime Technologies LLC, All rights reserved.   27
コールドバックアップ
•   サーバプロセスをすべてシャットダウンしてデータファイル全体をバック
    アップ
    – バックアップの間、サービス停止が発生する。
    – リカバリの際には、バックアップ時のデータに戻る。
•   利用ケース
    – 前回バックアップ以降の更新データを復旧できる場合。
    – ストレージスナップショットが一般化した今、案外現実的。




                                                                                  Crash

              ①ファイルを  WAL1                        WAL2                   WAL3
                                                                                  ②障害発生
               バックアップ
               (サービス中断)
                                                                                   ③レストア

          Index
      Table


                   Copyright 2011 Uptime Technologies LLC, All rights reserved.            28
ホットバックアップ(pg_dump)
•   あるタイミングでデータの一貫性を保ちつつバックアップ
    – シンプルかつ柔軟(テーブル単位のバックアップも可)
    – バックアップ時にサービス停止は起こらない。
    – リカバリの際には、バックアップ時のデータに戻る。
•   利用ケース
    – 前回バックアップ以降の更新データを復旧できる場合。
    – データベース単位、テーブル単位でバックアップを取りたい場合。
    – 論理バックアップが必要な場合(メジャーバージョンアップなど)


                                                                                   Crash
                        WAL1                       WAL2                   WAL3
              ①pg_dumpで                                                            ②障害発生
               スナップショットを
               バックアップ
                                                                                    ③レストア

          Index
      Table


                    Copyright 2011 Uptime Technologies LLC, All rights reserved.            29
アーカイブログとPITRを用いたバックアップ
•   ベースバックアップ(基準点)+アーカイブログ(更新差分)
    – サービスを継続したままベースバックアップを取得可能
    – クラッシュ直前のWALの内容まで復旧することが可能
•   利用ケース
    – データベースクラスタ全体の完全なバックアップを取りたい場合。
    – クラッシュ直前の更新まで復旧させる必要がある場合。


                                                                                      Crash
                            WAL1                   WAL2                    WAL3

               ①ベースバック
                アップの取得            ②WAL1を                  ③WAL2を                  ④WAL3を
                                   アーカイブ                   アーカイブ                   アーカイブ



           Index
                            WAL1                   WAL2                    WAL3
       Table
                   PITRに必要なファイル類

                   Copyright 2011 Uptime Technologies LLC, All rights reserved.               30
アーカイブログとPITRを用いたリカバリ
•   ベースバックアップ(基準点)+アーカイブログ(更新差分)
    – 前回のベースバックアップ以降、長期間が経過しているとアーカイブログが
      多くなり、リカバリの時間が長くなる。
    – ベースバックアップレストア時間+アーカイブログ適用時間×アーカイブログ
      数
                                                                                     WAL3適用完了
                                                                                     リカバリ完了




                      WAL1                   WAL2                    WAL3

            ①ベースバック
             アップを展開         ②WAL1を                  ③WAL2を                  ④WAL3を
                             適用                      適用                      適用



        Index
                      WAL1                   WAL2                    WAL3
    Table


                      Copyright 2011 Uptime Technologies LLC, All rights reserved.          31
冗長化方式の選定
• 実現方式を評価するに当たって特に重視すべき点
      –     負荷分散の必要性の有無。
      –     単一障害点(Single Point of Failure、SPoF)の有無。
      –     運用が容易であるかどうか(運用の作業負荷、ノウハウの蓄積)。
      –     データ一貫性の厳密性(レプリケーション遅延)の程度。

実現方式            アーキテクチャ                負荷分散          同期遅延           運用性          備考
アーカイブログ転送       アクティブ/スタンバイ                ×         数十秒               ◎         ウォームスタンバイ方式。
                                                      ~数分
DRBDディスク同期      アクティブ/スタンバイ                ×         なし                △         要DRBD運用ノウハウ。
共有ディスク方式        アクティブ/スタンバイ                ×         なし                △         共有ディスクが高価でSPOF。
Slony-Iレプリケー    アクティブ/アクティブ、               ○         数秒                △         公開されているSlony-Iの運用ノウハ
ション             マスター/スレーブ                                                        ウが少ない。バージョン混在可。
pgpool-II       アクティブ/アクティブ、               ○         なし                ○         pgpoolサーバがSPOF(冗長化可)。
                マスター/スレーブ                                                        一部、APへの影響有り(now()等)。
ストリーミング・レプリ     アクティブ/アクティブ、               ○         数百ms              △         公開されている運用ノウハウが少な
ケーション(9.0~)     マスター/スレーブ                                                        い。



                      Copyright 2011 Uptime Technologies LLC, All rights reserved.                  32
冗長化方式の選定 cont’d
• PostgreSQLの代表的な冗長化方式の構成は以下の通り。
  – シンプルな冗長化のみで良い場合は共有ディスク方式。
  – スケールアウトが必要な場合は pgpool か Slony-I。
  – 9.0以降はストリーミングレプリケーション(SR+HS)構成が可能。
   共有ディスク方式                                    pgpool方式                                    SR+HS方式




                                                                                   Web/APサーバ   Web/APサーバ
Web/APサーバ   Web/APサーバ                Web/APサーバ         Web/APサーバ

                     読み書き                                                                             読み込み可
                     不可




                                               pgpoolサーバ
                                                                                       マスタDB   スレーブDB
 マスタDB      スレーブDB
                                                 SQL転送


                                                                                         ログ(レコード)転送

                                        マスタDB            スレーブDB
    共有ストレージ



                        Copyright 2011 Uptime Technologies LLC, All rights reserved.                          33
参考文献
•   書籍・雑誌
    –   WEB+DB PRESS vol.32~37 「PostgreSQL安定運用のコツ」 (技術評論社)
    –   データベースパフォーマンスアップの教科書 基本原理編 (翔泳社)


•   オンラインドキュメント類
    –   PostgreSQL 9.0.2文書
        http://www.postgresql.jp/document/pg902doc/html/index.html
    –   Explaining Explain ~ PostgreSQLの実行計画を読む ~ (PDF版)
        http://lets.postgresql.jp/documents/technical/query_tuning/explaining_explain_ja.pdf
    –   HOTの仕組み (1) - Let's Postgres
        http://lets.postgresql.jp/documents/tutorial/hot_2/
    –   ソーシャルゲームのためのデータベース設計
        http://www.slideshare.net/matsunobu/ss-6584540




                           Copyright 2011 Uptime Technologies LLC, All rights reserved.        34
PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門

Weitere ähnliche Inhalte

Was ist angesagt?

PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)NTT DATA Technology & Innovation
 
Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそうPython 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそうRyuji Tsutsui
 
PostgreSQLの関数属性を知ろう
PostgreSQLの関数属性を知ろうPostgreSQLの関数属性を知ろう
PostgreSQLの関数属性を知ろうkasaharatt
 
あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界Yoshinori Nakanishi
 
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)NTT DATA Technology & Innovation
 
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...NTT DATA Technology & Innovation
 
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)Hironobu Suzuki
 
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)NTT DATA Technology & Innovation
 
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)NTT DATA Technology & Innovation
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話Kumazaki Hiroki
 
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!NTT DATA Technology & Innovation
 
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)NTT DATA Technology & Innovation
 
PostgreSQL - C言語によるユーザ定義関数の作り方
PostgreSQL - C言語によるユーザ定義関数の作り方PostgreSQL - C言語によるユーザ定義関数の作り方
PostgreSQL - C言語によるユーザ定義関数の作り方Satoshi Nagayasu
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションMasahiko Sawada
 
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)NTT DATA Technology & Innovation
 
PostgreSQL 13でのpg_stat_statementsの改善について(第12回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL 13でのpg_stat_statementsの改善について(第12回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL 13でのpg_stat_statementsの改善について(第12回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL 13でのpg_stat_statementsの改善について(第12回PostgreSQLアンカンファレンス@オンライン 発表資料)NTT DATA Technology & Innovation
 
今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説Masahiko Sawada
 

Was ist angesagt? (20)

PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそうPython 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそう
 
PostgreSQLの関数属性を知ろう
PostgreSQLの関数属性を知ろうPostgreSQLの関数属性を知ろう
PostgreSQLの関数属性を知ろう
 
PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題
 
あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界
 
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
 
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
 
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
 
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
 
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
PostgreSQL - C言語によるユーザ定義関数の作り方
PostgreSQL - C言語によるユーザ定義関数の作り方PostgreSQL - C言語によるユーザ定義関数の作り方
PostgreSQL - C言語によるユーザ定義関数の作り方
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
 
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
PostgreSQL 13でのpg_stat_statementsの改善について(第12回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL 13でのpg_stat_statementsの改善について(第12回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL 13でのpg_stat_statementsの改善について(第12回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL 13でのpg_stat_statementsの改善について(第12回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
NTT DATA と PostgreSQL が挑んだ総力戦
NTT DATA と PostgreSQL が挑んだ総力戦NTT DATA と PostgreSQL が挑んだ総力戦
NTT DATA と PostgreSQL が挑んだ総力戦
 
今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説
 
使ってみませんか?pg_hint_plan
使ってみませんか?pg_hint_plan使ってみませんか?pg_hint_plan
使ってみませんか?pg_hint_plan
 

Ähnlich wie PostgreSQLアーキテクチャ入門

PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)
PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)
PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)Uptime Technologies LLC (JP)
 
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)Uptime Technologies LLC (JP)
 
C16 45分でわかるPostgreSQLの仕組み by 山田努
C16 45分でわかるPostgreSQLの仕組み by 山田努C16 45分でわかるPostgreSQLの仕組み by 山田努
C16 45分でわかるPostgreSQLの仕組み by 山田努Insight Technology, Inc.
 
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009Ryota Watabe
 
AWSのデータベースサービス全体像
AWSのデータベースサービス全体像AWSのデータベースサービス全体像
AWSのデータベースサービス全体像Amazon Web Services Japan
 
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会Shigeru Hanada
 
Intro2 Sqlanalyzer
Intro2 SqlanalyzerIntro2 Sqlanalyzer
Intro2 Sqlanalyzersaeka
 
ログブラウズ、解析サービスSumologicの紹介
ログブラウズ、解析サービスSumologicの紹介ログブラウズ、解析サービスSumologicの紹介
ログブラウズ、解析サービスSumologicの紹介Yasuhiro Araki, Ph.D
 
SQL Server 使いのための Azure Synapse Analytics - Spark 入門
SQL Server 使いのための Azure Synapse Analytics - Spark 入門SQL Server 使いのための Azure Synapse Analytics - Spark 入門
SQL Server 使いのための Azure Synapse Analytics - Spark 入門Daiyu Hatakeyama
 
PostgreSQL 9.2 新機能 - OSC 2012 Kansai@Kyoto
PostgreSQL 9.2 新機能 - OSC 2012 Kansai@KyotoPostgreSQL 9.2 新機能 - OSC 2012 Kansai@Kyoto
PostgreSQL 9.2 新機能 - OSC 2012 Kansai@KyotoShigeru Hanada
 
OSS-DB Gold技術解説セミナー@db tech showcase 東京 2014
OSS-DB Gold技術解説セミナー@db tech showcase 東京 2014OSS-DB Gold技術解説セミナー@db tech showcase 東京 2014
OSS-DB Gold技術解説セミナー@db tech showcase 東京 2014Shigeru Hanada
 
5ステップで始めるPostgreSQLレプリケーション@hbstudy#13
5ステップで始めるPostgreSQLレプリケーション@hbstudy#135ステップで始めるPostgreSQLレプリケーション@hbstudy#13
5ステップで始めるPostgreSQLレプリケーション@hbstudy#13Uptime Technologies LLC (JP)
 
Kyoto Tycoon Guide in Japanese
Kyoto Tycoon Guide in JapaneseKyoto Tycoon Guide in Japanese
Kyoto Tycoon Guide in JapaneseMikio Hirabayashi
 
PostgreSQL 9.2 新機能 - 新潟オープンソースセミナー2012
PostgreSQL 9.2 新機能 - 新潟オープンソースセミナー2012PostgreSQL 9.2 新機能 - 新潟オープンソースセミナー2012
PostgreSQL 9.2 新機能 - 新潟オープンソースセミナー2012Shigeru Hanada
 

Ähnlich wie PostgreSQLアーキテクチャ入門 (20)

PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)
PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)
PostgreSQLアーキテクチャ入門(INSIGHT OUT 2011)
 
PostgreSQLバックアップの基本
PostgreSQLバックアップの基本PostgreSQLバックアップの基本
PostgreSQLバックアップの基本
 
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)
 
PostgreSQL安定運用のコツ2009 @hbstudy#5
PostgreSQL安定運用のコツ2009 @hbstudy#5PostgreSQL安定運用のコツ2009 @hbstudy#5
PostgreSQL安定運用のコツ2009 @hbstudy#5
 
C16 45分でわかるPostgreSQLの仕組み by 山田努
C16 45分でわかるPostgreSQLの仕組み by 山田努C16 45分でわかるPostgreSQLの仕組み by 山田努
C16 45分でわかるPostgreSQLの仕組み by 山田努
 
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009
 
Mysql casial01
Mysql casial01Mysql casial01
Mysql casial01
 
AWSのデータベースサービス全体像
AWSのデータベースサービス全体像AWSのデータベースサービス全体像
AWSのデータベースサービス全体像
 
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
 
Fluentd casual
Fluentd casualFluentd casual
Fluentd casual
 
Intro2 Sqlanalyzer
Intro2 SqlanalyzerIntro2 Sqlanalyzer
Intro2 Sqlanalyzer
 
ログブラウズ、解析サービスSumologicの紹介
ログブラウズ、解析サービスSumologicの紹介ログブラウズ、解析サービスSumologicの紹介
ログブラウズ、解析サービスSumologicの紹介
 
SQL Server 使いのための Azure Synapse Analytics - Spark 入門
SQL Server 使いのための Azure Synapse Analytics - Spark 入門SQL Server 使いのための Azure Synapse Analytics - Spark 入門
SQL Server 使いのための Azure Synapse Analytics - Spark 入門
 
PostgreSQL 9.2 新機能 - OSC 2012 Kansai@Kyoto
PostgreSQL 9.2 新機能 - OSC 2012 Kansai@KyotoPostgreSQL 9.2 新機能 - OSC 2012 Kansai@Kyoto
PostgreSQL 9.2 新機能 - OSC 2012 Kansai@Kyoto
 
OSS-DB Gold技術解説セミナー@db tech showcase 東京 2014
OSS-DB Gold技術解説セミナー@db tech showcase 東京 2014OSS-DB Gold技術解説セミナー@db tech showcase 東京 2014
OSS-DB Gold技術解説セミナー@db tech showcase 東京 2014
 
PostgreSQL Query Cache - "pqc"
PostgreSQL Query Cache - "pqc"PostgreSQL Query Cache - "pqc"
PostgreSQL Query Cache - "pqc"
 
Nginx
NginxNginx
Nginx
 
5ステップで始めるPostgreSQLレプリケーション@hbstudy#13
5ステップで始めるPostgreSQLレプリケーション@hbstudy#135ステップで始めるPostgreSQLレプリケーション@hbstudy#13
5ステップで始めるPostgreSQLレプリケーション@hbstudy#13
 
Kyoto Tycoon Guide in Japanese
Kyoto Tycoon Guide in JapaneseKyoto Tycoon Guide in Japanese
Kyoto Tycoon Guide in Japanese
 
PostgreSQL 9.2 新機能 - 新潟オープンソースセミナー2012
PostgreSQL 9.2 新機能 - 新潟オープンソースセミナー2012PostgreSQL 9.2 新機能 - 新潟オープンソースセミナー2012
PostgreSQL 9.2 新機能 - 新潟オープンソースセミナー2012
 

Mehr von Uptime Technologies LLC (JP)

PL/Pythonで独自の集約関数を作ってみる
PL/Pythonで独自の集約関数を作ってみるPL/Pythonで独自の集約関数を作ってみる
PL/Pythonで独自の集約関数を作ってみるUptime Technologies LLC (JP)
 
pgstattuple2: デッドタプル推定のための統計的手法
pgstattuple2: デッドタプル推定のための統計的手法pgstattuple2: デッドタプル推定のための統計的手法
pgstattuple2: デッドタプル推定のための統計的手法Uptime Technologies LLC (JP)
 
「今そこにある危機」を捉える ~ pg_stat_statements revisited
「今そこにある危機」を捉える ~ pg_stat_statements revisited「今そこにある危機」を捉える ~ pg_stat_statements revisited
「今そこにある危機」を捉える ~ pg_stat_statements revisitedUptime Technologies LLC (JP)
 
BigDataを迎え撃つ! PostgreSQL並列分散ミドルウェア「Stado」の紹介と検証報告
BigDataを迎え撃つ! PostgreSQL並列分散ミドルウェア「Stado」の紹介と検証報告BigDataを迎え撃つ! PostgreSQL並列分散ミドルウェア「Stado」の紹介と検証報告
BigDataを迎え撃つ! PostgreSQL並列分散ミドルウェア「Stado」の紹介と検証報告Uptime Technologies LLC (JP)
 
Uptime Database Appliance テクノロジープレビュー
Uptime Database Appliance テクノロジープレビューUptime Database Appliance テクノロジープレビュー
Uptime Database Appliance テクノロジープレビューUptime Technologies LLC (JP)
 

Mehr von Uptime Technologies LLC (JP) (8)

PL/Pythonで独自の集約関数を作ってみる
PL/Pythonで独自の集約関数を作ってみるPL/Pythonで独自の集約関数を作ってみる
PL/Pythonで独自の集約関数を作ってみる
 
PostgreSQLセキュリティ総復習
PostgreSQLセキュリティ総復習PostgreSQLセキュリティ総復習
PostgreSQLセキュリティ総復習
 
Postgres Toolkit
Postgres ToolkitPostgres Toolkit
Postgres Toolkit
 
Postgres Toolkitのご紹介
Postgres Toolkitのご紹介Postgres Toolkitのご紹介
Postgres Toolkitのご紹介
 
pgstattuple2: デッドタプル推定のための統計的手法
pgstattuple2: デッドタプル推定のための統計的手法pgstattuple2: デッドタプル推定のための統計的手法
pgstattuple2: デッドタプル推定のための統計的手法
 
「今そこにある危機」を捉える ~ pg_stat_statements revisited
「今そこにある危機」を捉える ~ pg_stat_statements revisited「今そこにある危機」を捉える ~ pg_stat_statements revisited
「今そこにある危機」を捉える ~ pg_stat_statements revisited
 
BigDataを迎え撃つ! PostgreSQL並列分散ミドルウェア「Stado」の紹介と検証報告
BigDataを迎え撃つ! PostgreSQL並列分散ミドルウェア「Stado」の紹介と検証報告BigDataを迎え撃つ! PostgreSQL並列分散ミドルウェア「Stado」の紹介と検証報告
BigDataを迎え撃つ! PostgreSQL並列分散ミドルウェア「Stado」の紹介と検証報告
 
Uptime Database Appliance テクノロジープレビュー
Uptime Database Appliance テクノロジープレビューUptime Database Appliance テクノロジープレビュー
Uptime Database Appliance テクノロジープレビュー
 

Kürzlich hochgeladen

2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦Sadao Tokuyama
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~arts yokohama
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdfAyachika Kitazaki
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfMatsushita Laboratory
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-LoopへTetsuya Nihonmatsu
 

Kürzlich hochgeladen (12)

2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
 
2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 
2024 04 minnanoito
2024 04 minnanoito2024 04 minnanoito
2024 04 minnanoito
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
 

PostgreSQLアーキテクチャ入門

  • 1. PostgreSQLアーキテクチャ入門 アップタイム・テクノロジーズ合同会社 永安 悟史 2011.2.25 Copyright 2011 Uptime Technologies LLC, All rights reserved. 1
  • 2. PostgreSQLアーキテクチャ入門 アジェンダ • アーキテクチャ概要 • パフォーマンス管理 – PostgreSQLの構成要素 – パフォーマンスは何で決まるか? – PostgreSQLの基本的なアーキテクチャ – パフォーマンス改善の基本手順 – プロセス – SQLパフォーマンス分析 – ファイル – 発生する3種類のI/O • 可用性管理 – メモリ – バックアップ – コールドバックアップ • クエリの処理 – ホットバックアップ – SQL文の処理される流れ – アーカイブログとPITRを用いたバックアップ – クエリとクエリプラン – アーカイブログとPITRを用いたリカバリ – クエリプランの詳細 – 冗長化方式の選定 – クエリプランの確認方法 – データアクセスのパターン – テーブルスキャン – インデックスアクセス – 結合 • I/O処理の詳細 – テーブルに対する更新処理 – タプルの更新とインデックスの更新 – VACUUM処理 – トランザクションロギング ※本資料の最新版は以下に掲載されています。 http://www.uptime.jp/ (ホーム→リソース→技術情報) Copyright 2011 Uptime Technologies LLC, All rights reserved. 2
  • 3. PostgreSQLの構成要素 PostgreSQLは、さまざまなプロセス・メモリ領域・ファイル によって構成されている。 writer postmaster logger wal writer autovacuum (バックグラウンド (リスナプロセス) (サーバログ) (WALライタ) (自動vacuum) ライタ) プロセス群 archiver stat collector postgres wal sender wal receiver (WALアーカイバ) (統計情報収集) (サーバプロセス) (レプリケーション) (レプリケーション) shared_buffers wal_buffers freespacemap トランザクション メモリ群 (共有バッファ) (WALバッファ) (空き領域情報) 制御情報 ファイル群 テーブル インデックス トランザクション アーカイブ 設定ファイル ファイル ファイル ログファイル ログファイル Copyright 2011 Uptime Technologies LLC, All rights reserved. 3
  • 4. PostgreSQLの基本的なアーキテクチャ 共有バッファを中心として、複数のプロセス間で連携し ながら処理を行うマルチプロセス構造。 postmaster (リスナプロセス) ( shared_buffers postgres 共 postgres 有 (サーバプロセス) バ postgres (サーバプロセス) クライアント ッ (サーバプロセス) フ ァ ) writer (バックグラウンド ライタ) トランザクション ログファイル テーブル ファイル インデックス ファイル Copyright 2011 Uptime Technologies LLC, All rights reserved. 4
  • 5. プロセス • Postmasterプロセス – PostgreSQLを起動すると最初に開始されるプロセス。 – クライアントからの接続を受け付け、認証処理を行う。 – 認証されたクライアントに対して、Postgresプロセスを生成(fork)して処理 を引き渡す。 • Postgresプロセス – クライアントに対して1対1で存在する。 – クライアントからSQL文を受け付け、構文解析、最適化、実行、結果返却 を行う。 – 共有バッファを介してデータを読み書きし、トランザクションログを書く。 • Writerプロセス – 共有バッファの内容をディスク(テーブルファイル、インデックスファイル) に非同期的に書き戻す。 Copyright 2011 Uptime Technologies LLC, All rights reserved. 5
  • 6. テーブルファイル • 8kB単位のブロック単位で管理 • ブロックの中に実データのレコード(タプル)を配置 – 基本的に追記のみ – 削除したら削除マーク(VACUUMで回収) – 更新時は「削除+追記」 DBT1=# SELECT * FROM pgstattuple('customer'); -[ RECORD 1 ]------+----------- レコード1 table_len | 1754857472 レコード2 ブロック1 tuple_count | 3456656 レコード3 tuple_len | 1703225491 レコード4 tuple_percent | 97.06 レコード5 ブロック2 dead_tuple_count | 695 dead_tuple_len | 350038 dead_tuple_percent | 0.02 free_space | 31391624 ブロック3 free_percent | 1.79 DBT1=# Copyright 2011 Uptime Technologies LLC, All rights reserved. 6
  • 7. インデックス(B-Tree)ファイル • ブロック(8kB単位)をノードとする論理的なツリー構造を持つ – ルート、インターナル、リーフの各ノードから構成 – ルートノードから辿っていく – リーフノードは、インデックスのキーとレコードへのポインタを持つ DBT1=# SELECT * FROM インデックスファイル pgstatindex('customer_pkey'); -[ RECORD 1 ]------+---------- version | 2 root tree_level | 2 index_size | 108953600 root_block_no | 217 internal_pages | 66 leaf_pages | 13233 empty_pages | 0 deleted_pages | 0 1~5 6~10 11~17 18~25 avg_leaf_density | 90.2 leaf_fragmentation | 0 DBT1=# Copyright 2011 Uptime Technologies LLC, All rights reserved. 7
  • 8. トランザクションログ • テーブルやインデックスの更新情報が記録(追記)される – 共有バッファのデータを更新する「前」に記録(Write-ahead) – 16MBずつのセグメント(ファイル)に分割されている。 – リカバリの際に読み込まれる (pg_xlog/ 以下に配置) WAL 1 WAL 2 Aテーブルのレコード1をmに変更 Bテーブルのレコード6をnに変更 Aテーブルのレコード4をxに変更 Aテーブルのレコード1をyに変更 Bテーブルのレコード2をzに変更 ファイルの先頭から 順番に更新情報が 追記されていく Copyright 2011 Uptime Technologies LLC, All rights reserved. 8
  • 9. 発生する3種類のI/O • 例えば、主キーで検索して該当レコードを更新する場合 – プライマリーキーでインデックスエントリを探す – インデックスのポインタを元に、テーブル内のレコードを探す – テーブルレコードを更新する前にトランザクションログに記録する – テーブルファイルを更新する 物理ディスク テーブルファイル ②読む テーブルファイル テーブルファイル ④書く ディスク ヘッド ①読む インデックスファイル インデックスファイル インデックスファイル ③書く トランザクション ログファイル Copyright 2011 Uptime Technologies LLC, All rights reserved. 9
  • 10. メモリ(共有バッファ) • ディスク上のブロックをキャッシュするメモリ領域 – ディスク上のブロックのうち、アクセスするものだけを読み込む – すべてのバックエンドプロセスで共有 • キャッシュすることで、ディスクI/Oを抑えて高速化 – 更新の永続性はトランザクションログで担保する postgres 9 17 5 14 postgres postgres 共有バッファ 1 2 3 4 5 6 7 8 9 10 11 12 バックエンド 13 14 15 16 17 18 19 ・・・・ トランザクション ログファイル テーブル/インデックスファイル Copyright 2011 Uptime Technologies LLC, All rights reserved. 10
  • 11. SQL文の処理される流れ クエリ受信 •SQL構文の解析、文法エラーの検出 構文解析(parse) •構文木(parse tree)の生成 •VIEW / RULE に基づいた構文木の書き換え 書き換え(rewrite) 実行計画生成 / 最適化 •最適なクエリプラン(実行計画)の生成 (plan / optimize) •統計情報などを用いて実行コストを最小化 (コストベース最適化) •クエリプランに沿ったデータアクセス、抽出/結合/ 実行(execute) 並べ替えなどの演算処理 •(更新時)トランザクションログ追記、共有バッファ更新 結果送信 Copyright 2011 Uptime Technologies LLC, All rights reserved. 11
  • 12. クエリとクエリプラン ネステッドループ ジョイン テーブル スキャン 集約 count() インデックス スキャン Copyright 2011 Uptime Technologies LLC, All rights reserved. 12
  • 13. クエリプランの詳細 Copyright 2011 Uptime Technologies LLC, All rights reserved. 13
  • 14. クエリプランの確認方法 • EXPLAINコマンド – 最適であると判断された「実行計画」を表示。 – 入力されたSQL文を、PostgreSQLがどのように解釈して処理しよう としているのかを表示。 • EXPLAIN ANALYZEコマンド – 「実行結果」を表示。 – 実際に、どのアクセスにどの程度の時間がかかっているのか、何件 のレコードを処理したのか、などを表示。 • その他(pgAdminIII) – 「クエリー解釈」、「アナライズ解釈」は、EXPLAIN、EXPLAIN ANALYZEと同等。 Copyright 2011 Uptime Technologies LLC, All rights reserved. 14
  • 15. データアクセスのパターン • シーケンシャルアクセス – 全レコード、または多くのレコードを処理する必要がある場合 – 集約処理、LIKE文の中間一致など • ランダムアクセス – 特定のレコード(を含むブロック)だけにアクセスする必要がある場合 – 主にインデックスを用いたアクセス シーケンシャル ランダム アクセス アクセス ファイルの先頭から 順番に読み込んでいく 必要なブロックだけ ピンポイントで読み込む テーブルファイル テーブルファイル Copyright 2011 Uptime Technologies LLC, All rights reserved. 15
  • 16. テーブルスキャン SELECT count(*) FROM customer; Customer テーブルからの ブロック読込 ×214,216 Customer_pkey インデックスの ブロック読込×0 Copyright 2011 Uptime Technologies LLC, All rights reserved. 16
  • 17. テーブルスキャン cont’d • すべてのデータを確認する必要があるため、customerテー ブルファイルを構成するブロックを先頭から読み込む – よって、データが増えれば増えるほど時間がかかるようになる。 – この例では、214,216 ブロック(約1.7GB)を読んでいる。 Customer_pkeyインデックス Customerテーブル レコード1 root レコード2 レコード3 レコード4 レコード5 1~5 6~10 11~17 18~25 Copyright 2011 Uptime Technologies LLC, All rights reserved. 17
  • 18. インデックスアクセス SELECT * FROM customer c WHERE c.c_id=7; Customer テーブルからの ブロック読込×1 Customer_pkey インデックスの ブロック読込×3 Copyright 2011 Uptime Technologies LLC, All rights reserved. 18
  • 19. インデックスアクセス cont’d • “c_id=7” レコードの位置を探すため、customer_pkeyを辿っ てポインタを見つけ、レコードを含むテーブルファイルのブ ロックを読み込む。 – この例では、customer_pkeyインデックスから3ブロック、customer テーブルから1ブロックを読んでいる。 – レコードの量とディスクアクセス量が比例しない。 Customer_pkeyインデックス Customerテーブル レコード1 root レコード2 レコード3 レコード4 レコード5 1~5 6~10 11~17 18~25 Copyright 2011 Uptime Technologies LLC, All rights reserved. 19
  • 20. 結合(Nested Loop Join) • SELECT count(*) FROM orders o, customer c WHERE o.o_c_id=c.c_id AND c.c_uname=‘UL’; – customer を c_uname=‘UL’ でインデックススキャン – customer のレコードの c_id を使って orders をインデックススキャン i_c_uname customer i_o_c_id orders Copyright 2011 Uptime Technologies LLC, All rights reserved. 20
  • 21. テーブルに対する更新処理 レコード1 「レコード5」を追加 レコード1 レコード レコード2 レコード2 追加処理 レコード3 レコード3 レコード4 レコード4 (INSERT) レコード5 ファイル中に4件のレコードが 順番に並んでいる レコード5がファイル末尾に追加され、 ファイルサイズが増える 「レコード2」を削除 レコード1 レコード1 レコード レコード2 (レコード2) 削除処理 レコード3 レコード3 レコード4 レコード4 (DELETE) ファイル中に4件のレコードが レコード2に削除マークが付けられる 順番に並んでいる 「レコード2」を レコード1 「レコード2’」として更新 レコード1 レコード レコード2 (レコード2) 更新処理 レコード3 レコード3 レコード4 レコード4 (UPDATE) レコード2’ ファイル中に4件のレコードが レコード2に削除マークが付けられ、 順番に並んでいる レコード2’が新たに追加、ファイルサイズ増加 Copyright 2011 Uptime Technologies LLC, All rights reserved. 21
  • 22. タプルの更新とインデックスの更新 8.2以前 インデックス付きカラム ヒープタプル レコード1 レコード1 インデックスのない (テーブル) レコード2 カラムを更新すると・・・ (レコード2) レコード2’ エントリ1 エントリ1 インデックスサイズも インデックス エントリ2 (エントリ2) 増える エントリ2’ 8.3以降 インデックス付きカラム ヒープタプル レコード1 レコード1 (テーブル) インデックスのない レコード2 カラムを更新すると・・・ (レコード2) レコード2’ エントリ1 エントリ1 インデックスサイズは インデックス エントリ2 エントリ2 増えない インデックスの張られていないカラムを更新すると、 ヒープのみの(インデックスエントリが無い)カラムができる。 これが、HOT(Heap Only Tuple) Copyright 2011 Uptime Technologies LLC, All rights reserved. 22
  • 23. VACUUM処理 VACUUM前 VACUUM後 レコード1 レコード1 (レコード2) VACUUM処理 空き領域 VACUUM レコード3 レコード3 処理 レコード4 レコード4 レコード2’ レコード2’ レコード2に削除マークが レコード2の領域が「空き領域」として 付いている 再利用可能になる。 追記前 追記後 レコード1 レコード5を追記 レコード1 空き領域 レコード5 VACUUM レコード3 レコード3 してあると レコード4 レコード4 レコード2’ レコード2’ 「空き領域」がある ファイルサイズを変えずに追記できる レコード1 レコード1 レコード5を追記 (レコード2) (レコード2) VACUUM レコード3 レコード3 してないと レコード4 レコード4 レコード2’ レコード2’ レコード2の領域が埋まったまま レコード5 ファイルサイズが増加 Copyright 2011 Uptime Technologies LLC, All rights reserved. 23
  • 24. パフォーマンスは何で決まるか? • 「単一クエリのレスポンス×クエリの同時実行数」 – 単一クエリのレスポンス • サーバ・クライアント間通信(ネットワーク) • SQLの構文解析、最適化(CPU処理) • ロックの競合(ロック待ち、デッドロックの発生) • テーブル、インデックス、ログへのI/O量(ディスクI/O) • ソート、結合などの演算処理(CPU処理) – クエリの同時実行数 • 接続クライアント数(いわゆるWebユーザ) • コネクションプール接続数 • これらが全体としてハードウェアのキャパシティの範囲内で ある必要がある。 – ネットワーク、ディスクI/O、メモリ、CPUなどがボトルネックとなり得る。 – ただし、サーバリソースネック自体は「結果」であり、「原因」ではない。 – 「なぜ、それがボトルネックになっているのか?」が重要。 Copyright 2011 Uptime Technologies LLC, All rights reserved. 24
  • 25. パフォーマンス改善の基本手順 • 遅いSQL文を特定する or 実行回数の多いSQLを特定する – log_min_durationオプション – pgFouine • SQLの実行プランを確認する – EXPLAIN / EXPLAIN ANALYZE • 対策をする – SQL文を書き換える、インデックスを張る、テーブル設計を修正する – アプリケーションを修正する – ハードウェアを増強する – 他・・・ Copyright 2011 Uptime Technologies LLC, All rights reserved. 25
  • 26. SQLパフォーマンス分析 • pgFouineによる問題SQL文の抽出 – 総実行時間=レスポンスタイム(実行時間)×実行回数 – 最長レスポンスタイム – 他・・・ Copyright 2011 Uptime Technologies LLC, All rights reserved. 26
  • 27. バックアップ • バックアップの難しさ – データはファイルの中にだけあるのではない! – 通常は、共有バッファの内容が最新 – ファイルだけバックアップを取ってもダメ – ミリ秒単位で処理が進む中、すべてを一貫性を保った状態で • バックアップの種類 – コールドバックアップ – ホットバックアップ – アーカイブログバックアップ • バックアップ&リカバリはリハーサルをしよう! – 簡単な試験や手順書を作るだけで満足してはいけない・・・ Copyright 2011 Uptime Technologies LLC, All rights reserved. 27
  • 28. コールドバックアップ • サーバプロセスをすべてシャットダウンしてデータファイル全体をバック アップ – バックアップの間、サービス停止が発生する。 – リカバリの際には、バックアップ時のデータに戻る。 • 利用ケース – 前回バックアップ以降の更新データを復旧できる場合。 – ストレージスナップショットが一般化した今、案外現実的。 Crash ①ファイルを WAL1 WAL2 WAL3 ②障害発生 バックアップ (サービス中断) ③レストア Index Table Copyright 2011 Uptime Technologies LLC, All rights reserved. 28
  • 29. ホットバックアップ(pg_dump) • あるタイミングでデータの一貫性を保ちつつバックアップ – シンプルかつ柔軟(テーブル単位のバックアップも可) – バックアップ時にサービス停止は起こらない。 – リカバリの際には、バックアップ時のデータに戻る。 • 利用ケース – 前回バックアップ以降の更新データを復旧できる場合。 – データベース単位、テーブル単位でバックアップを取りたい場合。 – 論理バックアップが必要な場合(メジャーバージョンアップなど) Crash WAL1 WAL2 WAL3 ①pg_dumpで ②障害発生 スナップショットを バックアップ ③レストア Index Table Copyright 2011 Uptime Technologies LLC, All rights reserved. 29
  • 30. アーカイブログとPITRを用いたバックアップ • ベースバックアップ(基準点)+アーカイブログ(更新差分) – サービスを継続したままベースバックアップを取得可能 – クラッシュ直前のWALの内容まで復旧することが可能 • 利用ケース – データベースクラスタ全体の完全なバックアップを取りたい場合。 – クラッシュ直前の更新まで復旧させる必要がある場合。 Crash WAL1 WAL2 WAL3 ①ベースバック アップの取得 ②WAL1を ③WAL2を ④WAL3を アーカイブ アーカイブ アーカイブ Index WAL1 WAL2 WAL3 Table PITRに必要なファイル類 Copyright 2011 Uptime Technologies LLC, All rights reserved. 30
  • 31. アーカイブログとPITRを用いたリカバリ • ベースバックアップ(基準点)+アーカイブログ(更新差分) – 前回のベースバックアップ以降、長期間が経過しているとアーカイブログが 多くなり、リカバリの時間が長くなる。 – ベースバックアップレストア時間+アーカイブログ適用時間×アーカイブログ 数 WAL3適用完了 リカバリ完了 WAL1 WAL2 WAL3 ①ベースバック アップを展開 ②WAL1を ③WAL2を ④WAL3を 適用 適用 適用 Index WAL1 WAL2 WAL3 Table Copyright 2011 Uptime Technologies LLC, All rights reserved. 31
  • 32. 冗長化方式の選定 • 実現方式を評価するに当たって特に重視すべき点 – 負荷分散の必要性の有無。 – 単一障害点(Single Point of Failure、SPoF)の有無。 – 運用が容易であるかどうか(運用の作業負荷、ノウハウの蓄積)。 – データ一貫性の厳密性(レプリケーション遅延)の程度。 実現方式 アーキテクチャ 負荷分散 同期遅延 運用性 備考 アーカイブログ転送 アクティブ/スタンバイ × 数十秒 ◎ ウォームスタンバイ方式。 ~数分 DRBDディスク同期 アクティブ/スタンバイ × なし △ 要DRBD運用ノウハウ。 共有ディスク方式 アクティブ/スタンバイ × なし △ 共有ディスクが高価でSPOF。 Slony-Iレプリケー アクティブ/アクティブ、 ○ 数秒 △ 公開されているSlony-Iの運用ノウハ ション マスター/スレーブ ウが少ない。バージョン混在可。 pgpool-II アクティブ/アクティブ、 ○ なし ○ pgpoolサーバがSPOF(冗長化可)。 マスター/スレーブ 一部、APへの影響有り(now()等)。 ストリーミング・レプリ アクティブ/アクティブ、 ○ 数百ms △ 公開されている運用ノウハウが少な ケーション(9.0~) マスター/スレーブ い。 Copyright 2011 Uptime Technologies LLC, All rights reserved. 32
  • 33. 冗長化方式の選定 cont’d • PostgreSQLの代表的な冗長化方式の構成は以下の通り。 – シンプルな冗長化のみで良い場合は共有ディスク方式。 – スケールアウトが必要な場合は pgpool か Slony-I。 – 9.0以降はストリーミングレプリケーション(SR+HS)構成が可能。 共有ディスク方式 pgpool方式 SR+HS方式 Web/APサーバ Web/APサーバ Web/APサーバ Web/APサーバ Web/APサーバ Web/APサーバ 読み書き 読み込み可 不可 pgpoolサーバ マスタDB スレーブDB マスタDB スレーブDB SQL転送 ログ(レコード)転送 マスタDB スレーブDB 共有ストレージ Copyright 2011 Uptime Technologies LLC, All rights reserved. 33
  • 34. 参考文献 • 書籍・雑誌 – WEB+DB PRESS vol.32~37 「PostgreSQL安定運用のコツ」 (技術評論社) – データベースパフォーマンスアップの教科書 基本原理編 (翔泳社) • オンラインドキュメント類 – PostgreSQL 9.0.2文書 http://www.postgresql.jp/document/pg902doc/html/index.html – Explaining Explain ~ PostgreSQLの実行計画を読む ~ (PDF版) http://lets.postgresql.jp/documents/technical/query_tuning/explaining_explain_ja.pdf – HOTの仕組み (1) - Let's Postgres http://lets.postgresql.jp/documents/tutorial/hot_2/ – ソーシャルゲームのためのデータベース設計 http://www.slideshare.net/matsunobu/ss-6584540 Copyright 2011 Uptime Technologies LLC, All rights reserved. 34