PGSimCity - แสดงภาพวิธีการทำงานของ PostgreSQL เป็นเมือง 3D ที่สำรวจได้

 (nikolays.github.io)
2 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็น ซิมูเลชัน 3D เพื่อการศึกษา ที่นำการเชื่อมต่อ/แบ็กเอนด์/หน่วยความจำร่วม/WAL/สตอเรจ/checkpoint/autovacuum/replication ของ PostgreSQL มาแทนด้วยอาคารและย่านต่าง ๆ โดยอาคารและแอนิเมชันแต่ละส่วนสอดคล้องกับกลไกฐานข้อมูลจริง
  • ย่อค่าตัวเลขและสเกลลงเพื่อให้สามารถ สังเกตการทำงานภายในด้วยสเกลเวลาที่ช้าลง เช่น การแทนที่แบบ clock-sweep ของ shared_buffers, การเขียนและ flush WAL, การ pacing ของ checkpoint, xmin horizon และ table bloat
  • ไม่ใช่ emulator ที่รันโค้ด PostgreSQL จริง แต่เป็นโมเดลที่เขียนขึ้นเอง โดยอ้างอิงเอกสารและซอร์สของ PostgreSQL ผ่านการตรวจทานโดยผู้เชี่ยวชาญสามรอบและการ audit ด้านภาพแยกต่างหาก พร้อม 210 tests ที่ตรึงการคำนวณหลักและค่าขีดจำกัดไว้
  • สามารถรัน scenario เช่น buffer ไม่พอ, transaction ที่รันยาว, checkpoint storm, synchronous_commit=off, replay ของ replication ที่ช้า เพื่อดูโดยตรงว่า การตั้งค่าด้าน operation ส่งผลต่อ latency/bloat/durability/replication lag อย่างไร
  • เป็นแอปพลิเคชัน WebGL2 แบบ static ที่สร้างด้วย three.js/TypeScript/Vite และกำลังพิจารณาแนวทาง สถาปัตยกรรมแบบ hybrid ในอนาคตที่เชื่อมผลการรัน query และ plan จาก PostgreSQL บน WebAssembly จริงเข้ากับโมเดลภายในปัจจุบัน

วิธีแสดง PostgreSQL ในรูปแบบเมือง

  • PGSimCity เป็นโปรเจกต์ visualization เพื่อการศึกษาแบบอิสระ/ไม่แสวงหากำไร ที่ให้เดินสำรวจโครงสร้างภายในของ PostgreSQL ได้
  • ลานกลางเมืองแทน shared_buffers โดยความสูงของ page frame 1,024 เฟรมแสดงค่า clock-sweep usage_count และสีแสดงสถานะ buffer จริง
  • ย่านสีส้มทางตะวันออกคือ WAL, พื้นที่ขุดค้นใต้ลานคือ data directory และเมืองทางใต้แทน standby server ที่ replay WAL ที่ primary server ส่งมาโดยมีความหน่วงเล็กน้อย
  • ออกแบบมาเพื่อช่วยวิศวกรที่ยังไม่เคยดูแลฐานข้อมูลด้วยตนเองให้เข้าใจปรากฏการณ์ต่อไปนี้
    • เหตุผลที่ checkpoint ทำให้ latency พุ่งสูง
    • วิธีที่ transaction ที่ยังไม่จบทำให้ table bloat ดำเนินต่อไป
    • synchronous_commit ทำให้เกิดต้นทุนอะไรในตอน commit

ความถูกต้องและข้อจำกัดของโมเดล

  • PGSimCity ยังเป็น โมเดลระยะ 0.x และไม่ใช่ PostgreSQL emulator
    • ไม่ได้รันซอร์สโค้ด PostgreSQL
    • ปรับค่าตัวเลขและสเกลเวลาเพื่อให้มนุษย์มองเห็นการเปลี่ยนแปลงได้
    • ไม่ parse SQL หรือคำนวณผลลัพธ์ query จริง
  • ผ่านการตรวจทานโดยผู้เชี่ยวชาญสามรอบ โดยเทียบความถูกต้องของพฤติกรรม PostgreSQL กับ postgresql.org/docs และซอร์สโค้ด และแต่ละประเด็นที่พบจะถูกตรวจซ้ำโดยผู้ตรวจทานอีกคนที่ได้รับมอบหมายให้พยายามหักล้างประเด็นนั้น
  • ข้อกล่าวอ้างโดยนัยที่เกิดจากตำแหน่งอาคาร/ความใกล้เคียง/แอนิเมชัน ก็ผ่านการ audit แยกต่างหากด้วย
  • มี 210 tests และหากมี test ล้มเหลว CI build จะหยุดลง
    • จุดเริ่มต้น checkpoint ตาม WAL: max_wal_size / (1 + checkpoint_completion_target)
    • cache hit ratio: blks_hit / (blks_hit + blks_read)
    • ค่าสูงสุดของ clock-sweep usage_count: 5
  • ข้อผิดพลาดที่พบและกระบวนการแก้ไขถูกบันทึกไว้ใน commit history
  • การใช้งานแบบ touch ตรวจสอบแล้วเฉพาะบน Chrome mobile emulation เท่านั้น
  • พฤติกรรมที่ทำให้ง่ายขึ้นจะระบุไว้ใน inspector ของแต่ละ component

