Comments 22
Не рассматривали ydb как альтернативу Postgres?
Большинство кластерных баз данных, которые имеют встроенное шардирование, не предоставляют строгой консистентности при записи и стерилизации транзакций, говоря техническим языком
ACID, она и в распределённом режиме исполнения кода обеспечивала строгую стерилизацию транзакций. Это значит: если мы что-то записываем в базу данных, оно либо точно записалось и тут же доступно для чтения, либо не записалось — и нигде не осталось мусора и несогласованных данных.
Автопроверка орфографии - зло. "Стерилизация" транзакций
Сериализация, видимо, имелась в виду она, не относится к согласованности распред. систем. Это уровень изоляции ACID.
То, что далее описано, это смешение, атомарности (или записалось или нет, без мусора) с согласованностью (тут же доступно для чтения) и это не про сериализацию. Надо б разлепить, а то ничего тут непонятно.
Ну и уровень согласованности, которого добились интересно. Линеаризуемость, секвенчуал или лимитед эвенчуал, там, например?
Именно она аккумулирует все назначенные людям и компаниям платежи и контролирует их оплату, сверяя платёжные поручения банков с начислениями.
Как вы думаете, много ли там начислений? А платежей? Сотни миллиардов.
Реально каждый житель получает в год в среднем пару штрафов, а также налогов. То есть миллиард условно актуальных начислений - платежей. Остальное - архив...
Спасибо за вопрос! Тут есть два момента.
Активные начисления в данный момент не отделены от архива, потому что такое разделение повлечет за собой переработку всей системы, ФК пока что не готовы на это идти.
Была идея переложить все начисления (включая активные) в DataLake, а в БД держать исключительно только активные. Это открыло бы большие возможности для анализа и снизило бы количество данных в активной базе. Но пока что это остается только проектом.
Вы знаете не смотря на то, что Казначейство "ворочяет" триллионами наших суверенных финансов, финансирование развитийных проектов у них проходит весьма сдержанно и осознанно. Сейчас в подобной оптимизации большой потребности нет и по этому ФК в это не вкладываются.
Второй момент: первоначально в Оракл база данных была сильно нормализована и каждый атрибут каждого начисления и каждого платежа хранился отдельной записью. Ну и записей таких на примерно 13 миллиардов начислений и платежей (Вы правы в порядках) было несколько сотен миллиардов строк атрибутов. Ну и конечно же индексы атрибутов нещадно тормозили. По итогу мы эту нормализацию убрали и положили атрибуты в jsonb прямо в объекты начислений и платежей. Места мы не сэкономили, но бутылочное горлышко убрали.
Как вам удалось понизить стоимость этой работы, чтобы уменьшить бюджетные расходы и снизить коррупционный риск?
Не могли бы вы утонить что вы имеете в виду более подробно?
В статье описана большая и серьёзная задача. Обычно за решение такой задачи требуют огромных денег. При огромных расходах возникают две проблемы: во-первых, как уменьшить эти расходы хотя бы в десять раз, а во-вторых, как сократить количество откатов и взяток при согласовании таких расходов.
До сих пор единственным решением для этих проблем было резкое, многократное уменьшение стоимости работ. С одной стороны, это помогает сократить бюджетные расходы, а с другой стороны, уменьшает и сумму процентного отката.
Отсюда и возникает вопрос, как вам удалось во много раз понизить стоимость всей этой работы? Как удалось перейти от первоначальной, завышенной стоимости — к той небольшой, которую согласился оплачивать заказчик?
РТЛабс является давним партнером ФК по разработке и эксплуатации, ставит минимальные цены и честно выигрывает контракты на конкурсах без откатов. На самом деле мы работаем четко в рамках зафиксированных возможностей ФК и пытаемся поставить максимум возможного в рамках их не гибких бюджетов. Поскольку мы ничего не завышаем нет ни торга ни отскоков, потому что отскакивать нам собственно некуда, цены и так минимальные.
Почему минимальные? Потому что нам важнее крепкое долгосрочное партнерство и репутация, чем сиюминутная выгода. Мы же дочка Ростелекома как-никак, у нас стратегические цели и подходы в безусловном приоритете.
Слышали о ГИС ГМП? Скорее всего, мало кто слышал.
Слышал и каждый раз корежит когда приходится работать с ней.
"Вы не обращайте внимания. тут просто копченую рыбу заворачивали и следы на спецификации".
Поля в которых "вот это поде заполняет эти, если эти поля такие". "тут будет "1111-11-11", если 106 = "0, а если 106='ТП' то то 107 вот такого странного формата (типа если начинается с "ЗД", то дальше дата такого формата, а если с "КВ", то дальше месяц, а если с ..)" и т.д. и т.п.
Банки плачут, но пытаются жевать этот кактус. С магией настройки/описания данных ГИС ГМП.
Какой нафиг поиск в БД. Какое структруриование данны.. не.. не слышали.
Даже СБП с C2G от этого фактически открестились "мы тут не при чем. мы только данные передаем".
Мне всегда очень хочется взглянуть в глаза тех людей которые бессистемно ляпали заплату на заплату и придумывали эти дикие форматы полей в ГИС ГМП.
Студентов ПТУ нанимали за еду?
Как ни Гос. ПО, так такая гадость... (Цифровой Рубль пошел той де кривой архитектурной дорожкой)
Потому что при проектировании натянули ужа на ежа. Попытка скрестить OLTP и OLAP в рамках классической РСУБД всегда приводит к таким монстрам.
При переезде могли бы и учесть ошибки прошлых лет и построить архитектуру Data Lakehouse и golden layer с витринами на РСУБД. Было бы на порядки проще масштабировать в петабайты, развивать функциональность и постепенно мигрировать поставщиков данных на чистую архитектуру, без тайных знаний по кодированию данных на стороне клиента.
Стадно. Клонировать кривую архитектуру 1:1, а не реализовывать бизнес-требования к системе.
Так обычно бывает, когда заказчик дает не требования, а требует решение в своей архитектуре. Но другой, заказной разработки по госконтрактам у нас для вас нет. Все ушли в продуктовую…
Как показывает печальная практика совмещать апгрейд архитектурный системы с крупной миграцией всегда плохая рискованная затея.
Даже несмотря на то, что иногда кажется это единственный момент для этого.
В это проекте мы даже пытаясь этого не делать, даже то немного концептуально переписанное что включили, после первого переключения (я упоминал первый не до конца удачный запуск) отключили и откатили на стабильную старую версию со старым подходом чтобы завершить миграцию.
Не смотря на то, что софт который не взлетел был не наш, а нашего субподрядчика, все равно было очень больно.
К сожалению когда архитектура системы развивается год за годом без переосмысления получаются вот такие монстры, я согласен. Есть некоторая вероятность, что мы такое переосмысление запустим в следующем году с ФК.
Хотели бы собрать рабочую группы для выработки концептуально новой версии форматов? Это могло бы быть очень интересно!
К сожалению, мест (и не только в ГИС ГМП) хотелось бы изменить много, а физически времени на все нет (иногда хоть ночью работай).
Мы, как вендоры, более менее научились работать с этими сакральными знаниями по форматам. Но тут сверху наложилась еще "понимание" НСПК в C2G и...
И банки, которые хотели в своих ДБО сделать C2G "немного" в шоке от запутанности документаций или просто отсутствия ее.
Как вы думаете сколько проектов C2G еще не взлетело или вообще не взлетит (в основном по этой причине)? Открою "секрет" много.
P.S. Впрочем, с ЦР еще веселее. Хотя вроде бы такого архитектурного бэкграунда не имеет, а уже уродец уродцем и без документации (понятной).
А в каком месте не хватает документации по c2g НСПК, на стороне интеграции с НСПК? Я знаю людей в центробанке которые заведуют проектом, могу передать весточку если есть возможность ее предметно сформулировать.
нет уж. не буду испорченным телефоном между банками и..
Мы поступили проще. Как НСПК.
Просто говорим "вот этот параметр возвращается от НСПК на запрос по QRC C2G, а вот эти ЭБД XXX и дальше вопросы не к нам как они соотносятся с ГИС ГМП данными и как интерпретировать ГИС ГМП поля. Мапинг, транспорт и прочее мы обеспечили."
Свои реализации ГИС ГМП - это одно (делаем), а помогать сакральными знаниями (не факт что правильными, полученными зачастую экспериментальным путем) - это нарываться на проблемы типа "вы нам так сказали, а у нас не работает. Скажите почему". Доброе дело зачастую наказуемо.
Понятно, так и запишем. Нет пока в РФ СУБД. Все едут на PostgreSQL (Pro) с шардированием.
Приходится делать танцы.
А сколько было ядер на оракле (single instance или RAC/Exadata ?) и сколько стало на шардмане с учетом всех шардов и их реплик ?
На оракле был рак из 2х узлов 4TB RAM 192 ядра 8 сокетов с гипертрейдингом 382 на каждом сервере. На шардмане 19 узлов по 48 ядер (2 сокета, с гирертредингом 96) с 1.5TB RAM. По ресурсам на новом кластере с запасом, но он стоит почти не нагруженный. То есть фактическое потребление ресурсов не то чтобы увеличилось.
Миграция ГИС ГМП: как мы перенесли сотни терабайт данных, не останавливая федеральный ресурс