Комментарии 20
Снимаю шляпу.
Если абстрагироваться, можно было разделить данные по разным базам?
Если база будет расти дальше, то с каким темпом? Упрется в какой то потолок в обозримом будущем?
В одном проекте (репозиторий на основе базы) с ростом хранилища примерно 6 млн документов в день на 25 лет (архив на 50 млрд документов, в основном сканы и пдф), было решено каждый год создавать новое хранилище для активных изменений, старое становилось архивом, только для чтения, а текущее хранилище имело приоритет (перекрывало данные из архива). Программным путем все разруливалось уровнем выше. Примерно как слои в докере, но на уровне репозитория документов (файлнет). Сколько занимала база для каждого года, не могу точно сказать, но документ с метаданными и содержимым был около 100кб ( 2 млрд * 0.1 MB равно 18 терабайт получается, в год, база могла пухнуть и уходить в архив?).
Нума - штука серьёзная, как влияет на работу под нагрузкой лучше тестировать до переезда.
У нас numa=off сеть ограничивает, если надо больше 100Гб.
Есть такой замечательный продукт от ИБМ называемый IBM InfoSphere Data Replication.
Этот продукт делает то что описано в статье без шороха и пыли. Без каких либо проблем обозначенных в статье и с временем переключеня на новую БД измеряемым минутами.
Устроен продукт IIDR следущим образом. Для каждой известной БД в нем есть CDC (Change Data Capture) Replication Engine или в просторечии DB agent. DB agent читает журнал изменений исходной (source) DB и преобразует запси изменения данных журнала в SQL стейтменты изменения данных для принимающей (target) DB и посылает эти стейтменты агенту принимающей БД. Агент принимающей БД применяет (apply) стейтменты в примимающей БД.
Таким образом происходит непрерывная синхронизация данных в двух связанных БД. Т.е. выполняется репликация БД.
Миграция данных из продакшн системы выполняется в три простых шага:
Создается конфигурация связи таблиц исхлодной и принимающей БД. IIDR предлагает массу решений связанных с различиями разнородных БД (типы данных, и т.д.), в том числе различиях структур.
Выполняется начальная закрузка данных из исходной БД, синхронизация изменений данных произошедщих в течении времени начальной загрузки, и поддержка сихронизации данных в реальном времени. Все это происходит с IIDR в одном действии ("start mirroring") время выполнения которого зависит исключительно от размера данных, а размер данных может быть каким угодно.
В день переключения (cutover day) доступ к исходной БД останавливается. Ожидается завершение синхронизации данных. Как правило это будут секунды, пусть минуты. Открывается достпуп приложения и пользователей к новой БД.
В IIDR есть агенты БД и для Оракл и для Postgre SQL (тотал 37 различных БД).
Я лично участвовал в миграции данных большой БД (полторы тысячи таблиц) из DB2 for z/OS в Oracle, и сейчас сопровождаю репликацию из Oracle в MS SQL.
так IBM же ушел, как они применят? Это же не домашний проект, надо официально проводить
А Оракл не ушел? Они использовали Оракл-ские методички и технологии. Откуда они у них?
Наконец почему бы не воровать орошие вещи. Есть же СВР в России. Это их прямая обязонность добывать то что надо. В 70-е, 80-е мы же пользовались и много ворованным ПО. А что сейчас надо изобретать велосипед?
Кстати последнее тоже актуально. IIDR работает на публичной информации. ИБМ смог читать журналы изменений Оракл. Почему российские программисты не могут? А вся хитрость в IIDR это умение читать журналы изменений баз данных и дата сторес.
Подход описанный в статье и основанных на тригерах это самый примитивный, неэффективный и проблематичный путь решения проблемы миграции данных. Именно им, навеянным Оракл, пошли наши ИТ-ники, работающие на государственных сервисах. Мне, гражданину РФ, живущему и работающему в ИТ в Канаде обидно за мое отечество (я за него служил два года в РВСН, офицером). Оно достойно лучшей участи. И эта участь легко достижима.
В нынешних условиях воровство не самый плохой вариант. Ушли и хрен с ними. А мы будем пользоваться их продуктами. Когда одумаются и вернуться будем платить.
На мой век ИТ-шника выпал переход от холодной войны к сотрудничеству с враждебным Западом. Я, с Челябинским Металлургическим Комбинатом, попал в десятку первых кто получал софтвар от ИБМ по цене 3% от той что была у них там на Западе. А до того мы пользовались ворованным КГБ американским, ИБМ-ским, софтом, имея поддержку наших научных институтов и центров которые владели исходными кодами и прекрасно в них разбирались.
Эти времена возвращаются (вернулись), и у нас есть опыт. Надо его испоьзовать.
В году этак 97-ом, 98-ом мои друзья и коллеги из ИБМ представительства в Москве "сватали" меня их американскому боссу, мол парень знает ИБМ мэйнфрэймы, мама не горюй, и у него весь уральский регион его клиенты были. Но боссу не понравился мой английский (да я учил немецкий и в школе и в институте).
В 99-ом я самостоятельно эммигрировал в Канаду. И вот уже полных 25 лет отработал и работаю в канадской компании Ontario Power generation (OPG opg.com если интересно). Работаю на их мэйнфрэймах и с ИБМ-овсой репликацией, которая сделал бы миграцию данных авторов статьи легким путешествием всместо многосложного и не надежного процесса высасанного из пальца Оракл. Кстати в Оракл меня тоже в 98-ом году приглашали. Как раз перед дефолтом августа 98. Не успел. Они тогда тоже сокращались в России. Но оказазлся в Канаде.
ОPG примено половина генерации в Онтарио, хорошее место.
А я в 98м конфигурил телефонные станции и вторично, консультантом по радиорелейкам. Первую продажу 6 радиорелеек сделал за время работы компании (сидели пацаны из МФТИ, у них туговато было с этим профилем, хоть в целом головастые).
И сосед мой, незадолго до дефолта, вдруг говорит: а я в Канаду поеду, мир посмотреть. Ну думаю, странное желание. Через месяц - хоп, дефолт, 750 баксов в зубы (спасибо что зеленью, остальным выдали в рублях по преддефолтному курсе позже) и я свободен.
Посидел в провинции - дело тухлое. Сдал быстренько 6 экзаменов на сертификат админа от M$, помню еще для экономии сдавал по 2, а последний сразу 3 экзамена за день, чтоб меньше ездить в Москву и под рождество в Канаде, зашел в их консульство.
Тетка принимающая заявления, перечеркнула крест накрест мою анкету: "не знаете английского почти, не пройдете!". Я ей: "берите 500 баксов за рассмотрение и точка". Понимал что дело тухлое но тему решил довести до конца чтоб потом не думать "если бы да кабы..."
Парнишка передо мной сачканул, ушел.
Сходил и забыл. Думаю, ну съезжу, мир посмотрю.
В феврале вызов на интервью в начале мая, метнулся курсы по английскому проходить, благо учительница знакомая жила в Лондоне некоторое время. Полтора месяца немного поднатаскала, что то вспомнил. Так то учил с 6 лет, но забыл все напрочь, особенно в ВУЗе, там язык был формальный.
На интервью тоже было смешно - как то само собой повернулось что начал задавать вопросы а в конце резюмировал "когда зайти за визой?"
Как то так, нашару проскочил и в конце 99го заехал.
Знакомый подал в январе 2000го и попал в Канаду только в 2004м, когда я оттуда уже уезжал - нашел ему работу, жилье, сдал вахту, так сказать а сам отвалил.
Есть такой замечательный продукт от ИБМ называемый IBM InfoSphere Data
Боюсь, что для банка в РФ этого продукта сегодня не существует.
Ретроспектива заставила команду по-другому взглянуть на многие моменты:
Вода мокрая
Иногда нужно читать что же за ошибки вам выдаёт перед тем, как проектировать новый велосипед
В общем то полезно, спс, но .. очередная статья про то как смигрировали оракл без бизнес логики с ora2pg, fdw и track-таблицами... и тестированием после взлета😁
Где же реальные миграции каких нибудь банковских АБС с миллионами строк бизнес логики
с разработкой какого нибудь ультра конвевертера plsql в pg/plsql на основе AI, своим CDC, шинами ? Не видно что-то...
А банки никогда и не переведут АБС на Oracle на иную БД. Там же в хранимках вся бизнес-логика, плюсом поставщики АБС все это шифруют. Ну какой банк в здравом уме перейдет с Oracle который 40+ лет пилит БД на решения российких компаний которым от роду 5-10 лет?
Репутационные риски и потери от простоя АБС, а про денежные я умолчу, перекроют все плюшки российких СУБД многократно.
Ошибаетесь. Процесс небыстро, но идёт. Где-то уже перевели.
А зачем в АБС системах столько бизнес логики реализовывали в хранимках, это реально дает какой-то выигрыш? Ну казалось бы база данных это только хранение и извлечение данных, а вся логика на условных Java/C# и пр.
Да, это реально дает выйгрышь во многих местах. Ну представьте себе что нужно посчитать сумму просрочки по кредиту для 10 млн. клиентов, доя чего гонять огромную кучу данных между бд и приложением если все можно посчитать ч самой базе? Приложение просто вызывает код из бд и все.
Насчет перфоманса соглашусь, обратная сторона эта полная зависимость от конкретной СУБД всего бизнеса. Я не участвовал в разработки системы АБС, но участвовал в разработке систем для бэк офиса профессиональных участников торгов (брокеры, управляющие компании, депозитарии и пр), там просто сразу ставились требования поддержки разных СУБД (MSSQL Server, PostgreSQL) и тоже были задачи начиная от дневных клиентских отчетов, отчетов для регуляторов (сотнями тысяч), заканчивая разной аналитикой и пр, и не сказать что бы прочитать необходимые записи из СУБД было самым узким место, а если и было то и хранимки вероятно так же бы просели , но возможно в в банках другие объёмы данных.
Это что-то вроде возгласа облегчения после проделанной работы?
Миграция Левиафана: как удалось перевести базу в 40 ТБ данных на Postgres Pro