Комментарии 19
Юзаю snowflake для DWH уже второй год и просто балдею от удобства. После всех этих плясок с админскуим бубном вокруг гринплама, просто рай.
p.s. "И если вы захотите сменить поставщика, вам почти наверняка потребуется обновить свои операционные инструменты и, вероятно, модифицировать свой код "
А так-то при смене поставщика серверной субд ничего делать не надо ага, с mssql на postges например столько переделывать, проще с нуля все написать
А так-то при смене поставщика серверной субд ничего делать не надо ага
От поставщика serverless-технологий в любом случае зависимость выше. А с учетом нынешней нестабильной ситуации это может внезапно аукнуться. Что нужно учитывать.
Несколько раз приходилось добавлять нового провайдера СУБД в разные проекты.
Сильно зависело от кода: какой ORM, сколько аналитических запросов. Условные ~80% запросов - стандартные SELECT / UPDATE / INSERT / DELETE, и они просто работают либо легко их изменить на работающие везде.
Сложные (как правило, аналитические) иногда приходилось решать через что-то вродеswitch (dbType) {
case DbType.MSSQL:
...
case DbType.Postgres:Но все решалось, хотя иногда для этого требовались недели-месяцы.
...
}
Если были юнит-тесты - они экономили время в несколько раз. В очередной раз убеждался, что это их основной use-case :)
MySQL можно ничего не делая перенести в любой датацентр любого хостера. Админ средней руки справится за недельку.
А вот завязавшись на поставщика услуг вы уже никуда не переедете без огромных проблем. Не для всех проектов этот риск значим, но помнить о нем обязательно надо.
При смене поставщика серверной СУБД вы просто поднимаете её на мощностях другого поставщика.
Если вы хотели сказать, что смена СУБД - это сложно, то тут немного другая ситуация. Код вы запускаете там где хотите и имеете SLA, юридические требования т.д. какие хотите.
А в случае сервиса вы не можете уйти к другому поставщику без существенных издержек, и поднять на "других" мощностях не можете. И вообще, ничего не можете. Но удобно. Молочко в бутылочке, попу подтирают, выбраться за пределы кроватки не дают.
Я так и не понял в каких сценариях это реализуемо. Можно примеры этих невероятно выгодных временных "вычислений на БД", которым не нужны предыдущие данные, сохранение текущих и пр.?
Может не увидел в статье, но есть ли ограничения на пиковые нагрузки, которые задает сам клиент? Например, как защита от кривых рук. Ведь если на обычном сервере сделал что-то не так, его мощностей на хватило, БД упала - быстро заметил, починил. А тут получается заметишь когда счет в конце месяца выставят? Или неверно понимаю процесс предоставления услуги?
Поддерживаю. Механизмы защиты от ситуаций, за которые придут астрономические счета, в облачных сервисах сейчас один из самых важных.
А тут получается заметишь когда счет в конце месяца выставят?
Всегда казалось, что такие случаи и приносят основной доход serverless провайдерам. Примерно как возможность уйти в минус у банков или опсосов. Все, конечно же, ради блага клиента.
А тут получается заметишь когда счет в конце месяца выставят?
В этом и "прелесть" облаков - платишь за каждый чих. Если у тебя небольшой проект, то может влететь в копеечку. А если у тебя крупный проект типа FB, то тебе выгоднее поднимать свои облака. Выгодны облака для тех, кто где-то по середине: средний бизнес, у которого непонятно, что будет завтра, и при этом им норм платить $100 000 за серверы, т.к. они принесли на чёрную пятницу им в сотню раз больше выручки. Но и там уже сидят матёрые DevOps, которые умеют считать все эти операции.
В больших облаках вроде AWS, GCP, Azure есть всевозможные cost control. Но конечно надо правильно настроить, что часто бывает не очевидно. В мелких облаках с этим сложнее, да и в целом опасения верны - все ограничения на нагрузки обычно появляются не сразу, а вводятся когда первые пользователи начинают жаловаться :)
В выпуске linkmeup sysadmins про бигдату описывался именно такой случай - когда кривой запрос обошёлся компании в круглую сумму. И описывалось принятое по результатам решение, когда специальная подсистема контролировала сложность запроса и алертила админам бд о слишком масштабных потребностях аналитиков.
Так и не понял в чем прелесть бессерверных БД. Они запускаются по несколько секунд (если спят). Если они спят, значит они не сжирают ваши деньги (значит, вы их экономите). А значит, вы тратите $0.
Но если вас устраивает то, что такой сервер будет подниматься несколько секунд при каждом (первом/случайном) запросе (значит, высокие задержки вас устраивают), и вам хочется очень сильно экономить, то разве не проще поднять самую дешманскую виртуалку за $2, которая будет вообще всегда онлайн, и также за 1 секунду отдавать данные вообще в любое время?
Ещё добавляем сюда проблему из предыдущей ветки комментариев - что ты не знаешь, сколько тебе по итогу предъявят счет за операции чтения. Это будет $0, это будет $100 или $10k. Ведь мы хотим экономить, и мы не хотим обслуживать сервер БД, а значит, мы не хотим поднимать тучу мониторингов, который бы за нас считал выгоду такого решения...
Короче одни противоречия.
Поднимаются несколько секунд это про те, где разделение пользователей на уровне VM или контейнера. Многим DB это не надо, скажем Google BigQuery (аналитическая база для больших данных) просто держит большой пул машин и при запросе выдает вам часть свободных, за миллисекунды решая кому какие ресурсы, в зависимости от нагрузки.
Если вам достаточно одной VM, то да - это часто не имеет смысла. А если надо тысячу машин для больших данных - то держать их самому дорого, используются то они только на время запроса, пока аналитик думает машины простаивают. А получить их на время интерактивного запроса дёшево и оправдано даже тем что результат получаешь за 10 секунд, а не час на одной своей машине.
Пользуюсь DynamoDB последние три года в куче проектов. Все прекрасно работает и покрывает 99% процентов наших кейсов, нужных при разработке приложений. Репорты и дашборды - те да, удобнее SQL когда есть.
Я как-то считал, во сколько раз дороже Aurora for PostgreSQL обходится просто обычного арендованного сервера в Hetzner той же мощности. Получилось ни много ни мало в 8 раз дороже.
«Но ее же не надо админить, и она отказоустойчива!» - скажет неопытный обыватель. Но нет: за 3 года на Aurora было в среднем по 2 многочасовых аутаджа каждый год. И в эти моменты делать ничего другого, кроме как тупо сидеть и ждать, было нельзя по сути (в половине случаев даже консоль не работала). Суппорт говорит «ничего не знаем, делайте кросс-региональный кластер». Что для небольшого сервиса просто смехотворно.
Вот вам и «бессерверная» и “cost efficient”.
Когда на безсерверную службу придет запрос на выполнение кода, облачный провайдер просто выделит специально под его обработку виртуальную машину или модуль (набор контейнеров, обычно управляемых Kubernetes).
Как это работает, более-менее понятно, а как это программировать то? Допустим, у меня есть веб-сервер на python + Django. Он состоит из набора view, каждая вьюшка - функция, казалось бы - вот оно. Но есть же еще, скажем, ОРМ. Для инициализации моделей, построения дерева отношений и пр. требуется время. В обычном "серверном" сценарии мы жертвуем несколькими секундами "на разогрев" на этапе импорта, один раз для процесса. Далее обработка каждого входящего запроса - ну то есть каждого вызова функции - эта работа не нужна, все уже в памяти процесса. Правильно ли я понимаю, что с модными молодежными безсерверными технологиями мне прийдется вручную строить SQL запросы в стиле PHP пятнадцатилетней давности?
Бессерверные базы данных: путь в будущее?