Полное руководство по стратегиям миграции технологий: (Часть 3 — Миграция базы данных)

Представьте себе ситуацию, когда вы покупаете новую квартиру, собрались для переезда и тщательно спланировали весь процесс. Все готово к переезду в новый дом, но вдруг вы понимаете, что есть проблема. Мебель и артефакты плохо вписываются в вашу новую квартиру.

Как бы вы себя чувствовали, если бы вам пришлось выбросить всю свою мебель и начать с нуля? Развивая эту аналогию, считайте новую квартиру своей новой базой данных, а мебель — данными. Мы уверены, что данные будут гораздо важнее для вашего бизнеса, чем мебель, и, следовательно, вы захотите сохранить каждую их частичку, пока планируете миграцию.

В качестве продолжения нашей серии статей о миграции технологий, в этом блоге мы попытаемся раскрыть основы миграции баз данных (DBM), что следует понимать, учитывать и о чем нужно заботиться при выполнении миграции базы данных.

Зачем и когда нужна миграция базы данных?

Как продолжение нашего предыдущего блога о миграции приложений, сегодняшняя часть посвящена миграции базы данных (также известной как миграция схемы), поскольку это одна из наиболее важных миграций, которая связана в основном с выбором, извлечением, передачей/обновлением данных из одной структуры базы данных в другую. еще один.

По существу, потребность в миграции базы данных может быть связана с конкретными бизнес-требованиями или даже с учетом последних многочисленных нормативных политик, установленных различными регулирующими органами. Хотя не существует определенных ситуаций, когда требуется DBM, мы перечислили некоторые ситуации, когда это неизбежно:

• Распространенной причиной является перевод вашей устаревшей системы на систему, которая соответствует вашим бизнес-требованиям и современным потребностям в данных. Новые и современные методы хранения стали необходимостью во времена больших данных.
• Некоторые регулирующие органы сделали обязательным, чтобы данные оставались только в определенной географии. Следовательно, необходимо, чтобы распределенные данные переносились в одно место.
• Некоторые компании предпочитают перемещать локальную базу данных в облачную базу данных. Обычно это позволяет сэкономить на инфраструктуре и экспертных ресурсах, необходимых для поддержки данных, а также ускорить работу систем.
• Переход на новую платформу обеспечивает комплексную целостность данных. Это снижает затраты на хранение и носители, что приводит к значительному повышению рентабельности инвестиций.
• Многие современные компании хотят хранить все свои данные в одном месте. Таким образом, данные доступны для всех отделов компании.

Миграция системы баз данных на новую платформу снижает количество сбоев в повседневных бизнес-операциях. Это можно сделать с минимальными ручными усилиями, если выбрать новую платформу базы данных с умом.

Типы баз данных

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

• Реляционная база данных . Реляционные базы данных известны как рабочие лошадки индустрии баз данных. Эти базы данных классифицируются набором таблиц. Таблицы состоят из строк и столбцов, где строка содержит экземпляр данных, а столбец содержит ввод данных для определенной категории. SQL — язык структурированных запросов — это стандартный программный интерфейс для реляционной базы данных.
• Распределенная база данных . Как следует из названия, данные распределяются по различным сайтам любой организации. Коммуникационные каналы используются для соединения сайтов друг с другом. Это помогает легко получить доступ к распределенной базе данных.
• Объектно-ориентированная база данных . Этот тип базы данных объединяет атрибуты реляционной базы данных и объектно-ориентированного программирования. Различные элементы, созданные на C++ и Java, могут храниться в реляционных базах данных, однако для них больше подходит объектно-ориентированная база данных.
• База данных NoSQL. База данных NoSQL может эффективно анализировать большие неструктурированные данные, хранящиеся на нескольких виртуальных серверах. Напротив, реляционная база данных не может эффективно обрабатывать некоторые производительности больших данных. Базы данных NoSQL могут легко справиться с такими случаями и используются для большого набора распределенных данных.
• Облачная база данных . Облачная база данных — это виртуальная среда, обеспечивающая гибкость оплаты по факту использования. Пользователю нужно платить только за пропускную способность и емкость хранилища, которые соответствуют его требованиям.
• База данных графов . Проще говоря, граф представляет собой набор узлов и ребер. База данных графов содержит узлы, которые представляют сущности, а ребро описывает отношения между этими сущностями. Это тип базы данных NoSQL, использующий теорию графов для сопоставления, хранения и запроса взаимосвязей.
• Централизованная база данных . В базе данных этого типа данные хранятся в одном централизованном месте. База данных по существу содержит прикладные процедуры, которые также позволяют пользователям получать доступ к БД из удаленных мест.

Подходы к миграции баз данных

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

Миграция данных Большого взрыва:

При таком подходе выбирается одновременная миграция всей базы данных в течение ограниченного периода времени. Хотя миграция больших данных кажется менее сложной, она требует достаточного времени простоя работающего веб-сайта. Кроме того, при таком подходе может быть непросто добиться полного отката процесса миграции в случае сбоя миграции в любой момент.

