Skip Navigation
Show nav
Heroku Dev Center
  • Get Started
  • ドキュメント
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
  • ドキュメント
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
View categories

Categories

  • Heroku のアーキテクチャ
    • Dyno (アプリコンテナ)
    • スタック (オペレーティングシステムイメージ)
    • ネットワーキングと DNS
    • プラットフォームポリシー
    • プラットフォームの原則
  • コマンドライン
  • デプロイ
    • Git を使用したデプロイ
    • Docker によるデプロイ
    • デプロイ統合
  • 継続的デリバリー
    • 継続的統合
  • 言語サポート
    • Node.js
    • Ruby
      • Rails のサポート
      • Bundler の使用
    • Python
      • Django の使用
      • Python でのバックグランドジョブ
    • Java
      • Maven の使用
      • Java でのデータベース操作
      • Java の高度なトピック
      • Spring Boot の使用
    • PHP
    • Go
      • Go の依存関係管理
    • Scala
    • Clojure
  • データベースとデータ管理
    • Heroku Postgres
      • Postgres の基礎
      • Postgres Getting Started
      • Postgres のパフォーマンス
      • Postgres のデータ転送と保持
      • Postgres の可用性
      • Postgres の特別なトピック
    • Heroku Redis
    • Apache Kafka on Heroku
    • その他のデータストア
  • モニタリングとメトリクス
    • ログ記録
  • アプリのパフォーマンス
  • アドオン
    • すべてのアドオン
  • 共同作業
  • セキュリティ
    • アプリのセキュリティ
    • ID と認証
    • コンプライアンス
  • Heroku Enterprise
    • Private Space
      • インフラストラクチャネットワーキング
    • Enterprise Accounts
    • Enterprise Team
    • Heroku Connect (Salesforce 同期)
      • Heroku Connect の管理
      • Heroku Connect のリファレンス
      • Heroku Connect のトラブルシューティング
    • シングルサインオン (SSO)
  • パターンとベストプラクティス
  • Heroku の拡張
    • Platform API
    • アプリの Webhook
    • Heroku Labs
    • アドオンのビルド
      • アドオン開発のタスク
      • アドオン API
      • アドオンのガイドラインと要件
    • CLI プラグインのビルド
    • 開発ビルドパック
    • Dev Center
  • アカウントと請求
  • トラブルシューティングとサポート
  • Integrating with Salesforce
  • データベースとデータ管理
  • Heroku Postgres
  • Postgres の基礎
  • 適切な Heroku Postgres プランの選択

適切な Heroku Postgres プランの選択

日本語 — Switch to English

この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。

最終更新日 2023年03月17日(金)

Table of Contents

  • プランの層
  • Essential 層
  • Standard 層
  • Premium 層
  • Private および Shield 層
  • キャッシュサイズ
  • Heroku Postgres プランの変更

Heroku Postgres​ には、個人的なブログから大きなデータセット、高トランザクションアプリケーションまでの各種サイズのユースケースを処理するためのさまざまなプランが用意されています。適切なプランの選択は、そのアプリの固有の使用特性 (可用性や稼働時間に対する要件など) によって異なります。

プランの層

Heroku Postgres の多くのプラン​は、 次の 5 つの高レベルの層​に分類されます。各層の主な違いは、その層で許容されるデータベースの毎月のダウンタイムの量です。5 つの層は次のとおりです。

  • Essential 層​ — 1 か月あたり最大 4 時間のダウンタイムを許容できるアプリ向け
  • Standard 層​ — 1 か月あたり最大 1 時間のダウンタイムを許容できるアプリ向け
  • Premium 層​ — 1 か月あたり最大 15 分のダウンタイムを許容できるアプリ向け
  • Private 層​ — Heroku Enterprise​ のお客様向け
  • Shield 層​ — コンプライアンスに対応したデータベースが必要な Heroku Enterprise​ のお客様向け

各層の違いの内訳を次に示します。

Heroku Postgres の層 ダウンタイムの許容範囲 フォーク フォロー ロールバック HA ディスクの暗号化
Essential 1 か月あたり 4 時間未満のダウンタイム なし なし なし なし なし
Standard 1 か月あたり 1 時間未満のダウンタイム あり あり 4 日間 なし あり
Premium 1 か月あたり 15 分未満のダウンタイム あり あり 1 週間 あり あり
Private 1 か月あたり 15 分未満のダウンタイム あり あり 1 週間 あり あり
Shield 1 か月あたり 15 分未満のダウンタイム あり あり 1 週間 あり あり

ダウンタイムの許容範囲は 30 日の月に基づいています。

共有される機能

Heroku Postgres プランのすべての層で次の機能が共有されます。

  • 自動ヘルスチェックによって完全に管理されたデータベースサービス
  • 60 秒ごとのログ先行書き込み (WAL) オフプレミスストレージ (重大な障害が発生した場合のデータ損失が最小限に抑えられる)
  • PG バックアップ​を使用した日次論理データベースバックアップ (無料のオプション)
  • データクリップ​ (データやクエリの簡単かつ安全な共有のため)
  • SSL で保護された psql/libpq アクセス
  • 変更されていない PostgreSQL 11、12、13、14、15 の実行
  • Postgres 拡張機能
  • フル機能を備えた Web UI

