פיצול טבלאות מסד נתונים: שאילתות מהירות יותר וניהול נתונים

פיצול טבלאות במסד נתונים: שאילתות מהירות יותר וניהול נתונים

אנו מיישמים פיצול טבלאות במסד נתונים. בעיית גידול הנתונים היא אחת הסיבות הנפוצות ביותר לירידה בביצועים. בפרויקט אחרון, טבלת CREATE TABLE events ( id BIGSERIAL, user_id INTEGER NOT NULL, event_type VARCHAR(64) NOT NULL, payload JSONB, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ) PARTITION BY RANGE (created_at); CREATE TABLE events_2023_01 PARTITION OF events FOR VALUES FROM ('2023-01-01') TO ('2023-02-01'); -- pg_partman: создание расписания SELECT partman.create_parent( p_parent_table => 'public.events', p_control => 'created_at', p_type => 'native', p_interval => 'monthly', p_premake => 3 ); של לקוח גדלה ל-500 מיליון שורות, ושאילתות נתקעו למשך 30 שניות. יישמנו פיצול לפי טווח חודשי — זמן התגובה ירד ל-50 אלפיות השנייה, ועלויות האחסון ירדו ב-40% הודות לארכוב של מחיצות ישנות.

בפרויקט אחר, טבלת לוגים צרכה 1.5 טרה-בייט. לאחר פיצול יומי, הסט הפעיל הצטמצם ל-50 ג'יגה-בייט, ו-TTFB ירד מ-3 שניות ל-200 אלפיות השנייה. ללא פיצול, כל SELECT סורק את כל הטבלה, מה שמגדיל את LCP ו-INP. גיזום מחיצות מבטל מחיצות מיותרות, ומאיץ שאילתות פי 5–20 בהתאם לסלקטיביות. שאילתה טיפוסית לחודש האחרון עם פיצול לפי טווח על עמודת תאריך רצה פי 10 מהר יותר מסריקה מלאה.

למהנדסים שלנו יש ניסיון של 10+ שנים באופטימיזציה של מסדי נתונים, והם סיפקו בהצלחה מעל 50 פרויקטי פיצול. אנו מבטיחים פתרון שעובד כראוי.

אילו בעיות פותר פיצול טבלאות?

• ירידה בביצועים: טבלאות גדולות ללא פיצול סורקות הכל, ומגדילות את LCP ו-TTFB. שאילתות המסננות לפי תאריך או קטגוריה סובלות ביותר.
• קשיי תחזוקה: ניקוי או ארכוב של נתונים ישנים הופך ל-DELETE כואב עם נעילות.
• עלויות אחסון גבוהות: כונני SSD יקרים; אחסון כל ההיסטוריה על אחסון מהיר הוא בזבזני.

כיצד אנו מיישמים פיצול טבלאות

טכנולוגיות וכלים

השוואת סוגי פיצול

מקרה קונקרטי

לקוח: סוכנות שיווק. טבלת events — 500 מיליון שורות, גדלה ב-10 מיליון בחודש. שאילתות לסטטיסטיקות של השנה האחרונה היו איטיות; גיבויים היו 200 ג'יגה-בייט.

תכננו פיצול לפי טווח על created_at עם מחיצות חודשיות. הגדרנו pg_partman: יצירה מוקדמת של 3 מחיצות מראש, שמירה ל-12 חודשים (מחיקה אוטומטית).

CREATE TABLE events (
    id BIGSERIAL,
    user_id INTEGER NOT NULL,
    event_type VARCHAR(64) NOT NULL,
    payload JSONB,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
) PARTITION BY RANGE (created_at);

CREATE TABLE events_2023_01 PARTITION OF events
FOR VALUES FROM ('2023-01-01') TO ('2023-02-01');

-- pg_partman: создание расписания
SELECT partman.create_parent(
    p_parent_table => 'public.events',
    p_control => 'created_at',
    p_type => 'native',
    p_interval => 'monthly',
    p_premake => 3
);

תוצאה: שאילתות הואצו פי 10, גודל הייצור היה רק 6 החודשים האחרונים, ונתונים ישנים הועברו לאחסון אובייקטים.

מדוע בחירת מפתח הפיצול הנכון חשובה

גיזום מחיצות עובד רק כאשר סעיף WHERE משתמש במפתח במפורש. טעות טיפוסית היא עטיפת המפתח בפונקציה: DATE(created_at) = '2023-01-15' — הגיזום מושבת. נכון: created_at >= '2023-01-15' AND created_at < '2023-01-16'. אנו מוודאים זאת במהלך הבדיקות.

כיצד לבצע הגירה ללא השבתה?

1. צור טבלה מפוצלת חדשה עם אותן עמודות.
2. העתק נתונים בקבוצות חודשיות (INSERT נפרד).
3. בצע מעבר באמצעות טרנזקציה: ALTER TABLE events RENAME TO events_old; ALTER TABLE events_partitioned RENAME TO events; — שניות.
4. מחק את הטבלה הישנה לאחר שבוע של ניטור.
5. הגדר את pg_partman לניהול אוטומטי.

תהליך העבודה שלנו

1. ניתוח — פרופיל שאילתות, זיהוי האיטיות ביותר, הערכת נפח נתונים וקצב גידול.
2. תכנון — בחירת מפתח וסוג פיצול (טווח, גיבוב, רשימה), מספר מחיצות.
3. יישום — כתיבת סקריפטים, הגדרת pg_partman, יצירת מחיצות היסטוריות.
4. בדיקות — אימות גיזום מחיצות, בדיקת ביצועים לפני/אחרי.
5. פריסה — הגירה לפי התוכנית המתוארת, בשעות עבודה או בחלון מינימלי.
6. ניטור — הגדרת התראות על מחיצות חסרות וחריגות מסף.

לוחות זמנים ומה כלול

לוחות זמנים משוערים: מ-3 עד 10 ימי עבודה. העלות מחושבת באופן אישי. מה כלול:

• תיעוד סכמת הפיצול
• סקריפטים ליצירת וניהול מחיצות
• הגדרת תחזוקה אוטומטית (pg_partman או מקביל)
• הוראות ניטור והתראות
• אחריות ל-3 חודשים על פעולה תקינה

צור קשר להערכת פרויקט — ננתח את עומס העבודה שלך ונציע את הפתרון האופטימלי.

טעויות נפוצות בפיצול טבלאות

• מפתח שגוי — גיזום לא עובד, ביצועים יורדים
• אינדקסים שנוצרו על טבלת האב אך לא על כל המחיצות (PG < 11)
• ללא יצירה מוקדמת — מחיצות חדשות לא נוצרות בזמן
• ב-MySQL, מפתחות ייחודיים חייבים לכלול את מפתח הפיצול

מתי פיצול אינו נחוץ

• טבלה קטנה מ-10–20 מיליון שורות — אינדקסים מספיקים
• אין מפתח ברור (נתונים ללא תווית זמן או קטגוריה)
• שאילתות לא מסננות לפי מפתח — אין תועלת

מידע נוסף על פיצול ב-PostgreSQL — תיעוד רשמי

צור קשר להערכת פרויקט. ננתח את עומס העבודה שלך ונציע את הפתרון האופטימלי.