Постепенно переходите с SQL Server на PostgreSQL

Question

Компания имеет множество приложений, работающих на SQL Server. База данных немного беспорядочна.

Цель состоит в том, чтобы постепенно перейти от SQL Server к PostgreSQL (другой экземпляр SQL Server не вариант)

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

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

Другая дикая идея - подключиться из экземпляра SQL Server к PostgreSQL, новые приложения будут подключаться к SQL Server, но использовать внешнюю базу данных PostgreSQL. Эта внешняя база данных (я думаю) имела бы доступ к объектам базы данных хоста. И в какой-то момент разработчики переключили бы все новые приложения с SQL Server на PostgreSQL.

И, конечно, есть возможность попытаться синхронизировать данные.

Какой был бы лучший вариант?

Answer 1

Все, что вы предлагаете, является рецептом боли и неудачных миграций. Люди будут разглагольствовать и кричать о том, как ужасный, медленный и ненадежный PostgreSQL, если вы попытаетесь использовать этот подход. Это был бы большой политический шаг того, кто хотел бы сохранить SQL Server, но не был хорошим способом перехода на PostgreSQL.

Существует новая оболочка для чтения/записи для новых версий Pg, но первоначально она будет поддерживать только другие серверы PostgreSQL. Поддержка MS SQL будет намного сложнее из-за необходимости переводить sqlstates и сообщения об ошибках, условия поиска и т. Д., Поэтому любая оболочка, без сомнения, будет весьма ограничена и имеет менее высокую производительность. Как вы говорите, поддержка FDW слишком незрелая на этом этапе.

Есть только так много вещей, которые вы потеряете, пытаясь сделать гибрид так:

• Нет ключ органов внешней целостности

• типов данных на каждой стороне не могу вести себя 100%, то же самое поэтому данные могут быть в порядке с одной стороны, а не с другой. Думайте временные метки/даты.

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

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

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

Серьезно, не делайте этого.

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

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

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

Answer 2

Это не проблема. Вы можете полностью или частично переместить свои данные в PostgreSQL. Вы можете записывать хранимые функции внутри PostgreSQL в Java, Python или какой-либо другой поддерживаемый язык и создавать представления, которые используют эти функции. Ваша функция должна подключаться к MSSQL при каждом выполнении. Названия и структура представлений должны представлять ваши таблицы MSSQL в разных базах данных. Только обновление в этом случае немного сложно, требует триггеров и большего количества кода. Таким образом, вы можете подключить PostgreSQL к любому другому поставщику SQL/NoSQL DB. Он работает хорошо, но медленнее, чем все ваши данные внутри PostgreSQL. Я считаю, что в некоторых случаях подключение к обоим поставщикам из приложения может быть более простым, но это ваш выбор: у вас есть варианты.

Answer 3

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

• Любое совершенно новое или сильно переписанное приложение полностью находится в Postgres. Это не обязательно означает, что прикладной уровень (в нашем случае PHP) подключается только к Postgres, так как целые библиотеки или общие модули могут оставаться на «устаревших» схемах.
• Центральные бизнес-данные, такие как конфигурация ядра, первоначально оставались в MS SQL, причем скрипт регулярно экспортировал данные и импортировал их в целевые объекты Postgres только для чтения. Для этого мы использовали простую сериализацию XML, после того, как обнаружили слишком простой вариант CSV/TSV, чтобы конвертировать между двумя платформами. У нас также были проблемы с выполнением процесса в обратном порядке, поскольку процесс импорта был более подвержен разрушительным исключительным блокировкам на MS SQL, чем Postgres.
• Данные, которые записываются только в одном месте (например, панель администратора), могут быть одновременно вставлены/обновлены как в старых, так и в новых БД. Очевидно, это сопряжено с риском того, что кто-то вручную создает несоответствия, но имеет преимущество, что обе копии одинаково актуальны. Он также требует ухода с автоматически генерируемыми значениями, например. используя команду SET IDENTITY_INSERT, чтобы ввести в соответствие идентификаторы.

Преобразование отдельных запросов относительно легко, с главной проблемой является с CamelCase имена таблиц и столбцов: SQL Server не чувствителен к регистру, но дело сохранения, в то время как Postgres чувствителен к регистру, но складки некотируемые идентификаторы в нижнем регистре. Таким образом, SELECT FooID FROM ... не только ищет столбец с именем fooid, но возвращает поле, помеченное fooid в приложение, которое ожидается FooID. Это потребовало аудита большого количества существующего кода приложения, чтобы он ожидал, что будет выделена underscore_сепаратированная версия, например. foo_id, что в большей степени соответствует поведению Postgres.