ความเป็นไปได้ในการผสานกับ engine จริง

  • ปัจจุบันใช้ simulation ที่เขียนเอง เพื่อแสดงขั้นตอนภายในที่ PostgreSQL ไม่เปิดเผยออกมาภายนอก เช่น กระบวนการที่ clock-sweep เลือก victim page ทีละ frame
  • หากรัน PostgreSQL จริงผ่าน WebAssembly เหมือน PGlite ก็สามารถให้ engine จริงจัดการผลลัพธ์ query และ execution plan ได้
  • ข้อมูลที่ engine จริงสามารถให้ใน browser จำกัดอยู่ในขอบเขตที่ PostgreSQL เปิดเผยภายนอก เช่น catalog, view pg_stat_*, EXPLAIN
  • วิธี hybrid ที่ให้การรันจริงและ plan ขับเคลื่อนการเคลื่อนไหวภายในโมเดลก็เป็นไปได้ แต่เป็นทิศทางในอนาคต ไม่ใช่คำมั่นว่าจะพัฒนาแน่นอน

ย่านและองค์ประกอบของเมือง

  • Client sky: การเชื่อมต่อที่เข้ามาจาก application layer
  • Postmaster: process ควบคุมที่สร้าง backend process สำหรับแต่ละ connection แต่ไม่เข้าถึงข้อมูลผู้ใช้โดยตรง
  • Backend row: backend process 16 ตัว แสดงสถานะปัจจุบันรวมถึง idle in transaction ด้วยไฟ
  • Shared memory plaza
    • shared_buffers
    • wal_buffers
    • ProcArray
    • lock table
    • CLOG
    • buffer mapping table
  • The excavation: ขอบเขตระหว่างพื้นที่ memory และพื้นที่ disk
  • Storage
    • heap file ที่ประกอบด้วย page ขนาด 8KiB
    • B-tree ในรูปแบบต้นไม้จริง
    • TOAST
    • FSM
    • visibility map
    • page cache ของระบบปฏิบัติการ
    • disk
  • WAL district: walwriter → segment pg_wal → archiver → walsender
  • Maintenance yard: checkpointer/background writer/autovacuum launcher และ worker
  • Standby: walreceiver/startup process ที่ replay WAL/ความหน่วงระหว่างสอง process
  • Query lab: แสดง statement ของ backend ที่เลือก โดยคลี่ออกเป็นขั้นตอน parse → rewrite → plan → execute

สีและความหมายเชิงภาพ

  • สีไม่ได้เป็นเพียงการตกแต่ง แต่สื่อสถานะและกลไก
    • WAL: สีส้ม
    • dirty page: สีแดง
    • clean page: สีน้ำเงิน
    • vacuum: สีม่วง
    • checkpoint: สีชมพู
    • background writer: สีฟ้าอมเขียว
    • replication: สีส้ม
    • storage: สีเขียว
    • index: สีอควา
    • lock: สีแดง
  • โครงสร้างใช้วัสดุแบบด้าน ส่วนองค์ประกอบที่มีความหมายใช้สีนีออน และตั้งค่าให้เฉพาะวัสดุที่เรืองแสงเท่านั้นที่เกิน threshold ของ bloom

