Vissza a Journal-hoz
adminhu

Tomeges termekimport: 5000 SKU egy delutan alatt

5000 SKU 7 perc alatt, idempotens SKU-alapu dedup, dry-run preview - es miert vettuk ki az inline kep-feltoltest.

A 2026 Q2-ben szallitott tomeges termekimport-moduluk a Netorigo Admin egyik leggyakrabban hasznalt funkcioja lett. Egy konkret pelda: egy 120,000 termeket kezelo, mosogep-alkatreszekkel kereskedo tenant 5,000 uj SKU-t toltott fel egy CSV-bol kb. 7 perc alatt. Az alabbiakban leirjuk, hogyan epul fel a flow es hol vannak a hatarok.

Oszlop-mapping varazslo

A feltoltes ket lepesbol all: file-upload (XLSX vagy CSV, max 50 MB), majd egy oszlop-mapping kepernyo. A varazslo az elso 100 sorbol auto-detect-tel ajanl egy mappinget: a Cikkszam, SKU, Item Code, Article ID fejlecek mind a sku mezore allnak be alapertelmezetten, hasonlokeppen a Nev, Name, Megnevezes -> name parok. Az operator manualisan felulbirakhatja a javaslatot, es nem-kotelezo mezoket (description, barcode, weight_grams, stb.) is hozzaadhat.

A mapping mentheto sablonkent (import_template tabla, tenant-scoped), igy a kovetkezo havi feltoltesnel egy klikk-kel betoltheto. 47 mezo tamogatott jelenleg, a legtobb sting + szam + boolean, plusz egy category_path segedmezo, ami > szeparator menten kategoriafat hoz letre, ha nem letezik (Elektronika > Mosogepek > Szivattyuk).

Dry-run preview

Mielott egy sor is iratlanra kerul, a rendszer egy 10-soros mintat parsol es egy validacios diff-et mutat: zold = ujonnan letrehozott, sarga = letezo SKU frissites, piros = hiba (kotelezo mezo hianyzik, ervenytelen format, stb.). Az operator dontheti el, hogy a hibas sorokat kihagyja-e, vagy az egesz batch-et megszakitja.

A dry-run egy temp_import_session tablaba megy, 24 ora TTL-lel. Ezzel megoldhato hogy az operator delben megnezze a previewt, ebedeljen, es 13:00-kor megnyomja a Confirm gombot anelkul hogy a CSV-t ujra fel kelljen toltenie.

Idempotencia SKU alapjan

A sku mezo a deduplication kulcsa. Ha egy 5,000-soros CSV-ben szerepel egy mar letezo SKU, az nem hiba: a meglevo termek a CSV ertekeivel frissul (UPDATE), es az audit-log egy bulk_import_update esemenyt rogzit a kulonbsegek diff-jevel. Igy ugyanaz a CSV barmennyiszer rerunolhato anelkul, hogy duplikatumokat hozna letre.

A per-soros hibareport CSV-ben tolhetik le: SKU, sorszam, hibakod, hibauzenet. A leggyakoribb hibak a category_path szintaktikai problemai (pl. dupla > szeparator) es a barcode invalid EAN-13 ellenorzesi osszege.

Miert NEM tamogatjuk az inline kep-feltoltest

A korai prototipusban egy image_url oszlop tamogatott volt, ahonnan a worker letoltotte es S3-ba meretvalkkal feltoltotte a kepet. Ezt elvettuk, mert (a) egy 5,000-soros import 5,000 HTTP-let jelentett ismeretlen domainekrol, ami security audit kockazat, es (b) az atlagos kepek 8x lassitottak az importot. Helyette: a media library kulon felulet, a termek-azonosito vagy SKU-mintaval bulk-kepfeltoltes mukodik, es a backfill egy kulon BullMQ job.

A szuk keresztmetszet: full-text reindex

5,000 SKU INSERT/UPDATE Prisma-n keresztul kb. 90 masodperc egy db.medium-2 instance-on (8 vCPU, 32 GB RAM). A maradek ~6 perc a full-text search reindex (Postgres tsvector + GIN index), amit egy BullMQ worker hatra-tolva csinal, hogy az import response nem blokkolja a UI-t. Az operator mar a feltolt utan 90 masodperccel lat ervenyes terkanyveket az admin katalogus listaban, de a publikus storefront search-ben kb. 5-7 perccel kesobb jelennek meg.

Nagyobb tenanteknel (1M+ termek) ez nem skalazodik linearisan: a db.large-4 instance-okon (16 vCPU) megfigyeltunk 4 perces full importot 5,000 SKU-ra. Ezert a benchmark szam ("5,000 SKU 7 perc alatt") a 100-200k katalogus-meretu tenantekre ervenyes.

Mit nem csinal

A jelenlegi verzio nem tamogat: termekvariansok inline (size + color matrix), bundle-termek osszeallitasa, kategoria-fa restructuring (az csak egy iranyba megy: uj kategoriak jonnek letre), arak idoszakos szablyozasa (azt a Promotions modul kezeli). Ezek kovetkezo ket sprintben kerulnek be.