การแบ่งพาร์ติชัน PostgreSQL สำหรับตารางเหตุการณ์ในการบันทึกการตรวจสอบ

ทำไมตารางเหตุการณ์และการตรวจสอบถึงเป็นปัญหา

ตารางเหตุการณ์ (event) และตารางบันทึกการตรวจสอบ (audit) ดูคล้ายกัน แต่มีเหตุผลการมีอยู่ที่ต่างกัน

ตารางเหตุการณ์บันทึกสิ่งที่เกิดขึ้น: การเข้าชมหน้า, อีเมลที่ส่ง, การเรียก webhook, งานที่รัน ในขณะที่ตารางตรวจสอบบันทึกว่าใครเปลี่ยนอะไรและเมื่อไหร่: การเปลี่ยนสถานะ, อัปเดตสิทธิ์, การอนุมัติจ่ายเงิน มักมีรายละเอียด “ก่อน” และ “หลัง” ด้วย

ทั้งสองโตเร็วเพราะเป็นแบบ append-only แทบไม่ค่อยลบแถวทีละแถว และแถวใหม่เข้ามาตลอดเวลา แม้ผลิตภัณฑ์ขนาดเล็กก็สามารถสร้างบันทึกเป็นล้านแถวภายในสัปดาห์ได้เมื่อนับงานแบ็กกราวด์และการเชื่อมต่อภายนอก

ความเจ็บปวดจะปรากฏในงานประจำวัน หน้าแอดมินต้องการฟิลเตอร์ที่ตอบสนองเร็วเช่น “ข้อผิดพลาดเมื่อวาน” หรือ “การกระทำโดยผู้ใช้คนนี้” เมื่อโตขึ้น หน้าพื้นฐานเหล่านั้นเริ่มหน่วง

โดยปกติคุณจะสังเกตเห็นอาการบางอย่างก่อน:

• ฟิลเตอร์ใช้เวลาหลายวินาที (หรือหมดเวลา) แม้ช่วงวันที่จะแคบ
• ดัชนีโตมากจนการแทรกช้าลงและค่าใช้จ่ายพื้นที่จัดเก็บเพิ่มขึ้น
• VACUUM และ autovacuum ใช้เวลานานขึ้น และคุณเริ่มเห็นงานบำรุงรักษา
• การเก็บข้อมูลเสี่ยง: การลบแถวเก่าใช้เวลานานและสร้าง bloat

การพาร์ติชันเป็นวิธีหนึ่งในการจัดการ พูดง่าย ๆ คือ แยกตารางใหญ่หนึ่งตารางออกเป็นหลายตารางย่อย (พาร์ติชัน) ที่แชร์ชื่อเชิงตรรกะ PostgreSQL จะกำหนดแถวใหม่แต่ละแถวไปยังพาร์ติชันที่ถูกต้องตามกฎ โดยทั่วไปใช้เวลามาเป็นตัวกำหนด

นั่นคือเหตุผลที่ทีมสนใจการแบ่งพาร์ติชัน PostgreSQL สำหรับตารางเหตุการณ์: มันช่วยเก็บข้อมูลล่าสุดเป็นก้อนเล็ก ๆ ทำให้ PostgreSQL สามารถข้ามพาร์ติชันทั้งก้อนเมื่อคำค้นต้องการเพียงช่วงเวลาเดียว

การพาร์ติชันไม่ใช่ปุ่มวิเศษที่ทำให้เร็วขึ้นทันที มันช่วยได้มากสำหรับคำค้นเช่น “7 วันที่ผ่านมา” และทำให้การเก็บข้อมูลง่ายขึ้น (การทิ้งพาร์ติชันเก่าเร็ว) แต่ก็สร้างปัญหาใหม่ได้:

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

ถ้าแผงแอดมินของคุณพึ่งพาฟิลเตอร์ตามเวลาและกฎการเก็บข้อมูลที่แน่นอน การพาร์ติชันอาจให้ผลดีจริง หากคำค้นส่วนใหญ่คือ “หาการกระทำทั้งหมดโดยผู้ใช้ X ในประวัติทั้งหมด” มันอาจสร้างปัญหาหาก UI และดัชนีออกแบบไม่ดี

