Как поставить миграцию баз данных на поток?

Илья Космодемьянский (Data Egret)

Многие производители систем хранения данных предлагают простые wizard-подобные системы для перевода вашего приложения на свою технологию. Однако, когда клиенты спрашивают нас о миграции с одной базы данных на другую, мы всегда начинаем объяснять, насколько этот процесс непрост и уникален в каждом конкретном случае. Прочитав хорошую книжку, можно получить представление об эксплуатации той или иной базы данных или базовые знания об устройстве веб-сервера. Но по книжкам нельзя научиться планировать миграцию одного из ключевых компонентов системы - слоя работы с данными - с одной технологии на другую. Да и нет таких книжек.

В этом докладе мы хотим рассказать об уникальном опыте одного из наших клиентов - 404 Group. В их случае миграция была фактически поставлена на поток: за последние несколько лет целый ряд независимых проектов был успешно перенесен на PostgreSQL c различных технологий хранения данных. На людей, предлагающих заменить систему хранения данных, часто смотрят как на профессиональных революционеров. Они проявляют и определенный фанатизм, и стремление разрушить “весь мир насилья до основанья, а затем...”, и (часто) нежелание работать в команде, и (иногда) неумение эволюционно развивать систему. Как избежать подобных крайностей? Как правильно оценить необходимость миграции, возможный выигрыш и возможные затраты? Как провести миграцию с минимальным ущербом для бизнеса? Мы ответим на эти вопросы и постараемся представить несколько точек зрения на них.

Вместе с Романом Друзягиным, техническим директором 404 Group, мы будем рассматривать каждый случай с двух точек зрения - с точки зрения технического руководителя и с точки зрения администратора баз данных.

Например, вы разработчик и точно знаете, что для оптимального хранения данных нужно выполнить миграцию с MySQL или PostgreSQL, или Oracle, или HBase на HandlerSocket или DB2 z/OS, или MongoDB, или вообще написать “свое простое хранилище“ (tm). О чем вам нужно подумать, прежде чем идти к руководству, и как нужно аргументировать свое предложение?

Другая ситуация: вы - технический руководитель. К вам ежедневно приходят разработчики и, сверкая глазами, предлагают сделать "как у Facebook" или "как у Вконтакте", или “как нам рассказывали в универе”. Какими соображениями руководствоваться, принимая решение? С чего начинать, если предлагают настолько новую технологию, что сами вы с ней еще не знакомы?

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