pg_timeseries: ส่วนขยายโอเพนซอร์สสำหรับข้อมูลอนุกรมเวลาใน PostgreSQL

 (tembo.io)
6 คะแนน โดย GN⁺ 2024-05-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ข้อมูลอนุกรมเวลาคืออะไร?

  • ข้อมูลอนุกรมเวลาคือชุดของข้อมูลที่แต่ละจุดข้อมูลมีการประทับเวลาไว้
  • ตัวอย่าง: ราคาหุ้น, ข้อมูลอุณหภูมิและความพร้อมใช้งานที่ส่งกลับจากอุปกรณ์และเซ็นเซอร์, ข้อมูลทราฟฟิกของเว็บไซต์
  • งานด้านอนุกรมเวลามักรวมถึงคิวรีกรองตามเวลาและคิวรี aggregate เพื่อสรุปข้อมูล

งานด้านอนุกรมเวลาด้วย PostgreSQL

  • PostgreSQL สามารถรองรับงานด้านข้อมูลได้ทุกประเภทด้วยความสามารถในการขยายและเครื่องมือใน ecosystem
  • Tembo ตั้งเป้าให้ผู้ใช้สามารถใช้งาน ecosystem ของ PostgreSQL ได้อย่างง่ายดาย
  • ความต้องการที่ใหญ่ที่สุดจากลูกค้าคือสแตกที่สามารถจัดเก็บและประมวลผลข้อมูลอนุกรมเวลาได้

องค์ประกอบของ pg_timeseries

  • ข้อกำหนดสำหรับการจัดเก็บและคิวรีข้อมูลอนุกรมเวลาอย่างมีประสิทธิภาพ:
    • จัดการข้อมูลอนุกรมเวลาได้ง่าย
    • รองรับ throughput สูง
    • ตอบสนองต่อ range query ได้รวดเร็ว
    • จัดเก็บข้อมูลปริมาณมากได้อย่างมีประสิทธิภาพ
    • รันฟังก์ชันวิเคราะห์ที่ซับซ้อน
  • ความสามารถพื้นฐานของ PostgreSQL:
    • native partitioning, ดัชนีหลายประเภท, materialized views, ฟังก์ชัน window/analytic
  • ส่วนขยายเพิ่มเติม:
    • pg_partman: จัดการพาร์ทิชัน
    • pg_cron: ตั้งเวลางาน
    • columnar: การบีบอัด
    • pg_ivm: incremental materialized views
    • pg_tier: offload พาร์ทิชันเก่าเพื่อเก็บระยะยาว

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');
  • มี views หลายแบบเพื่อแสดงข้อมูลสำคัญ: 
    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 ต้องใช้หลายองค์ประกอบ
  • มีแผนจะพัฒนาอย่างเปิดเผยร่วมกับชุมชน
  • โรดแมปปัจจุบัน:
    • offload พาร์ทิชันเก่าไปยัง cold storage อย่าง S3
    • ฟังก์ชันประมาณค่าเพื่อการวิเคราะห์ที่มีประสิทธิภาพ
    • incremental materialized views
    • rollup และ rolloff ของพาร์ทิชันเก่า
    • ฟังก์ชันตัวช่วยด้านการวิเคราะห์เพิ่มเติม
  • มีโรดแมปฉบับเต็มอยู่ใน GitHub README และจะจัดลำดับความสำคัญของฟีเจอร์ตามความต้องการของผู้ใช้

ความเห็นของ GN⁺

  • ความสำคัญของข้อมูลอนุกรมเวลา: ความสำคัญของข้อมูลอนุกรมเวลาเพิ่มขึ้นในหลากหลายด้าน เช่น IoT การเงิน และการวิเคราะห์เว็บ โดย pg_timeseries มอบเครื่องมือสำหรับจัดการข้อมูลประเภทนี้อย่างมีประสิทธิภาพ
  • ความสามารถในการขยายของ PostgreSQL: สามารถใช้ส่วนขยายของ PostgreSQL เพื่อรองรับงานด้านข้อมูลที่หลากหลาย และ pg_timeseries ก็รวมความสามารถเหล่านี้เข้าด้วยกันเพื่อเพิ่มความสะดวกให้ผู้ใช้
  • ความร่วมมือกับชุมชน: พัฒนาในรูปแบบโอเพนซอร์ส จึงสามารถนำฟีดแบ็กจากชุมชนมาปรับใช้ได้ ซึ่งช่วยอย่างมากต่อการปรับปรุงฟีเจอร์และการแก้บั๊ก
  • ผลิตภัณฑ์คู่แข่ง: เมื่อเทียบกับฐานข้อมูลอนุกรมเวลาอื่นอย่าง TimescaleDB มีข้อดีคือใช้งานได้โดยไม่มีข้อจำกัดด้านไลเซนส์ แต่ยังต้องพิจารณาเปรียบเทียบด้านประสิทธิภาพและฟีเจอร์
  • ข้อควรพิจารณาในการนำไปใช้: เมื่อนำ pg_timeseries ไปใช้ ควรพิจารณาความเข้ากันได้กับฐานข้อมูลเดิม ประสิทธิภาพ และค่าใช้จ่ายในการดูแลรักษา นอกจากนี้ เนื่องจากข้อมูลอนุกรมเวลามีแนวโน้มเพิ่มขึ้นอย่างรวดเร็ว จึงจำเป็นต้องมีการจัดการสตอเรจอย่างเหมาะสม

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-05-21
ความเห็นจาก Hacker News

