На оракле был рак из 2х узлов 4TB RAM 192 ядра 8 сокетов с гипертрейдингом 382 на каждом сервере. На шардмане 19 узлов по 48 ядер (2 сокета, с гирертредингом 96) с 1.5TB RAM. По ресурсам на новом кластере с запасом, но он стоит почти не нагруженный. То есть фактическое потребление ресурсов не то чтобы увеличилось.
А в каком месте не хватает документации по c2g НСПК, на стороне интеграции с НСПК? Я знаю людей в центробанке которые заведуют проектом, могу передать весточку если есть возможность ее предметно сформулировать.
РТЛабс является давним партнером ФК по разработке и эксплуатации, ставит минимальные цены и честно выигрывает контракты на конкурсах без откатов. На самом деле мы работаем четко в рамках зафиксированных возможностей ФК и пытаемся поставить максимум возможного в рамках их не гибких бюджетов. Поскольку мы ничего не завышаем нет ни торга ни отскоков, потому что отскакивать нам собственно некуда, цены и так минимальные.
Почему минимальные? Потому что нам важнее крепкое долгосрочное партнерство и репутация, чем сиюминутная выгода. Мы же дочка Ростелекома как-никак, у нас стратегические цели и подходы в безусловном приоритете.
Как показывает печальная практика совмещать апгрейд архитектурный системы с крупной миграцией всегда плохая рискованная затея.
Даже несмотря на то, что иногда кажется это единственный момент для этого.
В это проекте мы даже пытаясь этого не делать, даже то немного концептуально переписанное что включили, после первого переключения (я упоминал первый не до конца удачный запуск) отключили и откатили на стабильную старую версию со старым подходом чтобы завершить миграцию.
Не смотря на то, что софт который не взлетел был не наш, а нашего субподрядчика, все равно было очень больно.
К сожалению когда архитектура системы развивается год за годом без переосмысления получаются вот такие монстры, я согласен. Есть некоторая вероятность, что мы такое переосмысление запустим в следующем году с ФК.
Хотели бы собрать рабочую группы для выработки концептуально новой версии форматов? Это могло бы быть очень интересно!
Shardman уже взрослый и стабильный и это наша отечественная разработка. Вы бы хотели увидеть на рынке РФ нашу собственную с первого байта БД которая готова впитать 200ТБ данных?
Активные начисления в данный момент не отделены от архива, потому что такое разделение повлечет за собой переработку всей системы, ФК пока что не готовы на это идти.
Была идея переложить все начисления (включая активные) в DataLake, а в БД держать исключительно только активные. Это открыло бы большие возможности для анализа и снизило бы количество данных в активной базе. Но пока что это остается только проектом.
Вы знаете не смотря на то, что Казначейство "ворочяет" триллионами наших суверенных финансов, финансирование развитийных проектов у них проходит весьма сдержанно и осознанно. Сейчас в подобной оптимизации большой потребности нет и по этому ФК в это не вкладываются.
Второй момент: первоначально в Оракл база данных была сильно нормализована и каждый атрибут каждого начисления и каждого платежа хранился отдельной записью. Ну и записей таких на примерно 13 миллиардов начислений и платежей (Вы правы в порядках) было несколько сотен миллиардов строк атрибутов. Ну и конечно же индексы атрибутов нещадно тормозили. По итогу мы эту нормализацию убрали и положили атрибуты в jsonb прямо в объекты начислений и платежей. Места мы не сэкономили, но бутылочное горлышко убрали.
А какое количество данных и на каких мощностях вы реконсилировали в продакшне? Поставили ли этот подход на поток, как отображаете результаты реконсиляции?
Я думаю можно было еще указать в статье, что при наличии адаптеров при расхождении, можно потом по id этих записей выбрать их из адаптеров и глазами на них посмотреть (если сделать в адаптере поддержку не только выборку по диапазону дат, но еще и по массиву id).
Информация
В рейтинге
488-й
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
На оракле был рак из 2х узлов 4TB RAM 192 ядра 8 сокетов с гипертрейдингом 382 на каждом сервере. На шардмане 19 узлов по 48 ядер (2 сокета, с гирертредингом 96) с 1.5TB RAM. По ресурсам на новом кластере с запасом, но он стоит почти не нагруженный. То есть фактическое потребление ресурсов не то чтобы увеличилось.
А в каком месте не хватает документации по c2g НСПК, на стороне интеграции с НСПК? Я знаю людей в центробанке которые заведуют проектом, могу передать весточку если есть возможность ее предметно сформулировать.
РТЛабс является давним партнером ФК по разработке и эксплуатации, ставит минимальные цены и честно выигрывает контракты на конкурсах без откатов. На самом деле мы работаем четко в рамках зафиксированных возможностей ФК и пытаемся поставить максимум возможного в рамках их не гибких бюджетов. Поскольку мы ничего не завышаем нет ни торга ни отскоков, потому что отскакивать нам собственно некуда, цены и так минимальные.
Почему минимальные? Потому что нам важнее крепкое долгосрочное партнерство и репутация, чем сиюминутная выгода. Мы же дочка Ростелекома как-никак, у нас стратегические цели и подходы в безусловном приоритете.
Как показывает печальная практика совмещать апгрейд архитектурный системы с крупной миграцией всегда
плохаярискованная затея.Даже несмотря на то, что иногда кажется это единственный момент для этого.
В это проекте мы даже пытаясь этого не делать, даже то немного концептуально переписанное что включили, после первого переключения (я упоминал первый не до конца удачный запуск) отключили и откатили на стабильную старую версию со старым подходом чтобы завершить миграцию.
Не смотря на то, что софт который не взлетел был не наш, а нашего субподрядчика, все равно было очень больно.
К сожалению когда архитектура системы развивается год за годом без переосмысления получаются вот такие монстры, я согласен. Есть некоторая вероятность, что мы такое переосмысление запустим в следующем году с ФК.
Хотели бы собрать рабочую группы для выработки концептуально новой версии форматов? Это могло бы быть очень интересно!
Shardman уже взрослый и стабильный и это наша отечественная разработка. Вы бы хотели увидеть на рынке РФ нашу собственную с первого байта БД которая готова впитать 200ТБ данных?
Спасибо за вопрос! Тут есть два момента.
Активные начисления в данный момент не отделены от архива, потому что такое разделение повлечет за собой переработку всей системы, ФК пока что не готовы на это идти.
Была идея переложить все начисления (включая активные) в DataLake, а в БД держать исключительно только активные. Это открыло бы большие возможности для анализа и снизило бы количество данных в активной базе. Но пока что это остается только проектом.
Вы знаете не смотря на то, что Казначейство "ворочяет" триллионами наших суверенных финансов, финансирование развитийных проектов у них проходит весьма сдержанно и осознанно. Сейчас в подобной оптимизации большой потребности нет и по этому ФК в это не вкладываются.
Второй момент: первоначально в Оракл база данных была сильно нормализована и каждый атрибут каждого начисления и каждого платежа хранился отдельной записью. Ну и записей таких на примерно 13 миллиардов начислений и платежей (Вы правы в порядках) было несколько сотен миллиардов строк атрибутов. Ну и конечно же индексы атрибутов нещадно тормозили. По итогу мы эту нормализацию убрали и положили атрибуты в jsonb прямо в объекты начислений и платежей. Места мы не сэкономили, но бутылочное горлышко убрали.
Не могли бы вы утонить что вы имеете в виду более подробно?
На данном проекте нет. В Госуслугах смотрели на него, решение понравилось, цена не понравилась.