รูปแบบการเข้าถึงทั่วไปสำหรับบันทึกและการตรวจสอบ

ตารางเหตุการณ์และการตรวจสอบเติบโตในทิศทางเดียว: ขึ้น พวกมันรับการแทรกสม่ำเสมอและแทบไม่มีการอัปเดต ส่วนใหญ่เขียนครั้งเดียวแล้วอ่านทีหลังเมื่อซัพพอร์ต, ทบทวนเหตุการณ์, หรือตรวจสอบการปฏิบัติตามข้อกำหนด

รูปทรง append-only นี้สำคัญ ประสิทธิภาพการเขียนเป็นประเด็นเสมอเพราะการแทรกเกิดตลอดวัน ขณะที่ประสิทธิภาพการอ่านสำคัญเป็นช่วง ๆ (เมื่อซัพพอร์ตหรือตัวปฏิบัติการต้องคำตอบเร็ว)

การอ่านส่วนใหญ่เป็นการกรอง ไม่ใช่การค้นหาแบบสุ่ม ในแผงแอดมิน คนมักเริ่มจากกว้าง (24 ชั่วโมงล่าสุด) แล้วค่อยกรองลงตามผู้ใช้, เอนทิตี, หรือประเภทการกระทำ

ฟิลเตอร์ทั่วไปได้แก่:

