Теория и практика миграции веб-систем на PostgreSQL

[quard]

> Если в какой-то табличке умудрились сохранить “копипасту” из Microsoft Word со спецсимволами,

ась?

В целом, просто ооочень много воды.

[rdruzyagin]

> ась?
Исторически была кривая, плохо фильтруемая форма, в нее менеджеры «копипастили» из Word или еще чего-то подобного, попадали и сохранялись спец-символы. В итоге в базе появлялся «контент», который был проблемным при переносе.

> В целом, просто ооочень много воды.
Я честно выкинул 30% из первого «драфта».

[itcoder]

Не увидел в статье. Как вы решаете задачу с переносом индексов?

[rdruzyagin]

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

[itcoder]

Получается переносили только данные. констрейнты, индексы, уже вручную создавали?
Да и хочется конечно технических подробностей, напрмер: как вы на продакшен все запускали, если сервис достаточно нагруженный, его останавливать не нельзя, данных в секунду много пишется, которые не хочется потерять, соответственно надо их как то синхронизировать с уже существующей базой поднятой из миграции?

[rdruzyagin]

Да, физически «в продакшене» делается только перенос данных. Схема и все остальное заранее подготовлены. Это ведь все надо протестировать заранее, приложение адаптировать под него.

У нас на «продакшене» был предусмотрен частичный downtime. Сервис работал и обслуживал посетителей, но копил задачи на обработку для биллинга, потому что соответствующая база переезжала. После переноса данных выкатили новый код и стали включать и обрабатывать накопившееся.

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

[Envek]

Больше хардкора, больше технических подробностей, меньше воды!

С чего конкретно мигрировали и как? Какие именно трудности и несовместимости были, как решались?

[rdruzyagin]

Я не стал совмещать два-в-одном. Планирую вторую статью, в ней будет сугубо «техничка».

Вкратце отвечая на Ваш вопрос, много разных «мускулей», MongoDB, Redis (люди на нем пред-биллинг делали в проекте), Sphinx и всякий прочий наколенный «опен-сорц». Больше всего радости доставил MySQL, он вот прям все-все делает негуманно. Для затравки, отдельный пламенный привет был передан людям, которые додумались хранить все время «юникстаймом» в bigint, а часовой пояс мигрировать прибавлением 3600 секунд по всей базе.

[Envek]

ОК, с нетерпением жду следующей статьи.

[zk-zeka]

Заменить термин

миграция на постгрес

на

переход с пайтон на пхп

— и вуаля — готовая статья «Как перенести приложение с одного языка программирования на другой»

[rdruzyagin]

Вы безусловно правы! Не поверите, я вот именно так, но применительно к базам данных, рассказывал про проблематику миграции на позапрошлом «хайлоаде». Без привязки к конкретным «стораджам».

Вот только после выступления больше всего вопросов в кулуарах было от людей, которые устали жить с MySQL и хотят на «посгрес».

[Sartor]

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

[rdruzyagin]

Спасибо за поддержку. Действительно, программисты — люди творческие и изобретательные, подходы к решению технических задач они всегда найдут. А вот о других вещах могут и не подумать.

[saggid]

Добрый день) Большое спасибо за статью. Вы сказали, что пользуетесь переносом данных с помощью csv-дампов. А как вам такая программа, как pgloader? Чем она вас не устраивает? Было бы очень интересно узнать ваше мнение о работе с нею.

[hydrobiont]

Насколько я понимаю, на момент начала этой миграции pgloader в работоспособном виде не было.

pgloader программа хорошая, но малость монструозная я бы сказал — скорее не для миграции, а како-нибудь ETL городить. Миграция все-таки тука единичная и обычно требует простоты: пропарсить несколькими перловыми процессами csv и сделать из него COPY проще и надежней.

[rdruzyagin]

Собственно, коллега hydrobiont верно подметил. pgloader был тогда еще сырой, и нам было проще за день набросать свою штуковину. Сейчас pgloader и вовсе на лиспе написан, и коллектив наш такими компетенциями не обладает.

На практике, нашего инструмента хватает. Он крайне банален, примерно 150 строк кода. Вся основная работа — это схему перегнать.