Российские пользователи облачного сервиса MongoDB сообщили об отключении аккаунтов Статьи редакции
Компания разослала письма, в которых порекомендовала сохранить данные.
- MongoDB предупредила своих пользователей в России и Белоруссии, что их данные, которые хранятся на платформе MongoDB Atlas, будут уничтожены, и порекомендовала сохранить их.
- Соответствующие письма компания разослала пользователям, пишет TAdviser. Оно также есть и у редакции издания. Официально MongoDB об отключении пользователей не сообщала.
- Причиной отключения аккаунтов сервис назвал санкции против России и Белоруссии.
- MongoDB Atlas — облачный сервис, который ускоряет создание и упрощает управление базами данных для приложений.
0
показов
33K
открытий
Монго, да ещё и в облаке?
Что-то вроде Hotmail закроет аккаунты российских пользователей?
Хватает клиентов которые её используют. Много вы решений видели например из коробки за $67 в месяц три реплики.
Чисто экономически посчитай час DevOps стоит от $7. В минимальной конфигурации все это настроить на трех серверах, следить чтобы это все не отвалилось. Плюс один хрен платить за сервера.
Atlas в три кнопки нажал и все развернулось, любой бэкэнд разработчик это сможет.
Тоже можно сказать про почти любые облачные сервисы, в т.ч. и отечественные.
По ценнику Atlas может быть и выгоднее (хотя не уверен), но для бизнеса это копейки.
Ну и сама специфика MongoDB... Зачем, если есть к примеру опен-сорсный Postgres с поддержкой тех же JSON, и не только шардированием при создании реплик?
Частый кейс использования это Backend for Frontend (BFF).
Если вам нужно просто выдать всех users или posts там и прочее аля REST API, то вы не поймете преимущества.
В связке с GraphQL все это раскрывается, так как схема строится сейчас не то как лежат данные в базе, а то, в каком виде они нужны пользователю и как он с ними взаимодействует (мутирует). Этот подход в разработке приложения я называю Schema Driven Design.
Бывает такое, что вы делаете все запросы SQL, затем сохраняете все это в том виде, в котором будете отдавать пользователю в MongoDB и затем сразу через GraphQL отдаете.
У меня было такое, где Mongo отдала меньше чем за 400 мс, а MySQL раздуплялся от 2 секунд. Можете сказать что хм... ну типа нужно кэширование, но там прикол как раз в том, что запрос должен быть актуальный. А с кэшированием в GraphQL есть нюансы.
Ну и плюс клиенты бывают разные. Не все могут только за базу платить $100-$200 в месяц. Иногда это бюджет на инфраструктуру в целом)
В целом правильно написано, как по мне
Я бы дополнил, что на sql разгуляться тоже можно и 2 секунды легко устранимы ( и дело не в кеше )), но sql внезапно имеет более высокий порог входа и для поддержки нужны неплохие dba с навыками, в т.ч. как архитектурно правильно натянуть хотелку на базу и составить оптимальные запросы.
Mongo и любой noslq в большинстве несложных задач выглядит выигрышнее за счёт того, что dba не нужен. А в sql можно выстрелить себе в ногу ( хотя и в монге можно так-то... ).
+ Это сильно проще для многих вайтишников оказывается, куча вайтишников могут и вовсе не вдуплять про sql