• ช่วงเวลา
• ผู้กระทำ (user ID, service account, IP address)
• เป้าหมาย (ชนิดเอนทิตี + id เช่น Order #1234)
• ประเภทการกระทำ (created, updated, deleted, login failed)
• สถานะหรือความร้ายแรง (success/error)

ช่วงเวลาคือการ “ตัดครั้งแรก” ตามธรรมชาติเพราะมักมีอยู่เสมอ นี่คือข้อสังเกตสำคัญเบื้องหลังการแบ่งพาร์ติชัน PostgreSQL สำหรับตารางเหตุการณ์: คำค้นหลายคำต้องการชิ้นข้อมูลตามเวลา ส่วนที่เหลือเป็นการกรองภายในชิ้นนั้น

การเก็บข้อมูลเป็นอีกสิ่งที่คงที่ บันทึกไม่ได้เก็บตลอดไป ทีมมักเก็บเหตุการณ์ละเอียดสูง 30 หรือ 90 วัน แล้วค่อยลบหรือเก็บถาวร บันทึกการตรวจสอบอาจมีกฎนานกว่า (365 วันหรือมากกว่า) แต่แม้ในกรณีนั้นคุณมักต้องการวิธีที่คาดเดาได้ในการลบข้อมูลเก่าโดยไม่บล็อกฐานข้อมูล

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

รูปแบบเหล่านี้สะท้อนตรงในการออกแบบ UI ฟิลเตอร์ที่ผู้ใช้คาดหวังโดยปริยาย — ตัวเลือกวันที่, ตัวเลือกผู้ใช้, การค้นหาเอนทิตี, เมนูประเภทการกระทำ — คือฟิลเตอร์เดียวกับที่ตารางและดัชนีของคุณต้องรองรับถ้าต้องการให้ประสบการณ์แอดมินยังเร็วเมื่อปริมาณเพิ่ม

วิธีบอกว่าการพาร์ติชันคุ้มค่าหรือไม่

การพาร์ติชันไม่ใช่แนวปฏิบัติที่ต้องทำเสมอสำหรับบันทึกการตรวจสอบ มันคุ้มค่าเมื่อหนึ่งตารางใหญ่จนคำค้นประจำวันและงานบำรุงรักษาชนกัน

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

สัญญาณจากคำค้นที่ชัดเจนคือเมื่อคุณมักขอชิ้นเวลาเล็ก ๆ (วันล่าสุด, สัปดาห์ล่าสุด) แต่ PostgreSQL ยังคงแตะข้อมูลส่วนใหญ่ของตาราง คุณจะเห็นหน้ากิจกรรมล่าสุดช้า หรือการตรวจสอบที่กรองด้วยวันที่บวกผู้ใช้, ประเภทการกระทำ, หรือ entity ID หากแผนคำค้นแสดงการสแกนขนาดใหญ่หรือ buffer reads สูงอยู่เป็นประจำ คุณกำลังจ่ายค่าการอ่านข้อมูลที่ไม่ต้องการ

สัญญาณการบำรุงรักษาสำคัญไม่แพ้กัน:

• VACUUM และ autovacuum ใช้เวลานานกว่าที่เคย
• autovacuum ตามไม่ทันและ dead tuples (bloat) สะสม
• ดัชนีโตเร็วกว่าที่คาด โดยเฉพาะดัชนีหลายคอลัมน์
• การแข่งขันล็อกเด่นชัดขึ้นเมื่อการบำรุงรักษาทับซ้อนกับทราฟฟิก

ต้นทุนการปฏิบัติการคือหยดช้าที่ย้ายทีมไปสู่การพาร์ติชัน แบ็กอัพและการกู้คืนช้าลงเมื่อหนึ่งตารางโตขึ้น พื้นที่เก็บเพิ่มขึ้น และงานเก็บรักษากลายเป็นแพงเพราะ DELETE ขนาดใหญ่สร้าง bloat และงาน vacuum เพิ่ม

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

ตัวเลือกการพาร์ติชันที่เหมาะกับตารางเหตุการณ์และการตรวจสอบ

สำหรับข้อมูลส่วนใหญ่ของอีเวนต์และการตรวจสอบ ตัวเลือกที่ง่ายที่สุดคือ range partitioning ตามเวลา บันทึกเข้ามาตามลำดับเวลา คำค้นมักมุ่งที่ “24 ชั่วโมงล่าสุด” หรือ “30 วันที่ผ่านมา” และการเก็บข้อมูลมักอิงเวลา ด้วยพาร์ติชันตามเวลา การทิ้งข้อมูลเก่าสามารถง่ายเหมือนลบพาร์ติชันเก่าแทนที่จะรัน DELETE จำนวนมากที่ทำให้ตารางบวม

การแบ่งตามช่วงเวลายังช่วยให้ดัชนีเล็กลงและโฟกัสมากขึ้น แต่ละพาร์ติชันมีดัชนีของตัวเอง ดังนั้นการค้นหาสัปดาห์ล่าสุดไม่ต้องเดินผ่านดัชนีขนาดยักษ์ที่ครอบคลุมประวัติหลายปี

สไตล์การพาร์ติชันอื่น ๆ มีอยู่ แต่เข้ากับกรณีบันทึกและตรวจสอบน้อยกว่า:

• List (เช่น tenant หรือ customer) ใช้ได้เมื่อคุณมี tenant ใหญ่จำนวนน้อยและคำค้นมักอยู่ภายใน tenant เดียว แต่มันเจ็บมากเมื่อมี tenant เป็นร้อยหรือพัน
• Hash (กระจายการเขียนเท่า ๆ กัน) ช่วยเมื่อคุณไม่มีคำค้นตามเวลาและต้องการกระจายการเขียน ในงานตรวจสอบไม่ค่อยใช้เพราะทำให้การเก็บข้อมูลและการเรียกดูตามเวลายุ่งยาก
• Subpartitioning (เวลา + tenant) สามารถมีพลัง แต่ความซับซ้อนเพิ่มเร็ว เหมาะกับระบบปริมาณสูงมากที่ต้องการแยก tenant อย่างเข้มงวด

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

ตัวอย่างปฏิบัติ: ถ้าทีมแอดมินตรวจสอบการล็อกอินล้มเหลวทุกเช้าและกรอง 7 วันที่ผ่านมา พาร์ติชันรายวันหรือรายสัปดาห์หมายความว่าคำค้นแตะเฉพาะพาร์ติชันล่าสุด PostgreSQL สามารถข้ามส่วนที่เหลือได้

ไม่ว่าแนวทางใด ให้วางแผนส่วนที่น่าเบื่อ: สร้างพาร์ติชันล่วงหน้า, จัดการเหตุการณ์ที่มาช้า, และกำหนดขอบเขตสิ้นสุด (วัน, สิ้นเดือน) ให้ชัดเจน การพาร์ติชันให้ผลเมื่อขั้นตอนปกติยังคงเรียบง่าย

วิธีเลือกคีย์พาร์ติชันที่ใช่

คีย์พาร์ติชันที่ดีต้องสอดคล้องกับวิธีที่คุณอ่านตาราง ไม่ใช่วิธีที่ข้อมูลดูบนไดอะแกรม

สำหรับบันทึกและการตรวจสอบ ให้เริ่มจากแผงแอดมินของคุณ: ฟิลเตอร์ไหนคนใช้เป็นครั้งแรกเกือบทุกครั้ง? สำหรับทีมส่วนใหญ่คือช่วงเวลา (24 ชั่วโมงล่าสุด, 7 วันที่ผ่านมา, วันที่แบบกำหนดเอง) ถ้าเป็นเช่นนั้น การพาร์ติชันตามเวลามักให้ผลที่ใหญ่และคาดเดาได้ที่สุดเพราะ PostgreSQL สามารถข้ามพาร์ติชันนอกช่วงเวลาที่เลือก

ถือคีย์เป็นคำมั่นระยะยาว คุณกำลังปรับแต่งสำหรับคำค้นที่จะใช้ต่อไปเป็นปี

เริ่มจาก "ฟิลเตอร์แรก" ที่คนใช้

หน้าส่วนใหญ่ตามรูปแบบ: ช่วงเวลา + ตัวเลือกผู้ใช้, การกระทำ, สถานะ หรือทรัพยากร พาร์ติชันโดยสิ่งที่กรองผลลัพธ์เร็วและสม่ำเสมอ

การตรวจสอบสั้น ๆ:

• ถ้ามุมมองเริ่มต้นคือ “เหตุการณ์ล่าสุด” ให้พาร์ติชันตาม timestamp
• ถ้ามุมมองเริ่มต้นคือ “เหตุการณ์ของ tenant/บัญชีหนึ่ง” tenant_id อาจมีเหตุผล แต่เฉพาะเมื่อ tenant มีขนาดใหญ่พอ
• ถ้าขั้นแรกคือ “เลือกผู้ใช้” user_id อาจดูน่าสนใจ แต่มักสร้างพาร์ติชันมากเกินไปที่จะจัดการได้

หลีกเลี่ยงคีย์ที่มี cardinality สูง

การพาร์ติชันทำงานดีที่สุดเมื่อแต่ละพาร์ติชันเป็นชิ้นข้อมูลที่มีความหมาย คีย์อย่าง user_id, session_id, request_id, หรือ device_id อาจนำไปสู่พาร์ติชันนับพันหรือหลักล้าน เพิ่มภาระ metadata และทำให้การบำรุงรักษายุ่งยาก

พาร์ติชันตามเวลาทำให้จำนวนพาร์ติชันคาดเดาได้ คุณเลือกรายวัน รายสัปดาห์ หรือรายเดือนตามปริมาณ น้อยเกินไป (เช่นหนึ่งต่อปี) ไม่ช่วยมาก เกินไป (เช่นหนึ่งต่อชั่วโมง) เพิ่มภาระเร็ว

เลือก timestamp ที่ถูกต้อง: created_at vs occurred_at

ชัดเจนว่าคำว่าเวลาแปลว่าอะไร:

• occurred_at: เวลาที่เหตุการณ์เกิดขึ้นในผลิตภัณฑ์
• created_at: เวลาที่ฐานข้อมูลบันทึกมัน

สำหรับการตรวจสอบ “เกิดขึ้น” มักเป็นสิ่งที่แอดมินสนใจ แต่การมาส่งช้าของข้อมูล (ไคลเอนต์ออฟไลน์, รีไทร, คิว) ทำให้ occurred_at อาจมาช้า หากการมาช้าพบได้บ่อย การพาร์ติชันตาม created_at แล้วสร้างดัชนี occurred_at เพื่อกรองอาจเสถียรกว่าอีกทางเลือกหนึ่งคือกำหนดนโยบาย backfill ชัดเจนและยอมรับว่าพาร์ติชันเก่าอาจรับเหตุการณ์ที่มาช้าเป็นบางครั้ง

นอกจากนี้ตัดสินใจวิธีเก็บเวลา ใช้ชนิดที่สม่ำเสมอ (มัก timestamptz) และถือ UTC เป็นแหล่งความจริง แปลงเป็นโซนเวลาผู้ชมใน UI วิธีนี้ทำให้ขอบเขตพาร์ติชันคงที่และหลีกเลี่ยงปัญหา DST

ขั้นตอนทีละขั้น: วางแผนและเปิดใช้งานพาร์ติชัน

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

แผนการเปิดใช้งานที่ปฏิบัติได้

1. เลือกขนาดพาร์ติชันที่ตรงกับปริมาณ — พาร์ติชันรายเดือนมักพอเมื่อมีแถวเป็นแสนต่อเดือน หากคุณแทรกหลายสิบล้านต่อเดือน ให้พิจารณารายสัปดาห์หรือรายวันเพื่อลดขนาดดัชนีและงาน vacuum

2. ออกแบบคีย์และข้อจำกัดสำหรับตารางพาร์ติชัน — ใน PostgreSQL ข้อจำกัด unique ต้องรวมคีย์พาร์ติชันด้วย (หรือบังคับด้วยวิธีอื่น) รูปแบบทั่วไปคือ (created_at, id) โดยที่ id สร้างขึ้นและ created_at เป็นคีย์พาร์ติชัน เพื่อหลีกเลี่ยงความประหลาดใจเมื่อพบว่าข้อจำกัดบางอย่างไม่ถูกอนุญาต

3. สร้างพาร์ติชันล่วงหน้าก่อนจำเป็น — อย่ารอจนการแทรกล้มเพราะไม่มีพาร์ติชันที่ตรงกัน ตัดสินใจว่าจะสร้างล่วงหน้ากี่เดือน (เช่น 2-3 เดือน) และทำให้เป็นงานประจำ

4. เก็บดัชนีต่อพาร์ติชันให้เล็กและมีจุดประสงค์ — การพาร์ติชันไม่ได้ทำให้ดัชนีฟรี ตารกเหตุการณ์ส่วนใหญ่ต้องคีย์พาร์ติชันบวกหนึ่งหรือสองดัชนีที่ตรงกับฟิลเตอร์จริง เช่น actor_id, entity_id, หรือ event_type หลีกเลี่ยงดัชนี “กันไว้ก่อน” คุณสามารถเพิ่มดัชนีในพาร์ติชันใหม่และ backfill พาร์ติชันเก่าเมื่อจำเป็น

5. วางแผนการเก็บข้อมูลโดยการทิ้งพาร์ติชัน ไม่ใช่การลบแถว — ถ้าคุณเก็บ 180 วัน การทิ้งพาร์ติชันเก่าเป็นวิธีที่รวดเร็วและหลีกเลี่ยง DELETE จำนวนมากที่สร้าง bloat เขียนกฎการเก็บข้อมูลไว้ว่าใครรันและวิธีตรวจสอบว่าเสร็จ

ตัวอย่างเล็ก ๆ

ถ้าตารางตรวจสอบของคุณมี 5 ล้านแถวต่อสัปดาห์ พาร์ติชันรายสัปดาห์บน created_at เป็นจุดเริ่มต้นที่เหมาะสม สร้างพาร์ติชันล่วงหน้า 8 สัปดาห์และเก็บดัชนีต่อพาร์ติชันสองชุด: หนึ่งชุดสำหรับการค้นหาทั่วไปโดย actor_id และอีกชุดสำหรับ entity_id เมื่อหน้าต่างการเก็บข้อมูลหมดลง ให้ทิ้งพาร์ติชันสัปดาห์เก่าที่สุดแทนการลบล้านแถว

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

การพาร์ติชันเปลี่ยนแปลงอะไรสำหรับฟิลเตอร์ในแผงแอดมิน

เมื่อคุณพาร์ติชันตารางบันทึกแล้ว ฟิลเตอร์ในแผงแอดมินไม่ใช่แค่ UI อีกต่อไป มันกลายเป็นปัจจัยหลักที่ตัดสินว่าคำค้นแตะพาร์ติชันไม่กี่ตัวหรือสแกนหลายเดือน

การเปลี่ยนแปลงที่สำคัญ: เวลาไม่ควรเป็นตัวเลือกอีกต่อไป หากผู้ใช้สามารถรันการค้นหาไม่จำกัด (ไม่มีช่วงวันที่ แค่ “แสดงทุกอย่างสำหรับผู้ใช้ X”) PostgreSQL อาจต้องตรวจสอบทุกพาร์ติชัน ถึงแม้ว่าการตรวจสอบแต่ละพาร์ติชันจะเร็ว การเปิดหลายพาร์ติชันก็เพิ่ม overhead และหน้าอาจช้าลง

กฎที่ใช้ได้ดี: บังคับช่วงเวลาในการค้นหาบันทึกและตั้งค่าปริยายให้เหมาะสม (เช่น 24 ชั่วโมงล่าสุด) ถ้าจริง ๆ ต้องการ “ทุกเวลา” ให้ทำเป็นตัวเลือกที่ตั้งใจและเตือนว่าผลลัพธ์อาจช้า

ทำให้ฟิลเตอร์สอดคล้องกับ partition pruning

การ partition pruning ช่วยเมื่อ WHERE clause มีคีย์พาร์ติชันในรูปแบบที่ PostgreSQL ใช้ได้ ฟิลเตอร์อย่าง created_at BETWEEN X AND Y จะ prune ได้ดี รูปแบบที่มักทำให้ pruning พังคือการแคสต์ timestamp เป็น date, ห่อคอลัมน์ในฟังก์ชัน, หรือกรองหลักบนคอลัมน์เวลาที่ต่างจากคีย์พาร์ติชัน

ภายในแต่ละพาร์ติชัน ดัชนีควรสอดคล้องกับวิธีที่คนกรอง ในทางปฏิบัติ ชุดที่มักสำคัญคือเวลา + เงื่อนไขอีกอัน: tenant/workspace, user, action/type, entity ID, หรือ status

การเรียงลำดับและการแบ่งหน้า: ให้ตื้น ๆ ไว้

การพาร์ติชันไม่แก้ปัญหาการแบ่งหน้าแบบลึก การเรียงตามล่าสุดและผู้ใช้ข้ามไปยังหน้าที่ 5000 จะยังคงช้า การแบ่งหน้าแบบ cursor มักทำงานดีกว่าสำหรับบันทึก: “โหลดเหตุการณ์ก่อน (timestamp, id)” ซึ่งทำให้ฐานข้อมูลใช้ดัชนีแทนการข้ามแถวจำนวนมาก

การตั้งค่าล่วงหน้าช่วยได้เช่นกัน ตัวเลือกไม่กี่อย่างมักพอ: 24 ชั่วโมงล่าสุด, 7 วันที่ผ่านมา, วันนี้, เมื่อวาน, ช่วงกำหนดเอง ตัวเลือกเหล่านี้ลดการค้นหาแบบ “สแกนทุกอย่างโดยไม่ได้ตั้งใจ” และทำให้ประสบการณ์ผู้ใช้คาดเดาได้

ความผิดพลาดและกับดักที่พบบ่อย

โครงการพาร์ติชันส่วนใหญ่ล้มเหลวด้วยเหตุผลง่าย ๆ: การพาร์ติชันทำงาน แต่คำค้นและ UI ไม่สอดคล้องกับมัน ถ้าต้องการให้พาร์ติชันคุ้มค่า ให้ออกแบบรอบฟิลเตอร์จริงและกฎการเก็บข้อมูลจริง

1) พาร์ติชันบนคอลัมน์เวลาผิดตัว

