Temat: Pytanie o wydajność MySql Postgres ?
Moim zdaniem powinieneś zrobić to w konfiguracji klastrowej multi master (co eliminuje wariant z PostgreSQL...).
Szkoda słyszałem że Postgres przy większych rozwiązaniach jest wydajniejszy i ma większe możliwośći optymalizacji od MySQL.
Niestety nie mogę tu zaoferować twardych danych. Robiłem na Postgresie i na MySQL-u różne systemy, ale nie miałem okazji robić należytej analizy porównawczej (jedna aplikacja, ściśle zdefiniowane obciążenie, powtarzalne testy z użyciem backend-ów PgSQL oraz MySQL - tak to należałoby zrobić aby mieć faktyczne rozeznanie).
Mnie samemu bardziej podoba się PostgreSQL ze względu na przemyślaną architekturę. Faktycznie może być sprawniejszy przy barzdiej złożonych dziedzinach problemowych. Na przykład wyposażony jest w genetyczny optymalizator zapytań, odpalający się automatycznie przy złączaniu powyżej 13 tabel - wykonuje swoją pracę znacznie szybciej, niż klasyczny optymalizator, któremu złożoność obliczeniowa rośnie geometrycznie wraz ze wzrostem ilości złączeń.
PostgreSQL ma też bogaty wybór dedykowanych typów indeksów dla potrzeb rozwiązań GIS, OLAP, oraz przetwarzania danych geometrycznych.
MySQL natomiast wygląda jak zlepek poprawek dodawanych na zasadzie późniejszej refleksji, na przestrzeni ostatnich kilku lat, bez jakiegogkolwiek uprzedniego planu rozwojowego.
Jednak czasami rozwiązania bardziej eleganckie nie sprawdzają się wcale lepiej od tych bałaganiarskich.
Za MySQL przemawia jego wykorzystanie w praktyce przez:
* Livejournal (2 mln. aktywnych użytkowników)
* Wikipedia (przedstawiać chyba nie trzeba)
* Google AdWords
* YouTube
* Digg
* Facebook
* Yahoo! Finance
* Craigslist
Tak więc masz sporo literatury na temat skalowania rozwiązań na nim opartych.
Wadą tego rozwiązania jest trudniejsze zarządzanie, brak wsparcia komercyjnego - ze wszystkimi ew. problemami zostajesz sam.
Początki są zawsze trudne. Dzięki za poświęcony czas.
Jak ktoś słusznie zauważył, na MySQL możesz wykupić komercyjne wsparcie. W przypadku PostgreSQL masz multum małych firm świadczących wsparcie (n.p. dla Europy, łącznie z Polską:
http://www.postgresql.org/support/professional_support..., ale w takim przypadku zawsze trudno wybrać kogoś, kto ci da to, czego potrzebujesz.
MySQL daje ci możliwość kupienia wsparcia u samego producenta.
Do tego wykupienie MySQL przez Sun wróży kontunuację wsparcia komercyjnego na przyzwoitym poziomie.
====================
A teraz odpowiedzi dla innych kolegów:
Michał Zaborowski wrote:
Acha jest multi-master dla Postgresa - nazywa się PgCluster.
Jestem tego świadom, ale pominąłem go celowo bo:
* Tworzył go samotnie jeden japończyk, do tego kiepsko znający jęz. angielski, a od czasu jak go testowałem nie wyszło żadne nowe wydanie (tj od roku 2005)
* Replikacja jest oparta na poleceniach, nie na logu transakcji (command/statement-based replication), co stwarzać może problemy. W MySQL masz do wyboru Statement Based Replication, Row Based Replication oraz tryb mieszany Mixed Based Replication.
Piotr Likus wrote:
Jeśli nie jesteś pewien, to zrób rozwiązanie z wymienialną
warstwą danych - wtedy będzie można zmienić w razie czego.
Jesteś jednak świadom, że przy wymienialnej warstwie danych często trzeba rezygnować ze stosowania specyficznych dla danego silnika bazy danych "sztuczek", pozwalających z niego wysupłać dużo dodatkowej wydajności?
N.p. nie skorzystasz z wyszukiwania pełnotekstowego tsearch2 PostgreSQL-a bez użycia kodu SQL specyficznego dla Postgres.
Można co prawda stworzyć warstwę pośrednią na funkcjach/przechowywanych procedurach/widokach, z pewnym umownym "API", ale to ma swój narzut i w zasadzie mnoży pracochłonność przez dwa.
Wiesz, że prekompilowana funkcja zastępująca SELECT-a może wykonać się wolniej od tego SELECT-a bezpośredniego, bo na etapie kompilacji nie są optymalizatorowi zapytań znane statystyki na tabelach z przyszłego momentu wywołania funkcji i może ybrać suboptymalny plan wykonania zapytania (n.p. nierozsądną kolejność złączeń)?
Procedury i funkcje nie zawsze oferują zysk na wydajności.
пропозиції роботи
