ラベル Performance の投稿を表示しています。 すべての投稿を表示
ラベル Performance の投稿を表示しています。 すべての投稿を表示

2019年12月1日

Jupyter+Pandasを使ったPostgreSQLパフォーマンス分析

本記事は PostgreSQL Advent Calendar 2019 の1日目の記事です。初日から遅れ気味ですすみません。。

久しぶりの記事ですが、最近はPostgreSQLをゴリゴリと触る感じでもなくなってきているため、本記事もゆるめの感じでお送りしたいと思います。

■PostgreSQLの「パフォーマンス分析」とは


PostgreSQLのパフォーマンス分析は、ざっくり言って、以下のようなステップで進められます。(PostgreSQLには限らないと思いますが)
  • パフォーマンスの状況から、課題について仮説を設定する。
  • パフォーマンスに関連する何の情報を収集するかを決める。
  • 情報を収集する。
  • 収集した情報を加工し、分析しやすい形式に整える。
  • 分析し、仮説を検証、ないしは何かを発見する。
  • より深堀り、確証を高めるために、再度情報集をしたり、データを加工、分析したりする。
  • 何か対策を打って、その結果を再度分析して、従前と比較する。
ある程度PostgreSQLに詳しい人は、「仮説の設定」や「どこから情報を取得するか」はさくっと決められると思いますが、情報を収集したり分析に適した形に加工したりするのはそれなりの手間と時間がかかるものです。

しかも、ある程度探索的な分析を行わざるを得ないため、データやグラフの形式を最初から決めておいたとしても、パフォーマンス分析がディープになればなるほど、それが現実的に役に立つかどうかは微妙になっていきます。(なので、最終的には、あらゆるグラフを網羅的に出力するレポートを作成する羽目になります)

そのため「Excel最強説」が流れるわけですが、再現可能性や繰り返しの作業についてはやはりいろいろと難がありますので、スクリプトで処理したくなってきます。

■「Jupyter + Pandas」を使ってパフォーマンス分析


2018年12月24日

カラムナーDB拡張 cstore_fdw とその性能評価

本エントリは PostgreSQL Advent Calendar 2018 の Day24 の記事です。

昨日の記事は @kabaome さんによる 拡張統計情報とテーブル結合 でした。

本エントリでは、PostgreSQLのカラムナーDB拡張である cstore_fdw について、その基本的な使い方から、 DBT-3 のスキーマとクエリを使ってベンチマークをしてみた結果を解説してみます。

とは言え、私自身、cstore_fdw をそれなりに使ったのはこれが初めてですので、あまり深く踏み込めていないところもあるかと思いますが、そういったところがありましたら、コメント欄や Twitter などで補足いただけると助かります。

■cstore_fdw とは


cstore_fdw は Citus Data によって開発されているオープンソースの PostgreSQL 拡張で、PostgreSQL 本体に手を加えなくてもカラムストア型(カラムナー型)の備えたテーブルを利用することができるようになるものです。
cstore_fdw では、テーブルを外部テーブルとして定義することによって、 PostgreSQL のオリジナルのストレージ構造をバイパスして、独自のストレージフォーマットを持つテーブルを保持することができるようになっています。

2018年4月23日

この連休の読書にオススメの一冊「SQLパフォーマンス詳解」(割引コードあり)

最近、久しぶりにPostgreSQLのクエリチューニングをしていたのですが、その過程で「この本はぜひもっと多くの人に読んでもらいたい」と改めて思い出した一冊がありました。

それは、「SQLパフォーマンス詳解(原題:SQL Performance Explained)」という本です。
パフォーマンスチューニング、特にクエリチューニングについて説明する場合、その前提となる知識は広範なものになります。

そのため、自分が頑張って説明するよりも、優れたエキスパートのまとめたコンテンツを活用させてもらう方が、質・量ともに優れたインプットにしていただけるのではないか、と思うのです。

また、この「SQLパフォーマンス詳解」は非常に良い本であるにも関わらず、一般の出版社から出ているわけではないため、それほど積極的にプロモーションされているわけではなく、日本語版についても、(残念ながら)一般的な書籍ほど話題になることが無いように思います。

