Комментарии 16
> Если в какой-то табличке умудрились сохранить “копипасту” из Microsoft Word со спецсимволами,
ась?
В целом, просто ооочень много воды.
ась?
В целом, просто ооочень много воды.
> ась?
Исторически была кривая, плохо фильтруемая форма, в нее менеджеры «копипастили» из Word или еще чего-то подобного, попадали и сохранялись спец-символы. В итоге в базе появлялся «контент», который был проблемным при переносе.
> В целом, просто ооочень много воды.
Я честно выкинул 30% из первого «драфта».
Исторически была кривая, плохо фильтруемая форма, в нее менеджеры «копипастили» из Word или еще чего-то подобного, попадали и сохранялись спец-символы. В итоге в базе появлялся «контент», который был проблемным при переносе.
> В целом, просто ооочень много воды.
Я честно выкинул 30% из первого «драфта».
Не увидел в статье. Как вы решаете задачу с переносом индексов?
> Не увидел в статье. Как вы решаете задачу с переносом индексов?
Имеется ввиду адаптация схемы? Да так же, руками, при переписывании схемы под новое хранилище. Или Вы что-то другое подразумевали? Тогда поясните, пожалуйста.
Имеется ввиду адаптация схемы? Да так же, руками, при переписывании схемы под новое хранилище. Или Вы что-то другое подразумевали? Тогда поясните, пожалуйста.
Получается переносили только данные. констрейнты, индексы, уже вручную создавали?
Да и хочется конечно технических подробностей, напрмер: как вы на продакшен все запускали, если сервис достаточно нагруженный, его останавливать не нельзя, данных в секунду много пишется, которые не хочется потерять, соответственно надо их как то синхронизировать с уже существующей базой поднятой из миграции?
Да и хочется конечно технических подробностей, напрмер: как вы на продакшен все запускали, если сервис достаточно нагруженный, его останавливать не нельзя, данных в секунду много пишется, которые не хочется потерять, соответственно надо их как то синхронизировать с уже существующей базой поднятой из миграции?
Да, физически «в продакшене» делается только перенос данных. Схема и все остальное заранее подготовлены. Это ведь все надо протестировать заранее, приложение адаптировать под него.
У нас на «продакшене» был предусмотрен частичный downtime. Сервис работал и обслуживал посетителей, но копил задачи на обработку для биллинга, потому что соответствующая база переезжала. После переноса данных выкатили новый код и стали включать и обрабатывать накопившееся.
Ваш конкретный случай надо рассматривать предметно и придумывать, как после переключения накопившиеся данные потом докинуть в новое хранилище. Если Вы опишете более подробно ситуацию, можем подумать. Однозначного ответа нет, все слишком зависит от устройства Вашего хранилища и специфики нагрузки.
У нас на «продакшене» был предусмотрен частичный downtime. Сервис работал и обслуживал посетителей, но копил задачи на обработку для биллинга, потому что соответствующая база переезжала. После переноса данных выкатили новый код и стали включать и обрабатывать накопившееся.
Ваш конкретный случай надо рассматривать предметно и придумывать, как после переключения накопившиеся данные потом докинуть в новое хранилище. Если Вы опишете более подробно ситуацию, можем подумать. Однозначного ответа нет, все слишком зависит от устройства Вашего хранилища и специфики нагрузки.
Больше хардкора, больше технических подробностей, меньше воды!
С чего конкретно мигрировали и как? Какие именно трудности и несовместимости были, как решались?
С чего конкретно мигрировали и как? Какие именно трудности и несовместимости были, как решались?
Я не стал совмещать два-в-одном. Планирую вторую статью, в ней будет сугубо «техничка».
Вкратце отвечая на Ваш вопрос, много разных «мускулей», MongoDB, Redis (люди на нем пред-биллинг делали в проекте), Sphinx и всякий прочий наколенный «опен-сорц». Больше всего радости доставил MySQL, он вот прям все-все делает негуманно. Для затравки, отдельный пламенный привет был передан людям, которые додумались хранить все время «юникстаймом» в bigint, а часовой пояс мигрировать прибавлением 3600 секунд по всей базе.
Вкратце отвечая на Ваш вопрос, много разных «мускулей», MongoDB, Redis (люди на нем пред-биллинг делали в проекте), Sphinx и всякий прочий наколенный «опен-сорц». Больше всего радости доставил MySQL, он вот прям все-все делает негуманно. Для затравки, отдельный пламенный привет был передан людям, которые додумались хранить все время «юникстаймом» в bigint, а часовой пояс мигрировать прибавлением 3600 секунд по всей базе.
Заменить термин
миграция на постгресна
переход с пайтон на пхп— и вуаля — готовая статья «Как перенести приложение с одного языка программирования на другой»
Вы безусловно правы! Не поверите, я вот именно так, но применительно к базам данных, рассказывал про проблематику миграции на позапрошлом «хайлоаде». Без привязки к конкретным «стораджам».
Вот только после выступления больше всего вопросов в кулуарах было от людей, которые устали жить с MySQL и хотят на «посгрес».
Вот только после выступления больше всего вопросов в кулуарах было от людей, которые устали жить с MySQL и хотят на «посгрес».
Видно по статье, что автор — именно компетентный техлид. Именно в продумывании всех нюансов, постоянном тестировании на всех этапах и работа с подготовкой коллектива — самое важное. Технические детали, как раз, обычно простые (для тех, кто в этом варится) и не очень интересные, а вот как этот процесс организовать и возможные проблемы — это как раз сложно. Спасибо.
Добрый день) Большое спасибо за статью. Вы сказали, что пользуетесь переносом данных с помощью csv-дампов. А как вам такая программа, как pgloader? Чем она вас не устраивает? Было бы очень интересно узнать ваше мнение о работе с нею.
Насколько я понимаю, на момент начала этой миграции pgloader в работоспособном виде не было.
pgloader программа хорошая, но малость монструозная я бы сказал — скорее не для миграции, а како-нибудь ETL городить. Миграция все-таки тука единичная и обычно требует простоты: пропарсить несколькими перловыми процессами csv и сделать из него COPY проще и надежней.
pgloader программа хорошая, но малость монструозная я бы сказал — скорее не для миграции, а како-нибудь ETL городить. Миграция все-таки тука единичная и обычно требует простоты: пропарсить несколькими перловыми процессами csv и сделать из него COPY проще и надежней.
Собственно, коллега hydrobiont верно подметил. pgloader был тогда еще сырой, и нам было проще за день набросать свою штуковину. Сейчас pgloader и вовсе на лиспе написан, и коллектив наш такими компетенциями не обладает.
На практике, нашего инструмента хватает. Он крайне банален, примерно 150 строк кода. Вся основная работа — это схему перегнать.
На практике, нашего инструмента хватает. Он крайне банален, примерно 150 строк кода. Вся основная работа — это схему перегнать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Теория и практика миграции веб-систем на PostgreSQL