На что мигрировать с MS SQL? MySQL или PostgreSql?

Question

[Павел]

В базе около 30 таблиц. В самой большой около 20 000 000 записей.

Сейчас используем ХП, но хотим от них отказаться и хранить в базе только таблицы с данными.


Отказываемся в связи с переходом с Windows-платформы на Linux (Ubuntu).


Что предпочесть для миграции, MySQL или PostgreSql? Какой тулзой мигрировать?

Answer 1

[Алексей Ашурок]

Предпочесть PostgreSql, плюшек и возможностей больше -> меньше геморроя с перепиливанием СУБД-зависимого кода.

Answer 2

[Ivan Komarov]

PostgreSQL. В MySQL постоянно будеде сталкиваться, что нет фишек, к которым вы привыкли.

Answer 3

[maratfmu]

Почему бы не попробовать MongoDB?

Comments

[Павел]

в монго нет join'ов… а у меня много many-to-many

[Павел]

и если я правильно помню — он все таблицы в памяти хранит… а память не бесконечна :(

[Борис Сёмов]

А зачем тут пробовать MongoDB? Чтобы напрочь переписать все приложения, которые используют БД, вместо небольших правок, если вообще использовалось что-то MSSQL специфичное?

MongoDB как и все остальные NoSQL это модно конечно, но это не некая «серебряная пуля», а лишь инструмент, который имеет смысл применять в определённых ситуациях, когда это имеет смысл.

> и если я правильно помню — он все таблицы в памяти хранит
Неправильно помните.

[meta4]

MongoDB использует mmap, так что хранит в памяти только то, что решила держать в памяьи ОС. Но вот миграция на нее с MSSQL врядли оправдана — монго слишком «бедна» в смысле возможностей.

[rushter]

Ну и вброс :)

[Павел]

rushter +1 )))

[Malenkov]

Mongo DB Is Web Scale

Answer 4

[gmlexx]

Сначала нужно для себя решить — как вы видите свое приложение в будущем. Если там будет 20 млрд. записей через пару месяцев, и более тесная работа с базой, то PostgreSQL.
Если база нужна как редко обновляемый склад, то и MySQL сойдет. Зачем палить из пушки по воробьям?

Comments

[iav]

Если пушка и ружьё стоят одинаково, весят одинаково, места занимают одинаково, а воробьёв требуется не добывать, а уничтожать — то почему бы и не пострелять из пушки?

Если у вас есть возмодность ездить на «жигулях» и на «фольксвагене», при этом вопросы стоимости эксплуатации вас не касаются, то есть ли смысл ездить на «жигулях»? Ведь в «фольксвагене» приятнее.

Answer 5

[Malenkov]

Недавно перенёс один проект (500 млн записей) с mssql на postgresql. Пришлось конечно немного допилить, но в целом очень безпроблемно.

Мигрировал с помощью www.easyfrom.net/ Мне хватило триальной версии (строковых полей не было)
Тулза работала достаточно медленно (часов 6), но для меня это был самый простой способ.

Comments

[Павел]

Что значит строковых, Blob?
Не нашел на сайте ограничения у trial-версии

[Malenkov]

text, nvarchar и пр.
Ограничение триала — он при переносе заменяет первый символ строк на 'T'

[bulletproofcupid]

Придумал! Ограничение можно обойти. Перед миграцией добавить по лишнему символу в начало каждой строки. После миграции — удалить.

[Павел]

bulletproofcupid, тогда уж проще руками написать методы (на том языке на котором программируете) перегоняющие данные из одной базы в другую

Answer 6

[codecity]

Сравнивал MySQL и Postgree на скорость работы. Огномнейшая разница между использованием в одно-поточном и много-поточном режиме (много соединений из примерно 100 потоков).

Пишу по памяти результаты тестов (запускал на ноутбуке). Время — 1 секунда. Величина — количество записей менее1 Кб (одно поле и ключ).

MS SQL: ~700 записей в сек. в обеих режимах.
My SQL: 20 в одно, 120 в много.
Postgree: 100 в одно, 100 в много. Но в много-поточном вылетали ошибки одна за другой, из чего я сделал вывод о том, что она не работает корректно в много-поточном режиме.

Вообще рекомендую сравнить скорость работы, она не такая уж большая, как кажется на первый взгляд… Имхо, это один из важнейших параметров.

Я в итоге выбрал MySQL.

Comments

[Семен Дубина]

Очень большой разброс между mssql и postgresql. Что-то даже не верится… Какие версии сравнивали?

[codecity]

Разброс между MySQL и Postgree в многопоточном режиме не большой — примерно 100 и 120 (а вот MS SQL — да, там больше).

Сравнивал в сентябре 2011 г., использовал самые последние версии. Никаких настроек не производилось. Таблицы хранились на диске.

Если кто-то еще производил измерения — предлагаю поделиться результатами. А то почему то люди основывают свой выбор на советах типа «это лучше» без цифр, вместо того, чтобы самостоятельно провести измерения.

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

[Александр Коротков]

У вас каждое обновление записи — отдельная транзакция?
Какие ошибки возникали в PostgreSQL?
Никаких настроек не производить — это сильно. Если уж проводить тестирование, то нужно позаботится о том, чтобы базы потребляли примерно одинаковое количество ресурсов и обеспечивали аналогичные уровни надежности. Иначе не понятно вообще, что сравниваем.

Answer 7

[ztxn]

Пг — версионник, у него запись не блокирует чтение, MS — блокировочник. Изоляция транзакций реализована совершенно по разному.

Простой пример:
ms, выполняя запрос insert into table (value) select max(value) +1 from table, в read commited не допустит дублирования значений при вставке несколькими сессиями, а в PG — запросто.

В этом контексте на MySQL может оказаться переехать куда проще. Он тоже блокировочник.

Comments

[shagguboy]

>MS — блокировочник
с 2005 года уже таки и версионник.