PostgreSQL でのデータベースサイズ削減の戦略: 使用量ベースのアプローチ

データベースの価格モデルは難しいです。マネージド データベースを探している開発者にとって、検索プロセスで最も面倒な (そして重要な) 側面の 1 つは、データベース サイズに応じたソリューションの初期価格だけでなく、価格設定がどのように機能し、どの程度うまく拡張できるかを評価することです。 。 データベースの価格を評価する際の微妙な違いに加えて (例: 「データが増加すると請求額はいくら増加しますか?」、「書き込みまたは読み取りごとに料金が請求されますか?」、「バックアップごとに追加料金を支払う必要がありますか?」など)。 )、開発者は 1 つの側面を見落とす傾向があります。それは、データベースの価格モデルの構造が、データの管理方法と Postgres データベース サイズの評価方法に影響するということです。 料金モデルが異なれば、PostgreSQL を実行するためのアプローチも異なります。たとえば、大規模なディスクにロックされている場合は、データベース サイズの削減を優先しない可能性があります。データの読み取りごとに料金が請求される場合は、特定のクエリの実行についてよく考える必要があります。また、データの受信ごとに料金が請求される場合は、新しく取り込まれるデータの頻度と量について慎重になる可能性があります。 各価格要素は、最終的に採用する戦略や行動に微妙に影響を与え、コスト効率と最適なパフォーマンスの両方を確保するために、データベースの管理と操作の特定の方法を選択するようになります。 、顧客からの素晴らしいフィードバックが寄せられています。このブログ投稿では、使用量ベースのモデルで PostgreSQL ストレージを最適に管理する方法についての戦術とともに、このモデルに移行して以来お客様から観察された運用上の利点を探っていきます。 Timescale では、数か月前に使用量ベースのストレージ モデルに移行しました。 データベースの世界では、使用量ベースのストレージ モデルの人気が高まっています。使用していないディスク領域にお金を払いたい人がいるでしょうか?それでも、使用量ベースのモデルには結果が伴うため、効果的にナビゲートするにはいくつかのベスト プラクティスを考慮する必要があります。 PostgreSQL ストレージ モデルの簡単な要約 使用量ベースのモデルでのデータベース サイズの管理に関する議論の共通基盤を確立するために、まず、PostgreSQL プラットフォームでの価格設定がどのように機能するかを簡単に説明します ( ) と、Amazon RDS for PostgreSQL や Amazon Aurora などの他のマネージド PostgreSQL 製品との比較について説明します。 タイムスケール 昨日 (💥) から、Timescale プラットフォームで 2 種類のデータベース サービスを提供します。 では、開発者は動的コンピューティングを備えた PostgreSQL データベースを作成して、パフォーマンスを犠牲にすることなくコストを節約できます。 動的PostgreSQLサービス Time Series サービス。開発者は、ハイパーテーブル、列指向圧縮、 、階層型ストレージ。 連続集合体 プラットフォーム上のストレージの価格設定に注目してみましょう。これらのサービスには両方ともストレージの使用量ベースのモデルが付属しており、これは次のことを意味します。 開発者は、細かい部分を除いて、使用したボリュームに応じて料金が発生します。つまり、データベースの最小サイズやスケーリングの最小ステップはありません。月末までに 128 GB を使用した場合、その量が請求されます。 1 GB から開始して TB まで拡張できます。 書き込まれたデータ、データ転送、または実行されたクエリに基づく料金は発生しません。 データベースの作成時やスケーリング時にストレージを割り当てる必要はありません。 ディスクのサイズを手動でダウンサイズする必要はありません。 このことを理解していただくために、このモデル、Amazon RDS PostgreSQL、および Amazon Aurora の違いを整理してみましょう。 要約すると、比較から得られた主なポイントは次の 3 つです。 Timescale と Aurora はどちらも、実際のデータベース サイズに応じて課金されます。対照的に、RDS PostgreSQL はプロビジョニングされたストレージに対して課金されます。 RDS ではボリュームをダウンサイズすることはできません。 Timescale では、書き込まれたデータ、データ転送、クエリ操作に対して料金はかかりません。 RDS と Aurora はどちらも、データ転送、追加のバックアップ ストレージごとに料金が発生し、選択したストレージの種類に応じて追加の I/O 料金が発生する場合があります。 Timescale には最小スケーリング手順はありませんが、Aurora は 10 GB から開始した後、10 GB ずつ増分します。 ご覧のとおり、Timescale のモデルは次のものに近いです。 , 違いは、Timescale にはスケーリング手順やデータ転送などの追加料金がないことです。対照的に、RDS は、たとえ このモデルを運用しているデータベース ベンダーでは伝統的に見られます。 Aurora I/O に最適化 RDS には「ストレージ層」がありません 従量制料金設定により PostgreSQL ストレージ管理がどのように改善されるか 以前に紹介したように、価格モデルが異なると、データベース エクスペリエンスも異なります。割り当てベースのモデルから使用量ベースのモデルに移行したとき、お客様からは、次の 3 つの運用領域ですぐに改善が見られたとの報告がありました。 データベースの起動時にストレージを事前にプロビジョニングする必要がなかったので、オーバープロビジョニングの間違いが減り、ストレージ料金が削減されました。 スケールアップ中にストレージについて考える必要はありませんでした。 データを削除した場合、その料金の支払いを停止するなど、規模を縮小することもできます。 使用量ベースのモデルにより、ストレージのオーバープロビジョニングの問題が解消されます 従来の割り当てベースのモデルでは、開発者がストレージのニーズを予測することが多く、これがストレージのオーバープロビジョニングにつながることがよくあります。 Timescale が使用量ベースのモデルで運用していたときに、これをフリート全体で観察しました。顧客の大多数はディスク容量をフルに使用していませんでした。つまり、実質的に、まだ使用していないストレージ スペースに対して料金を支払っていることになります。使用量ベースのモデルは、この推測ゲーム (および間違った推測の結果) を排除します。 スケールアップ中にストレージについて考える必要はありません 「Timescale の使用量ベースのストレージは、ディスク サイズについてもう考える必要がないことを意味します。ストレージ コストは 30 % 削減され、何もする必要はありませんでした。」 アダム・マクリー (タイムスケールの顧客) 柔道尺度 使用量ベースのモデルでは、データベースの成長に合わせてストレージがシームレスに拡張されます。従来の割り当てベースのモデルにおけるストレスの主な原因は、ディスク領域が不足する危険性であり、これにより、アプリケーションのダウンタイムやトランザクションの損失から、最悪の場合のデータ破損に至るまで、さまざまな問題が発生する可能性があります。 使用量ベースのモデルを使用すると、開発者はストレージの壁にぶつからないようにストレージを注意深く監視する必要がなくなりました。同時に、重い自動スケーリング手順や階層ジャンプについて心配する必要もありません。 ダウンスケールすることができます (削除したデータに対する料金の支払いを停止します) 最後に重要なことですが、使用量ベースのモデルでは「ダウンスケール」が可能です。データを削除すると（またはデータベース サイズを大幅に削減できれば）、ストレージあたりの料金が安くなり始めますが、これは公平に思えます。次のセクションで説明するように、Timescale には、顧客が PostgreSQL データベースのサイズを削減できるようにするいくつかの機能があります。使用量ベースのモデルを採用することで、お客様はディスク使用量を削減したときに節約をすぐに実感できるようになり、データベースを無駄のない状態に保つ動機になりました。 使用量ベースのモデルを効果的にナビゲートする方法: Postgres データベースのサイズを削減するためのヒント 先ほど述べた利点により、ストレージを操作する開発者のエクスペリエンスが大幅に向上します。そのため、使用量ベースのモデルが非常に人気になっています。しかし、使用量ベースの価格設定には明らかな (しかし重大な) 結果が伴います。開発者は適切なデータ プラクティスを採用して、PostgreSQL データベースのサイズを可能な限り削減する必要があります。 ストレージのコストが実際に使用しているディスク サイズに直接関係していることがわかれば、データ ストレージをより慎重に扱う動機が新たに生まれます。ストレージの使用量ベースのモデルで運用している場合は、データを効率的に保存することがユーザーの責任となります。 ある意味、これは使用量ベースのモデルの「欠点」と考えることができ、ある程度の作業が必要ですが、実際にはこれが隠れて幸いです。従来の割り当てベースのモデルでは、コストが固定されているため、データの健全性が多少見落とされる可能性があります。RDS で 500 GB のディスクにロックされており、データベースが 200 GB である場合、データの健全性を維持する大きなインセンティブはないようです。ストレージの使用を効率的にします。 しかし、ここで重要なのは、優れたデータ実践とは、単にコストを節約することだけではありません。 PostgreSQL データベースを拡張するには、データベースを最適化した状態に保つことが不可欠です。適切な PostgreSQL データ管理手法を採用すると、パフォーマンスが向上するだけでなく、データベース管理者としての作業がはるかに楽になります。 これを念頭に置いて、ストレージの使用量ベースのモデルを可能な限り効果的にナビゲートし、体系的な方法で PostgreSQL データベースのサイズを削減するのに役立ついくつかのプラクティスを実行してみましょう。 Timescale の特定のケースでは、特に便利な機能がいくつかありますので、それについても説明します。 PostgreSQL データベースの肥大化を軽減する 使用量ベースのモデルで最初に行うべきことは、PostgreSQL ストレージの動作の詳細に注意を払うことです。つまり、肥大化を定期的に削減する必要があります。これは、データベースのサイズだけでなく、I/O 要件にも役立ちます。このセクションではいくつかの基本について説明します。 、そして私たちも書いています 。 しかし、この HN スレッドには素晴らしいアドバイスがいくつかあります PostgreSQL のテーブル肥大化に関するブログ投稿 PostgreSQL ストレージを最適化するためのプロアクティブなアプローチは、デッドタプルを注意深く監視することから始まります。デッドタプルをチェックしないままにしておくと、蓄積されて不必要なストレージのオーバーヘッドが発生する可能性があります。 拡張機能は、テーブルがこれらのタプルをどのように管理するかを理解するのに非常に役立ちます。 デッドタプルを監視します。 pgstattuple() テーブルの肥大化に効果的に対処するには、自動バキュームをより頻繁に実行するように構成するとよいでしょう。 postgresql.conf で autovacuum 設定をグローバルに調整するよりも、テーブルごとにこれらの設定を微調整する方が正確です。これは、テーブルごとにデッドタプルが蓄積する傾向が異なる可能性があるという事実に対応しています。自動バキューム操作を妨げる可能性のある長時間実行トランザクションを監視することも重要です。 頻繁に掃除機をかけます。 自動バキュームとバキュームはデッドタプルに対処しますが、未使用のページを再利用するには別のアプローチが必要です。 VACUUM FULL はこの目的に利用できますが、テーブル全体をロックするという固有の制限があります。 これをお手伝いできます。 未使用のページを再利用します。 Pg_repack PostgreSQL の微調整を行う PostgreSQL データベースのサイズを体系的に削減することは、PostgreSQL データベースを効果的に拡張できること、つまり、より多くのデータを追加しながら高速性と俊敏性を維持できることと密接に関係しています。いくつかの主要な PostgreSQL パラメータに注意を払う (そして場合によっては調整する) と役立つ場合があります。 。考慮する必要があるいくつかの側面を次に示します。 この記事では、最も重要なパフォーマンス パラメーターについて説明します。 : PostgreSQL のページ キャッシュに使用されるメモリを制御します。通常、システムの合計 RAM の 25 % に設定されます。 shared_buffers : クエリ内の操作ごとに割り当てられるメモリを設定します。タイムスケールでは、推奨設定は です。 work_mem (25 % of RAM) / max_connections : データベースに許可される同時接続の最大数を設定します。接続プーラーは、多くの短期間の接続の管理に役立ちます。 max_connections : PostgreSQL が開始できるワーカー プロセスの最大数を決定します。 Timescale を使用する場合、このパラメーターを設定する式は次のとおりです: 。 max_worker_processes max_worker_processes = 3 + timescaledb.max_background_workers + max_parallel_workers : 並列クエリをサポートするワーカーの最大数を指定します。デフォルトでは、これを使用可能な CPU の数と同じに設定します。 max_parallel_workers : 同時自動バキュームプロセスの最大数を決定します。タイムスケールでは、デフォルトで 10 に設定されます。 autovacuum_max_workers インデックス作成の衛生管理を実践する インデックスを定期的に最適化すると、特にデータベースの規模が拡大した場合に、PostgreSQL の効率を維持するのに役立ちます。インデックスは賢く使用するとクエリのパフォーマンスを向上させるのに役立ちますが、過剰なインデックスは大規模な PostgreSQL デプロイメントで問題を引き起こす可能性があります。 過剰なインデックス作成の最も明白な結果は、ストレージ消費量の増加です。これは、すべてのインデックスに個別のストレージが必要であり、テーブルのサイズに比例して増加するためです。 Timescale の ハイパーテーブルのようにテーブルがパーティション化されている場合、このオーバーヘッドはさらに大きくなる可能性があります。 不必要なインデックスは、書き込み操作の改善において逆効果になる可能性もあります。新しいデータのエントリや変更が発生するたびにインデックスの同時更新が行われるため、I/O 操作が増加し、テーブルが肥大化する可能性があります。インデックスを監視すると、使用されなくなったインデックスを特定し、無駄のない状態を保つことができます。 これを行う 1 つの方法は、 を使用することです。 pg_stat_user_indexes -- Retrieve indexes that might not be used or are infrequently used SELECT schemaname, relname AS table_name, indexrelname AS index_name, idx_scan AS times_used FROM pg_stat_user_indexes WHERE idx_scan = 0 OR idx_scan < some_low_threshold -- replace 'some_low_threshold' with a value that makes sense for your context ORDER BY idx_scan ASC, schemaname, relname; インデックスの idx_scan 列の値が 0 である場合、統計が最後にリセットされてからインデックスが使用されていないことを意味し、最適化の候補となる可能性があります。 のしきい値を低く設定すると、使用頻度の低いインデックスを特定することもできます。 idx_scan タイムスケール圧縮を使用して大きなテーブルを縮小します Timescale の優れた機能の 1 つは、列圧縮のネイティブ サポートです。これにより、クエリのパフォーマンスを損なうことなく、大規模なテーブルで使用されるディスク領域を大幅に削減できます。圧縮により、多くのクエリのパフォーマンスが向上します。 Timescale の圧縮は、通常の行ベースのデータをよりコンパクトな列形式に変換することで機能します。このプロセスは、多くの列に繰り返し値が含まれる可能性がある時系列データに特に効果的です。各データ型に応じて異なる圧縮アルゴリズムを適用することで、驚異的な圧縮率 (+90 %) を達成できます。これは、大きなテーブルを最大 10 倍まで縮小できることを意味します。 Timescale では、圧縮は時間ベースの圧縮ポリシーを介してテーブルごとに有効になります。たとえば、次のコードは特定のハイパーテーブルで圧縮を有効にし、2 週間以上古いデータを自動的に圧縮します。 -- Enable compression on the hypertable ALTER TABLE your_hypertable SET ( timescaledb.compress, timescaledb.compress_segmentby = 'some_column' ); -- Set a compression policy to compress data older than two weeks SELECT add_compression_policy('your_hypertable', INTERVAL '2 weeks'); 圧縮について詳しくは、 。 ドキュメントをチェックしてください データ管理戦略を立てる: 古いデータを安価なストレージに移動し、不要になったデータを削除します。 前述の戦術はデータベース サイズを削減するのに非常に役立ちますが、Timescale でストレージを効果的に拡張するために活用できる別の手段、つまり階層型ストレージがあります。 シンプルな階層化ポリシーを作成することで、アクセスの少ない古いデータを底なしのオブジェクト ストレージ レイヤーに移動できます。 -- This policy moves all data older than one month to object storage SELECT add_tiering_policy('example', INTERVAL '1 month); このオブジェクト ストアには次の特徴があります。 当社の高性能ストレージよりも低価格なので、何TBものデータをはるかに安価に保存できます。 無限であるため、必要なだけデータを保存できます。 この階層型ストレージ アーキテクチャは、Timescale のバックエンドに組み込まれています。オブジェクト ストレージはデータベースから切り離された「バケット」ではなく、データベースの不可欠な部分です。クエリは、ユーザーによるアクションを必要とせずに両方のストレージ層に透過的にアクセスします。同じスキーマ上で標準 SQL を使用し続けるだけで済みます。階層化ポリシーを設定したら、他に考慮する必要はありません。 パフォーマンスにコストがかかるため (オブジェクト ストアは通常のストレージほど高速ではありません)、アプリケーションによって頻繁にアクセスされなくなったデータは、低コストのストレージ レイヤーに移動することをお勧めします。ただし、このデータに対するアドホック クエリ (顧客のユーザー エクスペリエンスにとって重要ではなく、最高のパフォーマンスが必須ではないクエリなど) を快適に実行し続けることができます。 編集者注: 階層型ストレージに関するエキサイティングなニュースを間もなく共有する予定です。 🎉 乞うご期待！ Timescale では、この低コストのストレージ レイヤーを提供することに加えて、不要になったデータを削除するためのデータ保持ポリシーを簡単に設定できます。 -- Set a data retention policy to drop data older than 10 months SELECT add_retention_policy('your_hypertable', INTERVAL '10 months'); 上記のようなデータ保持ポリシーと連続集計を組み合わせて、データセットを効果的にダウンサンプリングすることができます。たとえば、粒度を 1 秒から 1 分に減らし、1 秒の値を削除して 1 分の集計を保持します。 。 このブログ投稿を読んで、これを実行し、長期データを積極的に管理する方法の例を確認してください。 使用量ベースのモデルとデータ管理パラダイム 使用量ベースのモデルは、表面的には価格変更にしか見えないかもしれませんが、開発者がデータベースのサイズについてどのように考え、データをどのように認識して処理するかにパラダイムシフトをもたらします。 使用量ベースのモデルは、単なるストレージ管理からデータベースの健全性と効率に焦点を移し、継続的な改善の文化を促進します。これには最初はある程度の規律が必要ですが、考え方が変わり、いくつかのテクニックを学べば、PostgreSQL データベースを効率的かつ効果的に拡張するのに最適な場所に立つことができます。 Timescale には、圧縮、階層化ストレージ、データ保持ポリシーなど、PostgreSQL データベースのサイズを体系的に削減するのに役立つ貴重なツールがあります。これにより、使用量ベースのモデルで PostgreSQL データベースを効果的に拡張できます。 。 自分で体験するには、Timescale にサインアップしてください。最初の 30 日間は無料で使用できます - 著。 カルロタ・ソータ こちらでも公開しております。