6 ポイント 投稿者 GN⁺ 2024-05-21 | 1件のコメント | WhatsAppで共有

時系列データとは何か?

  • 時系列データとは、各データポイントにタイムスタンプが付与されたデータの集合
  • 例: 株価、機器やセンサーから返される温度および可用性データ、Webサイトのトラフィックデータ
  • 時系列処理には通常、時間で絞り込むクエリと、データを要約するための集計クエリが含まれる

PostgreSQLを使った時系列処理

  • PostgreSQLは、その拡張性とエコシステムのツール群により、あらゆるデータ処理に対応できる
  • Temboは、ユーザーがPostgreSQLエコシステムを簡単に利用できるようにすることを目標としている
  • 顧客からの最大の要望は、時系列データを保存・処理できるスタックだった

pg_timeseriesの構成要素

  • 時系列データを効率的に保存・クエリするための要件:
    • 時系列データを簡単に管理できること
    • 高スループットを処理できること
    • 範囲クエリに高速に応答できること
    • 大量データを効率的に保存できること
    • 複雑な分析関数を実行できること
  • PostgreSQLの基本機能:
    • ネイティブパーティショニング、多様なインデックス、マテリアライズドビュー、ウィンドウ/分析関数
  • 追加の拡張機能:
    • pg_partman: パーティション管理
    • pg_cron: ジョブスケジューリング
    • columnar: 圧縮
    • pg_ivm: インクリメンタルマテリアライズドビュー
    • pg_tier: 古いパーティションの長期オフロード

pg_timeseries: PostgreSQLで時系列データを管理する最もシンプルな方法

  • pg_timeseriesは複数の拡張機能の機能を組み合わせ、統合インターフェースを提供する
  • 始めるには、時間に関連する列でパーティショニングされたテーブルが必要
    CREATE TABLE measurements (  
      metric_name text,  
      metric_value numeric,  
      metric_time timestamptz NOT NULL  
    ) PARTITION BY RANGE (metric_time);  
    
    SELECT enable_ts_table('measurements');  
    
  • 重要な情報を提供するさまざまなビューを含む:
    SELECT table_id, table_size_bytes FROM ts_table_info;  
    SELECT * FROM ts_part_info;  
    
  • パーティションの圧縮および削除ポリシーを設定可能:
    SELECT set_ts_compression_policy('measurements', '90 days');  
    SELECT set_ts_retention_policy('measurements', '365 days');  
    
  • 追加の関数も提供:
    SELECT  
      locf(avg(metric_value)) OVER (ORDER BY metric_time) avg_val,  
      last(metric_name, metric_value) highest,  
      metric_time  
    FROM date_bin_table(NULL::measurements, '1 hour', '[2024-05-09,2024-06-07]');  
    

まだ始まったばかり

  • PostgreSQL向けの時系列拡張を構築するには、多くの構成要素が必要
  • コミュニティとともにオープンに構築していく計画
  • 現在のロードマップ:
    • 古いパーティションをS3のようなコールドストレージへオフロード
    • 効率的な分析のための近似関数
    • インクリメンタルマテリアライズドビュー
    • 古いパーティションのロールアップとロールオフ
    • 追加の分析ヘルパー関数
  • GitHub READMEに完全なロードマップがあり、ユーザー需要に応じて機能の優先順位を決定する

GN⁺の見解

  • 時系列データの重要性: IoT、金融、Web分析などさまざまな分野で、時系列データの重要性が高まっている。pg_timeseriesは、こうしたデータを効率的に管理できるツールを提供する。
  • PostgreSQLの拡張性: PostgreSQLの拡張機能を活用することで、多様なデータ処理に対応できる。pg_timeseriesは、これらの拡張機能を統合してユーザーの利便性を高める。
  • コミュニティとの協力: オープンソースとして開発されており、コミュニティのフィードバックを反映できる。これは機能改善やバグ修正に大いに役立つ。
  • 競合製品: TimescaleDBのような他の時系列データベースと比べると、ライセンス制限なしで利用できる利点がある。一方で、性能や機能面での比較検討は必要。
  • 導入時の検討事項: pg_timeseriesを導入する際は、既存データベースとの互換性、性能、保守コストなどを考慮する必要がある。また、時系列データの特性上、データ量が急増する可能性があるため、適切なストレージ管理も必要。

1件のコメント

 
GN⁺ 2024-05-21
Hacker Newsの意見

Hacker Newsコメントまとめ

  • Incremental Materialized Views

    • Incremental materialized views が中核機能で、データが入るたびに性能低下なく最新状態を維持できる。
    • pg_ivm のような実装を使うのか、自前で実装するのか気になる。
    • いつか PostgreSQL コアに ivm が含まれることを期待している。
  • TimescaleDBとの比較

    • TimescaleDB のライセンス制限により、圧縮、増分マテリアライズドビュー、無限ストレージなどの機能を使えない。
    • こうした機能がないと顧客の時系列データ要件を満たせないと判断し、PostgreSQL ライセンスの拡張を自ら構築した。
    • 無料版の TimescaleDB を使って 5 億件の観測データベースをシャーディングした経験がある。大きな問題なく動作した。
    • ベンチマークや比較結果があればよいと思う。引き続き注目したい。
  • Append-Onlyテーブル

    • PostgreSQL や他のデータベースにネイティブな append-only テーブルが追加される時期に来ている。
    • これは時系列データベースそのものではないが、標準化に関するロジックやアプローチに役立つはずだ。
  • 時系列データベースの進化

    • 時系列データベースは次のように進化している:
      • カラム指向ストレージと Parquet や Arrow のようなオープンフォーマットへの収束: InfluxDB 3.0, QuestDB
      • PostgreSQL 上への時系列機能の追加: Timescale, pg_timeseries
      • Prometheus エコシステムを中心とした観測プラットフォーム: Grafana, Victoria Metrics, Chronosphere
  • カラム指向ストレージの必要性

    • ほとんどの時系列クエリは集計クエリである。
    • そのため、最高クラスのカラム指向ストレージを活用するか構築するのが望ましい。
    • ClickHouse のような製品がなぜ PostgreSQL に存在しないのか疑問だ。
  • 役立つリンク

    • Trunk と pgt.dev を知ることができて感謝している。
  • ロードバランサーのログエントリ

    • ロードバランサーのログエントリ(ステータス、レスポンス本文、ヘッダーなど)を処理する際に、この拡張が有用か気になる。
    • カラム型データベースストレージのほうが、一般的な行指向データベースより効率的に思える。
    • ロードバランサーのログエントリは分析イベントに近いものとして扱えるかもしれない。
  • オープンソースの革新

    • PostgreSQL は常にオープンソースであり、非常に自由度の高いオープンソースライブラリを使ってきた。
    • レプリケーションから時系列サポートまで、さまざまな独占的あるいはソース公開型の拡張が存在してきた。
    • 今やそれらの独占的な拡張は、適切なオープンソースによって阻まれつつある。
  • PostgreSQLライセンス

    • PostgreSQL ライセンスを採用するのは良い決断だ。
  • サイトデザインとアプリUI

    • サイトデザインはよくできていて読みやすい。
    • アプリの UI もデモ画像を見る限り素晴らしく、試してみたいと思う。