GitHub ทำสถิติ 7.38 พันล้านคอมมิตในเดือนกันยายน ปรับโครงสร้างระบบจัดเก็บโค้ด

นักพัฒนาและ AI agent สร้างคอมมิตบน GitHub รวม 7.38 พันล้านครั้งในเดือนกันยายน 2026 เพิ่มขึ้นมากกว่า 5 เท่าจากปีก่อน ทำให้บริษัทกำลังปรับโครงสร้างระบบจัดเก็บโค้ด

ไบรอัน เซเลนซา (Brian Celenza) วิศวกรซอฟต์แวร์อาวุโสของ GitHub ระบุในบล็อกวิศวกรรมเมื่อวันที่ 6 ตุลาคมว่า บริษัทกำลังสร้างโครงสร้างพื้นฐาน Git ขึ้นใหม่ ระบบใหม่นี้จะจัดเก็บข้อมูลหลักของรีโพซิทอรีไว้บน Azure Blob Storage ของไมโครซอฟท์ (Microsoft) และแยกชั้นประมวลผลคำขอออกจากกัน โดยยังคงรองรับสาขา การตรวจสอบโค้ด และกฎการป้องกัน พร้อมให้บริการต่อเนื่องระหว่างดำเนินงาน

กิจกรรม Git รายเดือนบน GitHub เพิ่มจาก 21.82 พันล้านครั้งในเดือนกันยายน 2025 เป็น 47.33 พันล้านครั้งในเดือนสิงหาคม 2026 หรือมากกว่าสองเท่า ส่วนจำนวนการพุชต่อเดือนในช่วงเดียวกันเพิ่มจาก 690 ล้านครั้งเป็น 3.35 พันล้านครั้ง คิดเป็น 4.9 เท่า การพุชคือการส่งการเปลี่ยนแปลงโค้ดจากนักพัฒนาไปยังรีโพซิทอรีระยะไกล

งานอัตโนมัติและการรวมโค้ดก็เพิ่มขึ้นเช่นกัน ในเดือนกันยายน 2026 การทำงานของ GitHub Actions มีจำนวน 3.26 พันล้านครั้ง เพิ่มขึ้นมากกว่า 4 เท่าจากปีก่อน ขณะที่จำนวนการรวม pull request เพิ่มขึ้นเกือบ 4 เท่า รีโพซิทอรีแห่งเดียวที่มีคำขอมากที่สุดได้รับคำขอประมาณ 1 พันล้านครั้งในเดือนสิงหาคม

ระบบเดิมที่ชื่อ Spokes เก็บสำเนารีโพซิทอรีทั้งหมดไว้ในดิสก์ภายในของเซิร์ฟเวอร์ไฟล์หลายเครื่อง โดยมีสำเนาพื้นฐาน 5 ชุดเพื่อเพิ่มความทนทานของข้อมูลและกระจายคำขออ่าน อย่างไรก็ตาม การพุชต้องได้รับการยืนยันจากสำเนาส่วนใหญ่

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

โครงสร้างใหม่แยกการจัดเก็บข้อมูลออกจากการประมวลผลคำขอ Azure Blob Storage จะเก็บข้อมูลหลักของรีโพซิทอรี ขณะที่ worker สำหรับประมวลผลซึ่งมีขนาดเบาจะเก็บข้อมูลไว้ในแคชเพื่อรองรับคำขออ่าน เมื่อความต้องการอ่านเพิ่มขึ้น บริษัทสามารถเพิ่ม worker แทนการเพิ่มสำเนารีโพซิทอรี และหาก worker ขัดข้อง worker ตัวใหม่จะดึงข้อมูลจากชั้นจัดเก็บเพื่อรับช่วงคำขอต่อ

สำหรับการเขียน ระบบจะรวมขั้นตอนประสานงานไว้ที่การอัปเดตตำแหน่งที่สาขาอ้างอิง ส่วนการจัดเก็บข้อมูล การตรวจสอบการเชื่อมโยง และการตรวจหาข้อมูลลับจะทำงานขนานกับงานเขียนอื่น ขณะที่ worker อีกชุดรับผิดชอบการบีบอัดข้อมูลและลบออบเจ็กต์ที่ไม่จำเป็น

GitHub ระบุว่าการทดสอบประสิทธิภาพภายในพบว่าอัตราการประมวลผลการเขียนเพิ่มขึ้นสูงสุด 35 เท่า อย่างไรก็ตาม ผลดังกล่าวมาจากการทดสอบภายใน ไม่ใช่การวัดหลังเปลี่ยนระบบที่ให้บริการจริง บริษัทยังไม่ได้เปิดเผยกำหนดการเปลี่ยนระบบทั้งหมด