สรุปรวมคอมเมนต์จาก Hacker News

  • Incremental Materialized Views

    • Incremental materialized views เป็นฟีเจอร์สำคัญ เพราะช่วยให้ข้อมูลอัปเดตเป็นปัจจุบันได้ตลอดเมื่อมีข้อมูลใหม่เข้ามา โดยไม่ทำให้ประสิทธิภาพลดลง
    • น่าสงสัยว่าจะใช้ implementation อย่าง pg_ivm หรือจะพัฒนาเอง
    • หวังว่าสักวันหนึ่ง ivm จะถูกรวมเข้าไปใน PostgreSQL core

  • การเปรียบเทียบกับ TimescaleDB

    • เนื่องจากข้อจำกัดด้านไลเซนส์ของ TimescaleDB จึงไม่สามารถใช้ฟีเจอร์อย่าง compression, incremental materialized views และ infinite storage ได้
    • มองว่าหากไม่มีฟีเจอร์เหล่านี้ ก็จะไม่สามารถตอบโจทย์ความต้องการด้านข้อมูล time-series ของลูกค้าได้ จึงเลือกสร้างส่วนขยายภายใต้ไลเซนส์ PostgreSQL ขึ้นมาเอง
    • เคยมีประสบการณ์ใช้ TimescaleDB รุ่นฟรีเพื่อทำ sharding ให้ฐานข้อมูลที่มี observation 500 ล้านรายการ และมันก็ทำงานได้โดยไม่มีปัญหาใหญ่
    • อยากเห็น benchmark และผลการเปรียบเทียบเพิ่มเติม และจะติดตามต่อไป

  • ตารางแบบ Append-Only

    • ถึงเวลาแล้วที่ PostgreSQL และฐานข้อมูลอื่น ๆ ควรมีตารางแบบ append-only native
    • แม้มันจะไม่ใช่ฐานข้อมูล time-series โดยตรง แต่ก็น่าจะช่วยในเชิงตรรกะและแนวทางที่เกี่ยวข้องกับการทำให้เป็นมาตรฐานได้

  • วิวัฒนาการของฐานข้อมูล Time-Series

    • ฐานข้อมูล time-series กำลังพัฒนาไปในทิศทางดังนี้:
      • มุ่งสู่ columnar storage และ open formats อย่าง Parquet และ Arrow: InfluxDB 3.0, QuestDB
      • เพิ่มความสามารถด้าน time-series บน PostgreSQL: Timescale, pg_timeseries
      • แพลตฟอร์ม observability ที่มี ecosystem ของ Prometheus เป็นศูนย์กลาง: Grafana, Victoria Metrics, Chronosphere

  • ความจำเป็นของ Columnar Storage

    • query ของ time-series ส่วนใหญ่เป็น query แบบ aggregate
    • เพราะแบบนั้น การใช้หรือสร้าง columnar storage ระดับท็อปจึงเป็นทางเลือกที่ดี
    • จึงสงสัยว่าทำไม PostgreSQL ถึงยังไม่มีสิ่งที่คล้าย ClickHouse

  • ลิงก์ที่มีประโยชน์

    • ขอบคุณที่ทำให้ได้รู้จัก Trunk และ pgt.dev

  • รายการล็อกจาก Load Balancer

    • สงสัยว่าส่วนขยายนี้จะมีประโยชน์หรือไม่เมื่อต้องจัดการรายการล็อกจาก load balancer เช่น สถานะ response body และ headers
    • ดูเหมือนว่า columnar database storage จะมีประสิทธิภาพมากกว่าฐานข้อมูลแบบ row-based ทั่วไป
    • รายการล็อกจาก load balancer อาจมองได้ว่าคล้ายกับ analytics events

  • นวัตกรรมโอเพนซอร์ส

    • PostgreSQL เป็นโอเพนซอร์สมาโดยตลอด และใช้งานไลบรารีโอเพนซอร์สที่เปิดกว้างมากมาเสมอ
    • ที่ผ่านมามีส่วนขยายแบบ proprietary และ source-available หลากหลาย ตั้งแต่ replication ไปจนถึงการรองรับ time-series
    • ตอนนี้ส่วนขยายแบบ proprietary เหล่านี้กำลังถูกท้าทายโดยโอเพนซอร์สที่เหมาะสม

  • ไลเซนส์ PostgreSQL

    • การใช้ไลเซนส์ PostgreSQL เป็นการตัดสินใจที่ดี

  • ดีไซน์เว็บไซต์และ UI ของแอป

    • ดีไซน์ของเว็บไซต์ทำได้ดีและอ่านง่าย
    • UI ของแอปก็ดูยอดเยี่ยมจากภาพเดโม และอยากลองใช้งาน