データクリップと日次論理バックアップは、Shield 層のデータベースプランでは使用できません。

Essential 層

Essential 層には mini​ と basic​ のプラン​が含まれています。この層には以下の制限があります。

  • インメモリキャッシュなし: インメモリキャッシュがないと、低レイテンシーストレージのデータにアクセスできないため、パフォーマンスが制限されます。
  • フォーク/フォロー​のサポートなし: レプリカデータベースやリーダー/フォロワー設定を作成するために使用されるフォークとフォローはサポートされません。
  • 高コストのクエリ​のサポートなし
  • 月ごとに 99.5% の予測される稼働時間
  • 予告なしのメンテナンスおよび Postgres バージョンの自動アップグレード
  • Postgres ログなし
  • 追加の資格情報なし

Essential 層の各プランは次のとおりです。

プラン名 プロビジョニング名 行数制限 ディスクサイズ 接続制限
Mini heroku-postgresql:mini​ 10000 1GB 20
Basic heroku-postgresql:basic​ 10000000 10GB 20

プランの制限の適用

Essential 層データベースの行数制限またはサイズ制限を超え、さらに挿入しようとすると、次の Postgres エラーが表示されます。

permission denied for relation <table name>

Essential 層のデータベースプランの行数制限は、次のメカニズムで適用されます。

  1. mini​ データベースが 7,000 行に達するか、または basic​ データベースが 700 万行に達すると、所有者は、それぞれの行数制限に近づいていることを示す警告メールを受信します。
  2. データベースがその行の容量を超えると、所有者は追加の通知を受信します。この時点で、データベースには、レコードの数を減らすか、または別のプランに移行する​ための 7 日の猶予期間が与えられます。
  3. 7 日経っても行数が引き続きプランの容量を超えている場合は、データベースに対する INSERT​ 権限が取り消されます。データの読み取り、更新、またはデータベースからの削除は引き続き可能です。これにより、ユーザーはデータベースをコンプライアンスに対応させたり、データへのアクセスを保持したりできるようになります。
  4. 行数が再びプラン制限のコンプライアンスに従うようになると、INSERT​ 権限が自動的にデータベースに復元されます。データベースサイズは非同期的にチェックされるため、権限が復元されるまでに数分かかる可能性があります。

Standard 層

Standard 層は、1 か月あたり最大 1 時間のダウンタイムを許容するアプリケーション向けに設計されています。すべての Standard 層データベースには、以下のものが含まれます。

  • 行数制限なし
  • インメモリキャッシュの段階的な拡張
  • フォークとフォロー​のサポート
  • 最大 4 日間のロールバック​
  • データベースメトリクス​をさらに分析するためのアプリケーションログストリームへの公開
  • 中断時の優先サービスの復元
  • ディスクに書き込まれたすべてのデータを自動で保存時暗号化
  • 資格情報管理

Standard 層の各プランは次のとおりです。

プラン名 プロビジョニング名 RAM サイズ ディスクサイズ 接続制限
Standard-0 heroku-postgresql:standard-0​ 4 GB 64 GB 120
Standard-2 heroku-postgresql:standard-2​ 8 GB 256 GB 400
Standard-3 heroku-postgresql:standard-3​ 15 GB 512 GB 500
Standard-4 heroku-postgresql:standard-4​ 30 GB 768 GB 500
Standard-5 heroku-postgresql:standard-5​ 61 GB 1 TB 500
Standard-6 heroku-postgresql:standard-6​ 122 GB 1.5 TB 500
Standard-7 heroku-postgresql:standard-7​ 244 GB 2 TB 500
Standard-8 heroku-postgresql:standard-8​ 488 GB 3 TB 500
Standard-9 heroku-postgresql:standard-9​ 768 GB 4 TB 500

Premium 層

Premium 層は、1 か月あたり最大 15 分のダウンタイムを許容するアプリケーション向けに設計されています。すべての Premium 層データベースには、以下のものが含まれます。

  • 行数制限なし
  • インメモリキャッシュの段階的な拡張
  • フォークとフォロー​のサポート
  • 最大 7 日間のロールバック​
  • データベースメトリクス​をさらに分析するためのアプリケーションログストリームへの公開
  • 中断時の優先サービスの復元
  • ディスクに書き込まれたすべてのデータを自動で保存時暗号化
  • 資格情報管理

Premium 層の各プランは次のとおりです。

プラン名 プロビジョニング名 RAM サイズ ディスクサイズ 接続制限
Premium-0 heroku-postgresql:premium-0​ 4 GB 64 GB 120
Premium-2 heroku-postgresql:premium-2​ 8 GB 256 GB 400
Premium-3 heroku-postgresql:premium-3​ 15 GB 512 GB 500
Premium-4 heroku-postgresql:premium-4​ 30 GB 768 GB 500
Premium-5 heroku-postgresql:premium-5​ 61 GB 1 TB 500
Premium-6 heroku-postgresql:premium-6​ 122 GB 1.5 TB 500
Premium-7 heroku-postgresql:premium-7​ 244 GB 2 TB 500
Premium-8 heroku-postgresql:premium-8​ 488 GB 3 TB 500
Premium-9 heroku-postgresql:premium-9​ 768 GB 4 TB 500