そういった理由により、本エントリではこの本について皆さんに知っていただくべくご紹介するとともに、著者のMarkus Winand氏から日本の読者の皆さんに「最大で半額」となる割引コードを提供いただけることになりましたので、その使い方についてご紹介したいと思います。

ゴールデンウィーク直前ですが、ぜひ連休中に読む一冊に加えていただければと思います。データベースのパフォーマンスについて、網羅的かつ本質的な理解が深まること、間違いのない一冊です。

■著者のMarkus Winand氏について


著者のMarkus Winand氏は、PostgreSQLを始めとするRDBMSのチューニングのエキスパート/コンサルタントとして有名な方で、「Use the Index, Luke!」というブログでお馴染みです。

2017年11月28日

[翻訳] たった一つの設定変更が如何にしてクエリのパフォーマンスを50倍も改善したか (How a single PostgreSQL config change improved slow query performance by 50x)

先日、「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
■たった一つの設定変更が如何にしてクエリのパフォーマンスを50倍も改善したか


Pavan Patibandla

At Amplitude, our goal is to provide easy-to-use interactive product analytics, so everyone can find answers to their product questions. In order to provide a great user experience, Amplitude needs to provide these answers quickly. So when one of our customers complained about how long it took to load the event properties dropdown in the Amplitude UI, we started digging into it.

Amplitudeでの我々のゴールは、簡単に使えるインタラクティブなプロダクト分析を提供することです。それによって、すべての人が自分たちのプロダクトについての疑問の答えを得ることができるようになります。素晴らしいユーザエクスペリエンスを提供するために、Amplitudeは答えを迅速に提供する必要があります。ある顧客から Amplitude UI でイベントプロパティのドロップダウンリストのロードに時間がかかると苦情が来たため、その調査を開始しました。

2016年8月4日

【翻訳】 On Uber’s Choice of Databases (データベースにおけるUberの選択について)

数日前、Uberのブログで「Why Uber Engineering Switched from Postgres to MySQL」というエントリが公開されました。
それに対して、PostgreSQLコミュニティ界隈でもいろいろなブログエントリが公開されました。
今回は、そのエントリの中でも、「Use The Index, Luke!」でおなじみのMarkus Winand氏のエントリ「On Uber’s Choice of Databases」が個人的に興味深かったので、同氏の翻訳許可をいただきまして、ここに対訳形式で公開します。

なお、当然ですが翻訳に際しての文責は翻訳者である永安にありますので、問題を見つけた場合にはコメント欄またはTwitter (@snaga)などで連絡いただけますと幸いです。

では、どうぞ。


■On Uber’s Choice of Databases (データベースにおけるUberの選択について)


On 7-29-2016
By Markus Winand

2016年3月6日

パラレルスキャンのスケーラビリティ調査とFlame Graphsによるプロファイリング可視化

先月、弊社にデータベース系の研究をしていた中国人留学生がインターンに来ており、その彼にお願いしてPostgreSQLのパラレルクエリのスケーラビリティの調査と、プロファイリング+可視化のツールとしてFlameGraphを使ってもらいました。

大学のスケジュールの関係上、インターンの期間が急遽、3週間から2週間に短縮されてしまったため、結果をきちんとまとめたり追試をしたりといったところまでは到達できなかったのですが、個人的にもそれなりに面白いアウトプットになったと思いますので、簡単にご紹介したいと思います。

なお、細かい手順の詳細などは、インターンに参加していた学生さんのGithubにまとまっています。参考文献に載せておきますので、興味のある方はそちらも参照してください。(本テストと直接関係のない内容も含まれています)

■テストの背景


PostgreSQLの9.6develにパラレルシーケンシャルスキャンが実装されたのは、みなさんご承知のことと思います。

2015年12月1日

PostgreSQL 9.6のパラレルシーケンシャルスキャンを検証する

今年もこの季節になりました。PostgreSQL Advent Calendar 2015のDay1の記事です。

今回は、現在開発中のPostgreSQL 9.6に実装されたパラレルシーケンシャルスキャンについて、動作確認とフラッシュストレージでの簡単な性能検証をしてみようと思います。

なお、現在開発中の機能ですので、正式リリースされる時には仕様や動作などが変わっている可能性があることをご了承ください。

