Import dat z CSV, jak optimalizovat?

Ahoj, pro klienta importujeme velke mnozstvi autodilu. Import je z CSV souboru. Celkove jsou desitky takovych souboru a v nich je cca 4 miliony zaznamu. Importni skript (cron) prochazi postupne tyto soubory a vzdy v jednom souboru projde treba tisic radku, ulozi pozici v tomto souboru a za 5 minut jede z novu, od tohoto mista a porad dokola. Pri nacteni jednoho radku je jeden dotaz, zda uz polozka existuje a pripadne se vlozi/edituje. Od doby, co je importovano cca pul milionu radku, tak behem dvou minut se stihne projit treba jen 90 polozek. Bohuzel je tam klasicky webhosting, neni tam VPS. Na skript jsou cca dve minuty, pak ho to killne. Z toho mi vyplyva, ze tim jak se tabulka plni, strasne se zpomaluje proces vyhledavani. Porovnava se kod produktu (dlouhy retezec) a ID vyrobce. Ted to bohuzel dela 1.04 sekund na jeden dotaz ohledne toho, zda dil existuje. A to uz je hrozne moc. Polozkam vsak chybi unikatni klic na kod produktu, protoze ten muze existovat ve dvou zaznamech kvuli dobe dodani, nese jine ceny, apod. A tady je myslim problem. Prijde mi, ze ten unikatni klic by to hodne dokazal zrychlit, nebo se pletu? Tabulka je MySQL (InnoDB). Jak na to? Prejit na VPS nebo klienta nechat prekopat ceniky, coz je asi nerealne vzhledem k mnozstvi? Pomohl by hodne ten unikatni klic na kod produktu? Problemy jsou nejvetsi pri tom overeni, zda ten produkt uz je v databazi.

1 vteřina na 0,5 mil řádků je celkem dost - jsou na daných sloupcích, podle kterých se hledá, indexy? Druhá varianta - naimportovat si to na localhostu, nebo na nějakém VPS a pak přemigrovat celou databázi, nebo jen příslušnou velkou tabulku.Každopádně, ten hosting asi nebude nejvhodnější na provoz takovéto aplikace/databáze

Určitě bych nejdřív přešel na výkoné VPS, pokud možno s SSD disky a velkou pamětí. Osobně jsem v minulosti importoval taky miliony záznamů z CSV a na hostingu mi to VPSko nějak nastavili, aby si databáze zabrala dost paměti (jinde nebyla potřeba) a dost to pomohlo. Podle čeho to vyhledává, když to nemá nějaký unikátní parametr? Nebo to má nějaký jakoby unikátní, ale jsou tam od toho 2 záznamy, s různými parametry, jestli to chápu? Má to nějaké kategorie? Pokud ano, hledá se produkt jen v dané kategorii, nebo v celé DB?

Tiez som riesil tento identicky problem (X CSV suborov, miliony zaznamov + porovnavanie s dalsimi milionmi v DB). A jedine riesenie bolo VPS.

Staci index na data dle kterych se vyhledava. Pokud jde o optimalizaci poctu db dotazu, nemusite se dotazovat na kazdy radek. Pokus to jde, nactete stav cele tabulky a overujte jednotlive polozky pole v ramci php cyklu. Vysledky pak nahrajte zpet do db.

Napsal lukaspulda;1416323

Staci index na data dle kterych se vyhledava.

Pokud jde o optimalizaci poctu db dotazu, nemusite se dotazovat na kazdy radek. Pokus to jde, nactete stav cele tabulky a overujte jednotlive polozky pole v ramci php cyklu. Vysledky pak nahrajte zpet do db.

Opravdu nacist najednou pul milionu zaznamu? To mi neprijde dobre. Pujdeme cestou VPS, diky vsem za rady. Verim ze takovy projekt si to stejne zaslouzi a je moje chyba, ze jsem cekal, ze to zvladne bezny hosting s par priplatkovymi sluzbami navic.

Jen pro upřesnění: tohle se bude dělat pravidelně, nebo je to jednorázový import, po kterém budou následovat pouze aktualizace? Pokud jednorázově, tak by se to samo sebou dalo udělat a připravit off line a předpřipravit import do databáze v nějaké optimalizované formě.A... absence unikátního klíče mne taky zarazila.

Napsal musil.david;1416350

Opravdu nacist najednou pul milionu zaznamu? To mi neprijde dobre.

Porovnej 1x select a 500 000 řádků a hromadný update a hromadný insert VS 500 000x provádět select/update/insert. 500 000 řádků je pro DB málo, není to žádný velký počet. Mnohem větší zátěž pro DB je neustále v datech hledat, přepočítávat indexy po každým update/insert apod.