Миграция с MySQL на PostgreSQL [закрыто]

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

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

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

20.08.2008 10:40:38
Есть некоторые хорошие технические статьи на эту тему здесь: wiki.postgresql.org/wiki/...
user13550 16.09.2008 20:39:06
Тиражирование может быть проблемой для вас. MySQL поддерживает это из коробки.
l_39217_l 17.09.2008 17:45:06
3 ОТВЕТА

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

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

Надеюсь, это поможет хоть немного. Приятно играть с Postgres!

27
21.08.2008 15:14:27

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

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

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

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

Подсказки:

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

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

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

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

3
6.05.2012 22:46:40
"Postgresql", "PostGreSql", "PostGresql" => "PostgreSQL" ;-)
Patryk Kordylewski 27.11.2008 17:26:39
Вздох. Девять голосов за комментарий, но никто не пошел и не внес изменения. Будьте уполномочены честные пользователи StackOverflow!
mlissner 6.05.2012 22:15:16