@drag_op: To jest dość skomplikowane. PostgreSQL jest projektem który jest stary, PostgreSQL wywodzi się z projektu Postgres a ten z Ingres, Ingres został zapoczątkowany w 1973 roku gdy jeszcze nikomu się o webdevie nie śniło. W czasach gdy sieć startowała to Postgres był już zaawansowaną bazą danych, z obsługą wielu rzeczy ale wymagał sporych zasobów i był wolny, to nie był problem bo nikomu się nie śpieszyło. msql powstał jako wrapper dla postgresa a następnie dostał własny prościutki system. MySQL został napisany by zastąpić popularny msql i od początku był nastawiony na szybkość kątem jakości więc były idealny dla prostych aplikacji. Na dodatek wspierał Windowsa (Postgres dostaje wsparcie dla Windowsa w 2005!) więc był dobry dla początkujących którzy po prostu chcieli stworzyć prostą stronę i nie obchodziło ich że nie ma transakcji a domyślne kodowanie znaków jest po szwedzku.
No więc mamy sytuację gdy MySQL lepiej się nadaje do webdevu, pisane są oparciu o niego tutoriale, programiści go używają, kolejne wchodzące na rynek pokolenia uczą się od starszych, nowe projekty są tworzone w oparciu o MySQL bo programiści tę bazę danych znają i już się zdołali przyzwyczaić do jej niedoróbek i świetnie się wpisuje w filozofię PHP "zwróć jakikolwiek wynik, będzie dobrze".
Projekty korporacyjne tworzone są w oparciu o Oracle, SQL Server, DB2 i Sybase, Postgres jest używane przez środowiska akademickie a kolejne webowe startupy rosną w siłę i wywalają się na ryj bo MySQL ma swoje limity.
MySQL z czasem zyskuje normalną funkcjonalność (transakcje, functional dependency) a PostgreSQL zyskuje na wydajności; W 2012 ostatecznie przestaje obowiązywać argument że MySQL jest szybszy bo w Postgresie count() wolno działa. Postgres w tym czasie jest też rozwijane o szereg funkcjonalności, obsługuje kolejne wersje standardu SQL, indeksy częściowe, indeksy na funkcjach, zyskuje świetne projekty typu PostGIS i jest forkowany do wielu świetnych projektów typu Redshift, Greenplum czy Netezza. Po prostu PostgreSQL jest tak świetnie napisany że można na nim zbudować wszystko.
Odpowiedzią na problemy z MySQL jest modny buzzword "NoSQL", czyli bazy danych zrobione na rympał które też nie oferują żadnych zaawansowanych ficzerów ale za to szybko działają więc zyskują poklask developerów którzy nawet za bardzo nie wiedzą jak indeksy pozakładać. Tak, NoSQL ma swoje zastosowanie ale tym zastosowaniem nie jest "bo strona szybciej działa".
No i tak docieramy do czasów obecnych, MySQL jest popularny bo jest popularny a za Postgresem ciągnie się sława tego że jest wolny. Była szansa że MySQL upadnie jak ich Oracle wykupił ale tego nie doczekaliśmy, co więcej Oracle nam podarowało najlepszy ficzer w 5.7 czyli prawidłowo działające functional dependency. Jeszcze przez wiele, wiele lat kolejne projekty będą zaczynane w MySQL a następnie wpadać w problemy gdy się okaże że MySQL nie da się zrobić skomplikowanych zapytań SQL, potrzebny jest dedykowany admin bo w sumie nie wiadomo jak to stuningować by działało, explain absolutnie nic nie mówi, wsparcie dla indeksów jest bardzo słabe a na dodatek wcale się dobrze nie skaluje pomimo tego że Facebook go używa.
Zanim zaczniesz kolejny projekt z MySQL tylko dlatego że znasz podstawowe w nim funkcje to się zastanów.
@plushy dziękuję. Co do szybkości działania count'a. Zobacz jak szybko działa count w mysql na innodb... Nie wiem jak robi to postgre ale pewnie w cholerę szybciej ;D
@drag_op: Chodzi o zapytanie SELECT COUNT(*) FROM tbl. Silnik MyISAM dla MySQL nie wspierał transakcji i zapisywał liczbę wierszy dla każdej tabeli dlatego zwracał błyskawicznie wynik, PostgreSQL sprawdzał widoczność każdego wiersza dla aktualnej transakcji przez odwiedzenie krotki na dysku co było bardzo wolne, od 2012 pg wspiera index-only-scan i potrafi zwrócić wynik po przeanalizowaniu indeksu, natomiast MySQL obecnie wspiera transakcje w domyślnym silniku innodb i już tak błyskawiczny nie jest.
@Zdalny: A teraz nadal jest problem :) Generalnie replikacja master-master jest trudna i nie powinieneś tego robić jeśli nie masz naprawdę dobrego powodu (a prawdopodobnie nie masz). Jest BDR który to wspiera i robi to dobrze ale zwykle odpowiedzią jest posiadanie klastra master-slave który automatycznie promuje kolejny serwer jeśli oryginalnemu coś się stanie, i kuloodporne serwery.
@Zdalny: Nie, bo w MySQL są te same problemy z tym że tam zwykłą odpowiedzią jest "Będzie pan zadowolony". PostgreSQL jest nastawiony na niezwodność i dokładność dlatego trudne problemy typu replikacja master-master są opisywane jako trudne. MySQL jest robiony w myśl zasady "My ze szwagrem po pijaku nie takie rzeczy robili" dlatego trudne problemy są opisywane jako "No przecież jakoś działa".
@wnocy: Większość developerów nie pracuje na taką skalę by replikacja master-master naprawdę była potrzebna. By zaszła taka konieczność to albo musisz pchać dziesiątki tysięcy zapisów na sekundę albo musisz obsługiwać portal który ma na tyle duży zasięg by konieczne było stawianie baz danych z kopią na każdym kontynencie. Zwykła baza danych potrafi obsłużyć tysiące insertów/updateów na sekundę, a przy tej skali albo masz bardzo specyficzną aplikację albo jesteś gigantem w branży.
@plushy: jeżeli chodzi o bazy to jestem zielony. Powiedz mi w takim razie, w jaki inny sposób zapewnić spójność danych w razie awarii jednego serwera. Powiedzmy, ze mam odpalone usługi na X serwerach, które zrzucają dane do bazy. W przypadku padu serwera z bazą danych, mogą zrzucać się do drugiego mastera. Natomiast po powrocie pierwszego, serwery "ustalą wspólną wersję wydarzeń". Klient musi widzieć w czasie rzeczywistym raporty z danych, które podsyłają
@plushy: Dodałbym jeszcze, że przez wiele lat MySQL miał chory sposób licencjonowania (i chyba nadal ma) - gdzie sterownik bazy był traktowany tak samo jak cała baza i oparty był na licencji GPL, która wymagałaby aby oprogramowanie jeśli tylko korzystało z connectorów dostarczonych przez Sun a potem Oracle na takiej licencji, samo również było dystrybuowane tak (Free & Open), co w praktyce uniemożliwiało sprzedaż własnego oprogramowania używającego sterowników do MySQL bez
@wnocy: Mamy trzy sposoby na rozwiązanie problemu: 1) Transakcja nie jest zapisana dopóki nie zostanie zreplikowana 2) No to trudno, promujemy slave'a i dane przepadły 3) Developer definiuje jak rozwiązać ewentualne konflikty
Jedyną różnicą tutaj jest to że pg twierdzi że te problemy są poważna a my twierdzi że nie, obie bazy wspierają wszystkie opcje.
@plushy: Nie wiem czy jest sens implementować samemu mechanizmy replikacji/rozwiązywania konfliktów, skoro może się tym zając baza danych. Dlaczego ja miałbym to zrobić lepiej niż MySQL?
@ppawel: Licencja GPL to ogólnie trochę rak bo w sumie nie wiadomo gdzie ona się zatrzymuje. Jeśli robię wtyczkę do programu GPL to jest on pracą pochodną no chyba że interfejs jest uniwersalny to wtedy nie. Jeśli robię program który korzysta z interfejsu na GPL to jest on pracą pochodną,no chyba że nie. Jeśli stworzę adapter do swojej aplikacji który wywołuję aplikację na GPL to się on zaraża GPL ale być
Nie wiem czy jest sens implementować samemu mechanizmy replikacji/rozwiązywania konfliktów, skoro może się tym zając baza danych. Dlaczego ja miałbym to zrobić lepiej niż MySQL?
@wnocy: Nie lepiej, tylko musisz wybrać. Zarówno w Postgresie jak i w MySQL musisz wybrać co się stanie jeśli na kilku masterach jest np. update do tego samego wiersza. Domyślnie jest wybrany pewny sposób rozwiązywania konfliktów ale to ty musisz zdecydować czy chcesz pierwszy zaktualizowany rekord,
@plushy: rozumiem. U mnie na szczęście taka konfliktowa sytuacja nie wystąpi, bo dane nie są aktualizowane, tylko dorzucane kolejne. Więc sądzę, że master-master w moim przypadku jest tym czego potrzebuję i co nie spowoduje większych problemów. No i (na nieszczęście dla postgresa) w MySQL robi się to łatwiej.
#sql #programowanie #webdev #mysql #postgersql
@drag_op: To jest dość skomplikowane. PostgreSQL jest projektem który jest stary, PostgreSQL wywodzi się z projektu Postgres a ten z Ingres, Ingres został zapoczątkowany w 1973 roku gdy jeszcze nikomu się o webdevie nie śniło. W czasach gdy sieć startowała to Postgres był już zaawansowaną bazą danych, z obsługą wielu rzeczy ale wymagał sporych zasobów i był wolny, to nie był problem bo nikomu się nie śpieszyło. msql powstał jako wrapper dla postgresa a następnie dostał własny prościutki system. MySQL został napisany by zastąpić popularny msql i od początku był nastawiony na szybkość kątem jakości więc były idealny dla prostych aplikacji. Na dodatek wspierał Windowsa (Postgres dostaje wsparcie dla Windowsa w 2005!) więc był dobry dla początkujących którzy po prostu chcieli stworzyć prostą stronę i nie obchodziło ich że nie ma transakcji a domyślne kodowanie znaków jest po szwedzku.
No więc mamy sytuację gdy MySQL lepiej się nadaje do webdevu, pisane są oparciu o niego tutoriale, programiści go używają, kolejne wchodzące na rynek pokolenia uczą się od starszych, nowe projekty są tworzone w oparciu o MySQL bo programiści tę bazę danych znają i już się zdołali przyzwyczaić do jej niedoróbek i świetnie się wpisuje w filozofię PHP "zwróć jakikolwiek wynik, będzie dobrze".
Projekty korporacyjne tworzone są w oparciu o Oracle, SQL Server, DB2 i Sybase, Postgres jest używane przez środowiska akademickie a kolejne webowe startupy rosną w siłę i wywalają się na ryj bo MySQL ma swoje limity.
MySQL z czasem zyskuje normalną funkcjonalność (transakcje, functional dependency) a PostgreSQL zyskuje na wydajności; W 2012 ostatecznie przestaje obowiązywać argument że MySQL jest szybszy bo w Postgresie count() wolno działa. Postgres w tym czasie jest też rozwijane o szereg funkcjonalności, obsługuje kolejne wersje standardu SQL, indeksy częściowe, indeksy na funkcjach, zyskuje świetne projekty typu PostGIS i jest forkowany do wielu świetnych projektów typu Redshift, Greenplum czy Netezza. Po prostu PostgreSQL jest tak świetnie napisany że można na nim zbudować wszystko.
Odpowiedzią na problemy z MySQL jest modny buzzword "NoSQL", czyli bazy danych zrobione na rympał które też nie oferują żadnych zaawansowanych ficzerów ale za to szybko działają więc zyskują poklask developerów którzy nawet za bardzo nie wiedzą jak indeksy pozakładać. Tak, NoSQL ma swoje zastosowanie ale tym zastosowaniem nie jest "bo strona szybciej działa".
No i tak docieramy do czasów obecnych, MySQL jest popularny bo jest popularny a za Postgresem ciągnie się sława tego że jest wolny. Była szansa że MySQL upadnie jak ich Oracle wykupił ale tego nie doczekaliśmy, co więcej Oracle nam podarowało najlepszy ficzer w 5.7 czyli prawidłowo działające functional dependency. Jeszcze przez wiele, wiele lat kolejne projekty będą zaczynane w MySQL a następnie wpadać w problemy gdy się okaże że MySQL nie da się zrobić skomplikowanych zapytań SQL, potrzebny jest dedykowany admin bo w sumie nie wiadomo jak to stuningować by działało, explain absolutnie nic nie mówi, wsparcie dla indeksów jest bardzo słabe a na dodatek wcale się dobrze nie skaluje pomimo tego że Facebook go używa.
Zanim zaczniesz kolejny projekt z MySQL tylko dlatego że znasz podstawowe w nim funkcje to się zastanów.
Co do szybkości działania count'a. Zobacz jak szybko działa count w mysql na innodb... Nie wiem jak robi to postgre ale pewnie w cholerę szybciej ;D
SELECT COUNT(*) FROM tbl. Silnik MyISAM dla MySQL nie wspierał transakcji i zapisywał liczbę wierszy dla każdej tabeli dlatego zwracał błyskawicznie wynik, PostgreSQL sprawdzał widoczność każdego wiersza dla aktualnej transakcji przez odwiedzenie krotki na dysku co było bardzo wolne, od 2012 pg wspiera index-only-scan i potrafi zwrócić wynik po przeanalizowaniu indeksu, natomiast MySQL obecnie wspiera transakcje w domyślnym silniku innodb i już tak błyskawiczny nie jest.Powiedzmy, ze mam odpalone usługi na X serwerach, które zrzucają dane do bazy. W przypadku padu serwera z bazą danych, mogą zrzucać się do drugiego mastera. Natomiast po powrocie pierwszego, serwery "ustalą wspólną wersję wydarzeń". Klient musi widzieć w czasie rzeczywistym raporty z danych, które podsyłają
Dodałbym jeszcze, że przez wiele lat MySQL miał chory sposób licencjonowania (i chyba nadal ma) - gdzie sterownik bazy był traktowany tak samo jak cała baza i oparty był na licencji GPL, która wymagałaby aby oprogramowanie jeśli tylko korzystało z connectorów dostarczonych przez Sun a potem Oracle na takiej licencji, samo również było dystrybuowane tak (Free & Open), co w praktyce uniemożliwiało sprzedaż własnego oprogramowania używającego sterowników do MySQL bez
1) Transakcja nie jest zapisana dopóki nie zostanie zreplikowana
2) No to trudno, promujemy slave'a i dane przepadły
3) Developer definiuje jak rozwiązać ewentualne konflikty
Jedyną różnicą tutaj jest to że pg twierdzi że te problemy są poważna a my twierdzi że nie, obie bazy wspierają wszystkie opcje.
Nie wiem czy jest sens implementować samemu mechanizmy replikacji/rozwiązywania konfliktów, skoro może się tym zając baza danych. Dlaczego ja miałbym to zrobić lepiej niż MySQL?
@wnocy: Nie lepiej, tylko musisz wybrać. Zarówno w Postgresie jak i w MySQL musisz wybrać co się stanie jeśli na kilku masterach jest np. update do tego samego wiersza. Domyślnie jest wybrany pewny sposób rozwiązywania konfliktów ale to ty musisz zdecydować czy chcesz pierwszy zaktualizowany rekord,