Комментарии 19
Отсутствие достойного аналога ... Схожие типы данных в разных СУБД
В показанном виде скриншоты сбивают с толку. В нынешнем виде они как бы проводят аналогию между тем, что есть в разных СУБД - а это не так, вам нужно перейти от конструкции, используемой в СУБД из левой колонки, к её аналогу в СУБД из правой колонки.
Я уж не говорю о том, что CURRENT_DATE в PostgreSQL вовсе даже не является аналогом NOW() из MariaDB, потому как не возвращает компоненту времени. Тут скорее нужен CURRENT_TIMESTAMP(), да ещё с удалением зоны времени.
А ещё - надо бы проверить, везде ли TINYINT в MariaDB использовался как однобайтовое целое, а не как булево...
Пример конфигурационного файла pgloader`а
И тут есть вопросы. Почему тип TIME из MariaDB приводится к TIMESTAMP? ведь TIME не имеет компонента даты...
Вы правы, действительно NOW() не является полным аналогом CURRENT_DATE, возможно, к таблице, имело бы смысл дополнительно указать что в старом драйвере для столбца даты и даты-времени использовался NOW() в обоих случаях, впоследствии при написании нового драйвера решили разделить функции отдельно для даты-времени и отдельно для даты.
По поводу tinyint, без указания конфигурации pgloader всегда конвертировал его в булево значение, не смотря на то, что в некоторых местах это было целочисленное значение > 1.
А конвертация time в timestamp была указано намеренно, так как было принято принципиальное решение для решения дальнейших задач
Ну просто изумлён вашими ответами на этот и другие комментарии. По ним получается, что вы значительную часть информации об исходной системе и поставленной задаче, причём порой если и не критичной, то достаточно важной, просто взяли и пропустили.
Может, имеет смысл взять статью на доработку и довести её до нормального состояния?
Сервис базы стал потреблять почти на 30% меньше процессорного времени и на 20% меньше оперативной памяти...
Дешевле было чуток оперативки добавить. А ещё дешевле - нанять грамотного мускульщика, который бы вымел из базы "терабайты данных" (что вы там храните, файлы в блобах?), настроил индексы для отчётов (которых у кадровиков не много, штук 20-30 максимум) и перевёл тяжелые нестандартные отчёты (если они уж так нужны) на отдельную "аналитическую" реплику.
Зачем кадровой софтинке PostgreSQL, - загадка.
А может стало лучше, не потому что СУБД сменили, а потому что провели работу по рефакторингу, оптимизации, и т.д.
Некоторые целевые заказчики принципиально требовали PostgreSQL и это являлось стоп фактором. По поводу объемов хранения данных, исторически так сложилось что основной сервис хранил в себе много данных, фактически - все необходимые для работы. Добавлю, что мы не надеялись что переход на другую СУБД магически решит все наши проблемы, продолжается распил на отдельные сервисы для уменьшения объемов данных.
Вы написали про масштабирование. Вы его же реализовали? И насколько в Postgresql масштабирование у вас работало легче и проще чем в MariaDB Cluster? И сколько у вас всего серверов под базу данных сейчас задействовано? Вы говорили про отказоустойчивость, она достигается сейчас каким образом и каким количеством резервных серверов? Бэкапы для терабайтов данных тоже хорошо работают? Вы как их делаете? Через репликацию master slave?
Ничего они из этого не сделали: ни кластеризации ни резервных серверов. Иначе бы написали. Про снижение времени отклика вскользь, видимо похвастаться нечем. А это основное что нужно пользователям.
Просто замена СУБД ради замены. Может, у руководства мысль была заменить СУБД из своих соображений, а разработчики неправильно их поняли.
Холиварная статья: как не разобрались с целями проекта и не смогли рефакторить старую систему, поэтому перешли на новую. Неверный вывод что постгрес круче и статья для холивара.
30 процентов снижения процессорного времени. Это не то чтобы много. Про время отклика без цифр...
Можно уточнить, как одно с другим сочетается?
MariaDB перестала справляться даже с формированием индексов, часто падала при операциях вставки (INSERT, UPDATE) и банальном поиске по первичным ключам.
и
У нас не высоконагруженная система
Не пробовали для начала пригласить толкового специалиста по оптимизации?
Обычные SQL‑запросы также изобиловали различными встроенными функциями, тут тоже ничего сложного: ищи аналог, заменяй, проверяй. Если не получалось найти достойный аналог, то приходилось дописывать бизнес‑логику под новые условия.
А почему просто не написать аналог функции? Мы именно так и поступили при переходе с MS SQL.
В некоторых наших хранимках использовались функции которых не было в PostgreSQL, поэтому для некоторых написали аналоги и миграцией затащили в БД.
Плюсом был некоторый легаси код от фреймворка, который с помощью функций MySQL выполнял вычисления с датами (высчитывал интервалы дат). Такую логику решили не сохранять и поменять логику в самом коде без обращения к БД
Таблицы были myisam ? Или innotdb?
"
Один убежденно говорил: "Конструкторская мысль не может стоять на месте. Это закон развития общества. Мы изобретем его. Обязательно изобретем. Вопреки бюрократам вроде Чинушина и консерваторам вроде Твердолобова". Другой юноша нес свое: "Я нашел, как применить здесь нестирающиеся шины из полиструктурного волокна с вырожденными аминными связями и неполными кислородными группами. Но я не знаю пока, как использовать регенерирующий реактор на субтепловых нейтронах. Миша, Мишок! Как быть с реактором?" Присмотревшись к устройству, я без труда узнал велосипед.
"
Насчёт миграции
У вас он автомастерски проверяет то что в коде и то что в бд и генерирует "исправляющий" скрипт
А теперь вопрос: как переименовать столбец? Ведь для вашей системы надо один столбец удалить и один создать. А если сразу два столбца надо?
В экосистеме nodejs есть orm sequelize, где разрабы как раз этим и грешат. у них есть метод .sync(), который магически все приводит в порядок. Но, прямо в документации написано: строго для development, ни в коем случае не тащите это в production
Прощай, Маша, не поминай лихом! Как мы переходили с MariaDB на PostgreSQL