Amazon Web Services ブログ

Category: PostgreSQL compatible

PostgreSQL 11 の新機能を詳しくご紹介

初期のPostgreSQL プロジェクトは 1986 年に大学のプロジェクトとしてスタートしました。1996 年に PostgreSQL プロジェクトはオープンソースコミュニティが引き継ぎ、毎年メジャーバージョンを定期的にリリースしています。ソフトウェアの複雑さを考えると、このような早急なリリーススケジュールには、主要な機能を小さく基本的な要素に分割する必要があります。こうした小規模で基本的な機能を組み合わせることで、最新リリースの PostgreSQL 11 を含む PostgreSQL のすべてのメジャーリリースが行われています。PostgreSQL 11 は、Amazon RDS for PostgreSQL および PostgreSQL と互換性のある Amazon Aurora の両方に対応しています。 この記事では、パーティション分割、並列処理、ジャストインタイム (JIT) コンパイルという、PostgreSQL 11 の 3 つの素晴らしい機能について詳しく説明します。複数の PostgreSQL バージョンにおけるこれらの機能の進化について調べます。また、PostgreSQL 11 が提供する利点についても説明し、これらの機能をアプリケーションに適合させる方法を説明する実用的な例を示します。 パーティション分割 データベースが成長するにつれ、少数のテーブルが通常は成長の主な原因となっています。成長は、すべてのアクティビティの履歴ログを保持するテーブルや、ユーザーテーブルに集中する場合があります。 テーブルのパーティション分割により、データベースの大幅な成長に対処できます。つまり、単一の大きなテーブルをより小さく管理しやすいチャンク (パーティション) に分割することで、大きなテーブルでのクエリを高速化します。クエリの実行中にデータベースがパーティション全体を除外できると、処理するデータが大幅に減るため、パフォーマンスが向上します。テーブルを分割するという概念は PostgreSQL 11 の新機能ではありません。PostgreSQL では、2005 年リリースのバージョン 8.1 において最初にテーブルのパーティション分割という形式を導入しました。 以下の orders テーブルを例に考えてみましょう。アプリケーションは、販売注文がある度に新しい行をこのテーブルに追加します。注文が多くなるにつれ、このテーブルは日ごとに大きくなります。このように時間の流れと共に成長するテーブルには、時間に基づくパーティション分割が基本的に使われます。 CREATE TABLE orders ( o_orderkey INTEGER, […]

Read More

Amazon Aurora PostgreSQL から通知を送信する

企業のお客様は、Amazon Aurora PostgreSQL データベースで多くの日々のバッチジョブを実行し、そのようなジョブを完了した後にアクティビティを追跡するためにメールやテキストなどの通知方法が必要です。Aurora PostgreSQL はマネージドサービスであるため、セキュリティ上の理由から pgsmtp や pgplpythonu などのデータベース拡張機能へのアクセスを制限しています。これにより、他の自動メッセージングの手段で通知を送信するデータベースの必要性が高まります。 この記事では、組織が定期的にビジネス検証のために従業員の情報をプルし、ジョブの完了後に通知を必要とするシナリオを使用します。この記事では、Python を使用してサンプルジョブを作成し、AWS Lambda と Amazon SNS を使用して、E メールまたはテキストメッセージで通知する方法を示します。 前提条件 このソリューションには以下が必要です。 適切な AWS のサービスにアクセスできる有効な AWS アカウント。 Aurora PostgreSQL データベース。詳細については、「Amazon Aurora DB クラスターの作成」を参照してください。 VPC の外部に通知を送信するための、SNS の VPC エンドポイント。詳細については、「Amazon SNS の Amazon VPC エンドポイントの作成」を参照してください。 データベースに接続するための pgadmin または PSQL Client ツールなどのクライアントツール。 AWS Secret Manager にすでに設定および保存されているデータベースパスワード。詳細については、「AWS Secrets Manager とは」を参照してください ソリューションアーキテクチャ […]

Read More

AWS SCT および AWS DMS を使用した移行後のデータベースオブジェクトの検証

データベースの移行は複雑なタスクになりかねません。移行には、ソフトウェアプラットフォームの変更、ソースデータの複雑性の把握、データ損失チェック、既存機能の詳細なテスト、アプリケーションパフォーマンスの比較、およびデータの検証といったあらゆる課題が伴います。 AWS では、移行前チェックリストと移行評価を提供するツールとサービスをいくつかご用意しています。AWS Schema Conversion Tool (AWS SCT) は、既存のデータベーススキーマをひとつのデータベースエンジンから別のデータベースエンジンに変換するために使用できます。AWS Database Migration Service (AWS DMS) は、リレーショナルデータベース、データウェアハウス、NoSQL データベース、およびその他のタイプのデータストアの移行を容易にしてくれます。AWS DMS は、AWS クラウドへのデータの移行、またはオンプレミスインスタンス間 (AWS クラウドセットアップ経由)、クラウドとオンプレミスセットアップとの組み合わせの間でのデータの移行に使用できます。 さらに、AWS はデータベース移行の全体を通じてユーザーをガイドする幅広いドキュメントも提供しています。詳細については、「Oracle データベースの PostgreSQL への移行」を参照してください。 AWS SCT は、スキーマオブジェクトを変換するために役立ち、AWS SCT が PostgreSQL に変換した Oracle コードの割合と、手動で変換する必要があるコードの量を示すレポートを構築します。データベースオブジェクトの移行中は常に、ターゲットデータベースでオブジェクトが欠落している、新しいオブジェクトを作成する、またはソースオブジェクト全体を意図的に無視する可能性のリスクがあります。検証は、移行対象のすべてが正常に移行されたことを顧客に証明するプロセスです。 この記事は、データベースオブジェクトの移行とコードの変換の完了後に、ソース Oracle データベースと PostgreSQL ターゲット間でオブジェクトを検証する方法の概要を説明します。 オブジェクトの検証 問題になるのは、何を検証するかということです。 これを理解するためには、Oracle データベースオブジェクトの異なるタイプと、それらに相当する PostgreSQL データベースオブジェクトのタイプを知っておく必要があります。 以下の表は、Oracle (ソース) データベースのオブジェクトと、対応する PostgreSQL (ターゲット) のオブジェクトのタイプを示しています。DB 変換が正常に行われたことを確認するには、これらのオブジェクトを詳細に検証しなければなりません。 Oracle オブジェクト […]

Read More

Aurora PostgreSQL ストレージの I/O コストを削減

多くの企業における IT 部門では、オンプレミスのワークロードをクラウドに移行することの最大の理由の 1 つがコスト削減となっています。今回の記事では、コスト管理についての実例を、Amazon Aurora PostgreSQL のチューニングに着目しながらご紹介していきます。 ヒストリー 私は最近、当社の自動車向けテレマティクスアプリケーションの、AWS への実装作業を指揮するという機会に恵まれました。少し説明しますと、テレマティクスアプリケーションとは、データ提供者から運転データをストリーミングで受信するものです。このデータは、検証、修正、および正規化されます。そして、処理に合わせた変換が行われた後、専用のスコアリングアルゴリズムを用いて、ドライバーの点数付け計算に使われます。このプロジェクトには、次に示す主要な目的がありました。 高い可用性 (HA) の実現 (99.999%) 。 レスポンスタイプは、数ミリ秒台という高いパフォーマンスの実現。 現状の TCO をその何割かまでに削減する。これには、人的および設備的なリソースの削減も含まれます。 実際の使用量を反映した、従量課金制の支払に移行する。 国や地域を問わず、デプロイと新規顧客の受け入れを容易にする。 規模の拡大と需要変動に適応できる、スケーラビリティと伸縮性の獲得。 コストと HA での目標を達成するため、アプリケーションはサーバーレス/マネージド型のアーキテクチャを用いて、ゼロから再設計と再コーディングが行われました。これにより、保守に必要なリソースの最小化と従量課金制の利用がはかられましたこの再設計は、ほとんどの目的を達成し大きな成功となりましたが、コストだけに問題が残りました。オンプレミスに比べればコスト削減ができたものの、依然として想定した金額の 3 倍の金額になってしまったのです。 概要 他のどの変更作業と同様に、オンプレミスから AWS への移行要素には、次の 3 つが含まれます。 人材 処理 テクノロジー 個人的には、人材の要素がキーになると思います。オンプレミス環境とは違い、AWS でのインフラストラクチャーのコストは、いわゆる埋没費用ではありません。AWS での運用コストは、サービス利用量をベースに変化するからです。この利用量には、サービスの実行/経過時間だけでなく、メモリー、ストレージ、I/O といった、サービス毎に違いがうまれるものの利用も含まれます。AWS での課金手法になじむには、少し時間がかかることもあります。作業の工程の見直しやサービスの自動化は、AWS の環境が提供するメリットを活用するための重要なポイントです。 AWS を利用する上でのコスト削減の取り組みは、次のようなステップにグループ分けされます。 AWS のコストを理解する: まず始めに、請求管理ダッシュボードの使用になれることです。それぞれのサービスが、AWS のコストにどの程度影響しているかを理解します。タスクを優先付けするために、まず上位 3 つの高コスト要件に取り組みます。また最終的には、これらの検証がコスト面での重要性だけでなく、セキュリティーの抜け道を洗い出す目的にも重要となります。 ハウスキーピング: サーバーレスでマネージド型のサービスに移行するからといって、データのクリーニングやアプリケーションの保守のためにオンプレミスで行ったベストプラクティスが完全に不要になるわけではありません。むしろ、そういった作業はより厳格に行う必要が生まれます。 アプリケーションとサービスの低い機能を特定し調整します。 詳細情報 […]

Read More

ネイティブツールと外部ツールに基づいた Amazon RDS PostgreSQL のクエリの最適化とチューニング

PostgreSQL は最も人気のあるオープンソースのリレーショナルデータベースシステムの 1 つです。30年以上の開発作業の成果である PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。Oracle などの商用データベースから移行する場合、PostgreSQL はオープンソースデータベースの主要な選択肢と見なされています。 AWS は、PostgreSQL データベースのデプロイを、コスト効率の良い方法でクラウドに簡単にセットアップ、管理、およびスケールできるサービスを提供しています。これらのサービスは、Amazon RDS for PostgreSQL および PostgreSQL と互換性のある Amazon Aurora です。 データベースのパフォーマンスは、アプリケーションレベルの多くの要因、および CPU やメモリなどのハードウェアに依存しています。この記事では、主要なパフォーマンス要因の 1 つであるクエリパフォーマンスを取り扱います。クエリの遅延は、ほとんどの環境で一般的に見られる問題です。この記事では以下について説明します。 ネイティブデータベースツールを使用して、どのクエリが遅いかを見つける方法。 Amazon RDS Performance Insights を使用してパフォーマンスの問題を見つける方法。 遅いクエリを修正する方法。 RDS および Amazon Aurora PostgreSQL 環境を管理する開発者と DBA にとって、遅いクエリを特定し、パフォーマンスを向上させるためのチューニングは重要なタスクです。 PostgreSQL には、人気のある pgBadger など、遅いクエリを識別するためのツールが多数用意されています。pgBadger は、PostgreSQL ログファイルからの完全なレポートを使用して速度を上げるために構築された PostgreSQL ログアナライザーです。これは、他の PostgreSQL ログアナライザーよりも優れた小さな Perl スクリプトです。このツールを使用してレポートを生成するには、それに応じてログレベルを設定する必要があります。 次の論理図は、pgBadger の使用方法を示しています。PostgreSQL ログをダウンロードして […]

Read More

Amazon Aurora PostgreSQL でのクエリ計画管理のユースケース

このブログの投稿は一連の投稿の 2 回目です。前回のブログ記事では、SQL ステートメントの実行計画に回帰を引き起こす可能性があるその他の変更の中で、安定かつ一貫したデータベースパフォーマンスの必要性について説明しました。また、PostgreSQL と互換性のある Amazon Aurora のクエリ計画管理 (QPM) が、計画安定性と計画適応性の問題を克服できるようにする方法も述べています。 この記事では、引き続き Aurora PostgreSQL QPM の機能について説明します。特に、これらの機能によって、さまざまな高度なユースケースに対して計画安定性と適応性を実現する方法についてお話します。 ユースケース #1: QPM 手動取得による計画安定性と適応性の支援 最初のユースケースでは、QPM が計画安定性を確保する方法について例を挙げて説明します。次に、前回の記事 Aurora PostgreSQL クエリ計画管理の概要で説明した変更を行います。QPM を使用しない場合は、これらの変更により計画の回帰が生じる可能性があります。 ほとんどの場合、自動計画取り込みを使用するように QPM を設定して、2 回以上実行されるすべてのステートメントを取得することもできます。ただし、手動で指定した特定のステートメントセットの計画を取得することもできます。そのためには、デフォルトに capture_plan_baselines = off を設定します。セッションレベルでは、capture_plan_baselines = manual を設定します。設定の仕方については後で説明します。 手動計画取り込みを有効にして、目的の SQL ステートメントの実行計画を手動で取得するように QPM に指示します。 pg105db=> SET apg_plan_mgmt.capture_plan_baselines = manual; SET QPM がクエリ計画を取得できるように、クエリ説明計画を実行します (説明計画の以下の出力は、簡潔にするために省略されています)。 pg105db=> explain (hashes true) SELECT […]

Read More

Aurora PostgreSQL クエリ計画管理の概要

すべての AWS サービスと同様に、Amazon Aurora PostgreSQL のロードマップは、主にお客様のご意見と製品強化のご要望によって推進されます。Oracle と Microsoft SQL Server から Amazon Aurora にデータベースを移行した、複数の企業お客様からいただいたフィードバックは、2 つの点を示唆しています。重要なアプリケーションのデータベースワークロードを実行する企業は、最適なデータベースパフォーマンスを必要とします。また、企業には Aurora PostgreSQL と互換性のあるデータベースでさまざまなシステム変更を行っても、安定かつ一貫性を保つパフォーマンスが必要です。 PostgreSQL データベースのパフォーマンスが変動する主な原因の 1 つはチェックポイントプロセスにあります。多くの場合、パフォーマンスと回復性の間のトレードオフのことです。Aurora PostgreSQL では、データベースのチェックポイントを排除することでこの問題に対処してきました。ログ記録とストレージレイヤーを切り離すために、ログベースのストレージサブシステムを実装します。応答時間が変動するもう 1 つの主な原因は、クエリ計画の不安定性によるものです。クエリ実行計画を予期せずに変更する、さまざまな要因があります。以下に例を挙げます。 オプティマイザ統計の変更 (手動または自動) クエリ計画設定のパラメータに対する変更 新しいインデックスの追加など、スキーマに対する変更 クエリで使用されるバインド変数に対する変更 PostgreSQL データベースバージョンへのマイナーバージョンまたはメジャーバージョンのアップグレード。PostgreSQL 9.6.x から 10.x など クエリ計画管理 Aurora PostgreSQL クエリ計画管理 (QPM) 機能は、データベースユーザーが一連の管理 SQL ステートメントに対して安定かつ最適なパフォーマンスを維持できるようにすることで、計画不安定性の問題を解決します。QPM では主に 2 つの目的を果たすことができます。 計画安定性。システムに上記の変更が発生した場合、QPM は計画の回帰が生じないようにして、計画安定性を向上させます。 計画適応性。QPM は、新しい最小費用計画を自動的に検出し、新しい計画が使用されるときに制御し、その変更に適応します。 QPM の仕組み 以下のフローチャートは、QPM […]

Read More

2018 年に最もよく読まれた AWS データベースブログ

この記事では、私たちが 2018 年に掲載した AWS データブログ記事で、最もよく読まれた10本を紹介しています。このリストをガイドとして使って、まだ読んでいないデータベースブログに目を通す、または特に有益だと思った記事を読み返すことができます。

Read More

Oracle から PostgreSQL へ移行する際に、よく直面する課題を解決する方法

企業は年々データが急激に増加するのを目の当たりにしています。データベースとハードウェアインフラストラクチャをスケーリングし続けることは、ますます困難になっています。ワークロードが非リレーショナルデータストアに適していない場合に、基盤となるインフラストラクチャの管理に膨大な費用を費やすことなく、スケーリングの課題をどのように克服したらいいでしょうか? Amazon RDS for PostgreSQL と Amazon Aurora with PostgreSQL により、コスト効率の高い方法で PostgreSQL クラウドのデプロイを簡単にセットアップ、運用、拡張することができます。昨年、私たちは (数百 GB から数 TB に及ぶ) 100 を超える Oracle データベースを Amazon Aurora PostgreSQL と Amazon RDS for PostgreSQL に移行しました。 この記事では、移行中に持ち上がった最も一般的な問題のいくつかについて説明します。皆さんは AWS Database Migration Service (AWS DMS) を使用して、あるデータベースから別のデータベースにデータを移動させた経験があることでしょう。私も AWS Schema Conversion Tool (AWS SCT) をかなり使い込みました。手始めに、データ抽出プロセスで直面する可能性のある問題を取り上げます。次に、データの移行中に起こる問題について取り上げます。最後に、移行後に PostgreSQL で観察するパフォーマンスの問題について説明します。 抽出フェーズの問題 このフェーズで一般的に直面する問題は、大きなテーブルのデータ抽出が遅くなり、ソース DB で ORA-01555 エラー (スナップショットが古すぎます) […]

Read More

Amazon Aurora PostgreSQL によるフェイルオーバー

レプリケーション、フェイルオーバー、レジリエンス、災害対策、バックアップ—従来の、または非クラウドベースのアーキテクチャでは、これらの一部またはすべてを実現するのはとても困難です。さらに、時にはかなりのリエンジニアリング作業が必要になることがあります。関係する実装やインフラストラクチャのコストが高いため、一部の企業では最も重要なアプリケーションのみが適切に保護されるようにアプリケーションを階層化せざるを得ません。 こうした懸念は、Amazon Aurora for PostgreSQL に移行すること軽減できます。AWS は、Oracle、MySQL、PostgreSQL、Aurora を含む (ただしこれらに限定されない) 幅広い種類のリレーショナルデータベースエンジンを提供しています。PostgreSQL の場合、AWS は Amazon EC2 インスタンスでの PostgreSQL、Amazon RDS for PostgreSQL、Amazon Aurora with PostgreSQL compatibility を含むさまざなバリエーションをサポートしています。適切なバージョンの PostgreSQL を選択するための多くの指標の中で、以下のいくつかが重要です。 高可用性 (HA) パフォーマンス 管理のしやすさ それでは、Amazon Aurora PostgreSQL がこうした基準をどのように満たしているかを掘り下げてみましょう。 高可用性: HA は、Aurora PostgreSQL のアーキテクチャに組み込まれており、3 つのアベイラビリティーゾーンにわたって 6 つのデータコピーが維持されています。つまり、アベイラビリティーゾーンごとに 2 つのコピーがあることになり、いずれかのアベイラビリティーゾーン全体がダウンしてもわずかな中断で済むことから可用性が向上します。さらに、データベースは Amazon S3 に継続的にバックアップされるため、S3 の高耐久性 (99.999999999) をバックアップで利用できます。Aurora PostgreSQL は、ポイントインタイムリカバリもサポートしています。 パフォーマンス: Amazon Aurora […]

Read More