יישום ייבוא מוצרים מצטבר: רק שינויים

תארו לעצמכם שאתם מנהלים חנות מקוונת עם קטלוג של 300,000 מוצרים. כל לילה מתבצע ייבוא מלא—השרתים בעומס של 100%, מסד הנתונים ננעל, ולקוחות מתלוננים על מחירים מיושנים ועיכובים בעיבוד הזמנות. אך במציאות, לא יותר מ-5% מהמבחר באמת משתנה; 95% האחרים נטענים מחדש ללא צורך. מצב זה מוכר לפרויקטים רבים של מסחר אלקטרוני. אופטימיזציה זו יכולה לחסוך מעל $2,500 בחודש בעלויות שרת ומסד נתונים עבור קטלוגים בינוניים, ועבור גדולים יותר, החיסכון יכול לעלות על $6,000 בחודש.

אנו פותרים בעיה זו עם ייבוא מוצרים אינקרמנטלי: שיטת סנכרון קטלוג שמעדכנת רק פריטים שהשתנו. ייבוא מוצרים אינקרמנטלי מהיר פי 10 מטעינות מלאות ומפחית את עומס השרת ב-80%. במשך מספר שנים, יישמנו גישה זו עבור 15 פרויקטים—מחנויות קטנות ועד מרקטים עם קטלוגים של עד 500,000 SKU. המומחיות שלנו מבטיחה שתקבלו פתרון עובד במהירות. תהליך היישום המוסמך שלנו מבטיח פתרון אמין במסגרת לוחות הזמנים שלכם.

ייבוא אינקרמנטלי (ייבוא דלתא) הוא שיטת סנכרון שמעדכנת רק רשומות שהשתנו. אופטימיזציית ייבוא זו מפחיתה את עומס השרת ב-80% ומקצרת את זמן הייבוא פי 10 בהשוואה לטעינות מלאות. לדוגמה, בפרויקט עם קטלוג של 200,000 SKU, צמצמנו את זמן הסנכרון מ-3 שעות ל-18 דקות באמצעות שימוש בחותמות זמן והשוואת hash לאמינות. כל עדכון מוצר מעובד בנפרד, מה שמוביל לחיסכון משמעותי במשאבים.

בחירת אסטרטגיית זיהוי שינויים

הבחירה תלויה ביכולות מקור הנתונים. הטבלה שלהלן משווה בין הגישות העיקריות:

נבחן כל שיטה בפירוט.

חותמת זמן

הגישה הנפוצה ביותר—הספק תומך בסינון לפי תאריך שינוי: GET /api/products?updated_after=2024-01-15T10:00:00Z. המערכת זוכרת את זמן הסנכרון המוצלח האחרון ומעבירה אותו בבקשה הבאה. שיטת ייבוא זו המבוססת על חותמת זמן פשוטה אך עלולה לפספס שינויים המתרחשים במהלך העיבוד. לכן, אנו תמיד רושמים את זמן תחילת הסנכרון, לא את סופו.

סמן / יומן שינויים

הספק מנהל יומן שינויים עם מזהה הולך וגדל. אמין יותר מחותמת זמן: לא מפספסים שינויים במהלך העיבוד. דוגמה: GET /api/changes?since_id=48291. ייבוא מבוסס סמן אמין יותר ומתאים ל-API עם תדירות עדכון גבוהה.

השוואת Hash

כאשר המקור אינו תומך בסינון שינויים—אנו משווים את ה-hash של שורת הנתונים:

$hash = md5(serialize([ $row['price'], $row['qty'], $row['name'], $row['description'] ])); 

השורה מעובדת רק אם ה-hash השתנה. שיטה זו עובדת היטב כאשר הנתונים מגיעים כייצוא מלא, אך אנו רוצים לעבד רק רשומות שהשתנו.

קבצי Diff

הספק מפרסם קובץ diff שעתי במקום רשימת מחירים מלאה:

<changes>
  <updated id="SKU-123">
    <price>4990</price>
    <qty>15</qty>
  </updated>
  <updated id="SKU-456">
    <qty>0</qty>
  </updated>
  <deleted id="SKU-789"/>
  <created id="SKU-999">
    <!-- полные данные -->
  </created>
