Об импортозамещении в IT

На смену вирусологам и специалистам по внеземным формам жизни пришли военные эксперты и финансисты. Я не умею рассуждать ни на ту, ни на другую тему, зато немного могу порассуждать на другую модную тему – импортозамещение в сфере информационных технологий.
Банковское программное обеспечение в России всегда было своё. Настолько своё, что даже Oracle, гордящийся своей интеграцией сверху до низу, от собственных процессоров SPARC до собственных банковских систем FlexCube и OBP, в России делал ставку на партнёрство с ЦФТ – с той самой фирмой, выпускавшей красивые настенные календари. Только вот платформа для всех банковских приложений – базы данных, серверы приложений, – были исключительно импортными, преимущественно от «die Große Treuke» – Oracle, IBM, Microsoft.
Казалось бы, в чём проблема перейти, например, с Oracle на PostgreSQL? Попытаюсь ответить на этот вопрос, по возможности без специальной терминологии.
Функциональные возможности. Здесь между двумя платформами практически паритет. Если поставить задачу автоматизировать что угодно, то лучше получится сделать это на той платформе, которую лучше знает разработчик. Нет таких вещей, которые в Oracle сделать можно, а в PostgreSQL – нет, скорее даже наоборот.
Производительность. Здесь, как ни странно, тоже паритет. В сети можно найти множество нагрузочных тестов, и побеждает то одна, то другая платформа. Секрет прост: побеждает та платформа, под которую система написана изначально. Несмотря на одинаковую идеологию, внутри платформы очень разные, и при разработке это надо учитывать, как бы рекламные буклеты ни обещали «независимость от платформы». Давным-давно, когда я смотрел гонки серии DTM, я заметил, что на одних трассах всегда побеждают Audi, а на других – Mercedes, хотя разница между ними куда меньше, чем между Oracle и PostgreSQL.
Возможность вертикального масштабирования. Пусть, например, у нас есть двухъядерный сервер, который выполняет N транзакций. Четырёхъядерный сервер, скорее всего, сможет выполнять 2N транзакций, восьмиядерный – уже 3,5N, шестнадцатиядерный – 6N и так далее. В конце концов увеличение мощности сервера приведёт только к ухудшению работы. Так вот, в Oracle заложен ряд крайне удачных архитектурных решений, благодаря чему его способность к вертикальному масштабированию существенно лучше. Казалось бы, победа, но нет.
Во-первых, стоимость сервера с какого-то момента начинает расти быстрее производительности, и до этого момента PostgreSQL масштабируется вполне нормально. Во-вторых, на свете почти нет компаний, которым нужен самый мощный сервер. Либо компания маленькая, и ей достаточно маленького сервера, либо компания очень большая, и даже самых мощных серверов нужно много. А если их всё равно много, то вместо N самых больших можно взять 4N обычных, обойдётся значительно дешевле. Так что сейчас все так или иначе работают над горизонтальным масштабированием, то есть делением приложения на много относительно мелких частей с мелкими базами, и возможность вертикального масштабирования уже не играет решающей роли.
Поддержка. В отличие от хакера Васи Пупкина, корпоративным пользователям важно иметь возможность обратиться за поддержкой к людям, которые могут действовать за рамками документации – например, править исходный код. За рубежом достаточно давно существуют компании, предоставляющие коммерческую поддержку PostgreSQL – например, EnterpriseDB или 2nd Quadrant. Сегодня такие компании есть и в России – например, Postgres Professional и Сбербанк-Технологии.
Удобство администрирования и мониторинга. Всем известно, что лучший инструмент администратора БД – это командная строка, которая одинаково хороша у обеих платформ. Но когда у тебя команда из 10 администраторов поддерживает 20 тысяч баз, управляться с командной строкой становится трудновато. «Сообщество» никогда не сделает ничего стоящего, потому что не знает проблем и задач, стоящих перед службами сопровождения действительно больших компаний. Сегодня компании вкладываются в создание инструментов администрирования PostgreSQL, но пока Oracle со своим Enterprise Manager’ом на корпус впереди.
Отказоустойчивость. Здесь тоже более или менее паритет. Схемы обеспечения отказоустойчивости у обеих платформ одинаковы с точностью до названия товарных знаков.
Резервное копирование. И у Oracle, и у PostgreSQL есть утилиты командной строки, полностью закрывающие потребность в резервном копировании. Отличие в том, что утилита Oracle интегрирована со всеми известными системами управления резервного копирования. Плюс у Oracle есть шкаф под названием ZDLRA («задрала»): включаешь его одним шнуром в силовую сеть, другим – в сеть передачи данных и получаешь готовую систему резервного копирования для всех баз, сколько бы их не было. Постгресу до такого дзена ещё далеко, здесь конкурент впереди на два корпуса.
Безопасность. Традиционно безопасности баз данных уделялось немного внимания, ведь хакеры с ней практически не взаимодействуют. В какой-то момент Oracle догадался, что от администраторов тоже может исходить опасность, и сделал защиту данных от администратора. В PostgreSQL такая защита тоже появилась, но пока она входит лишь в коммерческие дистрибутивы, в основной ветки «ванильного» Постгреса её нет. Да и непонятно, нужна ли она там.
Сообщество разработчиков. Казалось бы, у «свободной»
платформы должно быть большое сообщество. Однако и здесь, как ни
странно, Oracle впереди. Любой желающий может скачать сервер себе и
попробовать. Хитрость в том, что для свободного скачивания доступны
версии X.X.0.0, совершенно не пригодные к промышленному
использованию. А все патчи и фиксы – за деньги в рамках
лицензионного соглашения. Объём материалов в сети и на полках
книжных магазинов поражает. Думаю, не будет преувеличением сказать,
что Oracle тут чемпион (и красно-белая расцветка логотипа как бы
намекает). Но и с PostgreSQL ситуация постепенно выправляется.
Пользуясь случаем, рекомендую книжку одного из лучших отечественных специалистов,
известного в ЖЖ как egorius
Подводя итог, скажу, что если отбросить фактор стоимости и
геополитические риски, то Oracle – пока ещё СУБД №1 в мире (что бы
на эту тему ни думал товарищ daniel_grishin). Но оба фактора
таки играют огромную роль, и миграция на PostgreSQL идёт весьма
впечатляющими темпами, причём не только в России.
Такие дела.
|
</> |