Private および Shield 層

Heroku は、Heroku Enterprise​ のお客様に Private Spaces​ 内の Heroku Postgres を提供します。さらに、コンプライアンスに対応したデータベースが必要なお客様は Postgres Shield プランをご使用いただけます。Private および Shield プランについての詳細は、Heroku Postgres および Private Spaces​ の記事を参照してください。

キャッシュサイズ

Essential 層でないデータベース​の場合、RAM サイズは、基礎となるインスタンスのハードウェア上のシステムメモリの合計量を示します。このほとんどは、Postgres に割り当てられ、キャッシングに使用されます。少量の RAM は接続やその他のタスクの管理に使用されますが、Postgres では、この RAM のほぼすべてがそのキャッシュのために利用されます。キャッシュの詳細な機能については、この記事​を参照してください。

Postgres は、書き込まれた行、作成されたインデックス、Postgres が保持しているメタデータなどのデータのキャッシュを常に管理しています。クエリに必要なデータがキャッシュ内に完全に含まれている場合、パフォーマンスは高速です。キャッシュされたデータから作成されたクエリは多くの場合、完全なデータセットから作成されたクエリに比べて 100 ~ 1000 倍高速です。

適切に設計された高性能な Web アプリケーションから処理されるクエリの 99% 以上はキャッシュから処理されます。

逆に、ディスクへのフォールバックが必要になると、少なくとも 1 桁低速になります。さらに、大きなデータ型 (大きなテキスト列など) を含む列は TOAST​ を使用して行の外で保存されるため、TOAST 化された大量のデータへのアクセスは低速になる場合があります。

一般的なガイドライン

アクセスパターンは、アプリケーションごとに大きく異なります。多くのアプリケーションは、そのデータ全体の中の小さな、最近変更された部分にのみアクセスします。Postgres は、時間が経過しても常にその部分をキャッシュ内に保持できるため、これらのアプリケーションは小さめのプランでは適切に実行できます。

すべての​データに頻繁にアクセスするアプリケーションにこの好条件はありません。これらのアプリでは、そのデータセット全体が確実にメモリに収まるようにすることにより、パフォーマンスを大幅に向上させることができます。データセットの合計サイズを確認するには、heroku pg:info​ コマンドを使用し、Data Size​ 行を探します。

$ heroku pg:info
=== HEROKU_POSTGRESQL_CHARCOAL_URL (DATABASE_URL)
Plan:        Crane
Status:      available
Data Size:   9.4 MB
...

大まかな尺度ではありますが、合計のデータセットのサイズと少なくとも同じ量のインメモリキャッシュを使用できるプランを選択すると、高いキャッシュ比率が確保されます。ただし、最終的には最大のプランよりデータ量が多くなるポイントに達するため、シャードすることが必要になります。シャーディングを前もって計画してください。シャーディング方式の実行には長い時間がかかります。

必要なキャッシュサイズの特定

適切なキャッシュサイズを特定するには、本番稼働トラフィックでのアプリケーションのデータベース要求を観察することが最適です。理想的には、キャッシュヒット率は 99% 以上の範囲に入ります。一般的でないクエリには 100 ミリ秒未満が、一般的なクエリには 10 ミリ秒未満が必要です。

このブログ投稿 には、Postgres のパフォーマンスの問題や手法のより詳細な説明が含まれています。

テーブルのキャッシュヒット率を測定するには、次のようにします。

SELECT
    'cache hit rate' AS name,
     sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) AS ratio
FROM pg_statio_user_tables;

インデックスのキャッシュヒット率の場合は、次のようにします。

SELECT
    'index hit rate' AS name,
    (sum(idx_blks_hit)) / sum(idx_blks_hit + idx_blks_read) AS ratio
FROM pg_statio_user_indexes

pg extras プラグイン​をインストールした後、 heroku pg:cache_hit を実行するだけです。

どちらのクエリも 0.99​ に近い ratio​ を示します。

heap_read | heap_hit |         ratio
-----------+----------+------------------------
       171 |   503551 | 0.99966041175571094090

キャッシュヒット率が低下し始めたら、一般には、データベースのアップグレードによりこの比率が 99% に戻ります。

Heroku Postgres プランの変更

データベースのプランは作成後に変更できます。プランを変更するオプションの詳細については、こちら​を参照してください。

関連カテゴリー

  • Postgres の基礎

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Podcasts
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing

Subscribe to our monthly newsletter

Your email address:

  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Heroku Podcasts
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Facebook
  • Instagram
  • Github
  • LinkedIn
  • YouTube
Heroku is acompany

 © Salesforce.com

  • heroku.com
  • Terms of Service
  • Privacy
  • Cookies
  • Cookie Preferences