Partition pruning เกิดขึ้นเมื่อ WHERE clause ตรงกับคีย์พาร์ติชัน ความผิดพลาดทั่วไปคือพาร์ติชันโดย created_at ขณะที่ UI กรองโดย event_time (หรือกลับกัน) หากทีมซัพพอร์ตถาม “เกิดอะไรขึ้นระหว่าง 10:00 ถึง 10:15” แต่ตารางพาร์ติชันตามเวลา ingestion คุณอาจแตะข้อมูลมากกว่าที่คาด

2) สร้างพาร์ติชันเล็กเกินไปมากเกินไป

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

3) สมมติว่า uniqueness แบบ global ยังคงทำงาน

ตารางพาร์ติชันมีข้อจำกัด: ดัชนี unique บางอย่างต้องรวมคีย์พาร์ติชัน มิฉะนั้น PostgreSQL จะไม่สามารถบังคับใช้ข้ามพาร์ติชันได้ เรื่องนี้มักสร้างความประหลาดใจทีมที่คาดหวังว่า event_id จะ unique ตลอด หากต้องการตัวระบุที่ unique ให้ใช้ UUID และทำความเข้าใจการบังคับใช้ความเป็นเอกลักษณ์

4) ปล่อยให้ UI รันการค้นหาแบบกว้างโดยไม่จำกัด

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

