Комментарии 22
Юзаю snowflake для DWH уже второй год и просто балдею от удобства. После всех этих плясок с админскуим бубном вокруг гринплама, просто рай.
p.s. "И если вы захотите сменить поставщика, вам почти наверняка потребуется обновить свои операционные инструменты и, вероятно, модифицировать свой код "
А так-то при смене поставщика серверной субд ничего делать не надо ага, с mssql на postges например столько переделывать, проще с нуля все написать
А так-то при смене поставщика серверной субд ничего делать не надо ага
От поставщика serverless-технологий в любом случае зависимость выше. А с учетом нынешней нестабильной ситуации это может внезапно аукнуться. Что нужно учитывать.
Несколько раз приходилось добавлять нового провайдера СУБД в разные проекты.
Сильно зависело от кода: какой ORM, сколько аналитических запросов. Условные ~80% запросов - стандартные SELECT / UPDATE / INSERT / DELETE, и они просто работают либо легко их изменить на работающие везде.
Сложные (как правило, аналитические) иногда приходилось решать через что-то вродеswitch (dbType) {
case DbType.MSSQL:
...
case DbType.Postgres:Но все решалось, хотя иногда для этого требовались недели-месяцы.
...
}
Если были юнит-тесты - они экономили время в несколько раз. В очередной раз убеждался, что это их основной use-case :)
А как юнит-тесты помогают при миграции на другую базу? Они же с самой базой, по идее, не взаимодействуют вообще никак, иначе это уже и не юнит-тесты. Или что-то еще имеется в виду?
Видимо имеется в виду, что тесты показывают на проблемное место (что бы тотально все 100% кода не проверять вручную).
Конечно, это не совсем юнит тесты, правильнее назвать "слегка интеграционные". Просто чистые юнит тесты для БД малополезны, что тестировать в POCO / Entities ?
Польза случается, когда, например, в БД поле было double, стало int (часто же обновляется десяток полей в разных таблицах) , а в классе осталось double. И тут тест покажет некорректность сохранить - прочитать - сравнить с исходным.
Формально это не совсем юнит тест, но если он только связку entity - orm - db проверяет, как его назвать?
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 пятнадцатилетней давности?
Я в таких случаях всегда думаю с точки зрения провайдера таких сервисов. Как он может обеспечивать такую доступность лучше, чем я сам это буду делать на своих мощностях? Если ему выгодно держать про запас несколько инстанцев, то я как клиент явно должен переплачивать за это. Иначе ему будет не выгодно. Т.е. такие сервисы нужно использовать только тогда, когда время от времени ожидается значительный всплеск необходимых мощностей. Например, маркетинг размещает вирусный ролик и посещаемость с 10 подскакивает до миллионов, а потом возвращается в свой порядок. В остальных случаях имхо не стоит переплачивать за гибкость.
Бессерверные базы данных: путь в будущее?