Scylladb спонсировал этот пост.
Ни одна команда не хочет принять миграцию базы данных. Но многие команды мигрируют базы данных NOSQL для оптимизации производительности в масштабе, облегчают бремя обслуживания и/или контрольные расходы. Если миграция находится на радаре вашей команды, как вы делаете процесс максимально безболезненным, с минимальными нарушениями как вашей командой, так и для вашей пользователей?
Вот несколько проверенных в битве советов по планированию, выполнению и дефекту миграции базы данных NOSQL.
Перво -на первый взгляд
Хорошей новостью является то, что переход из одной базы данных в другую — или даже в ту же базу данных в новой топологии — на самом деле не так уж и сложно. По своей сути, миграция — это просто перемещение данных из исходной системы в целевую систему. Когда команды переполняют процесс, это обычно потому, что им не хватает четкого сквозного понимания того, что связано.
Прежде чем вы фактически начнете процесс миграции, вам нужно решить, какой тип подхода миграции следует использовать. Есть два основных варианта: онлайн или офлайн.
- Офлайн миграцияЗдесь вы останавливаете исходную систему, переводите данные, а затем переключаете клиентов, чтобы использовать новую базу данных.
- Онлайн -миграция: Здесь нет времени простоя применения. Это создает повышенную сложность и требует тестирования, чтобы убедиться, что вы не представляете возвышенное воздействие на приложения для чтения и написания в вашей базе данных.
Независимо от того, какой маршрут вы решите выбрать, вам нужно выполнить три ключевых шага:
- Миграция и изменения схемы: Обычно требуется некоторый уровень настройки схемы, если вы не переходите в другую версию одной и той же базы данных или в двух базах данных, совместимых с API.
- Миграция данных: Перемещение ваших данных из одного места в другое.
- Проверка данных: Проверка ваших данных, чтобы гарантировать, что все работает, как и ожидалось.
Пусть это течет
Это приводит нас к фактическому потоку миграции, который показан на следующей диаграмме. Стадии процесса разделены пунктирными вертикальными линиями.
Когда вы начинаете, приложение пишет и читает из исходной базы данных. Вы начнете мигрировать схему в этот момент. Абсолютно важно правильно настроить вашу схему в базе данных назначения. Если вы поймете это неправильно, вам нужно повторить все шаги миграции. Инженер Discord Bo Ingram и я много говорили о стратегиях моделирования данных в недавнем моделировании данных NOSQL для мастер -класса производительности, который доступен по требованию.
Если вы запускаете онлайн -миграцию, вам также необходимо начать захватывать изменения, поскольку они происходят в вашей исходной базе данных. Лучший подход здесь зависит от того, из каких баз данных вы мигрируете (и в). Например, в DynamoDB вы включили бы потоки динамо. Если вы мигрируете из Кассандры в Scylladb, то большую часть времени с двойным написанием приложения будет работать очень хорошо. Другие подходы будут включать использование KAFKA, сбора данных о изменениях вашей базы данных (CDC) и аналогичных инструментов.
Далее пришло время фактически переместить существующие данные. Если вы включили CDC на предыдущем шаге, то вам следует дождаться воспроизведения всех изменений, прежде чем перейти к следующему шагу.
Как только это будет сделано, ваши источники и целевые базы данных должны быть синхронизированы. На этом этапе вы захотите проверить результаты миграции, прежде чем обновить приложение для использования новой базы данных. Это может быть достигнуто разными способами. Например, вы можете провести быстрое сравнение случайных отдельных записей. Или вы можете сделать более обширную проверку, сравнивая каждую отдельную запись, прежде чем принять решение о выходе/не ходи. Уровень проверки для выполнения зависит от требований вашей команды и терпимости к риску.
Наконец, как только система ведет себя так, как ожидалось, вы переключаете трафик клиента на новую настройку. Вы можете перемещать все сразу или делать это постепенно, используя стратегию развертывания канарейки в качестве меры безопасности (перемещение по одному набору пользователей за раз).
Что следить
Процесс миграции, описанный выше, довольно прост в теории. Но на практике иногда это сложно. Например, вам также необходимо учитывать такие аспекты, как:
- Технологические переключатели: Если вы переходите из одной базы данных в другую, то вы быстро поймете, что некоторые функции, на которые вы полагаетесь, недоступны в новой базе данных. Или, может быть, они доступны, но реализованы по -разному. Вам также необходимо будет понять характеристики целевой базы данных, чтобы гарантировать, что ваше моделирование данных масштабирует по мере роста рабочей нагрузки. И для каждого изменения приложения и изменения моделирования данных, которые вы делаете, вы захотите посвятить достаточно времени для тестирования.
- Инструмент: Если вы не являетесь экспертом Spark/Scala, вы практически невозможно найти один инструмент, который позволяет вам мигрировать из любой базы данных в любую базу данных. Даже когда такие инструменты существуют, могут потребоваться дальнейшие корректировки, чтобы работать специально для вас, в зависимости от вашей рабочей нагрузки и требований. И когда нет инструментов, вам будет в значительной степени приготовить свои собственные инструменты и процессы с нуля.
- Крайные случаи: Некоторые варианты использования могут зависеть от конкретных функций базы данных — таких как пользовательские типы данных (такие как счетчики) или методы управления параллелизмом (сериализация). Они могут представлять дополнительные проблемы во время миграции; Они не могут быть непосредственно поддерживаться или вести себя по -разному в целевой системе. Вам нужно будет выявить эти случаи на раннем этапе и справиться с ними с особой осторожностью.
Только перемещай то, что важно
Последний, и часто упускаемый из виду, рассмотрение: вам, вероятно, не нужно мигрировать все.
Команды обычно предполагают, что им нужно мигрировать все свои данные, но это часто излишне. Быть более избирательным может сэкономить значительное время и усилия. Это также заставляет вас более внимательно рассмотреть ваши рабочие нагрузки, что часто выявляет проблемы, такие как требования к последовательности и шаблоны поведения пользователей, которые в противном случае могут остаться незамеченными.
Когда я спрашиваю людей: «Можете ли вы терпеть некоторый уровень потери данных?» Их интуитивная реакция почти всегда является громким «нет!» Но допустим, у вас есть вариант использования IoT, и ваше приложение генерирует отчеты почасовой/ежедневно/еженедельно. Сбросить несколько точек данных во время миграции, вероятно, не будет иметь значения, особенно если ваши панели панели собирают данные в течение более длительных сроков.
Во многих случаях пользователи не заботятся о данных старше, чем несколько недель. Если это верно для ваших рабочих нагрузок, не беспокойтесь об этом. То же самое касается журналов и трассов: вместо того, чтобы мигрировать исторические данные, вы сможете просто снимать их и начать только что на новой системе.
Конечно, некоторые варианты использования (например, приложения для обмена сообщениями, социальные платформы или финансовые системы) действительно требуют нулевой потери данных. Любая отсутствующая запись может напрямую повлиять на бизнес. Но даже тогда у вас все еще может быть некоторый уровень гибкости по сравнению с тем, как вы структурируете миграцию. Например, возможно, вам нужно мигрировать 10 таблиц, но вы можете сопоставить несколько таблиц с определенными микросервисами. В этом случае вы можете разделить фактическую миграционную работу на меньшие итерации. И, возможно, некоторые из этих таблиц используют время для жизни (TTL), чтобы вы могли перенести только те части, которые наиболее важны для вашего бизнеса.
Последние мысли
Потратьте время, чтобы рассмотреть эти миграционные нюансы, прежде чем начать. Немного планирования должно помочь вам на ранних стадиях выяснить потенциальные проблемы и возможности оптимизации, в конечном итоге, сэкономив вам много времени и горе в долгосрочной перспективе. И самое главное: протестируйте свой план миграции, прежде чем запустить его в производстве. Пропуск этого шага может привести к болезненным (и потенциально дорогостоящим) сюрпризам, которые вы определенно захотите избежать.
Хотите узнать больше о миграциях NOSQL? Посмотрите этот мастер -класс миграции NOSQL с экспертом по распределенной системе Джоном Хаддадом по требованию.
Scylladb разработан для обеспечения предсказуемой производительности в масштабе. Он принят организациями, которые требуют ультра-низкую задержку, даже с рабочими нагрузками, превышающими 1M OPS/SEC. Наша уникальная архитектура использует силу современной инфраструктуры — переводится на меньшее количество узлов, меньшую административную и снижающую затраты. Узнайте больше последних из Scylladb Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Felipe Cardeneti Mendes является ИТ -специалистом с многолетним опытом работы в распределенных системах и технологиях с открытым исходным кодом. Он является соавтором Three Linux Books и является частым оратором на публичных мероприятиях и конференциях для продвижения технологий с открытым исходным кодом …. Подробнее от Felipe Cardeneti Mendes