Медленная миграция данных

При таком подходе необходимо разделить процесс миграции на более мелкие фрагменты или этапы. Почти как при гибком подходе к миграции: если происходит сбой одной фазы, необходимо откатить только эту фазу и повторить процесс. Однако миграция данных Trickle занимает очень много времени и, следовательно, может увеличить стоимость проекта.

Различные типы миграции

Реляционная БД в реляционную БД

Этот подход является наиболее прямой миграцией. Существует множество доступных инструментов, которые выполняют этот тип миграции довольно эффективно, почти на 100%.

Реляционная БД в нереляционную БД и наоборот

Эта миграция является более сложной по сравнению с вышеупомянутой. Поскольку реляционная БД и нереляционная БД принципиально различаются, их миграция может быть неэффективной на 100%. По сути, переход на нереляционную БД означает отказ от свойств ACID (атомарных, непротиворечивых, изолированных и надежных), которые гарантируют масштабируемость базы данных.
Однако существует несколько бесплатных инструментов, поддерживающих миграцию базы данных с реляционной на нереляционную БД. Хотя их использование широко не рекомендуется, поскольку эти инструменты не поддерживают структуру схемы системы и большинство из них кажутся слишком жесткими для адаптации к системным требованиям.

Хотя есть некоторые основные советы по преобразованию, которые мы можем предоставить для этого типа миграции, которые мы можем рассмотреть (для простоты давайте рассмотрим MySQL как нашу реляционную базу данных и MongoDB как нашу нереляционную базу данных).

• Преобразование типа данных MySQL String в String в MongoDB. Это может быть char, varchar, blob, текст и т. д.
• Преобразование числового типа данных MySQL в числовой в MongoDB. Это может быть int, float, decimal, double и т. д.
• Преобразование типа данных MySQL Date в Date в MongoDB. Это может быть дата, год, временная метка и т. д.
• Преобразуйте тип данных MySQL Bool & Boolean в Boolean в MongoDB.
• Таким же образом вы можете оценивать и другие случаи.

Миграция с гибридной моделью

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

Резервное копирование данных

Планирование стратегии миграции до ее выполнения может обеспечить плавный процесс миграции. При этом у нас всегда должен быть план Б. Предполагая наихудший сценарий, когда происходит некоторая потеря данных или данные повреждаются при выполнении миграции; вы должны быть готовы восстановить данные в исходное состояние, прежде чем пытаться снова. Вот почему резервное копирование данных является крайне важным шагом во время DBM (миграции базы данных). Итак, какие варианты существуют для обеспечения безопасного резервного копирования данных, давайте углубимся.

Облачное резервное копирование

Одним из наиболее эффективных и безопасных методов защиты вашей инициативы по миграции является выполнение резервного копирования в облачное хранилище. По сути, когда вы создаете резервную копию своих данных в облачном хранилище, ваши файлы хранятся за пределами сайта. Это устраняет локальные уязвимости оборудования, которые могут вызвать проблемы. Итак, зачем резервное копирование в облаке?

• Облачные резервные копии доступны по цене, потому что вам нужно платить только за использование.
• Резервное копирование в облаке безопасно, так как обеспечивает сквозное шифрование.
• Позволяет легко аварийное восстановление и восстановление данных
• Надежные варианты резервного копирования в облаке включают полное резервное копирование образа системы. Таким образом, вам не нужно переустанавливать ОС. Компьютеры и серверы восстанавливаются до последней работающей версии.

Программное обеспечение для обмена файлами

Пакеты программного обеспечения, такие как Dropbox, расширяются, чтобы удовлетворить потребности своих пользователей. Dropbox хранит версии файлов, которые при необходимости можно восстановить. Подобно резервному копированию в облаке, этот вариант доступен по цене, а файлы хранятся вне офиса. Каковы его преимущества?

• Файлы можно восстановить в любой системе в любом месте.
• Это бесплатно и поддерживает совместную работу.
• Высокий уровень безопасности (облачное хранилище шифрует ваши файлы при передаче)
• Возможности автономной работы

Однако недостатком является то, что восстановление не автоматизировано. Вам необходимо скопировать и вставить данные в структуру каталогов общего доступа к файлам, чтобы сохранить данные. Файлы должны находиться в определенной структуре, иначе они не будут скопированы. Если файлы находятся в общей папке или каталоге, вам, вероятно, потребуется больше пропускной способности для резервного копирования этих файлов.

Вообще говоря, есть и другие доступные носители для резервного копирования, такие как резервное копирование на флэш-накопитель или внешний жесткий диск. Но эти варианты не рекомендуются, поскольку они не полностью безопасны по сравнению с облачным резервным копированием или программным обеспечением для обмена файлами. Например, любое физическое повреждение жесткого диска может привести к потере данных. Кроме того, они более уязвимы и восприимчивы к атакам программ-вымогателей и криптовирусов.

Как обеспечить безопасность данных?

