Mam problem dość spory dotyczący granic możliwości przerobowych mysql i php.
Mam skrypt który ściąga dane w postaci xml i wrzuca je do bazy.
W czasie wykonywania skryptu parsuje on 6 plików xml (simplexml) o wadze 300mb każdy razem okoł 3 milionów rekordów które następnie wrzucam do bazy mysql. Jak dotąd

- skutecznie wieszam kompa lub
- dostaje komunikat o koncu limitu czasu wykonywania skryptu który wydłużam do 2700 sec.
- lub o czyms takim "Fatal error: Out of memory (allocated 702808064) (tried to allocate 16 bytes) "

(działa póki co na localhost amd64 3,4 ghz, 1gb ram, winXp). czy ktoś z was miał podobne projekty do realizacji ? i czy jest na to jakiś sposób w ramach php+mysql

Ja mam coś takiego jednak przy znacznie mniejszych danych. Tzn. plik xml ma około 23 mega następnie dodaje do bazy danych (ok. 100 tys. rekordów). Na lokalnym komputerze działa prawidłowo. Niestety na serwerze home.pl wywala bład o alokacji pamięci i nic się z tym nie da zrobić.

Pytanie:Może jest jakiś sposób na "sekwencyjne" wczytywanie xml'a?

to co zaznaczylem jest najwiekszym bledm, Simplexml z tego co wiem (mam nadzieje ze nie pomylilem sie) parsuje caly plik naraz metoda DOM. wiec taki plik bezproblemowo zapcha kazdy serwer. Proponuje uzyc parsowania SAX'em (Uzyj tego) i parsujac plik dodaj go do bazy. Tym sposobem paro GB pliki xml mozna ładowac do bazy i nic sie nie bedzie dzialo. To wina blednego zastosowania lub raczej rozwiązania.

Edit: zreszta temat chyba tutaj nie pasuje

Przenoszę do XML, AJAX > XML

Spróbuj składać zapytanie w postaci masowej. Zgaduję, że teraz jeden rekord = 1 insert. To potrafi zabić bazę danych. Składaj zapytanie o wielkości powiedzmy 10 tys rekordów i wysyłaj je od razu. Mówiąc 10 tys mam na myśli:

[SQL] pobierz, plaintext 
INSERT INTO foo (bar, baz) VALUES
(1, 2),
(2, 2),
(3, 2),
(4, 2),
// i tak dalej
[SQL] pobierz, plaintext 

No tutaj to ja bym sie spieral czy to bedzie lepsze. Nie wiem czy mysql "łyknie" tak wielkie zapytanie. Nie jestem przekonany czy nie braknie mu ramu aby trzymac wszystkie dane jednoczesnie, po sparsowaniu pojedynczego rekordu jeden insert, niepodejzewam zeby mysql sie zatkał. A tak wogole błędem było

a nie problemy z mysqlem. Sam przerabiałem ten problem przy xml'ach wiec ja mowie z doswiadczenia.

Będę złośliwy, ale widocznie masz skromne doświadczenie skoro tak się tym obnosisz i piszesz takie banialuki. Z testów, które przeprowadzaliśmy w pracy wynikało jasno, że wielokrotny insert po prostu miażdżył.
Zapytanie wykonywane dla 2 kolumnowej tabelki, bez jakichkolwiek indeksów, ponieważ częstotliwość zmian w testowanej tabelce była bardzo wysoka.


Jako bonus, dodam, że COPY PostgreSQL zajmowało dla 200 000 rekordów zajmowało około 4 sekund..
Testy wykonywane przy pomocy biblioteki sqlapi.

Proszę Cię Sh4dow, poważnie się zastanów zanim poddasz wątpliwości moje słowa.

Czy przypadkiem COPY w PG nie ma jakis ograniczen? Chodzi mi o wielkosc danych

@splatch, hmmm, jesli ma 3 miliony rekordow, wszystko pakowac do stringa no to ile bedzie wazyc zmienna z tym zapytaniem ?
Jesli blad jaki jest w temacie wyglada tak:
Fatal error: Out of memory (allocated 702808064) (tried to allocate 16 bytes)
Wiec jaki jest sens ładowac wszystko naraz i zyskiwac 30s, jesli parsowanie xmla bedzie zajmowac pare minut ? Nie chodzi o predkosc ale raczej o blad podany w temacie.

Jeśli mam 30 milionów rekordów to szybciej będzie robić 30 milinów zapytań czy 300 000?

wiesz w sumie to mozna zrobic binda w mysqli.
A co do paczkowania ilosci zapytan to juz podejzewam jego sprawa jak cobie rozwiaze

Sorki za OT'a:

~Sh4dow śledzę ten wątek od początku i muszę przyznać, że z każdym Twoim postem wątek coraz bardziej się nadaje na Humor.
Czy Ty zdajesz sobie sprawę jakie pierdoły gadasz?

Przecież każdy argument i wypowiedź ~splatcha kładzie na łopatki Twoje. A jednak się bezsensownie miotasz. Przecież dostałeś konkretne benchmarki.
Czy Ty w ogóle masz doświadczenie w tym temacie? Po tym co czytam: wątpię.

Jedyne co do czego masz rację to że lepiej parsować strumieniowo xml'a.

Proszę napisz coś jeszcze: bawisz mnie

Nie no oczywiscie ze mam zielonego pojescia a dla ciebie szczegolnie pisze cos zeby poprawic ci humor w taki szary dzien jak dzis
zgodze sie ze zapytanie bedzie sie wykonywac dluzej. Ale niepodejzewam zeby biblioteka w c++ odzwiercieglala zachowanie skryptu w php bardzo dokladnie

test pierwszy 100 rekordow 1 zapytanie sql


100 rekordow 100 zapytanie sql


drugi test 5000 rekordow 1 zapytanie


5000 rekordo 5000 zapytan


trzeci test 10000 rekordo 1 zapytanie


10000 rekordow 10000 zapytan sql


czwarty test 50000 rekordow 1 zapytanie

zapytanie sie nie udalo

50000 rekordow 50000 zapytan sql


dla ostatniego testu byłem zmuszony zwiekszyc ilosc pamieci dla skryptu do 64 MB

Nie mowie ze sie nie zgadzam ze splatch'em. Ale podaje rozwiazanie na tyle optymalne ze nie ogranicza mnie wielkosc xml'a bedzie to dzialac dla 10 rekordow i dla 100 GB xml'a poprostu bedzie dłuzej sie wykonywac. Nie musze kombinowac i sprawdzac jak duze packi beda mi przechodzic. Jesli pojawi sie blad w zapytaniu, z jakiego kolwiek powodu. Powiedzmy ze chodzi o dane z xml'a to niezaladuje sie jedno zapytanie a nie cala paczka. Wszystko zalezy od tego jak krytyczny jest skrypt. Skrypt uzalezniasz od tego jak ma dzialac. Jesli administrator zmniejszy wartosc max_allowed_packet na serwerze mysqla to ? A no i jeszcze jedno, ja nie testowalem tego na tablicy gdzie sa dwa inty ale na 6 kolumnach gdzie 3 to int i 3 to varchar.

Podkreslam jeszcze raz, ze nie neguje tego co pisał splatch. Ja stwierdzam cos co zauwazylem kiedys pracujac z duzymi plikami xml ktore obslugiwalem przez php.