Міграція між СУБД: PostgreSQL, MySQL, MongoDB

Коли потрібна зміна СУБД: реальні сценарії

Ми не раз зустрічали проєкти, де компанія вирішує перейти з MySQL на PostgreSQL через нестачу віконних функцій, або з MongoDB на реляційну СУБД для ACID-транзакцій. Інший частий кейс — міграція з MySQL на PostgreSQL для роботи з геоданими через PostGIS. Зміна типу БД — це не просто дамп таблиць: трансформація схеми, перевірка цілісності та налаштування продуктивності. Наш досвід включає понад 50 міграцій за 5 років роботи з базами об'ємом від 10 ГБ до 5 ТБ. Ми знаємо типові пастки і як їх обійти.

Які ризики при міграції між різними СУБД?

Основні складнощі — відмінності в типах даних, регістрозалежність, обробка NULL та дат. Нижче — таблиця відповідності типів для трьох популярних СУБД:

Також типова проблема — нульові дати (0000-00-00): PostgreSQL їх не приймає, необхідна заміна на NULL. Потрібно переписувати запити з нестандартним GROUP BY і прибирати бектики.

Як ми мігруємо дані: стек та інструменти

Для автоматизації використовуємо спеціалізовані ETL-інструменти та власні скрипти. Розглянемо два популярні сценарії.

MySQL → PostgreSQL з pgloader

pgloader — найкращий вибір для прямого перенесення. Він конвертує в 3 рази швидше ручного підходу і автоматично обробляє індекси, зовнішні ключі та послідовності. Приклад конфігурації:

LOAD DATABASE FROM mysql://user:pass@mysql-host/myapp INTO postgresql://user:pass@pg-host/myapp WITH include no drop, create tables, create indexes, reset sequences SET work_mem to '256MB', maintenance_work_mem to '512MB' CAST type datetime to timestamptz using midnight-in-utc, type tinyint(1) to boolean using tinyint-to-boolean, type enum to text, column orders.status to text ALTER SCHEMA 'myapp' RENAME TO 'public' EXCLUDING TABLE NAMES MATCHING 'cache_*', 'sessions' ; 

pgloader дозволяє гнучко налаштовувати касти та виключати непотрібні таблиці. Порівняння з ручним ETL:

MongoDB → PostgreSQL з нормалізацією

MongoDB зберігає вкладені документи, які в реляційній моделі вимагають окремих таблиць. Наш Python-скрипт обробляє колекції побатчово, використовуючи jsonb для гнучкого поля метаданих:

from pymongo import MongoClient import psycopg2 from psycopg2.extras import execute_batch import json mongo = MongoClient('mongodb://localhost:27017') pg = psycopg2.connect('host=pg-host dbname=myapp user=app') source = mongo.myapp.users cursor = pg.cursor() batch = [] for doc in source.find(): batch.append(( str(doc['_id']), doc.get('email'), doc.get('name'), json.dumps(doc.get('metadata', {})), doc.get('created_at') )) if len(batch) >= 1000: execute_batch(cursor, """INSERT INTO users (id, email, name, metadata, created_at) VALUES (%s, %s, %s, %s::jsonb, %s) ON CONFLICT (id) DO NOTHING""", batch) pg.commit() batch = [] if batch: execute_batch(cursor, query, batch) pg.commit() 

Для вкладених масивів (наприклад, адрес) створюємо окрему таблицю із зовнішнім ключем і переносимо дані циклічно.

Чому zero-downtime — стандарт для бізнес-критичних систем?

Щоб уникнути простою, ми впроваджуємо патерн dual-write. Кожен запис дублюється в обидві СУБД, читання залишається на старій, поки історичні дані не синхронізуються. Після перемикання читання та тижневого моніторингу вимикаємо стару базу. Код репозиторію:

class DualWriteRepository: def __init__(self, primary, secondary): self.primary = primary self.secondary = secondary def create_user(self, data): result = self.primary.create_user(data) try: self.secondary.create_user(data) except Exception as e: logger.error(f"Secondary write failed: {e}") queue.put(('create_user', data)) return result 

Такий підхід знижує ризик втрат даних до 0.01% і дозволяє відкотитися в будь-який момент. Гарантуємо 99.99% цілісності за умови штатної роботи dual-write.

Як гарантувати цілісність даних?

Перевіряємо кількість записів та контрольні суми по всіх таблицях. Для PostgreSQL використовуємо md5 на відсортованих даних:

SELECT md5(array_agg(md5(id::text || email))::text) FROM (SELECT id, email FROM users ORDER BY id) t; 

MySQL дає аналогічний хеш, і після міграції вони повинні збігтися. Додатково проводимо вибіркове порівняння 10% записів.

Як ми тестуємо міграцію?

Тестування — ключовий етап. Ми розгортаємо повну копію бази на стенді, проганяємо скрипти, порівнюємо хеші та проводимо навантажувальне тестування. Тільки після успішного проходження запускаємо dual-write на проді. Якщо щось йде не так — відкочуємося до вихідної БД.

Процес роботи

Що входить у роботу та гарантії

• Документація підсумкової схеми та мапінгу типів.
• Скрипти міграції та відкату.
• Тестовий прогін на повній копії бази.
• Навчання команди роботі з новою СУБД.
• Підтримка 2 тижні після деплою.
• Гарантія 99.99% цілісності даних.

Терміни та вартість

Для бази до 100 ГБ міграція займає від 3 робочих днів (MySQL → PostgreSQL) до 2 тижнів (MongoDB → PostgreSQL з нормалізацією). Вартість розраховується індивідуально після оцінки об'єму даних та складності трансформації. Зв'яжіться з нами для консультації та отримайте індивідуальний план міграції без зобов'язань. Замовте попередній аудит вашої бази!