Комментарии 33
Снимаю шляпу.
Если абстрагироваться, можно было разделить данные по разным базам?
Если база будет расти дальше, то с каким темпом? Упрется в какой то потолок в обозримом будущем?
В одном проекте (репозиторий на основе базы) с ростом хранилища примерно 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 процентов работы на ней, но косяков хватает для доработок напильником. И пользовательские интерфейсы у МежДелМаша это вечная жесть.
Сценарий миграции в статье описан примитивный, без обид.
Есть аналогичный БЕСПЛАТНЫЙ symmetricDS https://symmetricds.org/
Принцип тот же, на основе триггеров. Все те же возможности: начальная загрузка, синхронизация и многое другое
Ретроспектива заставила команду по-другому взглянуть на многие моменты:
Вода мокрая
Иногда нужно читать что же за ошибки вам выдаёт перед тем, как проектировать новый велосипед
В общем то полезно, спс, но .. очередная статья про то как смигрировали оракл без бизнес логики с 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 прерывается, и с обновлением строки обновится и индекс, поэтому указатель на новую версию строки в индексе тоже будет.
Вероятно, проблема была в чём-то другом. Но интересно было бы разобраться.
Запросы с проверкой FK стали одними из самых тяжёлых. Проверка FK (SELECT 1 FROM X WHERE id = Y FOR NO KEY UPDATE) блокировала строки и при большом количестве параллельных транзакций генерировала мультитранзакции, включающие все активные ID транзакций, что создавало огромный оверхед.
Опять же по рекомендации Postgres Professional, на особо популярных таблицах от FK пришлось отказаться. Позже выяснилось, что это поведение является багом, который был отдан в доработку.
можно подробнее про баг: баг в ванильном PostgreSQL или Postgres Pro и в чём баг выражается? Это интересно!
Миграция Левиафана: как удалось перевести базу в 40 ТБ данных на Postgres Pro