Scylladb спонсировал этот пост.
«Никто никогда не говорил:« Мех, это только наша база данных ».
— Тим Купманс, старший директор Scylladb
Каждая миграция данных — это высокие ставки для человека, ведущего его. Независимо от того, обновляете ли вы базу данных внутреннего приложения или перемещаете 362 петабайт социальной платформы x [Twitter’s] Данные от Bare Metal до Google Cloud Platform (GCP), многое может пойти не так, и вы не хотите, чтобы вас обвиняли в времени простоя или потери данных.
Но сделанная миграция не только оптимизирует инфраструктуру вашего проекта. Это также оставит вас более глубоким пониманием вашей системы и, возможно, даже даст несколько забавных «военных историй», чтобы поделиться со своими сверстниками.
Чтобы немного обмануть, почему бы не научиться в первую очередь из опыта других? Введите Майлз Уорд, технический директор SADA и бывшего Google и AWS Cloud Lead, а также Тим Купманс, старший директор Scylladb, Performance Geek и основатель SaaS Startup. Уорд и Купманс недавно собрались вместе, чтобы поговорить о уроках, которые они лично извлекли из руководства реальных миграций данных.
Вы можете посмотреть полное обсуждение и услышать некоторые интересные анекдоты здесь:
Давайте посмотрим на три ключевых вывода из чата.
1. Начните с самой сложной, самой уродливой части сначала
Всегда заманчиво начать проект с некоторыми быстрыми победами, но сначала занятие худшей частью принесет лучшие результаты в целом. Уорд объясняет: «Начните с самой сложной, самой уродливой части сначала, потому что вы будете ошибаться с точки зрения оценки сроков и лапши через у кого правильные навыки для каждого шага и каковы все условия края, которые способствуют сложности».
Например, он увидел этот подход в действии во время семилетней миграции Google в бэкэнд Gmail (обработка триллионов транзакций в день) от внутренней системы данных Gmail до гаечного камера. Во -первых, Google построил Spanner специально для этой цели. Затем, миграционная команда запускала Rollwards и отзывчики отдельных миграций почтовых ящиков в течение более двух лет, прежде чем решить, что производительность, надежность и последовательность в новой среде соответствовали их ожиданиям.
Уорд добавил: «Вы также получаете эмоциональную выгоду в своих командах. Как только эта самая страшная часть будет сделана, все остальное станет проще. Я думаю, что это имеет тенденцию работать хорошо, как межличностно, так и технически».
2. Карту минного поля
Вы не можете безопасно мигрировать, пока не намете на карту каждую небольшую зависимость. Как Купманы, так и Уорд подчеркивают важность исчерпывающего открытия: каталогизируя каждого восходящего абонента, каждого нижнего потребителя, каждого проверки здоровья и окна простоя договора перед сменой одного байта. Уорд предупреждает: «Если у вас нет представления о том, каковы последствия ваших изменений… вы разработаете миграцию, которая не знает этих потребностей».
Затем Уорд предложил предостерегающий анекдот от своего времени в Твиттере, как часть команды, которая перенесла 362 петабайт активных данных из центров обработки данных в Google Cloud. Они использовали взаимосвязь 800 Гбит / с (примерно общую пропускную способность в Интернете в то время) и передали все через 43 дня. Чтобы быть справедливым, это была миграция хранилища данных, поэтому она не включала сотни тысяч транзакционных запросов в секунду. Тем не менее, рекламные системы и доходы Twitter полностью зависели от этого склада, что делает миграционную миссию критически важной.
Уорд поделился: «Они принесли невероятных инженеров, и эти люди работали с нами в течение нескольких месяцев, чтобы установить план до того, как мы перенесли какие-либо байты. Сравните это с чем-то немного большим отборочным.
3. Инженер «блаженно скучная» сокращение
«Если вы не чувствуете сонливого в день,-сказал Уорд,-вы сделали что-то ужасно неправильное». Но как добраться до этой точки?
Купманс поделился, что он всегда находил двойные записи с единичными чтениями полезными: вы можете переключиться, как только обе системы будут скорость. Если база данных не поддерживает двойные записи, репликация записей с помощью сбора данных изменений (CDC) или чего -то подобного работает хорошо. Эти стратегии обеспечивают уверенность в том, что источник и цель ведут себя так же под нагрузкой, прежде чем вы начнете служить реальным трафика.
Затем Купманс спросил Уорда: «Вы бы сказали, что это, как правило, хорошие подходы, или это просто зависит?» Ответ Уорда: «Я думаю, что самый большой драйвер из« это зависит », заключается в том, что эти концепции, как правило, являются обоснованными, но миграции реального мира более сложны. Вы всегда хотите, чтобы расколотые записи были в целом, поэтому вы создаете эксплуатационный опыт под нагрузкой в новой среде. Но выборки архитектурных диаграмм и примеры терраформ делают миграции более простые, чем они обычно бывают».
Еще один усложняющий фактор: у большинства компаний нет одного приложения в одной базе данных. У них есть десятки приложений, говорящих по нескольким базам данных, хранилищам данных, кэш -слоям и так далее. Все это имеет значение, когда вы начинаете маршрутизировать трафик из различных источников. Некоторые системы используют запланированные экстракции базы данных, в то время как другие избегают потоковой репликации. Заборы нагрузки сдвигаются в течение дня, когда различные рабочие нагрузки выходят в Интернете. Вот почему вы должны проверить вне непосредственного чтения после миграции или когда первоначальные записи переезжают в новую среду.
Так что кодифицируйте каждый шаг, верните его и протестируйте все несколько раз — точно одинаково. И если вам нужно оправдать дополнительную подготовку или планирование миграции, создайте ее как улучшение вашего общего дизайна высокой доступности. Эти практики будут перенесены даже после сокращения.
Кроме того, имейте в виду, что новые платформы неизбежно будут иметь различные операционные характеристики. Вот почему вы их принимаете. Но эти изменения могут нарушать твердые оповещения или автоматизацию. Например, возможно, у вас были оповещения, которые будут запускать на 10 000 транзакций в секунду, но новая система легко обрабатывает 100 000. Убедитесь, что ваша предыдущая автоматизация все еще работает и систематически оценивает все зависимости вверх по течению и нисходящим.
Следуйте этим советам, и большой день может напоминать звездный пример цифровой турбины. Уорд поделился: «Если база данных цифровой турбины исчезла, его бизнес снизился. Но миграция DynamoDB компании в Scylladb была полностью без драмы. Это заняло две с половиной недели, все застегнуты, все прошло.
Заключительные мысли
Миграции данных всегда являются «высокими ставками». Как прямо сказал Уорд, «я знаю, что если я это испорчу, я разозлюю клиентов, приведу их к конкурентам или упущу возможности совместного роста. Все сводится к доверию. Существует бесчисленное множество способов испортить приложение таким образом, чтобы нарушать заинтересованные лица, которые заинтересованные средства доверяют. Но осторожно планируя, вдумчивая процесс миграции, и принятие правильных дизайнерских решений подходит к команде.
Проекты по миграции данных также являются отличными возможностями для укрепления архитектуры вашей команды и создания собственного инженерного опыта.
Купманс оставил нас с этой мыслью: «Мой совет для тех, кто боится запустить миграцию данных: просто взломай.
Бонус: доступ к нашему бесплатному мастер -класса миграции NOSQL для более глубокого погружения в стратегию миграции, ошибки и логистику.
Scylladb разработан для обеспечения предсказуемой производительности в масштабе. Он принят организациями, которые требуют ультра-низкую задержку, даже с рабочими нагрузками, превышающими 1M OPS/SEC. Наша уникальная архитектура использует силу современной инфраструктуры — переводится на меньшее количество узлов, меньшую административную и снижающую затраты. Узнайте больше последних из Scylladb Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Синтия Данлоп пишет о разработке программного обеспечения и тестировании гораздо дольше, чем она хочет признать. В настоящее время она является старшим директором по контент -стратегии в Scylladb. Подробнее от Синтии Данлоп
