PostgreSQL データベースのスケーリングがさらに安価に: Timescale の階層型ストレージが一般提供開始

Amazon RDS for のような製品は小規模な導入には適していますが、PostgreSQL のスケーリングとなると話は別です。プロジェクトが数テラバイトに成長すると、これらの管理されたデータベースは遅くなり高価になり、データ管理がさらに複雑になります。 PostgreSQL テーブルが数十億行に達するとパフォーマンスが低下します。 、データは増え続けます。適切なデータ管理がなければ、開発者はディスク (および請求書) のサイズが増大するのをただ眺めることしかできません。 それを 改善する方法があります もうそうじゃない。 本日、Tiered Storage の一般提供を発表できることを嬉しく思います。これは、Timescale プラットフォームの時系列データベースと分析データベースの無限かつ低コストのスケーラビリティを可能にするように設計された多層ストレージ アーキテクチャです。アクセス頻度の低い古いデータを低コストのストレージ層に保存しながら、頻繁にアクセスするデータのパフォーマンスを犠牲にすることなく、アクセスできるようになりました。 新しい多層ストレージ バックエンドを使用して Timescale 時系列データベースにデータを挿入すると、次のことが起こります。 最新のデータは、高速クエリと大量の取り込み向けに最適化された に書き込まれます。 高性能ストレージ層 そのデータに頻繁にアクセスしない場合は、階層化ポリシーを設定することで、データを に自動的に階層化できます。低コストのストレージ層のデータはデータベース内で完全にクエリ可能であり、保存できるデータ量に制限はありません (最大数百 TB 以上)。 より低コストのオブジェクト ストレージ層 低コストのストレージ層は、データの定額料金が 1 GB/月あたり 0.021 ドルで、Amazon S3 よりも安価です。 開発者は、パフォーマンスを損なうことなく、 で大規模な PostgreSQL データベースを安価に拡張する方法を必要としています。オブジェクト ストアは驚くほどスケーラブルで手頃な価格ですが、最速ではないため、開発者はアプリケーションに対してミリ秒単位のクエリ応答を取得する必要 あります。 AWS も ただし、データが古くなり、ほとんどアクセスされなくなると、リアルタイム パフォーマンスはそれほど重要でなくなります。開発者は、アドホック クエリ、データ分析、または規制遵守のためにこの履歴データにアクセスできる必要がありますが、この種のクエリではある程度の待ち時間が想定されます。現在、開発者が望んでいるのは、この履歴データをできるだけ手頃な価格で効率的に保存できることです。 この新しい階層型ストレージ アーキテクチャにより、開発者はリアルタイム アプリケーションのストレージ コストとパフォーマンスのトレードオフのどちらかを選択する必要がなくなります。最近の頻繁にアクセスされるデータを高パフォーマンス層に保持することで、ミリ秒単位のクエリ速度と Timescale の取り込み機能を活用し、古いデータを階層化することで、PostgreSQL データベースに必要なだけの TB を保持できます。少ない。 階層型ストレージを使用した PostgreSQL データ管理: 知っておくべきこと Timescale の階層型ストレージ アーキテクチャは、PostgreSQL の柔軟性を活用し、 効果的なデータ管理のために。ハイパーテーブルを作成するときに、両方のストレージ層にシームレスに拡張できるようになりました。 , Timescale は、応答を生成するためにどのストレージ層にアクセスすればよいかをシームレスに把握し、最新のデータのパフォーマンスを向上させ、古いデータのストレージ コストを削減します。クエリやデータの読み取りごとに追加料金が発生したり、隠れた料金が発生したりすることはないため、簡単でコスト効率の高いデータ管理が可能になります。 ハイパーテーブル クエリを実行するとき このストレージ アーキテクチャでは、Timescale サービスのストレージ制限も排除されます。低コストのストレージ層は無限であるため、必要な数の TB を保存できます。例えば、 当社は、内部で階層型ストレージを活用して、Insights 製品を動かす巨大な Timescale データベースを保存しています。 この Insights データベースは、当社の顧客フリート全体からクエリ統計を継続的に収集して分析しており、現在その容量は 350 TB を超え、急速に増加しています。これら 350 TB のうち、250 TB が低コストのストレージに階層化されます。 計算してみましょう: もちろん、圧縮は有効になっており、圧縮率は 20 倍になっています。つまり、元々 100 TB だった Postgres データが、圧縮 (!) のおかげで 5 TB のディスクに収まるようになりました。 圧縮後、5 TB を高性能ストレージ層に保存します。 残りの 250 TB のデータは、低コストのストレージ層に保存されます。この階層化は、データが特定の期間 (現在は数週間前) に達すると自動的に行われます。 大規模な導入を行っている当社のお客様もすでに階層型ストレージを利用しています。 「私たちは市場データに対して多くの分析を行っていますが、保存する必要があるデータ量が膨大であるため、通常のディスクベースのデータベース ソリューションは実現不可能です (コストが高すぎるため)。Timescale の階層型ストレージを使用すると、大量のデータをシームレスに移動できます。 「オブジェクト ストレージ レイヤーがなければ、これは大量の履歴データを保存し、事後分析を実行するための優れたソリューションです。これがなければ、社内でソリューションを開発する必要がありました。」 - 独自のデジタル資産取引会社の最高技術責任者 シンプルさは階層型ストレージの重要な機能です。データを高パフォーマンス層から低コストのオブジェクト層に移動するには、弊社の 特定のハイパーテーブル上でデータが古くなるにつれてデータを階層化するポリシーを定義します。データ階層化ポリシーはチャンク ベースで機能します (ポリシーで定義された期間に達すると、完全なチャンクが階層化されます)。 ETL (抽出、変換、読み込み) プロセスやインフラストラクチャの変更は必要ありません。 シンプルなAPI タイムスケール ハイパーテーブルは、時間によって自動的にパーティション化された PostgreSQL テーブルです。それらのパーティションはチャンクと呼ばれます。チャンクは、タイムスケールのユーザー定義ポリシーの単位です。たとえば、データ保持ポリシーを定義する場合は、パーティション (チャンク) 全体を削除することになり、ストレージ階層間でデータを移動する場合は、チャンク全体を移動することになります。 。これは、リソースの使用率と開発者のエクスペリエンスの観点からデータを管理する非常に便利な方法です。 編集者注: たとえば、このポリシーは、1 か月より古いすべてのデータを ハイパーテーブルのオブジェクト ストレージに移動します。 events SELECT add_tiering_policy('events', INTERVAL '1 month'); 必要なのはそれだけです!適切な層で SQL クエリのみを実行するインテリジェントなクエリ プランニングを含め、その他の処理はすべて自動的に行われます。 低コストのストレージ層に現在保存されているデータを削除するには、データ保持ポリシーを定義して、一定の期間 (たとえば、5 年後) が経過するとデータが自動的に削除されるようにすることができます。 。 特定のチャンクを手動で削除することもできます また、特定のチャンクを低コストのストレージ層から高パフォーマンス層に「戻す」場合は ( ）、簡単に「階層を解く」ことができます。 たとえば、データをバックフィルまたは更新する必要がある場合 -- Untier a particular chunk CALL untier_chunk('_hyper_1_1_chunk'); Timescale コンソールで、階層化されたデータの量 (および月末のコスト) を追跡できます。 そして請求額の見積もりについて言えば… 階層型ストレージを使用するとどれくらい節約できますか? 当社の高性能ストレージ階層の実効価格は、データ 1 GB/月あたり 0.177 ドルです。 (フリート全体で予想される圧縮率を考慮して)。これに、データ 1 GB/月あたり 0.021 ドルの定額料金で、すべてのクラウド リージョンで同じ料金の低コスト ストレージ レイヤーが加わりました。 圧縮後 データを階層化する場合、実行されたクエリやスキャンされたデータの量ではなく、 します。これはまさに定額料金です。この価格体系の目標は、データ ストレージの総コストを計算する透明性が高く、明確で簡単な方法を提供し、データの管理を容易にすることでした。 保存したデータに対してのみ料金が発生 簡単な例として、5.2 TB のストレージを持つハイパーテーブルがあり、最近のハイパーテーブル チャンクと他の Postgres テーブルが約 200 GB を占有し、1 か月以上前のハイパーテーブル データが約 5 TB を占有しているとします。この古いデータに頻繁にアクセスしたりクエリを実行したりすることはありません。つまり、アプリケーションの日常的な操作にはそのデータが必要ありません。それでも、アドホックなクエリやコンプライアンス要件のためにデータベース内でアクセスできるようにしておきたいと考えています (当社の顧客の間ではそのようなケースが多く見られます)。 コスト効率の高いデータ管理戦略として、1 か月より古いすべてのチャンクを低コスト層に階層化し、その 5 TB のデータを保存するコストを月額約 478 ドルから月額約 105 ドル ( 削減できます。 ( 78% 削減) に 保管請求書に記載されています。 この推定では、ハイパーテーブルの圧縮が有効になっていると仮定し、すべての Timescale サービスにおける全体的な圧縮の中央値を考慮します)。 データの節約に伴って節約効果も高まります。数テラバイトをこの低コスト層に移動すると、ストレージの請求額が数千ドルから数百ドルに減ります。次の参照表は、低コストのストレージ層が実際にどれくらい手頃な価格であるかを示しています。 要点はわかりますね！ 階層型ストレージによる節約効果の相乗効果 階層型ストレージをさらに驚くべき点がもう 1 つあります。データを低コストのストレージ層に保持する場合、サービス内で高可用性レプリカまたは読み取りレプリカを実行しているかどうかに関係なく、このデータの料金を支払うのは 1 回だけです。 。 フォークにも同じことが当てはまります。 Timescale では、たとえばテストの実行や開発環境の作成のために、UI から 1 つのボタンをクリックすることで、プライマリ データベースのコピー (フォークと呼びます) を作成できます。 1 つ (または複数) のフォークを作成する場合、 。プライマリにないデータをさらに階層化することにした場合、そのデータを低コストの階層に保存するために料金を支払いますが、フォークの高パフォーマンスの階層からより安価な階層にデータを移動することで、大幅な節約のメリットが得られます。 。 低コスト ストレージ内のプライマリと共有されるデータに対しては課金されません これを明確にするために、例を示してみましょう。 6.5 TB のデータを含むプライマリ サービスがあり、次の設定も行っていると想像してください。 障害によるダウンタイムとデータ損失のリスクを大幅に軽減する高可用性レプリカ 読み取りクエリを処理し、プライマリが書き込みに完全に専念できるようにするリードレプリカ 開発とテストを目的としたそのサービスのフォーク 請求の観点から見ると、ハイパフォーマンス ストレージ層のプライマリ サービスに 6.5 TB のデータを保持した場合、2 つのレプリカ、フォーク、およびプライマリ サービス - 合計 26 TB。圧縮率の中央値を仮定すると、コストが高くつき、月額約 4,602 ドルになります。 しかし、アプリケーションが最新の 500 GB のデータのみにアクティブにアクセスする必要がある場合はどうなるでしょうか? 6 TB を低コストのストレージに階層化し、高性能ストレージ階層には 500 GB のみを維持することもできます。また、低コストのストレージ層のデータに対して支払うのは 1 回だけであるため、新しいストレージの請求額は次のようになります。 [500 GB x 4] = 2 TB の高性能ストレージ (26 TB ではなく) 低コストストレージ階層の [6 TB x 1] 上記のストレージ料金は月額約 480 ドルになります。つまり これが階層型ストレージの節約効果の相乗効果です。特にレプリカまたはフォークを実行している場合は、低コストのストレージ層を利用することをお勧めします。全体的な請求額の節約は非常に重要になります。 、月額 4,000 ドル以上節約できることになります。 階層型ストレージへの取り組み 3 月に、Timescale プラットフォームの階層型ストレージ機能の初期バージョンを早期アクセスとしてリリースしました。多くの改良を経て、現在は一般公開されています。最初のリリース以来、私たちは階層型ストレージの安定性、信頼性、高速性を実現するために懸命に取り組んできました。 また、価格モデルについても長く熱心に検討し、低コストのストレージ層の価格を設定する複数の方法を一貫して繰り返しました。最後に、私たちは最も単純な方法、つまり圧縮前のデータ量に対する定額料金に落ち着きました。シンプルで予測可能な価格設定を重視していることはすでに述べましたが、GB/月あたりの価格をできるだけ低く設定することも重要でした。価格は 0.021 ドルでした。比較として、Amazon S3 にファイルを保存するとコストがかかります 。 0.023 ドル/GB/月 個人的に、私 (ヤニス) は、10 年以上クラウド ネイティブ ソリューションを構築するチームを率いてきたにもかかわらず、さまざまなクラウドの価格設定ページにある複数の料金表を時折再確認し、毎回、特に追加料金を探す必要があることを認めなければなりません。サービスの総コストを正確に計算したいと考えています。 Timescale では、データベース サービスを実行したり、ストレージ レイヤーに関する情報に基づいた選択を行うために、複雑なスプレッドシートを構築する必要はないと考えています。 開発者の作業を容易にするという当社の取り組みにより、定額料金は 1 GB/月あたり 0.021 ドルとなり、推測や隠れたコスト、クエリやデータ読み取りごとの料金は発生しません。 タイムスケール圧縮を適用する前のデータ量を意味します。たとえば、タイムスケール圧縮により、ハイパフォーマンス ストレージ層の 500 GB ボリュームは、圧縮されると最終的には 50 GB のディスク領域のみが必要になる場合があります。このデータを低コストのストレージに階層化することにした場合、請求額は元の 500 GB ボリュームに基づいて、月額 [500 GB * 0.021 ドル] のように計算されます。 圧縮前のデータ量とは、 階層型ストレージの仕組み: 舞台裏 Timescale に挿入されたすべてのデータは、最初に高性能ストレージ層に書き込まれます。最新のデータに高速なディスクを使用すると、最新の値の挿入およびクエリのパフォーマンスが最高になり、データ集約型アプリケーションのニーズに適した使用パターンになります。 逆に、低コストのストレージ層は、Amazon S3 上に構築されたオブジェクト ストアです。ただし、このオブジェクト ストアはデータをアーカイブするための外部バケットをはるかに超えたものであり、データベースの不可欠な部分です。データをこのオブジェクト ストレージ層に移動すると、データベースはすべてのセマンティクスとメタデータを完全に認識したままになり、(パフォーマンスは低下しますが) 標準 SQL を使用して通常どおりクエリを実行し続けることができます。 バックグラウンドでは、圧縮された列形式 (具体的には ) でデータを保存しています。データが階層化されると、チャンクは Timescale のネイティブの内部データベース形式 (通常は ) は非同期的に Parquet 形式に変換され、基礎となる S3 オブジェクトに保存されます。階層化されたチャンクがトランザクションによって高パフォーマンス層から削除される前に、低コストのストレージ層に永続的に保存されるようにするためのいくつかのメカニズムを構築しました。 Apache Parquet ネイティブ列圧縮 SQL クエリを実行すると、必要に応じて、高性能ストレージ層、オブジェクト ストレージ層、またはその両方からデータが透過的に取得されます。透過的とは、透過的を意味します。Timescale は、複雑な述語、JOIN、CTE、ウィンドウ処理、ハイパー関数などを含む、標準データと階層化データにわたる任意の複雑なクエリをサポートします。 以下のクエリ例 ( 句を使用) では、データベースがオブジェクト ストレージ層のデータにアクセスしているときに、クエリ プランに どのように含まれているかがわかります。この例では、 と 標準の Postgres テーブル (高性能ストレージのみに存在) ですが、 は両方のストレージ層にまたがるハイパーテーブルです。このクエリを ハイパーテーブルに対して実行すると、そのチャンクのうち 3 つが標準ストレージから読み取られ、5 つのチャンクがオブジェクト ストレージから読み取られました。 EXPLAIN Foreign Scan devices sites metrics metrics EXPLAIN SELECT time_bucket('1 day', ts) as day, max(value) as max_reading, device_id FROM metrics JOIN devices ON metrics.device_id = devices.id JOIN sites ON devices.site_id = sites.id WHERE sites.name = 'DC-1b' GROUP BY day, device_id ORDER BY day; QUERY PLAN ---------------------------------------------------------- GroupAggregate Group Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Sort Sort Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Hash Join Hash Cond: (_hyper_5666_706386_chunk.device_id = devices.id) -> Append -> Seq Scan on _hyper_5666_706386_chunk -> Seq Scan on _hyper_5666_706387_chunk -> Seq Scan on _hyper_5666_706388_chunk -> Foreign Scan on osm_chunk_3334 -> Hash -> Hash Join Hash Cond: (devices.site_id = sites.id) -> Seq Scan on devices -> Hash -> Seq Scan on sites Filter: (name = 'DC-1b'::text) 上記のクエリ プランでは、 底なしのオブジェクト ストレージ層からのデータのフェッチに対応します。 Foreign Scan on osm_chunk_3334 チャンクの処理がクエリの時間枠を超えないようにするには、チャンクの除外を実行して、クエリを満たすために必要なチャンクのみに触れます。データベースは、オブジェクト ストレージ内の行グループと列オフセットの「マップ」を構築するために、さまざまな形式のメタデータを保存します。 さらに、クエリを実行するときは、読み取るデータがさらに選択されます。クエリが一定範囲の行と少数の列のみを操作する場合、データのそのサブセットのみが、低コストのストレージ層の背後にある S3 オブジェクトから読み取られます。 たとえば、上記では、 と 列のみがオブジェクト ストレージ層から読み取られます。追加の時間ベースの フィルターが含まれていた場合、データベースはまずそのメタデータ (高性能ストレージに保存され、メモリにキャッシュされた) を使用して、クエリを実行するために読み取る必要がある Parquet ファイルと行グループをさらに減らします。すべては、PostgreSQL を通じてこの底なしのストレージに透過的にアクセスする場合でも、クエリのレイテンシを短縮するためです。 device_id value WHERE 階層型ストレージを試してみる 履歴データに関するストレージの決定にコストがかかる必要はありません。 Timescale では、価格設定の問題のない低コストの無限ストレージ層にアクセスできるようになり、アプリケーションのパフォーマンスを損なうことなく、手頃な価格でデータベース ストレージを拡張できます。 これが自分のユースケースに適したソリューションかどうか疑問に思っている場合は、 より実用的な観点を探している場合は、次のように実験することもできます。 。 詳細とユースケースの適合については、ドキュメントを参照してください。 無料トライアルを利用して、Timescale プラットフォームで階層型ストレージを無料でご利用いただけます (クレジット カードは必要ありません) - ヤニス・ルソス、カルロタ・ソト、アナ・タバレス著。 こちらでも公開しております。