Scenario ที่ลองรันเองได้

  • ลด shared_buffers เหลือ 64 pages
    • usage_count พังลง และ clock hand หมุนวนอย่างรวดเร็ว
    • เมื่อ clean page ที่จะ evict มีไม่พอ backend จะเริ่มเขียน dirty page ของตัวเองโดยตรง
  • เปิดใช้งาน long-running transaction
    • xmin horizon ของ ProcArray ลดลงและเปลี่ยนเป็นสีแดง
    • autovacuum worker วนไปเรื่อย ๆ แต่ไม่สามารถลบ tuple ที่ต้องทำความสะอาดได้
    • ตาราง sessions เกิด bloat และไม่ฟื้นกลับ
  • รัน Checkpoint storm
    • checkpointer เร่งความเร็ว และขั้นตอน fsync สั่นไหว
    • หลังจากนั้น full-page write จะไหลเข้าสู่ย่าน WAL จำนวนมาก
  • ตั้งค่า synchronous_commit=off
    • backend จะไม่รอที่ commit_wait
    • สามารถดูเงื่อนไขด้าน durability ที่แลกกับการตอบสนองทันทีได้พร้อมกัน
  • เปิดใช้งาน Slow replay
    • LSN sent/written/flushed/applied ของ standby server แยกห่างจากกัน
    • ความแตกต่างนี้สอดคล้องกับ replication lag ที่สังเกตได้จาก pg_stat_replication
  • กดปุ่ม G เพื่อลงไปยังมุมมองเดินระดับความสูง 1.7m และสำรวจ buffer กับอาคารในระดับสายตาได้

การสำรวจและการควบคุม

  • การควบคุมด้วยเมาส์และ touch
    • ลากซ้าย: เคลื่อนที่เหมือนจับแผนที่เลื่อน
    • ลากขวา: หมุนรอบเมือง
    • ล้อเมาส์: ซูมเข้า/ออกโดยอิงตำแหน่ง cursor
    • หนึ่งนิ้ว: เคลื่อนที่
    • สองนิ้ว: ซูมเข้า/ออก, หมุน, ปรับความเอียง
  • โหมดการเคลื่อนที่
    • W/A/S/D หรือปุ่มลูกศร: เคลื่อนที่
    • Space/E: ขึ้น
    • C/Q: ลง
    • Shift: เคลื่อนที่เร็ว
    • Alt: เคลื่อนที่ละเอียด
  • ปุ่มสำคัญ
    • F: สลับกล้องบิน/โคจร
    • G: เดินบนพื้น
    • H: กลับไปยังมุมมองเริ่มต้น
    • T: tour 14 บทที่นำชมทั้งเมือง
    • / หรือ Ctrl-K: ค้นหา component/setting/scenario
    • ?: แผนผัง keyboard และคำอธิบายสี
    • K หรือ P: pause/resume
    • ,/.: ปรับความเร็ว 0.1×~5×
    • 1~8: ไปยังย่าน clients/backends/shared buffers/WAL/storage/checkpointer/autovacuum/standby

