W dniu 16.10.2012 13:45, Sylwester Kondracki napisał(a):
Dnia 2012-10-16, wto o godzinie 13:02 +0200, Tomasz Chiliński pisze:
W dniu 16.10.2012 12:52, Marcin napisał(a):
W dniu 16 października 2012 12:40 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
A ja lubię tak pisać o MySQL, bo zawsze widzę przed oczami rzeszę ludzi męczącą się z MySQL i mi ich trochę żal ;-)
a ja Tomku zastanawiałem się nad przejściem na postgress właśnie m.in [1]. po Twoich postach. porównuje wyniki wydajności mysq vs. postgres i przyznam, że prawie, podkreślam "prawie", nic nie przemawia za postgres. Dodatkowo replikacja jest też sporo utrudniona. żeby nie być gołosłownym pierwszy link porównujący bazy.
http://www.progresowi.pl/2011/11/10/porownujemy-wydajnosc-mysql-vs-postgresq... [1] [2] oczywiście w starszych wersjach mysql to postgres wygrywał znacząco. teraz te różnice się zatarły.
Twoim zdaniem, co konkretnie przemawia za postresem?
A i z tego co sobie przypominam przy tego typu testach MySQL zawsze był bardziej wydajny niż PostgreSQL i nic dziwnego, bo jak powstawał to miał być czymś podobnym do obecnie popularnego SQLite... Do dziś MySQL ma tryb embedded!
-- Pozdrawiam Marcin / nicraM
to i ja dołożę swoje 3 grosze.
Wydajność bazy można oceniać jak mamy np. z 1 mln rekordów, przy 3-4k to tak naprawdę decyduje jak jest napisane zapytanie SQL.
W LMS jest obsługa MySQL i PgSQL więc zapytania musza być "uniwersalne", a jak wiadomo co jest uniwersalne to jest do d...y, i w takim przypadku nie uzyskami 100% wydajności dla każdej z baz.
Kiedyś robiłem przeróbkę funkcji getcustomerlist pod kątem wydajności dla MySQL, przy 5k klientach, każdy z nich miał po 36 faktur czas generowania 1 strony był na poziomie 2.2 - 2.6(max) sek, (przy oryginalnym kodzie trwało to ponad 180 sekund, test na starej maszynce) ale ta sama przeróbka w postgresie nie miała racji bytu, PG wysypywał się przy zapytaniu, dla niego była błędna składnia zapytania.
Jedyne co można w tej chwili zrobić dla MySQL to poprawić trochę strukturę bazy danych, typy pól, indexy' itp. czy w niektórych tabelach przejść spowrotem na MyISSAM, na podstawie własnych eksperymentów mogę powiedzieć że można to jeszcze bardziej zoptymalizować i efekty są widoczne.
Co przemawia (jak dla mnie) żeby używać PgSQL, lepsza wydajność przy bardzo złożonych zapytaniach, i to jest jedyna rzecz która mogła by mnie skłonić do używania tej bazy "trwale", pozostałe niuanse jakimi rządzi się PG , zwłaszcza przy dodawaniu/edycji rekordów , dość mocno zniechęcają do używania tej bazy, delikatnie mówiąc PgSQL w zapytaniach nie jest tak "debiloodporny" jak MySQL. (plus dla MySQL)
Na co dzień nie używam PG (tylko jak muszę) , więc nie wiem jak jest w tej chwili, ale swojego czasu (info z różnych for) PG lubił się wysypać, mi MySQL nie padł jeszcze.
To bardzo interesujące - u mnie MySQL, gdy nastąpi zanik zasilania ma problemy sam ze sobą, czego ani razu nie doświadczyłem w PgSQL.
Najlepszym rozwiązaniem by było : albo wybranie "jedynej słusznej bazy" i pod nią pisać zapytania , wtedy będzie można wycisnąć soki z bazy, albo pisać osobne zapytania dla MySQL i PgSQL, ale jak życie pokazuje w/w rozwiązania mijają się realiami jakie mamy na co dzień.
MySQL jest naprawdę wydajną bazą, ale muszą być spełnione warunki : struktura i zapytania muszą być zrobione pod tą bazę.
To tyle jeżeli chodzi o spojrzenie na bazy zwykłego śmiertelnika :D