■「パラレルシーケンシャルスキャン」とは


「パラレルシーケンシャルスキャン」は、その名の通り、シーケンシャルスキャンを並列処理する機能です。

今まで、PostgreSQLでは1つのCPUを使ってシングルスレッド(というかプロセス)でしか処理をすることができませんでした。

しかし、直近のPostgreSQLのメジャーバージョンの拡張を見ていた方はご存じの通り、PostgreSQLではパラレル処理に向けての基本的な機能(開発者たちは infrastructure と呼んでいますが)が少しずつ実装されてきました。

そして、先月、PostgreSQLの待望のパラレル処理の一つ目の機能として、パラレルシーケンシャルスキャンがGitの最新版のコードにコミットされました。
このコードツリーは「9.6devel」と呼ばれており、約1年後にリリースされる予定のメジャーバージョン9.6から利用できるようになる予定です。

2013年12月15日

【9.3新機能チェック】データチェックサムの機能とパフォーマンスへの影響

このエントリは、PostgreSQL Advent Calendar 2013のDay15の記事です。

データベース管理システムにとって、「データを保護する」というのは非常に重要な役割のひとつです。

PostgreSQLには、9.3から「データチェックサム」という機能が追加されました。これは、ハードウェア障害などによってデータが壊れた時に、そのことを極力早期に検出しよう、という仕組みです。

今回は、このデータチェックサムについて、その仕組みと使い方、性能への影響について紹介します。

■「データチェックサム」とは

「データチェックサム」というのは、PostgreSQLのデータブロック内のデータのチェックサムのことで、PostgreSQLのデータブロックの中身が万が一壊れた時に、早期に検出できるようにするための仕組みです。

9.2まではこの機能が無かったため、「(メモリやディスク不良が起因で)データブロックの中身が壊れていることにかなり後になって気付く」ということもありました。

2013年12月3日

Apache JMeterでPostgreSQLの負荷試験をする

このエントリは、PostgreSQL Advent Calendar 2013のDay3の記事です。

「データベースの負荷試験」を考える時、皆さんはどのような方法で実施することを検討するでしょうか。自前のテストスクリプトでしょうか。あるいは、データベース単体の負荷試験は行わず、Webシステム全体の負荷試験として実施するでしょうか。

PostgreSQLには、pgbenchというベンチマークツールが付属しており、このツールのシナリオを作成することで多少は独自のシナリオでの試験を行うことも可能ですが、状況によってはそれだけでは自由度が不足することがあります。

今回は、Webシステムの負荷テストでよく使われるJMeterを使って、自由なシナリオでPostgreSQL単体の負荷試験を行う方法を紹介します。

(なお、JMeterは非常に多機能な負荷生成ツールですので、今回はJMeterの網羅的な説明ではなく、あくまでもPostgreSQLのテストをする際の観点に絞って紹介します。JMeterの詳細については、他の情報を参考にしてください)

■事前準備

事前準備として、以下のインストール、設定を行う必要があります。
  • Java SE
  • Apache JMeter
  • PostgreSQL JDBCドライバ
  • PostgreSQL
今回は、Java SEとPostgreSQLそのもののインストールについては割愛します。

2013年3月4日

【9.3新機能チェック】マテリアライズドビューを試してみる

昨日、PostgreSQLの次期リリースである9.3のソースコードに、マテリアライズドビューのコードが追加されました。

pgsql: Add a materialized view relations.
http://www.postgresql.org/message-id/[email protected]

PostgreSQLの開発者Wikiによると、マテリアライズドビューはもっとも要望の多かった機能のようです。

Materialized Views - PostgreSQL wiki
http://wiki.postgresql.org/wiki/Materialized_Views

今回は、このマテリアライズドビューがどのようなものなのか、そしてどのように使えるのかを見てみます。

■マテリアライズドビューとは


「マテリアライズドビュー」とは、特に集約や集計系の処理をする際に使われる機能で、ビューから取得できるデータの実体を持つ(materialized)ビューです。

通常、ビューというのは「見え方を定義する」だけですので、ビューに対する参照処理を行うと、その都度、元のテーブルに対してSQLの参照処理が行われることになります。

2013年2月19日

