Last updated 21 January 2021

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

プランの層

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

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

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

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

共有される機能

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

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

Hobby 層

Hobby 層 (hobby-dev​ と hobby-basic​ を含む) プラン​には、次の制限があります。

• hobby-dev​ プランの場合は 10,000 行、hobby-basic​ プランの場合は 10,000,000 行の行数制限が適用されます。
• hobby-dev プランで 1 GB、hobby-basic プランで 10 GB の最大ストレージ
• 最大 20 個の接続。
• インメモリキャッシュなし: インメモリキャッシュがないと、低レイテンシーストレージのデータにアクセスできないため、パフォーマンスが制限されます。
• フォーク/フォロー​のサポートなし: レプリカデータベースやリーダー/フォロワー設定を作成するために使用されるフォークとフォローはサポートされません。
• 高コストのクエリ​のサポートなし。
• 月ごとに 99.5% の予測される稼働時間。
• 予告なしのメンテナンスおよびデータベースアップグレード。
• Postgres ログなし。

行数制限の適用

Hobby 層の行数制限を超え、さらに挿入しようとすると、次の Postgres エラーが表示されます。

`permission denied for relation <table name>`

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

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

Standard 層

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

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

Standard 層の中で、各プランのメモリ、接続制限、ストレージ制限は異なります。Standard 層の各プランは次のとおりです。

Premium 層

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

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

Premium 層の中で、各プランのメモリ、接続制限、ストレージ制限は異なります。Premium 層の各プランは次のとおりです。

Private および Shield 層

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

キャッシュサイズ

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

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

逆に、ディスクへのフォールバックが必要になると、少なくとも 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 ミリ秒未満が必要です。

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

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

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

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

キャッシュヒット率が低下し始めたら、一般には、データベースのアップグレードによりこの比率が 99% に戻ります。アップグレードするには、プラン間で移行するためにフォロワーの切り替えの更新​を実行することをお勧めします。New Relic​ を監視し、アプリケーションのアクセスパターンに対して何が最適に機能するかを確認してください。