При переносе данных необходимо убедиться, что конфиденциальные данные не взломаны и не подделаны. Если миграция пойдет не так, это может привести к более серьезным последствиям и привести к утечке или потере данных, как в приведенных здесь примерах в 2020 году.

К сожалению, утечка данных может нанести ущерб репутации клиента, привести к потере бизнеса и клиентов; или в некоторых случаях может спровоцировать судебные иски. Чтобы избежать всех подобных последствий, вам необходимо заранее составить план безопасности с учетом стратегии миграции.

• Начнем с того, что надежный и безопасный доступ к серверу и доступ к данным должны быть в вашем списке приоритетов.
• Увеличьте количество разрешений, необходимых для передачи данных. В крупных организациях отделы безопасности ограничивают доступ к серверам и определяют миграцию данных между задействованными серверами.
• Данные подвергаются высокому риску, когда в процесс вовлечено больше сторон. Таким образом, избегайте передачи между сторонами через портативные устройства хранения или электронные письма. В таких случаях данные могут быть легко скомпрометированы.
• Чтобы обеспечить безопасный доступ, хранение и извлечение данных, необходимо постоянно практиковать шифрование и дешифрование. Вы можете использовать гибридные алгоритмы шифрования, чтобы обеспечить максимальную безопасность данных. Но это не всем рекомендуется. Если миграция завершится неудачно, данные будут загромождены, что может привести к повреждению или потере данных.

Чтобы обеспечить безопасную миграцию, избегайте использования примитивных инструментов. Использование примитивных инструментов может ослабить вашу систему и оставить лазейки для доступа хакеров. Вы должны использовать надежные инструменты для переноса данных, которые функционально специфичны.

Процесс переноса данных

Миграция данных в основном представляет собой многоэтапный процесс, и необходимо выполнить следующие шаги, чтобы избежать потери данных и обеспечить безопасную миграцию базы данных.

1. Оценка :

• Соберите анализ бизнес-требований и определите ключевую цель, которую необходимо достичь с помощью DBM.
• Определить область
• Проведите обширное профилирование данных:
  • Просмотрите исходные данные, формат данных, просмотрите структуру схемы, содержимое и отношения между экземплярами данных.
• Понять систему назначения
• Определите заинтересованные стороны
• Бюджет всей деятельности

2. Резервное копирование данных

• Убедитесь, что данные, которые вы переносите, надежно защищены. Рекомендуется использовать облачное резервное копирование.
• Убедитесь, что пункт назначения чист и защищен от любых взломов данных.

3. Доступность ресурсов :

• Наличие времени для миграции и время простоя целевой системы.
• Убедитесь, что нанятый человеческий ресурс имеет правильный набор навыков.
• Определите правильный инструмент и сценарии.

4. Выполнение переноса данных :

• Процесс миграции может включать сценарии, инструменты ETL или другие аналогичные инструменты для перемещения данных.
• Во время миграции вы преобразуете данные, нормализуете типы данных и, наконец, проверите возможные ошибки.

5. Тестирование и настройка :

• Команда и команда клиента должны быть абсолютно уверены, что все данные правильно перенесены.
• Итак, проверьте, правильно ли перемещены данные, полны ли данные и убедитесь, что нет пропущенных значений.
• Кроме того, убедитесь, что данные действительны и не содержат пустых значений.
• В случае несоответствия данных должен быть откат данных и весь процесс должен быть перезапущен.

6. Аудит

После запуска новой базы данных можно настроить систему для аудита данных. Это обеспечит точность переноса базы данных и привлечет внимание к неполным и неточным данным.

Потенциальные риски при миграции базы данных

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

• Устаревшие исходные системы: здесь источник данных может быть устаревшим, избыточным, устаревшим или тривиальным.
• Несопоставимая архитектура базы данных: в этом сценарии исходные базы данных могут быть расположены в нескольких местах, и они могут иметь совершенно разные архитектуры, но в целевой базе данных все должно быть синхронизировано.
• Длительное время простоя: бывают случаи, когда запланированная миграция занимает больше времени, чем ожидалось, и из-за этого происходит длительное время простоя системы. Это может привести к потере бизнеса для конечного клиента и может быть неприемлемым.
• Потенциальная потеря данных: не все потери данных могут быть выявлены на этапе тестирования. Некоторые случаи потери данных могут быть обнаружены в конечном итоге, когда система получит достаточно трафика.

Миграция из базы данных в режиме реального времени. Для любого веб-сайта с высоким уровнем транзакций миграция базы данных всегда затруднена, поскольку происходят постоянные обновления данных; и перенос данных в реальном времени и в реальном времени невозможен. Для любой миграции должно быть время простоя.

Заключительные замечания

Вы всегда можете обратиться за советом к сторонним экспертам по миграции баз данных. Мы, Creole Studios, специализируемся на миграции баз данных, и мы будем рады помочь или проконсультировать в любом таком начинании. Не пропустите четвертый и последний блог из серии о миграции технологий.