Comments 42
БД Енисей забыли.
Так и не понял в чем уникальность Proxima.
Было бы неплохо еще в следующем про ЛИНТЕР, NitrosBase, SoQoL, Глобал (правда, она NoSQL).
Из предложенного надо брать Postgres имхо.
- разумно выстроена. приятно удивляешься что оно действительно способно выполнять озвученный функционал без того чтобы упасть замертво.
- умеет в большие данные
- у вас будет кого нанять\спросить, немало людей с ней работает.
- давно есть фирмы, что предоставляют поддержку\сертификацию
Может быть принижаю остальные альтернативы, но ненамеренно.
А локальных вариантов MySQL/MariaDB нет?
Все что вы описали, мало имеет отношения к российским СУБД. За основу взят продукт с открытым кодом и допилен функционал. Нужно еще вопрос задать, насколько этот функционал нужен.
Если PostgresPro это компания, которая вносит свои патчи в сам Postgres, то есть действительно делает продукт, то что делают остальные?
Могут они предоставить ссылки на пр, апдейты документации и тд? Или только измененный логотип?
Богатый выбор между шестью базами: пять PostgreSQL и одна Firebird. Не упомянуто ни одного исконно российского решения.
а что значит исконно российская? вот например Oracle это исконно американская СУБД? если да то по какому признаку определяется - место регистрации компании или нахождение головного офиса или все сотрудники должны иметь гражданство этой страны?
Это как с айфоном) Собран в китае, но он американский! А если брать аналогию с Россией то значит китайское, а не российское! Пора уже давно выучить желчную пропоганду либерастов и не использовать ее если сам не либераст)
Зы: в случае с Америкой мы даже не можем приплести национальность, ее у них тупо нет.
Я бы определил это по признаку географической принадлежности компании разработчика основной части кода продукта. Например PostgreSQL - американская (институт Беркли), Oracle - американская, СУБД Линтер, tarantool, clickhouse - российские (на что наткнулся в гугле) и т.д.
Значит если "понауехавшие" русские разработчики соберутся толпой в казахстане и напишут прогу то она Казахстанская?
А ядро linux американское? Как бы в него уже не одно 10-ти летие строки кода летят со всего мира)
Если они зарегистрируют компанию в Казахстане и напишут код на основе своих разработок а не форка опенсорса то да.
Где собрано не важно, главное кто придумал и спроектировал.
Можно еще задать вопрос, смогли бы китайцы сделать айфон без эпл? Нет не смогли бы. А смогли бы в Эпл без помощи китайцев? Да смогли бы, но очень дорого бы получилось. Могут ли российские поставщики современных серверов сделать их без помощи китайцев? Нет не смогут, но те компании что проектируют собственные корпуса, систему охлаждения, мат-платы и управляющее ПО можно с чистой совестью считать российскими и их продукт созданным в России. К сожалению, в большинстве случаев разработка заканчивается переклейкой наклеек.
Ну например процессор в айфоне arm, а это Великобритания (китайское независимое представительство мы не берем в расчет), произведен он на оборудывании из Голандии, а оно сделанно с использованием сырья и разработок со всего мира.
Код в айфоне написан индусами, японцами, китайцами, неграми, корейцами, русскими, украинцами и т.п. еще куча кода это openSource.
Давно уже все в мире интернациональное и построенно гражданами мира...
Давайте без космополитизма ;)
Весь код в айфоне написан сотрудниками Apple (Cupertino, CA) за исключением того, что честно указан в разделе Настройки -> Основные -> Правовая информация -> Правовые уведомления (там длинный список).
Вы путаете постиндустриальные государства с развивающимися. Да США и Великобритания практически ничего не производят на сегодняшний момент, но это не значит что они это НЕ могут сделать или производить.
Они отдали материальное производство на outsource, а сами руководят мировой финансовой системой. То есть руководят распределением денег.
Могут ли США сделать IPhone у себя на родине? Конечно могут, ведь все компании и патенты в цепочке так или иначе принадлежат США или его союзникам (Великобритании). Они спокойно могут достроить нежные заводы в США. Станут ли они это делать? Как припрет, так сделают. Даже более того, уже начали.
Это как с историей с "батутом" Рогозина. Захотели США собственные космические челноки - сделали.
Может ли Россия или даже Китай, сам произвести IPhone? Нет не сможет. Китаю еще с 10 лет надо, а Россия похоже уже накрепко осталась на обочине истории. Изменить это сможет разве что война. Но тут такое дело... Еще неизвестно кто в этой войне победит.
А ядро linux американское? Как бы в него уже не одно 10-ти летие строки кода летят со всего мира)
Изначально финское, но это как раз отличный пример свободного ПО созданного в результате коллаборации разработчиков и компаний из разных стран.
А ядро linux американское?
Финское, же!
Не очень понимаю, в чём смысл использования форков постгреса для внешних (относительно разработчиков этих форков) компаний?
Сейчас можно присмотреться к YDB - распределённая реляционная СУБД. Вполне себе российская. В опенсорс вышла в прошлом году. К тому же, по мимо таблиц предлагает ещё и топики. Потенциально, одним решением можно заменить и БД и лог брокер.
Не хватает возможности в рамках одной транзакции писать/читать таблицы и топики, но, думаю, что это вопрос времени и такая возможность появится.
Самому ещё пока попробовать поработать с YDB не довелось, но выглядит интересно.
Их сайт: https://ydb.tech/ru/docs/concepts/
Была в свое время идея миграции чиновников с мерседесов на волги. И даже такая простая миграция не взлетела. Мигрировать большую легаси систему с хранимой логикой с oracle на pg очень сложно, проще переписать заново. А это гигантские затраты прежде всего - времени, не говоря уже о деньгах. Любая миграция упирается в двойной объем работы - разобраться в старом и написать ТЗ + поддерживать старое + написать новое и самое сложное - сравнить и убедиться в эквивалентности.
Уж сколько десятилетий назад учёные мужи твердили миру - отделяйте слой бизнес логики от слоя организации данных. Задолго даже до дядюшки Боба. Ещё в 1985 году авторы SICP на это напирали, как на основную концепцию всего курса. Но нет же. На дворе 2023, а бизнес логика намертво вплетена в СУБД, как грибок, проявляющийся только на ногте на самом деле живёт во всем теле человека.
К вопоосу выбора коммерческой СУБД я бы ещё обязательно добавил:
Год основания компании
Списочная численность сотрудников (чтобы кто-то поддерживал продукт)
Финансовые показатели
Риски по СПАРК
Квантом - в глубоком минусе по прибыли.
Orion soft - 28 сотрудников.
Да-да, конечно, PostgreSQL это риски, ага, ага, есть АЛЬТЕРНАТИВА. Лол
Могу я внятно услышать, чем опасны в санкционном смысле open-source продукты типа Postgres и MariaDB?
Ну навскидку приходит на ум разве что что-то вроде https://www.linux.org.ru/forum/security/16819987
Но на ситуацию с бд это, понятное дело, не натягивается так просто. Явно не уровень безымянного js куска кода
Понял, спасибо.
Согласен, в популярной БД это, конечно, не пройдет. Впрочем, это прекрасно прошло в terraform модулях AWS, где всем рулят украинцы. А это продукт, сравнимый по популярности с PostgreSQL. Причем, один мексиканец сделал PR на удаление ключа putinhuylo, уповав на то, что для политики там не место, но украинцы его отклонили и он до сихпор там: https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/latest?tab=inputs
Так и в чем отличие от "сертифицированного ФСТЭК"? Это что, дает какие-то гарантии, что в продукте вообще нет ошибок? Запрещает установку новых версий (патчей?), пока они не будут сертифицированы, но не факт, что это хорошо.
Я слабо представляю, чтобы более-менее приичная компания скачала апдтейт "из Интернета" и применила на продуктивную БД "не глядя". И проблема из примера выше "вылезет". А более сложные проблем (логические бомбы с отложенным запуском и т.п.) все равно пройдут сертификацию. Только становится непонятно, как поступить.
Пример (правда не из опенсоурсного мира)
"Не менее 330 000 брандмауэров FortiGate все еще не исправлены и уязвимы для CVE-2023-27997 — критической уязвимости в системе безопасности, которая активно эксплуатируются в дикой природе, спустя почти месяц после того, как Fortinet выпустила обновление. Такие неутешительные показатели отразили исследователи Bishop Fox в своем отчете. Они обнаружили почти 490 000 интерфейсов Fortinet SSL-VPN, открытых в Интернете, а по результатам анализа установили, что 69% из них уязвимы. RCE-уязвимость (CVE-2023-27997) имеет оценку CVSS: 9,8 и получила название XORtigate. Она возникает из-за проблемы переполнения буфера кучи в операционной системе FortiOS, которая соединяет все сетевые компоненты Fortinet для их интеграции в платформу Security Fabric поставщика. CVE-2023-27997 позволяет злоумышленнику, не прошедшему проверку подлинности, удаленно выполнять код на уязвимых устройствах с интерфейсом SSL VPN, открытым в Интернете. Fortinet устранила уязвимость 11 июня, прежде чем публично раскрыть ее, выпустив версии прошивки FortiOS 6.0.17, 6.2.15, 6.4.13, 7.0.12 и 7.2.5, а также признав эксплуатацию уязвимостей в таргетированных атаках, направленных на госсектор, производство и важные сектора инфраструктуры. Исследователи полагают, что несмотря на то, что 153 414 обнаруженных устройств были обновлены до исправленной версии FortiOS, многие из общедоступных устройств Fortinet не получали обновлений в течение последних восьми лет, работая под управлением FortiOS версий 5 и 6. Причем эти устройства уязвимы для нескольких критических уязвимостей с общедоступными PoC, не говоря уже о том, что их поддержка уже давно закончилась. Впрочем, повторяться не будем, столь негативные тренды наблюдаем не первый год - выводы все сделают сами."
Допустим обнаружилась в исходном коде PostgreSQL, на котором сделаны "сертифицированные версии" что-то страшное. Ну как в openssl в свое время. И что, не фиксить баг, пока не пройдет цикл сертификации, даже если окажется, что в некоторых ситуациях, при превышении БД определенного размера, данные модифицируются несколько неожиданным образом?
Ну т.е. я могу понять "готов платить за оперативную и качественную техподдержку, уровень которой существенно выше, чем собственных специалистов". Но это не про "готов платить из-за санкционных рисков опенсорсного PostgreSQL".
Отличный вопрос. Ответить на него однозначно трудно. Что мы должны всегда учитывать . PostgreSQL разрабатывается глобальным сообществом(в которое входят и специалисты из разных стран мира), MariaDB разрабатывается MariaDB Corporation Ab. Свободные продукты менее подвержены рискам чем закрытые. В частности возможность сделать fork продукта можно рассматривать как страховку. Но в любом случае, желание делать всё самим и изолироваться от остального мира выглядит довольно глупо.
Да. И если мелкое вредительство, упомянутое @Ritan действительно может принести неприятности, то в санкционном плане я так и не понял, чего они боятся. Звучит как попытка обосновать распил. Но для распила обосновывать надо несведующему начальству наверху, а не на Хабре. То есть я именно вот этот момент пытаюсь понять.
Логика для корпоративного сектора тут есть. Вам нужна DB, кто-то ее должен поддерживать (обладать экспертизой, чинить, отвечать на вопросы, обновлять). Продать чистую поддержку opensource - сложно с точки зрения обоснования руководству. Поэтому логика проста - берем форк, делаем новые функции, упаковываем вместе с платной поддержкой и продаем единым продуктом.
С точки зрения санкций тоже тогда понятно - предыдущие подрядчики, оказывавшие платную поддержку становятся недоступны.
Альтернатива есть! Обзор 6 российских СУБД для миграции