5) ไม่มีแผนการเก็บข้อมูล (และไม่มีแผนสำหรับพาร์ติชัน)

การพาร์ติชันไม่แก้ปัญหาการเก็บข้อมูลโดยอัตโนมัติ หากไม่มีนโยบาย คุณจะมีพาร์ติชันเก่ากองเต็ม พื้นที่จัดเก็บรก และการบำรุงรักษาช้า เซ็ตกฎปฏิบัติการง่าย ๆ: กำหนดระยะเวลาการเก็บข้อมูล, อัตโนมัติสร้างพาร์ติชันล่วงหน้าและทิ้งพาร์ติชันเก่า, ใช้ดัชนีอย่างสม่ำเสมอ, มอนิเตอร์จำนวนพาร์ติชันและวันที่ขอบเขต, และทดสอบฟิลเตอร์ที่ช้าที่สุดกับปริมาณข้อมูลจริง

เช็คลิสต์ด่วนก่อนตัดสินใจ

การพาร์ติชันอาจให้ประโยชน์มากสำหรับบันทึกตรวจสอบ แต่เพิ่มงานประจำ ก่อนเปลี่ยนสคีมา ตรวจสอบว่าใครใช้ตารางจริง ๆ อย่างไร

ถ้าปัญหาหลักคือหน้าของแอดมินหมดเวลาเมื่อใครสักคนเปิด “24 ชั่วโมงล่าสุด” หรือ “สัปดาห์นี้” คุณเข้าใกล้ความเหมาะสมแล้ว ถ้าคำค้นส่วนใหญ่คือ “user ID ตลอดประวัติ” การพาร์ติชันอาจช่วยน้อยลงเว้นแต่คุณจะเปลี่ยนวิธีที่ UI นำทางการค้นหา

