Переход с MySQL на PostgreSQL

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

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

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

Ответов (3)

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

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

Я надеюсь, что это хоть немного поможет. Удачи вам в игре с Postgres!

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

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

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

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

Подсказки:

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

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

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

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