Migracja z MySQL do PostgreSQL

Question

Obecnie korzystamy z MySQL dla produktu, który budujemy, i chcemy jak najszybciej przejść do PostgreSQL, głównie z powodów licencyjnych.

Czy ktoś inny wykonał taki ruch? Nasza baza danych jest siłą napędową aplikacji i docelowo będzie przechowywać TB danych, więc chętnie usłyszę o doświadczeniach poprawy wydajności/strat, głównych przeszkód w konwersji SQL i procedur przechowywanych, itp.

Edytuj: Just wyjaśnić tym, którzy zapytali, dlaczego nie lubimy licencjonowania MySQL. Opracowujemy produkt komercyjny, który (obecnie) zależy od MySQL jako back-endu bazy danych. Ich licencja mówi, że musimy zapłacić im procent naszej ceny katalogowej za instalację, a nie płaci się za to stałą opłatę. Jako startup jest to mniej niż atrakcyjne.

Answer 1

Steve, musiałem przenieść moją starą aplikację dookoła, czyli PgSQL-> MySQL. Muszę powiedzieć, że należy rozważyć sam szczęście ;-) Częste problemy to:

• SQL jest rzeczywiście bardzo blisko do standardu języka, więc może cierpieć z dialektu MySQL już wiesz
• MySQL cichu obcina varchars że przekraczać długości max, podczas gdy Pg narzeka - szybkie obejście ma mieć te kolumny jako „tekst” zamiast „varchar” i stosowania wyzwala obciąć długie linie
• cudzysłowy są stosowane zamiast odwrotnych apostrofach
• pola typu Boolean są porównywane za pomocą Operatory IS i IS NOT, jednak zgodne z MySQL, INT (1) z = i <> jest nadal możliwe
• nie ma, to wymienić należy użyć DELETE/INSERT kombi
• Pg jest całkiem ścisłe egzekwowanie na klucze integralności obcego, więc nie zapomnij użyć ON DELETE CASCADE na odniesień
• jeśli używasz PHP z PDO, należy pamiętać, aby przekazać parametr do lastInsertId metodę() - powinna być sekwencja nazwa, która tworzona jest zwykle w ten sposób: [tablename] _ [primarykeyname] _seq

mam nadzieję, że pomaga przynajmniej trochę. Baw się dobrze z Postgres!

Answer 2

Dokonałem podobnej konwersji, ale z różnych powodów. Stało się tak, ponieważ potrzebowaliśmy lepszej obsługi ACID i możliwości, aby użytkownicy Internetu widzieli te same dane, które mogli dzięki innym narzędziom DB (jeden identyfikator dla obu).

Oto rzeczy, które nieco nas:

1. MySQL nie narzuca ograniczeń jako ściśle jak PostgreSQL.
2. Istnieją różne procedury obsługi daty. Konieczne będzie ręczne przekonwertowanie.
3. Kod, który nie oczekuje zgodności z ACID , może być problemem.

To powiedziawszy, kiedy już było na miejscu i przetestowane, było o wiele ładniej. Dzięki poprawnemu blokowaniu ze względów bezpieczeństwa i dużemu równoległemu użyciu, PostgreSQL działał lepiej niż MySQL. W przypadku, gdy blokowanie nie było potrzebne (tylko do odczytu), wydajność nie była tak dobra, ale wciąż była szybsza niż karta sieciowa, więc nie było problemu.

Porady:

• Zautomatyzowane skrypty w katalogu contrib są dobrym punktem wyjścia do konwersji, ale będą musieli być dotykane trochę zwykle.
• Gorąco zalecam, aby użytkownik używał domyślnego poziomu serializacji jako izolacji .
• Narzędzie pg_autodoc dobrze jest naprawdę zobaczyć struktury danych i pomóc znaleźć wszelkie relacje, które ty zapomniałeś zdefiniować i wymusić.

Answer 3

Zrobiliśmy przejście z MySQL3 do PostgreSQL 8.2, a następnie 8.3. PostgreSQL ma podstawowe funkcje SQL i wiele więcej, więc jeśli Twój MYSQL nie używa fantazyjnych danych MySQL, wszystko będzie w porządku.

Z mojego doświadczenia wynika, że ​​nasza baza danych MySQL (wersja 3) nie ma klucza obcego ... PostgreSQL pozwala je mieć, więc musieliśmy to zmienić ... i to było dobre i znaleźliśmy jakiś błąd .

Inną rzeczą, którą musieliśmy zmienić, było złącze kodujące (C#), które nie było takie samo w MySQL. Wersja MySQL była bardziej stabilna niż PostgreSQL. Nadal mamy kilka problemów z PostgreSQL-em.