เช็คลิสต์สั้น ๆ ที่ทำให้ทีมตรงไปตรงมา:

• ช่วงเวลาเป็นฟิลเตอร์ปริยาย — คำค้นส่วนใหญ่ของแอดมินรวมหน้าต่างชัดเจน (from/to). ถ้าการค้นหาแบบเปิดกว้างเกิดขึ้นบ่อย ๆ การ partition pruning ช่วยน้อยลง
• การเก็บข้อมูลบังคับโดยการทิ้งพาร์ติชัน ไม่ใช่การลบแถว — คุณพร้อมทิ้งพาร์ติชันเก่าและมีกฎชัดเจนว่าข้อมูลต้องเก็บนานเท่าไร
• จำนวนพาร์ติชันยังคงสมเหตุสมผล — ประมาณการพาร์ติชันต่อปี (รายวัน, รายสัปดาห์, รายเดือน). พาร์ติชันเล็กเกินไปเพิ่ม overhead; ใหญ่เกินไปลดประโยชน์
• ดัชนีสอดคล้องกับฟิลเตอร์ที่ผู้ใช้ใช้จริง — นอกเหนือจากคีย์พาร์ติชัน คุณยังต้องมีดัชนีต่อพาร์ติชันที่เหมาะสมสำหรับฟิลเตอร์และการเรียงลำดับทั่วไป
• สร้างพาร์ติชันอัตโนมัติและมอนิเตอร์ — งานประจำสร้างพาร์ติชันล่วงหน้า และคุณรู้เมื่อมันล้มเหลว

