dzienny limit

[krzysztoflaniak]

Witam
mam problem z wczytywaniem baz danych do mojego sklepu, polega na tym, że codziennie wczytuję pliki z 3 sklepów w systemie dropshipping w każdym z tych sklepów jest około 15000 pozycji i pomiędzy 1-15 wielkości i niestety po zmianach nie mam możliwości wczytaniu plików limit wczytań pozycji proszę o możliwość zwiększenia limitu przesyłania danych jednego dnia
Pozdrawiam
Krzysztof

[Venite]

krzysztoflaniak, do jakiej strony odnosi się problem? Bardzo prosiłbym o podanie jej adresu.

W jaki sposób wczytuje Pan wspomniane pliki? Jakimś skryptem, poprzez phpMyAdmin?

[krzysztoflaniak]

problem dotyczy domeny modafhu.shop.pl w wczytuje przez poprzez phpMyAdmin zawsze tam wczytywałem i było ok ostatnio mam problem pliki csv i tak mam spakowane bo są dużej wielkości zaczyta się jeden góra 2 pliki potem wyskakuje błąd osiągnięto limit

[Piotr GRD]

O ile nic się nie zmieniło od grudnia, to może chodzić o godzinny limit 36 000 "update'ów" na każdego użytkownika bazy danych.
Wątpię, aby administracja była skłonna jeszcze bardziej ten limit zwiększyć, przy zbytnim obciążeniu MySQL lubi się zapychać, choć (bazując na wpisach na forum) w sierpniu było to 35 000, a na początku roku 2013 - 8 000, więc co jakiś czas się to zmienia.

@ krzysztoflaniak
Jeśli mam rację w powyższym, to nie powinieneś mieć problemów, gdy rozłożysz sobie to w czasie na ponad godzinę.

Poza tym z wielu względów powinieneś chyba pomyśleć o jakimś bardziej optymalnym rozwiązaniu, czyli nanoszeniu wyłącznie tego, co się zmieniło, zamiast za każdym razem wgrywaniu całej zawartości sklepów (chyba że faktycznie za każdym razem cały asortyment się zmienia). Oczywiście wrzucanie całości na pewno jest łatwiejsze.

[piwo]

Przyłączę się do Piotr GRD,
Wielkości limitów na CBA są ustawione na sensownych wysokościach i zapewniają sprawną pracę skryptów.
Również moim zdaniem, w tym wypadku wygląda na to że używa pan bardzo nieoptymalnego sposobu wprowadzania danych.

Rozwiązaniem byłoby przedstawienie wymogów i posiadanej infrastruktury (tzn. mam 3 sklepy, zbieram z nich dane, chcę te dane w jednej bazie itp.) osobie która zbudowała dla pana tą stronę i poproszenie o stworzenie systemu wykonującego to zadanie z naciskiem na
- łatwość użytkowania (najlepiej gdyby wykonywało się to automatycznie)
- optymalizację zasobów (czyli "aktualizowanie" wyłącznie pozycji które uległy zmianie, wprowadzanie wielu danych jednocześnie w pakietach powiedzmy po 2000 artykułów na zapytanie.)

...a to by było 7 zapytań SQL a nie 36000+ co jak widać jest tą słuszną drogą zamiast kontynuowanie nieefektywnej drogi która mimo podnoszenia limitów i tak doprowadziłaby do zatkania się wszystkiego.
SQL jest przede wszystkim mechanizmem efektywnego obrabiania dużej ilości danych, przechowalnią jest nie jako "przy okazji".

[Piotr GRD]

Być może możesz sprawę rozwiązać w bardzo prosty sposób.

Zakładam, że "gdzieś tam" zarządzasz/aktualizujesz w jakiś sposób zawartością sklepów, eksportujesz wynik do pliku CSV, a następnie wczytujesz to do tutejszej bazy danych. W ten sposób jednak każda kolejna pozycja w pliku CSV to jedno zapytanie do bazy danych.

Można to zrobić inaczej. Sprawdź czy jesteś w stanie eksportować swoje dane nie do CSV, a do formatu SQL z opcją wstawiania wielu wierszy w jednym zapytaniu INSERT (po angielsku tzw. "extended inserts"). W ten sposób znacząco zmniejszy się ilość zapytań do bazy danych przy niezmienionej ilości wprowadzonych danych.

To nadal nie będzie najlepsze rozwiązanie, wciąż niepotrzebnie za każdym razem wrzucana będzie całość, ale ominiesz limit ilości "update'ów".

[Venite]

krzysztoflaniak, poprzednicy myślę, wyczerpali temat. PiotrGRD słusznie zauważył, że można wiele zapytań wykonać tak naprawdę w jednym INSERT'cie. Liczone są pojedyncze wykonania zapytania, więc takie pojedyncze duże, zbiorowe wykonanie (oczywiście w granicach rozsądku) będzie liczone nie jako "X" tyś. zapytań, a jako jedno.