Миграция с MySQL на PostgreSQL

Question

В настоящее время мы используем MySQL для продукта, который мы строим, и стремимся как можно скорее перейти в PostgreSQL, в первую очередь, по причинам лицензирования.

Кто-нибудь еще сделал такой шаг? Наша база данных является жизненной основой приложения и в конечном итоге будет хранить ТБ данных, поэтому я хочу услышать об опыте улучшения/потери производительности, основных препятствий при преобразовании SQL и хранимых процедур и т. Д.

Редактировать: Just чтобы разъяснить тем, кто спросил, почему нам не нравится лицензирование MySQL. Мы разрабатываем коммерческий продукт, который (в настоящее время) зависит от MySQL как базы данных. В их лицензии говорится, что мы должны заплатить им процент от нашей цены за каждую установку, а не фиксированную плату. В качестве стартапа это менее привлекательно.

Answer 1

Стив, мне пришлось перенести свое старое приложение так, как будто это PgSQL-> MySQL. Я должен сказать, что вы должны считать себя счастливым ;-) распространённые ошибки:

• SQL на самом деле очень близко к стандарту языка, так что вы можете пострадать от диалекта в MySQL вы уже знаете
• MySQL тихо усекает VARCHARS что превышает максимальную длину, в то время как Pg жалуется - быстро устранить проблему, чтобы эти столбцы как «текст» вместо «VARCHAR» и использование триггеров укоротить длинные строки
• двойных кавычек используются вместо обратного апострофа
• булевых полей по сравнению с использованием IS и IS NOT, однако MySQL-совместимый INT (1) с = и> до сих пор можно
• там нет REPLACE, используйте DELETE/INSERT комбо
• Pg довольно строг обеспечения целостности внешних ключей, поэтому не забывайте использовать ON DELETE CASCADE на ссылках
• , если вы используете PHP с PDO, не забудьте передать параметр в lastInsertId() метод - это должно быть имя последовательности, которая создается обычно так: [имя_таблицы] _ [primarykeyname] _seq

Я надеюсь, что помогает, по крайней мере немного. Очень весело играть с Postgres!

Answer 2

Я сделал аналогичное преобразование, но по разным причинам. Это было связано с тем, что нам нужна была лучшая поддержка ACID, и способность веб-пользователей видеть те же данные, которые они могли бы использовать с помощью других инструментов БД (один идентификатор для обоих).

Вот то, что немного нас:

1. MySQL не накладывает ограничений так строго, как PostgreSQL.
2. Существуют различные процедуры обработки дат. Они должны быть преобразованы вручную.
3. Любой код, который не ожидает соответствия требованиям ACID , может быть проблемой.

Это, как только оно было на месте и проверено, было намного приятнее. Благодаря правильной блокировке по соображениям безопасности и сильному параллельному использованию PostgreSQL работает лучше, чем MySQL. О том, где блокировка не нужна (только для чтения), производительность была не совсем такой же хорошей, но она все же была быстрее, чем сетевая карта, поэтому это не проблема.

Советы:

• Автоматизированные скрипты в каталоге вно являются хорошей отправной точкой для преобразования, но нужно будет трогать немного обычно.
• Я бы очень рекомендовал, чтобы вы использовали сериализуемую изоляцию по умолчанию.
• Инструмент pg_autodoc хорош для действительно видеть ваши структуры данных и помогите найти любые отношения, которые вы забыли определить и обеспечить соблюдение.

Answer 3

Мы сделали переход от MySQL3 к PostgreSQL 8.2, затем 8.3. PostgreSQL имеет базовый язык SQL и намного больше, поэтому, если ваш MYSQL не использует причудливые вещи MySQL, все будет в порядке.

Из моего опыта наша база данных MySQL (версия 3) не имеет внешнего ключа ... PostgreSQL позволяет вам иметь их, поэтому нам пришлось изменить это ... и это было хорошо, и мы обнаружили ошибку ,

Другое, что нам пришлось изменить, это коннектор кодирования (C#), который не был таким же в MySQL. MySQL был более стабильным, чем PostgreSQL. У нас по-прежнему мало проблем с PostgreSQL.