Комментарии 30
Снимаю шляпу.
Если абстрагироваться, можно было разделить данные по разным базам?
Если база будет расти дальше, то с каким темпом? Упрется в какой то потолок в обозримом будущем?
В одном проекте (репозиторий на основе базы) с ростом хранилища примерно 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% от той что была у них там на Западе. А до того мы пользовались ворованным КГБ американским, ИБМ-ским, софтом, имея поддержку наших научных институтов и центров которые владели исходными кодами и прекрасно в них разбирались.
Эти времена возвращаются (вернулись), и у нас есть опыт. Надо его испоьзовать.
Не надо воровать. Надо свое разрабатывать. В свое время во времена Хрущева, вместо того, чтобы разрабатывать свои процессоры, мы начали воровать схемы чужих процессоров. Это привело к уничтожению своей школы со всем вытекающим.
То, что ушли западные вендоры - это шанс развить свою отрасль, и надо этот шанс использовать по максимуму.
Я обеими руками за создание своего. Но к сожалению СССР/Россия слишком рано начали копировать, и просто воровать западные решения. Возможно это было обоснованно тогдащней обстановкой и реальной опасностью проиграть войну не имея передового уровня в технологиях.
Ситуация с тех пор существенно ухудшилась со всех сторон. С одной технологии развились очень сильно и начинать с нуля значит отстать навсегда. С другой угроза войны как никогда реальна. По сути мы вернулись в начало 40-х.
Если посмотреть на современное российское ИТ оно все состоит из западных технологий. "Свое" это локализованное западное.
А воровать и спользовать западные технологии (например МФ и z/OS) это еще надо уметь и опыт подсказывает что возвращение, например, ИБМ в будущем не создаст особых проблем, но облегчит переход с ворованного на лицензированное. А как оно сечас с этим (МФ и z/OS), то и переходить то с чего будет. Ну сернется ИБМ в Россию, ну поймут российские ИТ-шники или их начальники что МФ это здорово. Но компетенций то нет.
Когда ИБМ пришел в СССР во время перестройки у нас был свой ЕС ЭВМ и ИБМ-вские, ворованные ОС, базы данных и т.д.. Без проблема купили лицензированное ПО и перешли. Потому что были компетенции. А сечас их нет. И это плохо. В этом мы отстаем от всего мира, не только от США. Китай, Индия, ЮАР!!!! ("IBM Z mainframe debuts in SA" https://it-online.co.za/2017/08/17/ibm-z-mainframe-debuts-in-sa/), Бразилия весь BRICS кроме России использует ИБМ МФ, а мы нет. Смешно и стыдно.
В году этак 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
Боюсь, что для банка в РФ этого продукта сегодня не существует.
После DB2 и Oracle использовать PG больно, очень больно на реальных задачах. Я переводил большие системы с Оракл/MS/Sybase на DB2, с MS на Oracle, и несколько небольших с Oracle на PG. Мало перевести, нужно все это еще и сопровождать... А вот об этой части у PG - ж...
Но и мышом с помощью только Infosphere (как там оно теперь называется), переехать - миф. Да, 90 процентов работы на ней, но косяков хватает для доработок напильником. И пользовательские интерфейсы у МежДелМаша это вечная жесть.
Сценарий миграции в статье описан примитивный, без обид.
Ретроспектива заставила команду по-другому взглянуть на многие моменты:
Вода мокрая
Иногда нужно читать что же за ошибки вам выдаёт перед тем, как проектировать новый велосипед
В общем то полезно, спс, но .. очередная статья про то как смигрировали оракл без бизнес логики с ora2pg, fdw и track-таблицами... и тестированием после взлета😁
Где же реальные миграции каких нибудь банковских АБС с миллионами строк бизнес логики
с разработкой какого нибудь ультра конвевертера plsql в pg/plsql на основе AI, своим CDC, шинами ? Не видно что-то...
А банки никогда и не переведут АБС на Oracle на иную БД. Там же в хранимках вся бизнес-логика, плюсом поставщики АБС все это шифруют. Ну какой банк в здравом уме перейдет с Oracle который 40+ лет пилит БД на решения российких компаний которым от роду 5-10 лет?
Репутационные риски и потери от простоя АБС, а про денежные я умолчу, перекроют все плюшки российких СУБД многократно.
Ошибаетесь. Процесс небыстро, но идёт. Где-то уже перевели.
А зачем в АБС системах столько бизнес логики реализовывали в хранимках, это реально дает какой-то выигрыш? Ну казалось бы база данных это только хранение и извлечение данных, а вся логика на условных Java/C# и пр.
Да, это реально дает выйгрышь во многих местах. Ну представьте себе что нужно посчитать сумму просрочки по кредиту для 10 млн. клиентов, доя чего гонять огромную кучу данных между бд и приложением если все можно посчитать ч самой базе? Приложение просто вызывает код из бд и все.
Насчет перфоманса соглашусь, обратная сторона эта полная зависимость от конкретной СУБД всего бизнеса. Я не участвовал в разработки системы АБС, но участвовал в разработке систем для бэк офиса профессиональных участников торгов (брокеры, управляющие компании, депозитарии и пр), там просто сразу ставились требования поддержки разных СУБД (MSSQL Server, PostgreSQL) и тоже были задачи начиная от дневных клиентских отчетов, отчетов для регуляторов (сотнями тысяч), заканчивая разной аналитикой и пр, и не сказать что бы прочитать необходимые записи из СУБД было самым узким место, а если и было то и хранимки вероятно так же бы просели , но возможно в в банках другие объёмы данных.
Мне приходят на ум эти причины.
Они начинались давно. Некоторые ещё в прошлом веке. А тогда у Oracle была политика - база до 4Гб вообще коммерчески бесплатная. И многие, кто начинал, влезали в этот объём.
Программисты на java были дороже.
Микросервисная архитектура была неизвестна.
Ну а потом подсели на вендора.
То что не видно не значит что этого нет :). Мы мигрировали не АБС конечно, но ERP/MES систему в которой вся бизнес логика была на PL/SQL (порядка 4 тыс пакетов) по итогам конвертации получилось больше 500 тыс строк кода. И да такое конечно не через ora2pg делается у нас был свой инструмент для конвертации кода (без всякого AI только православный yacc), и сам код под Oracle пришлось адаптировать там где автоматическая конвертация не справлялась. Думаю и АБС таким же образом можно перевести тут дело не сколько в коде на сервере сколько в объемах и дальнейшей эксплуатации ибо нюансов много и обычно да же после хорошего тестирования оно все уже под нагрузкой начинает лезть.
Это что-то вроде возгласа облегчения после проделанной работы?
Подскажите, а что за железо сейчас под pg?
Тогда подключилась команда Postgres Professional и по рекомендации для стабилизации работы остались на двух NUMA-нодах, что помогло. Перед выходом в PROD задействовали все NUMA-ноды.
непонятно написано. Вы заменили 16-сокетный сервер на 8-сокетный и стало работать быстрее. Рекомендация была в том, чтобы вы вернули 16-сокетный и отключили вторую системную плату, чтобы потом ее подключить?
При интенсивном обновлении одной и той же строки (до 300–500 раз в секунду) узким местом стал HOT Update. Внутренняя очистка генерировала очень длинные цепочки «мёртвых» строк.
С помощью команды Postgres Professional решили создать индекс на одно из изменяемых полей. Это помогло: мы отключили внутристраничную очистку, так как одним из условий её работы является как раз отсутствие индексов на обновляемых полях.
непонятно написано. Внутристраничная очистка очищает место в блоке, а не генерирует цепочки. Может быть написать пример создания индекса и таблицы, может новый индекс стал использоваться для доступа к актуальной версии строки. Если просто отключить внутристраничную очистку, то число мертвых версий строк не станет меньше и очистится только при следующем вакуумировании.
На период стабилизации отключили мониторинг pgpro_stats_statements в пользу ванильного pg_stats_statements из-за очень больших накладных расходов.
это инересно! На ванильном тоже с этим сталкиваются и чтобы устранить даже небольшие накладные расходы даже добавили параметр pg_stat_statements.sample_rate. Может быть и в pgpro_stat_statements есть аналогичный параметр
Ошибка лечилась простой настройкой Foreign Data Wrapper: ALTER SERVER oracle_fdw OPTIONS (SET isolation_level 'read_committed'); (по умолчанию serializable).
это самое интересное в статье! Не думал, что в oracle_fdw по умолчанию стоит SERIALIZABLE. Хорошо, что в postgres_fdw такого нет. Прочел, что Лоуренс Альбе поставил потому, что подумал, что для обслуживания одного запроса с внешней таблицей, планировщик может отправить в Oracle Database несколько запросов.
При интенсивном обновлении одной и той же строки (до 300–500 раз в секунду) узким местом стал HOT Update. Внутренняя очистка генерировала очень длинные цепочки «мёртвых» строк.
С помощью команды Postgres Professional решили создать индекс на одно из изменяемых полей. Это помогло: мы отключили внутристраничную очистку, так как одним из условий её работы является как раз отсутствие индексов на обновляемых полях.
Тоже не понял этот момент. Цепочки HOT-обновлений могут генерироваться только внутри одного блока и не могут выходить за его пределы. Когда места в блоке не хватает, то в момент следующего update будет выполняться внутристраничная очистка, которая должна освободить место. Возможно проблема была именно в ощутимом лаге в момент чистки цепочки HOT-chain во время апдейта, в моём понимании могло помочь уменьшение fillfactor таблицы. Но то, что поддержка неиспользуемого индекса обходится дешевле, чем чистки мертвых строк в цепочке апдейтов внутри одного блока, звучит очень неправдоподобно и противоречит концепции HOT-update.
Скорее всего, при таком интенсивном обновлении строки, в системе были другие активные транзакции, которые как раз препятствовали внутристраничным очисткам, т.к. могла нарушится целостность, ведь формально каким-то транзакция должны быть видны некоторые промежуточные версии. Но в этом случае HOT-chain прерывается, и с обновлением строки обновится и индекс, поэтому указатель на новую версию строки в индексе тоже будет.
Вероятно, проблема была в чём-то другом. Но интересно было бы разобраться.
Миграция Левиафана: как удалось перевести базу в 40 ТБ данных на Postgres Pro