</changes>

שיטה זו היא המדויקת ביותר אך דורשת תמיכה מהספק.

שלבי יישום

1. ניתוח יכולות מקור הנתונים שלכם (API, קבצי ייצוא).
2. בחירת אסטרטגיית זיהוי השינויים המתאימה (חותמת זמן, סמן, hash או diff).
3. יישום מעקב מצב במסד הנתונים שלכם.
4. בניית צינור הייבוא האינקרמנטלי.
5. הוספת זיהוי מחיקות באמצעות anti-joins.
6. יישום הגנה מפני ריצה כפולה באמצעות נעילה מבוזרת.
7. בדיקה עם הקטלוג שלכם ופריסה.

כיצד אנו מיישמים ייבוא אינקרמנטלי

מעקב מצב

מצב הסנכרון נשמר במסד הנתונים. אנו משתמשים בטבלה ייעודית:

CREATE TABLE import_sync_state (
    source_id int PRIMARY KEY REFERENCES import_sources(id),
    last_sync_at timestamptz,
    last_cursor varchar(200),
    last_change_id bigint,
    items_synced bigint DEFAULT 0,
    updated_at timestamptz DEFAULT now()
);

אנו רושמים את זמן תחילת הסנכרון, לא את סופו. אם שינויים חדשים מופיעים במהלך העיבוד, הם ייאספו במחזור הבא.

צינור ייבוא אינקרמנטלי

המחלקה המרכזית שמבצעת סנכרון:

class IncrementalImportJob implements ShouldQueue {
    public function handle(
        SyncStateManager $state,
        SupplierApiClient $client,
        IncrementalProductSync $sync,
    ): void {
        $since = $state->getLastSyncAt($this->sourceId);
        $state->markSyncStarted($this->sourceId);
        $stats = ['created' => 0, 'updated' => 0, 'deleted' => 0, 'skipped' => 0];
        foreach ($client->fetchUpdatedSince($since) as $item) {
            $result = $sync->process($item, $this->sourceId);
            $stats[$result]++;
        }
        $state->markSyncCompleted($this->sourceId);
        $this->logResult($stats);
    }
}

זיהוי פריטים שנמחקו

אם המקור אינו שולח אותות מחיקה מפורשים, אנו משתמשים ב-anti-join דרך טבלה זמנית (עבור קטלוגים מ-50,000 SKU):

CREATE TEMP TABLE current_import_skus (sku varchar(100));
COPY current_import_skus FROM STDIN;
UPDATE products SET deleted_at = now() WHERE source_id = $1 AND deleted_at IS NULL AND sku NOT IN (SELECT sku FROM current_import_skus);
DROP TABLE current_import_skus;

הגנה מפני ריצה כפולה

אנו משתמשים בנעילה מבוזרת דרך cache (Redis). אם סנכרון כבר רץ עבור מקור נתון, ריצה חדשה מדולגת. TTL הנעילה מוגדר לשעה, מה שמספיק לרוב הקטלוגים. זה מונע עיבוד כפול וקונפליקטים.

מה כלול בעבודה

• פיתוח מעקב מצב לאחסון מצב סנכרון
• יישום אסטרטגיית זיהוי השינויים שנבחרה (חותמת זמן, סמן, hash, diff)
• מנגנון לזיהוי וטיפול בפריטים שנמחקו
• הגנה מפני ריצה כפולה באמצעות נעילה
• בדיקה על קטלוגים של עד 500,000 SKU
• תיעוד לפריסה וניטור

לוחות זמנים משוערים

לוחות הזמנים המדויקים תלויים במורכבות API הספק ובגודל הקטלוג. צרו קשר להערכת פרויקט—נכין הצעה מותאמת אישית ונראה כיצד ייבוא אינקרמנטלי יכול להפחית את עלויות התשתית שלכם בעד 80%. בקשו יישום ייבוא אינקרמנטלי וקבלו ייעוץ לאופטימיזציית סנכרון הקטלוג שלכם.