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

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

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

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

Ответы

Ответ 1

Стив, мне пришлось перенести свое старое приложение так, как будто это PgSQL- > MySQL. Должен сказать, вы должны считать себя счастливым;-) Обычными ошибками являются:
  • SQL на самом деле довольно близок к языковому стандарту, поэтому вы можете столкнуться с диалогими MySQL, которые вы уже знаете.
  • MySQL спокойно усекает varchars, которые превышают максимальную длину, тогда как Pg жалуется - быстрое обходное решение состоит в том, чтобы эти столбцы были "text" вместо "varchar" и использовать триггеры для усечения длинных строк.
  • вместо обратных апострофов используются двойные кавычки
  • boolean fields сравниваются с использованием операторов IS и IS NOT, однако MySQL-совместимый INT (1) с = и < > по-прежнему возможен
  • нет REPLACE, используйте комбинацию DELETE/INSERT
  • Pg довольно строго соблюдает целостность внешних ключей, поэтому не забудьте использовать ON DELETE CASCADE для ссылок
  • Если вы используете PHP с PDO, не забудьте передать параметр lastInsertId() - это должно быть имя последовательности, которое создается таким образом: [tablename] _ [primarykeyname] _seq

Я надеюсь, что это поможет хотя бы немного. Поиграйте с Postgres!

Ответ 2

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

Вот что нас укусило:

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

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

Советов:

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

Ответ 3

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

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

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