【資料公開】「“今そこにある危機”を捉える ~ pg_stat_statements revisited」

2013年2月16日に開催された「PostgreSQLアンカンファレンス」でのセッション「“今そこにある危機”を捉える ~ pg_stat_statements revisited」で使ったスライドを公開しました。

SQLのパフォーマンス分析、チューニングに今や不可欠なpg_stat_statementsビューの使い方を簡単に解説した資料です。


当日、セッションに参加している方に聞いてみたら、「pg_stat_statementsを知らなかった」とか「知っていたけど使ったことがなかった」という方も多くいましたので、改めてぜひ見てみていただければと思います。

資料の中で便利スクリプトも紹介していますので、そちらも併せてどうぞ。

※関連エントリ
実行が遅いSQL文をpg_stat_statementsで抽出する

2012年12月22日

データブロックサイズの変更と分析系クエリへの性能影響(SSD編)

PostgreSQL Advent Calendar 2012(全部俺)のDay 22です。

最近、PostgreSQL上でデータ分析処理をよく行うようになってきました。また、いろいろなところでSSDも使うようになってきました。

PostgreSQLとデータ分析とSSD、という組合せを考えた時、どのようにチューニングするのが望ましいのか、あるいはどのようなチューニングができるのか、個人的にはまだまだ試行錯誤中だったりします。

SSDはハードディスクと比べてブロックサイズが大きいという特徴があります。また、DWH系のデータベースでは大きいブロックサイズを使うとパフォーマンス上のメリットがある、と言われています。

今回は、SSD上でPostgreSQLを使ってデータ分析系の処理を行う時に、データブロックのサイズを変えるとクエリのパフォーマンスにどのような影響を与えるのか、実際にクエリを実行しながら見ていきます。

■ブロックサイズの変更方法と確認方法


PostgreSQLでデータブロックのサイズを変更するには、PostgreSQLのブログラムバイナリをビルドする際にブロックサイズを指定する必要があります。

具体的にはconfigureスクリプトのオプションに--with-blocksizeというオプションを与えて、ここでブロックサイズを指定します。

2012年12月4日

pgBadgerでSQLログを分析する

PostgreSQL Advent Calendar 2012(全部俺)のDay 4です。

負荷試験や本番稼働中のデータベースサーバでは、通常さまざまな種類のSQLが実行されています。

昨日紹介したpg_stat_statmentsシステムビューは、PostgreSQLの内部でSQLの実行状況を積算することのできるモジュールでしたが、「pg_stat_statementsを使うには制約が・・・」というケースもあるでしょう。

PostgreSQLには実行しているSQL文をサーバログに出力する機能があります。SQL文だけでなく実行時間なども出力することができるため、このサーバログを集計することによって、どのようなSQLがどれくらい実行されていて、どのSQLにパフォーマンス上の問題がありそうなのか、といったことを絞り込んでいくことができます。

■SQLログ解析ツール「pgBadger」


サーバログを集計するツールとしてはいくつかあるのですが、今日は「pgBadger」というツールを紹介します。

pgBadger
http://dalibo.github.com/pgbadger/

2012年12月3日

実行が遅いSQL文をpg_stat_statementsで抽出する

PostgreSQL Advent Calendar 2012(全部俺)のDay 3です。

3日目となる今回はSQL文の実行状況を解析するツールとしてpg_stat_statementsを使ってみます。

■SQLパフォーマンスをどのように分析するか


特定のSQL文が遅いことが判明している場合は別ですが、通常、SQLのパフォーマンス分析を行う場合には、「どのSQL文が問題なのか」というところから調査します。その時の判断の軸としては、主に以下の2つがあります。

・実行回数の多いSQL文
・実行時間の長いSQL文

特定のSQL文を修正して得られるパフォーマンス向上の成果は、

・1つのSQL文の改善量×実行回数

となります。

例えば、1回実行するのに1秒かかるSQL文を1万回実行すると、トータルで1万秒となりますが、一回あたりの実行時間を0.5秒に短縮できればトータルの実行時間としては1万秒から5000秒に短縮されることになります。

このようにして、「クエリ1回の実行時間×クエリの実行回数」の大きいものから改善してくと、SQLチューニングに投入する費用対効果(時間も含む)が高くなります。