10 คะแนน โดย GN⁺ 2025-03-04 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • pgRouting เป็นส่วนขยายของ Postgres ที่โดยหลักแล้วใช้ในระบบสารสนเทศภูมิศาสตร์ (GIS) เพื่อค้นหาเส้นทางที่สั้นที่สุดระหว่างสองจุด
  • อย่างไรก็ตาม pgRouting ยังสามารถนำไปใช้จัดการข้อมูลที่มีโครงสร้างแบบกราฟได้หลากหลาย นอกเหนือจากข้อมูลเชิงพื้นที่
  • สามารถใช้เป็นทางเลือกแบบเบากว่าสำหรับฐานข้อมูลกราฟเฉพาะทางอย่าง Apache AGE หรือ Neo4j ได้

แนะนำ pgRouting

  • pgRouting เป็นส่วนขยายของ PostGIS ที่มอบความสามารถด้านการทำ routing เชิงภูมิสารสนเทศ
  • ทำให้สามารถคำนวณเส้นทางที่สั้นที่สุด วิเคราะห์เครือข่าย และแก้ปัญหา routing ที่ซับซ้อนได้
  • โดยมากถูกใช้งานใน GIS เช่น การค้นหาเส้นทางที่สั้นที่สุดระหว่างสองตำแหน่ง

การเชื่อมโยงกับกราฟ

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

ตัวอย่างการใช้งาน pgRouting นอกเหนือจาก GIS

  • การจัดตารางงาน

    • ในโครงการ งานต่าง ๆ มีความสัมพันธ์แบบพึ่งพากัน ซึ่งก่อให้เกิด กราฟไม่มีวัฏจักรแบบมีทิศทาง (DAG)
      • โหนดแทนงาน
      • เอดจ์แทนความสัมพันธ์แบบพึ่งพา
    • หนึ่งในความท้าทายหลักของการบริหารโครงการคือการหา 'critical path' ที่กำหนดระยะเวลารวมของทั้งโครงการ
    • สามารถใช้ pgRouting เพื่อจำลองความสัมพันธ์แบบพึ่งพาของงาน และหา critical path ด้วยอัลกอริทึมกราฟได้
  • การทำ reverse proxy routing ตามการจัดสรรทรัพยากร

    • ในระบบแบบกระจาย การจัดสรรทรัพยากรระหว่างโหนดต่าง ๆ ในเครือข่ายอย่างมีประสิทธิภาพเป็นสิ่งสำคัญ
    • แต่ละโหนดอาจแทนตำแหน่งทางกายภาพหรือกระบวนการคอมพิวต์ ส่วนเอดจ์แทนเส้นทางการเคลื่อนย้ายข้อมูลระหว่างโหนด
    • ตัวอย่างเช่น ในโครงสร้างพื้นฐานคลาวด์ สามารถใช้ pgRouting เพื่อกำหนดเส้นทางข้อมูลหรือภาระงานคอมพิวต์ระหว่างเซิร์ฟเวอร์แบบกระจายผ่านเส้นทางที่มีประสิทธิภาพที่สุด
  • เอนจินแนะนำแบบ YouTube

    • ในเอนจินแนะนำหรืออัลกอริทึมค้นหาที่ใช้ knowledge graph สามารถใช้ pgRouting เพื่อสร้างความสัมพันธ์ระหว่างเอนทิตีและเหตุการณ์ได้
    • ตัวอย่างเช่น ในอัลกอริทึมแนะนำของ YouTube:
      • โหนด แทนเอนทิตีอย่างผู้ใช้ วิดีโอ หมวดหมู่ เป็นต้น
      • เอดจ์ แทนความสัมพันธ์ เช่น ปฏิสัมพันธ์ระหว่างผู้ใช้กับวิดีโอ หรือการที่วิดีโออยู่ในหมวดหมู่เดียวกัน
    • โครงสร้างกราฟลักษณะนี้ช่วยให้สามารถมอบคำแนะนำที่ปรับให้เหมาะกับผู้ใช้แต่ละรายได้

ข้อมูลเพิ่มเติมเกี่ยวกับ pgRouting

  • pgRouting เป็นส่วนขยายอันทรงพลังของ Postgres ที่สามารถใช้แก้ปัญหาหลากหลายแบบที่อิงกับกราฟได้
  • ดูรายละเอียดเพิ่มเติมได้ที่ เอกสารทางการของ pgRouting

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

 
curiosityprocessor 2025-03-05

