Да бросьте Вы, какая желчь, так, рабочие моменты. Перегиб конечно есть, я PostgreSQL очень люблю. Преимущественно за то, что его внедрение в крупные проекты позволило мне больше спать по ночам и не получать смсок о том, что ваша реплика «отстает» на 52 тысячи секунд.
А вот пользоваться чем-то другим вряд ли пока что буду, я уже старею для всех этих экспериментов, приоритеты меняются в жизни. Хотя, с коммерческими СУБД с удовольствием бы поработал, не доводилось наблюдать в крупном «продакшене», но увы — специфика бизнеса не позволяет. Open source — наше все.
Вы абсолютно правы, извиняюсь за бессмысленный комментарий. Признаться, я крайне опечален. Давно приученная практика использовать транзакции привела к тому, что я это пропустил мимо. Тем не менее, это упрощает процесс миграции, так что хоть какая-то польза в этом все-таки есть. Спасибо за подсказку.
Вот с «групбаем» я как-то не припомню проблем в 9.0, но давно это было. Upsert — штука полезная, действительно. И приведенный в «посте» пример работает очень шустро. А вот STRICT MODE я таки сомневаюсь, что выключат, хотя чем черт не шутит. Все хорошее когда-то заканчивается)
Спасибо большое за конструктивный комментарий. Я вам даже «стрелочку вверх» нажал рядом с вашим именем.
MySQL ни в коем случае не является плохой СУБД. Мы ее применяли и даже применяем сейчас местами для наших проектов (см. мой комментарий выше). Просто, к сожалению, в ней много всяких непонятных нюансов, исторически возникших и усложняющих ее нормальную эксплуатацию. Типовые такие нюансы я и постарался представить.
> Не сказал бы, что это минус, но и не плюс. В каких-то ситуациях это является плюсом, в каких-то минусом. В любом случае, ответственность ложится на разработчика, которому не нужно терять данные. Чуть ниже вы предлагаете выбрасывать исключение, чтобы опять-же разработчик сел, нашел ошибку и разобрал её. В любом случае вы предлагаете привлекать разработчика, от БД ничего не зависит — всё зависит от прямоты рук.
В том-то и дело, что разработчики часто об этих вещах не подозревают. Начинают делать проект, думают — что все здорово, а потом выясняется через полгода «продакшена». За что я люблю PG — он сразу показывает программисту, где тот накосячил. Это приучает людей к порядку.
> Не соглашусь. Как-раз таки размерность поля расчитывается исходя из всех возможных принимаемых значений. Зато экономия «на спичках» оправдывает себя. Опять-же нужны прямые руки, кривые и так всё сломают.
Мой опыт мне подсказывает, что всегда что-то бывает неучтенным и рано или поздно «приедет» кривое значение. Касательно экономии, опять же, это лишь мой опыт, но я видел нагруженные базы на MySQL и проблемы там были далеко не из-за разрядности и кол-ва знаков. Чаще это были ручные блокировки, много DDL и подобные «тяжелые» вещи.
> Тоже не соглашусь. Что значит «постоянное использование»? Конечно эти команды используются не в каждом запросе на INSERT, но «иногда». Где грань между «иногда» = проблемы дизайна БД? Бывают ситуации, когда тебе нужно вставить много-много данных из другого источника, которые могут уже повторяться, а могут не повторяться, и в них могут быть важные новые данные. Забивать базу хламом ненужно, а удалять старые, чтобы потом сделать один большой INSERT накладно для БД. Так чем же эта команда плоха? Потому-что её нет в PostgreSQL?
В моем понимании, «долбежка» в таблицу повторяющихся значений с целью «напороться» на констрейнт — это признак непродуманного бизнес-процесса или его реализации. Как правило, сначала проектируют так, чтобы не было дубликатов и констрейнты расставляют более-менее по уму. Потом что-то меняется в условиях бизнеса, и начинают валиться дубли. Ленивые программисты моментально «нагугливают» INSERT IGNORE и радуются, вот же она — серебряная пуля! Вставляют IGNORE и отправляют код в «продакшен», не задумываясь, а что это за дубликаты, зачем они? Не надо ли переосмыслить дизайн схемы? Для меня, IGNORE сродни «собаки» в PHP, которая «подавляет» ошибки, вместо того, чтобы корректно их обрабатывать.
Ни в коем случае не старался вас обидеть. Это не презрение, а здоровый сарказм, призванный обратить внимание на типичные проблемы MySQL в «продакшене». Я их наблюдаю уже 9 год своей профессиональной деятельности. И про PostgreSQL такую же статью могу написать, в ней тоже полно нюансов и странных вещей, возникших по историческим причинам.
Коллега defuz абсолютно прав, накипело. К самому MySQL у меня нет претензий, я умею поддерживать и поддерживаю рабочие проекты на MySQL, если текущие условия бизнеса или самой «технички» не позволяют использовать привычный для нас PostgreSQL.
MySQL — замечательный продукт, на котором мы стартовали огромное количество успешных и прибыльных проектов. Просто, к сожалению, в нем слишком много нюансов даже в достаточно тривиальных вещах, которые на практике выливаются в беды и печали.
Собственно, коллега hydrobiont верно подметил. pgloader был тогда еще сырой, и нам было проще за день набросать свою штуковину. Сейчас pgloader и вовсе на лиспе написан, и коллектив наш такими компетенциями не обладает.
На практике, нашего инструмента хватает. Он крайне банален, примерно 150 строк кода. Вся основная работа — это схему перегнать.
Да, физически «в продакшене» делается только перенос данных. Схема и все остальное заранее подготовлены. Это ведь все надо протестировать заранее, приложение адаптировать под него.
У нас на «продакшене» был предусмотрен частичный downtime. Сервис работал и обслуживал посетителей, но копил задачи на обработку для биллинга, потому что соответствующая база переезжала. После переноса данных выкатили новый код и стали включать и обрабатывать накопившееся.
Ваш конкретный случай надо рассматривать предметно и придумывать, как после переключения накопившиеся данные потом докинуть в новое хранилище. Если Вы опишете более подробно ситуацию, можем подумать. Однозначного ответа нет, все слишком зависит от устройства Вашего хранилища и специфики нагрузки.
Спасибо за поддержку. Действительно, программисты — люди творческие и изобретательные, подходы к решению технических задач они всегда найдут. А вот о других вещах могут и не подумать.
Вы безусловно правы! Не поверите, я вот именно так, но применительно к базам данных, рассказывал про проблематику миграции на позапрошлом «хайлоаде». Без привязки к конкретным «стораджам».
Вот только после выступления больше всего вопросов в кулуарах было от людей, которые устали жить с MySQL и хотят на «посгрес».
Я не стал совмещать два-в-одном. Планирую вторую статью, в ней будет сугубо «техничка».
Вкратце отвечая на Ваш вопрос, много разных «мускулей», MongoDB, Redis (люди на нем пред-биллинг делали в проекте), Sphinx и всякий прочий наколенный «опен-сорц». Больше всего радости доставил MySQL, он вот прям все-все делает негуманно. Для затравки, отдельный пламенный привет был передан людям, которые додумались хранить все время «юникстаймом» в bigint, а часовой пояс мигрировать прибавлением 3600 секунд по всей базе.
> Не увидел в статье. Как вы решаете задачу с переносом индексов?
Имеется ввиду адаптация схемы? Да так же, руками, при переписывании схемы под новое хранилище. Или Вы что-то другое подразумевали? Тогда поясните, пожалуйста.
> ась?
Исторически была кривая, плохо фильтруемая форма, в нее менеджеры «копипастили» из Word или еще чего-то подобного, попадали и сохранялись спец-символы. В итоге в базе появлялся «контент», который был проблемным при переносе.
> В целом, просто ооочень много воды.
Я честно выкинул 30% из первого «драфта».
Да бросьте Вы, какая желчь, так, рабочие моменты. Перегиб конечно есть, я PostgreSQL очень люблю. Преимущественно за то, что его внедрение в крупные проекты позволило мне больше спать по ночам и не получать смсок о том, что ваша реплика «отстает» на 52 тысячи секунд.
А вот пользоваться чем-то другим вряд ли пока что буду, я уже старею для всех этих экспериментов, приоритеты меняются в жизни. Хотя, с коммерческими СУБД с удовольствием бы поработал, не доводилось наблюдать в крупном «продакшене», но увы — специфика бизнеса не позволяет. Open source — наше все.
Гори оно все синим пламенем!
Спасибо большое за конструктивный комментарий. Я вам даже «стрелочку вверх» нажал рядом с вашим именем.
MySQL ни в коем случае не является плохой СУБД. Мы ее применяли и даже применяем сейчас местами для наших проектов (см. мой комментарий выше). Просто, к сожалению, в ней много всяких непонятных нюансов, исторически возникших и усложняющих ее нормальную эксплуатацию. Типовые такие нюансы я и постарался представить.
> Не сказал бы, что это минус, но и не плюс. В каких-то ситуациях это является плюсом, в каких-то минусом. В любом случае, ответственность ложится на разработчика, которому не нужно терять данные. Чуть ниже вы предлагаете выбрасывать исключение, чтобы опять-же разработчик сел, нашел ошибку и разобрал её. В любом случае вы предлагаете привлекать разработчика, от БД ничего не зависит — всё зависит от прямоты рук.
В том-то и дело, что разработчики часто об этих вещах не подозревают. Начинают делать проект, думают — что все здорово, а потом выясняется через полгода «продакшена». За что я люблю PG — он сразу показывает программисту, где тот накосячил. Это приучает людей к порядку.
> Не соглашусь. Как-раз таки размерность поля расчитывается исходя из всех возможных принимаемых значений. Зато экономия «на спичках» оправдывает себя. Опять-же нужны прямые руки, кривые и так всё сломают.
Мой опыт мне подсказывает, что всегда что-то бывает неучтенным и рано или поздно «приедет» кривое значение. Касательно экономии, опять же, это лишь мой опыт, но я видел нагруженные базы на MySQL и проблемы там были далеко не из-за разрядности и кол-ва знаков. Чаще это были ручные блокировки, много DDL и подобные «тяжелые» вещи.
> Тоже не соглашусь. Что значит «постоянное использование»? Конечно эти команды используются не в каждом запросе на INSERT, но «иногда». Где грань между «иногда» = проблемы дизайна БД? Бывают ситуации, когда тебе нужно вставить много-много данных из другого источника, которые могут уже повторяться, а могут не повторяться, и в них могут быть важные новые данные. Забивать базу хламом ненужно, а удалять старые, чтобы потом сделать один большой INSERT накладно для БД. Так чем же эта команда плоха? Потому-что её нет в PostgreSQL?
В моем понимании, «долбежка» в таблицу повторяющихся значений с целью «напороться» на констрейнт — это признак непродуманного бизнес-процесса или его реализации. Как правило, сначала проектируют так, чтобы не было дубликатов и констрейнты расставляют более-менее по уму. Потом что-то меняется в условиях бизнеса, и начинают валиться дубли. Ленивые программисты моментально «нагугливают» INSERT IGNORE и радуются, вот же она — серебряная пуля! Вставляют IGNORE и отправляют код в «продакшен», не задумываясь, а что это за дубликаты, зачем они? Не надо ли переосмыслить дизайн схемы? Для меня, IGNORE сродни «собаки» в PHP, которая «подавляет» ошибки, вместо того, чтобы корректно их обрабатывать.
Коллега defuz абсолютно прав, накипело. К самому MySQL у меня нет претензий, я умею поддерживать и поддерживаю рабочие проекты на MySQL, если текущие условия бизнеса или самой «технички» не позволяют использовать привычный для нас PostgreSQL.
MySQL — замечательный продукт, на котором мы стартовали огромное количество успешных и прибыльных проектов. Просто, к сожалению, в нем слишком много нюансов даже в достаточно тривиальных вещах, которые на практике выливаются в беды и печали.
На практике, нашего инструмента хватает. Он крайне банален, примерно 150 строк кода. Вся основная работа — это схему перегнать.
У нас на «продакшене» был предусмотрен частичный downtime. Сервис работал и обслуживал посетителей, но копил задачи на обработку для биллинга, потому что соответствующая база переезжала. После переноса данных выкатили новый код и стали включать и обрабатывать накопившееся.
Ваш конкретный случай надо рассматривать предметно и придумывать, как после переключения накопившиеся данные потом докинуть в новое хранилище. Если Вы опишете более подробно ситуацию, можем подумать. Однозначного ответа нет, все слишком зависит от устройства Вашего хранилища и специфики нагрузки.
Вот только после выступления больше всего вопросов в кулуарах было от людей, которые устали жить с MySQL и хотят на «посгрес».
Вкратце отвечая на Ваш вопрос, много разных «мускулей», MongoDB, Redis (люди на нем пред-биллинг делали в проекте), Sphinx и всякий прочий наколенный «опен-сорц». Больше всего радости доставил MySQL, он вот прям все-все делает негуманно. Для затравки, отдельный пламенный привет был передан людям, которые додумались хранить все время «юникстаймом» в bigint, а часовой пояс мигрировать прибавлением 3600 секунд по всей базе.
Имеется ввиду адаптация схемы? Да так же, руками, при переписывании схемы под новое хранилище. Или Вы что-то другое подразумевали? Тогда поясните, пожалуйста.
Исторически была кривая, плохо фильтруемая форма, в нее менеджеры «копипастили» из Word или еще чего-то подобного, попадали и сохранялись спец-символы. В итоге в базе появлялся «контент», который был проблемным при переносе.
> В целом, просто ооочень много воды.
Я честно выкинул 30% из первого «драфта».