Исследование: российские госкомпании закупили программы американской Oracle на 13 млрд рублей вопреки импортозамещению Статьи редакции
Среди крупнейших заказчиков — «Сбербанк», «Ростелеком», ФНС и ЦБ.
- В 2018 году российские госкомании и госструктуры потратили на лицензии и услуги техподдержки продуктов американской корпорации Oracle более 13,3 млрд рублей. Об этом говорится в исследовании аналитической компании TAdviser.
- Среди крупнейших заказчиков — «Сбербанк», «Ростелеком», Федеральная налогова служба, Центробанк и «Росатом». Они заключили госконтрактов на 4,9 млрд, 2,5 млрд, 997 млн, 439,7 млн и 348,7 млн рублей соответственно, посчитали в компании.
- В TAdviser анализировали данные сайта zakupki.gov.ru, электронных торговых площадок, а также корпоративных сайтов. При этом реальные суммы затрат на продукцию Oracle могут быть выше, поскольку часть закупок могли быть включены в комплексные контракты, отмечают в компании.
- Общая сумма контрактов растёт последние пять лет — в 2014 году показатель составлял 7,17 млрд рублей. При этом количество закупок сокращается: с более чем 550 в 2014 году до 250 в 2018 году.
- Oracle Corporation специализируется на разработке систем для управления базами данных, систем планирования ресурсов предприятия, облачного ПО, а также поставляет серверное оборудование. Компания обслуживает 430 тысяч клиентов в 175 странах.
- С 2016 года в России действуют ограничения для госорганов на покупку иностранного программного обеспечения. Они должны приобретать продукты из реестра отечественного ПО кроме случаев, когда российских аналогов с необходимыми характеристиками нет. Этого же правительство требует от госкомпаний. По данным TAdviser, почти у всех закзчиков заготовлены обоснования невозможности соблюдения этого запрета. Документы при необходимости включаются в материалы закупки.
0
показов
10K
открытий
Я думал сбербанк хранит все данные в тетрадке, которую каждый день переписывает армия теток за 50 лет.
И из за этого только появилась фраза: где открывали карту туда и идите, ведь не успеет же тетка с тетрадкой доехать до филиала где ты щас находишься.
p.s Какие альтернативы защищенныи и быстрым базам в РФ? Да нихрена нет, так как зарубежом инвестируют в технологии, а у нас пилят бабки которые выделяют на разработку чего-то.
PostgreSql
Не совсем... Хоть и есть postgresql pro, в которой работают крутые чуваки и делают полезные вещи, надо понимать, что Oracle не только реляционное хранилище данных, а мощная экосистема, и нельзя просто взять и пересесть с Oracle игры...
Мы (коммерческая контора) планомерно меняем Оракл (как БД) на опенсорсные решения - Postgres, Clickhouse (вообще российская разработка), Elastic Search и т.д.
Бизнес-приложения (такие , как OEBS) - меняются на 1С, опенсорсные решения и собственные разработки - и все как правило начинает работать более предсказуемо.
начинает работать более предсказуемо
Падать с характерным звуком "бля-а-а!"?
до упоминания 1С пост еще имел какое-то право на жизнь
Ладно вам - особых альтернатив бухгалтерии 1С для формирования регламентной отчетности не много.
Поверьте, если бы я хотел собрать классы, я бы не писал про одинэс))
Но факт есть факт - многие зарубежные софтины на порядок кривее русских (хотя русского говна конечно тоже навалом). От того же оебса плюются чуть менее, чем все, у SAPа конский интерфейс, всякий специализированный софт типа AIMS - вообще труба. На их фоне правильно приготовленный 1С для решения точечных задач и с выделенной командой развития - вполне себе ок. Я с 1С вообще не пересекаюсь - мы пилим внутренний софт на Java+NodeJS+Angular7, но мнение коллектива примерно такое. Потом, разрабов на зарубежный ынтырпрайз несравненно сложнее найти, чем под остальное мной перечисленное.
"разрабов на зарубежный ынтырпрайз несравненно сложнее найти"
с этого и стоило начинать, несомненно "программистов 1С" больше на порядок.Всех нормальных программистов пылесосят Яндекс и Мейл, потом идут банки, а остальные...остальные "программисты 1С"
собственный разработки не всегда плюс. Стоит потерять документацию, или вообще забить на нее, как при увольнении сотрудника ответственного за разработку и эксплуатацию сразу настает локальный апокалипсис. У нас так 3 различные самописные системы со схожим функционалом образовались. Ну мы то ладно, маленькая фирмочка, а теперь представьте такую ситуацию на уровне, например ЦБ, уровень раздолбайства то всегда примерно один.
Yes! Let's change Oracle for 1C! Fuck you, Oracle!
да ладно, просто контора решила сэкономить, верно?
да, я это понимаю, и не утверждаю что можно легко взять и съехать, но можно
да и компаниям не запрещено покупать зарубежное ПО, они всего лишь должны обосновать такую необходимость, что сделать не так уж и сложно
— Чем заменить Белаз?
— Да вот детскую лопатку возьмите..
как копать белазом?
Не копать, а носить (вместо возить)
Оракл и постгрес не особенно разной весовой категории! Сопоставлять их вполне можно. Понятно, что коммерческое решение может иметь больше продвинутых фич. Но насколько они полезны заказчику, особенно в сравнении с ценой этого удовольствия - вопрос для обсуждения.
Не особенно разной - так может говорить только тот, кто Оракл видел только на картинке. Не говорите чушь.
Видимо, вы видели его в деле. Поясните плиз - в чем именно (для примера) оракл прям уделывает постгрес, что и сравнить нельзя!
Настолько это разные продукты для совсем разных аудиторий, что даже сравнивать их неловко. Оракл, к слову, это не только база, а еще сотни продуктов для энтерпрайза. Это как сравнить тачку для перевозки и грузовой поезд.
Безусловно под ораклом я имел ввиду их субд. Но конкретных несопоставимых функций я так и не услышал - чем же именно так волшебен оракл, что даже не сравнить. Но вот яндекс на почте вполне себе мигрировал с субд оракл на постгрес.
дело не в альтернативе самой БД, а в продуктах, купленных банками.
есть вендоры ПО (банковского), продукты которых написаны и писались десятилетия под оракл, и не уйти с него никуда и никак, только отказаться от вендора и перейти на другого.
У Сбера есть "таблички", которые по 100 ТБ весят и разнесены на целый кластер. Мускул или постгрис с таким можно подружить, если поработать напильником (как сделал ВК, например). Сбер выбирает готовое решение под свои объемы данных и требования, чтобы ничего не допиливать.
кормят гигантскую армию прогеров, но допиливать ничего не хотят
это сбер
"Велосипеды" в ИТ как бы не приветствуются)) так что тут Сбер прав.
А как же блокчейнбигдатаискуственныйинтеллект? На фоне этого подпилить PostgreSQL, или заказать подпиливание разбирающимся в ней людям, которые в России есть, должно быть раз плюнуть. При условии возврата этого нового кода в апстрим (банально для облегчения его сопровождения) это уже будет не велосипед.
Знаете, как бы то ни было, но в Сбере умные люди всё же есть (и весьма немалое количество), так что попилы в одном месте, а дельное дело - в другом))
С каких пор? Все IT держится на методологии велосипедостроения.
Там где есть риск потерь стараются использовать проверенные решения, а не самопал (велосипед), разве нет?
Там вряд ли вопрос стоит о том, хотят они или не хотят. Скорее всего там есть требования к скорости получения технологии и её надежности. Своё писать зачастую дороже, нежели покупать готовое.
Программисты не нужны (с)
Зачем пилить постгрес или мускуль для работы в кластере? Это вполне типовая установка такого софта - все работает в штатном режиме по документации. Чисто админская задача
Есть очень хорошие обзоры проблем MySQL на Хабре. Например, пост Олега Бунина: https://habr.com/ru/company/oleg-bunin/blog/328458/
Там очень хорошо описано, что с ним не так из коробки при высоких требованиях к объёмам, производительности, безопасности.
Есть на том же Хабре пост, где Яндекс.Почту мигрировали с Oracle на PgSQL: https://habr.com/ru/post/321756/
В конце есть краткое описание фич Оракла, без которых они скучают.
Есть куча других статей и сравнений эксплуатации разных БД на уровне Enterprise решений.
К тому же в соседних комментариях уже объяснили, что у Сбера проблема не только в объёмах данных. Есть ещё и тонна легаси, завязанного на фичи Оракла. Нельзя так просто взять и выкинуть их.
Во второй статье обратите внимание на абзац:
Это — не первая наша попытка избавиться от Oracle. В начале нулевых была попытка переехать на MySQL, она провалилась. В 2007 или 2008 была попытка написать что-то своё, она тоже провалилась. В обоих случаях был провал не столько по технически причинам, сколько по организационным.Если для Яндекса (являющегося изначально IT-компанией) переход является проблемой, то что говорить о банковских структурах.
Затем обратите внимание на следующую реплику:
Всего у нас это заняло 3 календарных года, но мы потратили больше 10 человеко-лет. То есть усилие всей команды довольно внушительное.То есть даже в Яндексе перевод лишь одной части Яндекс.Почты на PostgreSQL удался не с первого раза и занял 10 человеко-лет.
Зачем такие риски Сберу?
Если сберу переводить систему - то да, технические риски проекта есть. Но в итоге общий риск в работе системы снижается: у вас есть весь код системы, и вы никак не привязаны к вендору. Например, завтра вводятся санкции в отношении сбера, и оракл прекращает продавать ей софт и поддержку. Финиш.
А затраты времени как уменьшить? Я ещё раз обращаю внимание, что Яндекс 3 года потратил, чтобы только кусочек системы перевести. Сколько лет понадобится, чтобы весь Сбер перевести на другую базу?
Я просто выдвинул тезис что переход с субд оракла на опенсорс вполне реальна с технической и организационной точки зрения. Зачем это делать с точки зрения бизнеса тоже сказал - например, санкции. Поэтому Сбербанк если захочет - сделает. Возможно, его нужно заставить административно - как в СБП поучаствовать. Все таки это и наша финансовая безопасность - работающие фин системы крупнейшего банка даде под санкциями.
Почитал про опыт яндекса. Особенно по фичам оракла они не скучают, как я уяснил. Проблемы были, но рабочие, и не особенно связанные с самим постгресом - скорее с легаси и организацией проекта.
Просто тут в соседней ветке сказали, что даже сравнивать оракл с потгресом - никак нельзя. Кмк, неверный тезис.
Зачем работать напильником если есть шардирование?
Зачем самому делать ремонт в квартире, если есть отличная методика укладки керамической плитки?
Вот ты сейчас примерно такую хуйню и спросил. Без обид.
Да нет, не хуйня. Скорее хуйней звучит история про таблицу в 100ТБ.
На самом деле они уже сотни петабайт суммарно хранят. Сотня терабайт для Сбера и правда хуйня. Ты прав.
Помню на старой работе, около года назад, один проект хотели включили в базу отечественного по, но его завернули поскольку там был постгис, и пришлось срочно его выпиливать. Хотя в той же астре к примеру есть постгре и постгис. Так что в гос секторе все очень странно.
У Postgres есть ряд родовых травм