มีใครเคยนำ apache age หรือ pgRouting ไปใช้จริงบ้างไหมครับ?
ที่บริษัทกำลังจะนำ Graph DB มาใช้ โดยเดิมก็ใช้ Postgres เป็น RDB อยู่แล้ว
แม้ plugin/extension จะทำให้ใช้ Postgres "ให้เหมือนเป็น Graph DB" ได้ แต่ได้ยินมาว่าประสิทธิภาพจริงยังออกมาไม่ดี เลยกำลังชั่งใจว่าจะใช้ Neo4j ดีไหม แต่ดูเหมือนว่าความเห็นใน Hacker News เองก็มีคนไม่ค่อยพอใจกับ Neo4j เหมือนกัน

 
GN⁺ 2025-03-04
ความคิดเห็นจาก Hacker News
  • เมื่อห้าปีก่อน เคยผิดหวังกับฐานข้อมูลและไลบรารี Graph จึงพยายามวาง DBMS ที่ไม่ใช่ Graph หลายตัวไว้หลังอินเทอร์เฟซ Python ที่คล้ายกับ NetworkX

    • Neo4J ล่มกับทุกกราฟ ขณะที่ SQLite และ Postgres เป็นตัวเลือกที่เหมาะกับงานประมวลผลเครือข่ายมากกว่า
    • เมื่อความเข้ากันได้กับ Postgres เพิ่มขึ้น จึงสงสัยว่าโครงการนี้คุ้มค่าที่จะรื้อฟื้นหรือไม่
    • มี Graph DB มากขึ้นอย่าง MemGraph ที่เข้ากันได้กับ CYPHER และอาจทำงานได้ดีกว่า Neo4J
    • เป้าหมายคือดูว่า pgrouting เป็นเครื่องมือที่ดีสำหรับสร้าง memory layer สำหรับ AI/agent หรือไม่
    • ผลลัพธ์เบื้องต้นดูมีแนวโน้มที่ดี และจะติดตามต่อด้วยบทความอื่นในเร็ว ๆ นี้
    • มีส่วนขยายที่น่าสนใจอย่าง onesparse ที่อิงกับ SuiteSparse
  • Supabase ยังคงปล่อยคอนเทนต์ดี ๆ ที่เกี่ยวข้องกับ PostGIS อย่างต่อเนื่อง

    • มีเนื้อหาเกี่ยวกับการเสิร์ฟไทล์โดยตรงหรือการ (ใช้ผิดวัตถุประสงค์) ฟีเจอร์ในบริบทภูมิสารสนเทศของ PG
    • ไม่ได้ล้ำหรือซับซ้อนมาก แต่สนุกและกระตุ้นความคิด
    • ชื่นชมที่มักโพสต์คอนเทนต์ที่ช่วยจุดประกายความสนใจในการทำงานกับฐานข้อมูลอยู่บ่อย ๆ
  • สงสัยมาตลอดว่าทำไมถึงไม่มี "SQLite สำหรับกราฟ"

    • สงสัยว่ามีรูปแบบการจัดเก็บบางอย่างที่ขัดขวางโซลูชันแบบ in-process ที่มีสตอเรจบนดิสก์หรือไม่
  • กำลังทำโปรเจ็กต์ Graph DB บน Postgres แบบเรียบง่ายอยู่

    • สำหรับงานเดียวกัน คำสั่ง query และโครงสร้างตารางเรียบง่ายกว่ามาก
  • อยากฟังความเห็นเกี่ยวกับการเก็บ roaring bitmap ไว้ในคอลัมน์ bytea ของ postgres เพื่อแทน adjacency matrix

    • เนื่องจาก RDS รองรับ plrust และ SPI ของ PostgreSQL จึงคิดว่าน่าจะสร้างด้วย croaring-rs ได้
    • สามารถแทนกราฟจำนวนมากได้ โดยแต่ละกราฟถูกกำหนดให้กับ tenant (กรณีใช้งานบริษัท/B2B SaaS)
    • ใช้ plrust เพื่อเก็บ roaring bitmap ใน bytea บนเซิร์ฟเวอร์ DB และใช้ SPI เพื่อลด network overhead
    • PostgreSQL ให้ความปลอดภัยระดับทรานแซกชัน และยังรองรับข้อมูลแบบคอลัมน์อื่น ๆ เช่น JSONB สำหรับ query tenant ID column และ relationship metadata
    • ต้องรองรับ tenant graph จำนวนมาก และใช้งาน citus อยู่แล้ว จึงคิดว่าน่าจะทำได้ในสเกลใหญ่
    • คิดว่าน่าจะต้องสร้าง operator class บางส่วนเพื่อทำดัชนีความสัมพันธ์ให้ดีขึ้น
    • รู้จัก pg_roaringbitmap แต่ใช้ int64 และอยากเริ่มจากบน RDS มากกว่า
    • ใช้ PostgreSQL อย่างลึกซึ้งอยู่แล้วโดยไม่ใช้ Neo4J (เช่น ทำงานกับตารางขนาด ~20+ TB)
    • ขอบคุณผู้เขียนบล็อกโพสต์นี้มาก
    • ดูเหมือนว่าสามารถใช้ pgRouting เป็น Graph DB ได้ จึงเพิ่มเข้าไปในรายการทดสอบ
  • สงสัยว่ามีใครมีความเห็นเกี่ยวกับ "Apache AGE" หรือไม่

    • Apache AGE™ คือ PostgreSQL ที่มอบความสามารถของฐานข้อมูลกราฟ
  • สงสัยว่าเมื่อดูแค่ data model (เช่น ไม่รวม query language) แล้ว มีความแตกต่างจริงหรือไม่ระหว่างฐานข้อมูล "กราฟ" กับฐานข้อมูล "SQL ทั่วไป"

  • สงสัยว่ามีใครมีประสบการณ์ใช้ PgRouting เพื่อสร้าง isochrone หรือไม่

    • มีกรณีใช้งานสำหรับสร้างแผนที่ isochrone สำหรับการเดิน ปั่นจักรยาน ฯลฯ
    • หากเป็นไปได้ อยากใช้แค่ Postgres และหลีกเลี่ยงโครงสร้างพื้นฐานอื่นอย่าง Valhalla, OpenTripPlanner, OpenRouteService
  • Postgres มักมีส่วนขยายที่เปิดโอกาสใหม่ ๆ ในการทำ data modeling อยู่เสมอ

    • สงสัยว่าเมื่อเทียบกับความสามารถด้านกราฟของ CedarDB (เข้ากันได้กับ Postgres) แล้วจะอยู่ในระดับไหน