การทดสอบปฏิบัติ: ดูสามฟิลเตอร์ที่ทีมซัพพอร์ตหรือ ops ใช้บ่อยที่สุด ถ้าสองในสามมักใช้ “ช่วงเวลา + เงื่อนไขอีกหนึ่ง” การพาร์ติชัน PostgreSQL สำหรับตารางเหตุการณ์มักคู่ควรแก่การพิจารณาจริงจัง

ตัวอย่างสมจริงและขั้นตอนถัดไปที่ควรทำ

ทีมซัพพอร์ตเปิดสองหน้าตลอดทั้งวัน: “เหตุการณ์การล็อกอิน” (ล็อกอินสำเร็จและล้มเหลว) และ “การตรวจสอบความปลอดภัย” (รีเซ็ตรหัสผ่าน, เปลี่ยนบทบาท, อัปเดตคีย์ API) เมื่อมีลูกค้ารายงานกิจกรรมผิดปกติ ทีมกรองตามผู้ใช้, ตรวจสอบไม่กี่ชั่วโมงล่าสุด, และส่งออกรายงานสั้น ๆ

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

หลังพาร์ติชันตามเดือน (ใช้ timestamp ของเหตุการณ์) เวิร์กโฟลว์ดีขึ้น UI แอดมินบังคับฟิลเตอร์เวลา ดังนั้นคำค้นส่วนใหญ่แตะพาร์ติชันหนึ่งหรือสองอัน หน้าโหลดเร็วขึ้นเพราะ PostgreSQL ข้ามพาร์ติชันนอกช่วงที่เลือกได้ การเก็บข้อมูลกลายเป็นงานประจำ: แทนที่จะลบล้านแถว คุณทิ้งพาร์ติชันเก่า