License และ trademark

  • เผยแพร่ภายใต้ license Apache-2.0
  • ไม่มี code/asset/ภาพ/logo/character/audio/game content ของ SimCity
  • เป็นโปรเจกต์การศึกษาอิสระที่ไม่มีความสัมพันธ์ด้าน partnership/sponsorship/approval กับ Electronic Arts หรือ PostgreSQL project

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

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

 
GN⁺ 3 시간 전
ความเห็นจาก Hacker News

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

    • หน้าจอ 3D สวย ๆ 80% ถูกป๊อปอัปบังอยู่ ถ้ามีฟีเจอร์ลดสิ่งรบกวนให้เห็นชัด ๆ และทำให้ป๊อปอัปโปร่งแสงก็น่าจะดี
    • น่าลองเพิ่ม TTS ให้กับทัวร์ชม
    • ถ้าซอฟต์แวร์ต้องมี ฟีเจอร์ทัวร์ชม ก็อาจเป็นสัญญาณว่าต้องปรับ UX ถึงอยากแนะนำฟีเจอร์ใหม่ ผู้ใช้ก็มักจะค้นพบเองอย่างเป็นธรรมชาติเมื่อจำเป็น

  • ข้อจำกัดของสมองมนุษย์นั้นเหมือนกันทั้งฝั่งนักพัฒนาและผู้ใช้ ถึงจะสร้างของซับซ้อนด้วย LLM ได้ แต่ถ้าความซับซ้อนเชิงตกแต่งอย่าง greeble มากเกินระดับหนึ่ง มันก็ไม่รู้สึกเหมือนถูกออกแบบมาให้มนุษย์คนอื่นใช้งาน
    ถ้าทำโดยไม่มี LLM นักพัฒนาคงลดความซับซ้อนลงเพราะตัวเองก็ไม่อาจแบกแบบจำลองทางความคิดทั้งหมดไว้ในหัวได้ และผู้ใช้ก็มีข้อจำกัดแบบเดียวกัน ต่อให้พยายามทำความเข้าใจอุปมาอย่างแอนิเมชันกับแสงวิบวับ ความหมายก็ยังถูกกลบไป
    ไม่เข้าใจว่าทำไมโปรเซสใหม่ถึงเป็นสี่เหลี่ยมที่วิ่งผ่านท่อไปถึงตึก แล้วหลังจากนั้นสวิตช์พินบอลก็สว่างเป็นสีแดง พอกดอะไรสักอย่างก็มีป๊อปอัปเล็ก ๆ พร้อมย่อหน้าว่า "sessions is the victim" โผล่มาแวบเดียวแล้วหายไป ยิ่งทำให้งงกว่าเดิม
    มันอาจไม่ได้ตั้งใจทำมาเพื่อการสอน และอาจเป็นเพราะความรู้ฉันไม่พอ แต่ถ้ามองเป็นงานแปลกน่าสนใจก็ถือว่าเท่มาก

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

    • ลองกด T

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

    • ผมอยากทำเครื่องมือที่อธิบาย ระบบ deploy และการติดตามสถานะ ของ Fly.io ด้วยอุปมาเชิงภาพแบบ Factorio มาตลอด
    • อยากทำ เครื่องมือ visualization สำหรับ Kubernetes อยู่เรื่อย ๆ มีของที่มีอยู่แล้ว แต่ครั้งล่าสุดที่ดูยังไม่ค่อยน่าประทับใจนัก

  • มันคล้ายกับภาพที่ผมนึกในหัวมากเวลานั่งดีบักโปรแกรมด้วย gdb แบบจดจ่อสุด ๆ ถ้าได้สัมผัส การดีบักแบบ VR ด้วยกราฟิกแบบนี้ คงแทบไม่มีวิธีไหนดีกว่านี้แล้วสำหรับการเรียนรู้ codebase
    สงสัยว่าถ้าสร้างแผนที่ 3D จากโค้ดอะไรก็ได้ จะทำประสบการณ์ออกมาได้ดีแค่ไหน

  • ถ้านี่คือ ผลงาน vibe coding ที่ทำในเวลาไม่ถึง 48 ชั่วโมง ก็สงสัยว่าเนื้อหาถูกต้องจริงแค่ไหน มีความเสี่ยงจะพาไปสู่ข้อสรุปผิด ๆ หรือความรู้ครึ่ง ๆ กลาง ๆ หรือเปล่า

    • จะบอกว่าแน่ใจเต็มร้อยก็ไม่ได้ แต่คนที่ทำสิ่งนี้ รู้ Postgres ดีมาก
    • อยากรู้ว่ามีใครค้นพบหรือเรียนรู้อะไรที่เป็นรูปธรรมจากสิ่งนี้บ้าง สำหรับผมมันดูเหมือนของตกแต่งสไตล์ brutalist
    • ทุกวันนี้ ความแม่นยำของ LLM ก็ไม่ได้แย่ขนาดนั้น

  • ไม่น่าเชื่อว่า "Rendering The First Frame..." จะไม่ใช่ "Reticulating Splines..." UI เท่มาก

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

    • มุมซ้ายล่างมีปุ่มหยุดชั่วคราวกับปุ่ม ปรับความเร็วลงได้ถึง 0.1x อยู่สองปุ่ม บางองค์ประกอบของเมืองก็กดเพื่อปรับค่าได้ และผมเห็นแบบนั้นใน transactions/s ด้วย

  • มันดูเท่มากจริง ๆ ไม่กี่สัปดาห์ก่อนผมเริ่ม vibe coding Doom สำหรับ Beam ที่ให้เดินไปรอบ ๆ Beam VM เหมือนเดินในโรงงาน แล้วดูความเชื่อมโยงของโมดูลกับฟังก์ชัน ภาระการประมวลผล และข้อผิดพลาดที่มีประกายไฟพุ่งออกมา
    ยังทำไปได้ไม่มาก แต่ก็อยากพัฒนาต่อเพื่อหาเหตุผลซื้อชุดหูฟัง VR

  • ดูเหมือนจะทำขึ้นด้วยความช่วยเหลือของ AI ผมเองก็เคยใช้ AI ทำโปรเจกต์ vibe coding คล้ายกันเพื่ออธิบาย catastrophic forgetting
    ตอนนี้ถ้าอยากเรียนรู้อะไรจริง ๆ ก็พอใจที่มี AI คอยช่วยได้เสมอ สมัยก่อนหาข้อมูลดี ๆ ยาก แต่ตอนนี้คอขวดไม่ใช่ข้อมูลอีกต่อไป ย้ายไปอยู่ที่สมาธิและความริเริ่มของแต่ละคนแทน