Argumenty za PostgreSQL
Martin Langhoff popiera PostgreSQL (źródło: Moodle over webct and LNLS at Athabasca University? - post na forum).
Jest kilka powodów, dla których miałbyś używać Postgres. Spróbuję w skrócie nakreślić najważniejsze. W Catalyst uruchamiamy najróżniejsze RDBMS-y i mamy z nimi duże doświadczenie: Oracle, Postgres, MySQL oraz Progress, plus kilka innych. Mamy także doświadczenie z replikowanymi bazami danych, klastrami i innymi trickami, których używamy w serwerach z domeny .nz jak i na kilku innych krytycznych systemach.
Pod względem wydajności Postgres wymaga odrobinę więcej przygotowania ze strony konfiguracji niż MySQL. Dobrze skonfigurowany Postgres przy zapytaniach SELECT jest bardzo bliski wydajności MySQLa na małych bazach. Na dużych tabelach MySQL ma problemy z wydajnością. Postgres radzi sobie dużo lepiej.
Również wydajność zapisu jest problemem w MySQL. Przy dużym ruchu, ma on poważne problemy z współbieżnym zapisem. Pod dużym obciążeniem Postgres zachowuje się dużo lepiej.
Prawdę mówiąc, prawdziwym powodem, dle którego warto używać Postgres, jest niezawodność. Utrzymujemy dużo baz danych a Postgres jest stabilny jak skała i zachowuje poprawność ACID: po uaktualnieniu bazy, dane są bezpiecznie przechowywane na dysku i nie zostaną utracone -- jeśli pominiemy fizyczne problemy z dyskami, których unikamy za pomocą RAID-1.
Nie zależnie od tego jak bardzo się staramy, intensywnie bazy danych MySQL będą zawsze miały problemy z utratą indeksów. Jeśli spojrzysz na skrypty startowe MySQLa większości dystrybucji Linuksa, zobaczysz, że na początku jest wykonywane sprawdzanie poprawności danych. Jest tak, ponieważ utrata indeksów jest częstym wypadkiem.
Przy małych bazach danych, gdzie dane nie są krytyczne, jest to do przyjęcia. Powinieneś jednak się zastanowić, na ile możesz ufać takiemu podejściu. Uruchamianie isamchk/myisamchk na dużych zbiorach danych będzie trwało godzinami -- nie możemy sobie na to pozwolić.
Klastry MySQL są naciągane i uważam, że mijają się one z celem. Moją główną obawą przed nimi jest fakt, że zapisują one asynchronicznie -- oznacza to, że nie ma żadnej gwarancji, że są bezpiecznie na dysku. Od czasu do czasu trafiają na dysk. Trafiają też do maszyn podrzędnych... czasami. Hmmm.
Przyjmując, że klaster MySQL używa asynchronicznych zapisów, rozdzielanie odczytów/zapisów na maszynę nadrzędną (master) i podrzędną (slave) powoduje problemy, kiedy zapiszemy trochę danych a zaraz potem spróbujemy je odczytać. A takie sytuacje zdarzają się w kilku miejscach.
Powinieneś także rozważyć przyspieszenie, jakie daje używanie asynchronicznych zapisów: jeśli skonfigurujesz samodzielnego Postgresa albo MySQL, aby zapisywał asynchronicznie, będzie działał dużo szybciej (powinien być wstanie obsłużyć 3-4 razy więcej jednoczesnych zapisów). Po tym zabiegu procentowa przewaga w wydajności klastra MySQL nad samodzielnym serwerem w większości zanika. Cały czas ma przewagę w wypadku, kiedy master padnie, lecz Postgres może to uzyskać przez Slony -- z lepszą gwarancją spójności danych na slave'ie.
W skrócie, MySQL przeważnie nie jest zbyt pewny jeśli chodzi o bezpieczne zapisanie danych na dysku (nawet jeśli teoretycznie gwarantuje, że zostały zapisane). A klaster MySQL mówi, że nie ma już żadnej gwarancji. No właśnie ;).
Michael mówił o UPS-ach. Mamy UPS-a wielkiego jak samochód. Mamy też generator na potrzeby naszej witryny. Załącza się automatycznie i jest rozmiarów kontenera. Mimo to, nie powierzałbym im spójności mojej bazy danych, jeśli mówimy o dużych systemach. Jest wiele innych rzeczy, innych niż zasilanie, które mogą się zepsuć (i faktycznie się psują). Jeśli proces ma problem z zapisem danych, powinien poinformować o tym użytkownika. Z asynchronicznymi zapisami skończysz z kolejką danych wiszących w powietrzu, które czekają na zapis. Mimo to, użytkownik został już poinformowany o prawidłowym zapisie.
To nie jest to, czego oczekujemy od bazy danych.
Aktualnie odkrywam techniki podobne do tych, których używa się na livejournal i slashdocie. Powinniśmy być w stanie zwiększyć skalowalność Moodle'a przez zmniejszenie obciążenia witryny o ok. 50%. Robimy to w przerwach pomiędzy pilniejszymi projektami. Jeśli cię to interesuje, możesz śmiało odezwać się do mnie lub do Richarda.