สิ่งที่ยังยาก: การค้นหาข้อความอิสระข้าม “ทุกเวลา” หากใครสักคนค้นหา IP หรือวลีคลุมเครือโดยไม่มีขอบเขตเวลา พาร์ติชันช่วยไม่ได้มาก การแก้ไขมาจากพฤติกรรมผลิตภัณฑ์: ตั้งค่าการค้นหาให้เริ่มต้นที่หน้าต่างเวลาและทำให้ “24 ชั่วโมงล่าสุด / 7 วัน / 30 วัน” เป็นเส้นทางที่ชัดเจน

ขั้นตอนถัดไปที่ปฏิบัติได้ซึ่งมักได้ผลดี:

• แผนที่ฟิลเตอร์ในแผงแอดมินก่อน: เขียนว่าผู้คนใช้ฟิลด์ไหนและอันไหนต้องกำหนดเป็นข้อบังคับ
• เลือกพาร์ติชันที่ตรงกับวิธีการเรียกดูของคุณ: พาร์ติชันรายเดือนมักเป็นจุดเริ่มต้นที่ดี; ย้ายเป็นรายสัปดาห์เมื่อปริมาณบังคับ
• ทำให้ช่วงเวลาเป็นฟิลเตอร์ชั้นหนึ่งใน UI: ถ้า UI อนุญาต “ไม่มีวันที่” คาดว่าหน้าจะช้า
• จัดดัชนีให้สอดคล้องกับฟิลเตอร์จริง: เมื่อเวลามักมีเสมอ แนวทางดัชนีแบบ time-first เป็นฐานที่ดี
• ตั้งกฎการเก็บข้อมูลที่สอดคล้องกับขอบเขตพาร์ติชัน (เช่น เก็บ 13 เดือนแล้วทิ้งที่เก่ากว่า)

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