Встречайте Dynamic PostgreSQL: естественная эволюция облачных баз данных

Начиная с сегодняшнего дня, . вы можете создавать динамические базы данных PostgreSQL в шкале времени Динамический — это естественная эволюция облачных баз данных, решающая проблемы как подготовленных баз данных, так и бессерверных баз данных. Он поддерживается динамическими вычислениями — инновацией Timescale, которая мгновенно масштабирует доступные вычислительные ресурсы в заранее заданном минимальном/максимальном диапазоне в зависимости от вашей нагрузки. Вместо того, чтобы обеспечивать пиковую мощность (и постоянно платить за нее), теперь вы можете выбрать диапазон вычислений: ваша база данных будет работать с базовой мощностью и мгновенно получать доступ к пиковой мощности только при необходимости. Купите базу, арендуйте вершину. PostgreSQL Это приводит к беспрецедентному снижению цен: клиенты, выполняющие производственные рабочие нагрузки, сэкономят 10–20 % при переходе с AWS RDS на PostgreSQL и 50–70 % при переходе с AWS Aurora Serverless. Вы можете попробовать Dynamic PostgreSQL уже сегодня. Мы предлагаем бесплатную пробную версию (кредитная карта не требуется), которая дает вам полный доступ к платформе в течение 30 дней. Чтобы создать службу динамического PostgreSQL, просто выберите опцию PostgreSQL при входе в Timescale: Ваше приложение всегда включено, почему ваша база данных не должна быть включена? Добро пожаловать в будущее. Проблема 1. Разработчики предоставляют гораздо больше вычислительных ресурсов, чем им необходимо. В течение последних нескольких лет, с тех пор, как мы впервые запустили Timescale, мы занимали первое место в том, как разработчики используют базы данных. Например, только за последние несколько месяцев как часть нашего продукта Insights. мы проанализировали более триллиона запросов Мы узнали одну вещь: разработчики часто предоставляют гораздо больше вычислительных ресурсов, чем им действительно нужно. С одной стороны, это имеет смысл: вы никогда не захотите беспокоиться о своей базе данных. Большинство рабочих нагрузок базы данных являются непрерывными, обычно с некоторой изменчивостью или пульсацией. Например, игра, которую чаще используют ночью, бизнес-приложение, которым чаще пользуются днем, или подключенное домашнее устройство, которое чаще используется в выходные дни, чем в течение недели. Вы никогда не захотите, чтобы в вашей базе данных закончились ресурсы. Если ваша база данных заполнена до предела, это приводит к ужасному качеству обслуживания клиентов (или его отсутствию!). Таким образом, большинство разработчиков в конечном итоге предусматривают пиковую нагрузку плюс буфер. В результате разработчики платят за гораздо больше вычислений, чем им действительно нужно. С другой стороны, нам это кажется безумием. Какой еще бизнес-ресурс организации могли бы потратить гораздо больше, чем им нужно? Потраченные впустую вычисления равны потраченным впустую деньгам. Проблема 2. Бессерверные базы данных не справляются с производственными нагрузками. Некоторые из вас могут спросить: «А как насчет бессерверных баз данных?» Концепция бессерверной работы возникла из-за рабочих нагрузок без сохранения состояния. После успеха виртуальных машин в облаке, где пользователи могли перестать беспокоиться об оборудовании, они задали вопрос, зачем вообще беспокоиться о запуске серверов приложений? В конце концов, многие пользователи просто хотели запускать функции и получать оплату только за время работы этих функций. А развертывание функций по мере необходимости легко и беспрепятственно, почти именно потому, что они не имеют состояния. Бессерверные технологии, а также модели «функция как услуга» или FaaS стали хитом, когда их место заняла AWS Lambda. Затем разработчики задали себе вопрос: «Зачем платить за мою базу данных, если я ею не пользуюсь?» Фактический вопрос хорош: потраченные впустую ресурсы — это серьезная проблема базы данных. А практика предоставления базы данных AWS RDS на конкретном экземпляре сервера (скажем, db.m6gd.2xlarge) определенно не кажется современной или гибкой: фиксированный процессор, фиксированная память, фиксированный локальный диск. Большая часть из них большую часть времени используется недостаточно. Но здесь все становится сложнее: базы данных сильно отличаются от функций Lambda. Сегодня бессерверные базы данных не подходят для большинства производственных задач по двум основным причинам: Бессерверные базы данных ориентированы на экстремальные возможности масштабирования вверх и вниз, вплоть до нуля. Бессерверные базы данных предусматривают гораздо более высокие цены, чтобы учесть «запас» ресурсов, зарезервированный для удовлетворения меняющихся потребностей (и, что еще хуже, часто модели ценообразования, которые трудно понять или предсказать). Начнем с обсуждения горячей темы «масштабирования до нуля». Реальность такова, что большинству производственных баз данных не требуется масштабирование до нуля, и оно не принесет никакой выгоды. Теперь есть некоторые случаи использования, когда «масштабирование до нуля» имеет смысл. Например, демонстрационные версии концепции или приложения для любителей. Возможность время от времени запускать специальные запросы к вашему набору данных (AWS Athena и Google BigQuery являются убедительными аргументами в пользу недорогого бессерверного облачного хранилища данных для очень периодического использования). Другой подходящий вариант использования — не забывать останавливать экземпляр облачной разработки после завершения — есть смысл в «автоматической приостановке» непроизводственной базы данных (хотя для этого требуется гораздо более простая функциональность, чем предусмотрено в бессерверной версии). Но для вашей производственной базы данных и в более оперативных условиях? Вы не хотите масштабироваться до нуля. Масштабирование до нуля означает «холодную перезагрузку» при перезапуске: пустые общие буферы базы данных, пустой кэш ОС, пустые кэши каталогов (в случае PostgreSQL). (Да, некоторые бессерверные базы данных сокращают время, необходимое для запуска базы данных, но они делают это из пустого состояния. В реляционной базе данных, такой как PostgreSQL, для повторного создания теплого рабочего набора может потребоваться несколько минут (или больше!) особенно для больших баз данных.) Ухудшение производительности при холодном запуске еще больше, поскольку многие бессерверные базы данных используют разные архитектуры облачного хранилища, где стоимость и задержка извлечения страниц базы данных из удаленного хранилища в память еще выше. Эти накладные расходы снова приводят к ухудшению производительности или вынуждают поставщиков платформ компенсировать это за счет использования большего количества физических ресурсов (например, базы данных Amazon Aurora имеют в два раза больше памяти, чем RDS), и эти затраты в конечном итоге перекладываются на пользователей. Таким образом, во многих случаях бессерверные базы данных имеют более высокую и непредсказуемую цену. Например, если вы сравните Aurora Serverless с Amazon RDS, вы увидите, что вычислительные ресурсы с 8 виртуальными ЦП и хранилище объемом 500 ГБ в режиме Serverless на 85 % дороже, чем RDS (1097 долларов США против 593 долларов США). И это благодаря использованию Aurora I/O Optimized и более предсказуемых цен на хранилище, которое было запущено всего шесть месяцев назад. (Хотя даже здесь нам все равно придется делать выводы о его фактической вычислительной мощности, поскольку Aurora Serverless оценивает цену, путая непрозрачные «единицы мощности Aurora», которые, по нашим наиболее информированным оценкам, составляют 1 ACU = 0,25 виртуального ЦП.) скоро мы опубликуем полный тест, подтверждающий эти результаты. Следите за обновлениями. Примечание редактора: Раньше, при использовании Aurora Standard, пользователи также платили за каждую внутреннюю операцию ввода-вывода, которую было практически невозможно предсказать или запланировать. Многие бессерверные базы данных продолжают взимать плату за такие операции чтения и записи. Фактически, когда мы сравнивали бессерверный поток времени AWS, мы видели чем с Timescale, из-за всех этих более высоких предельных затрат. Непредсказуемость и изменчивость затрат были противоположностью беззаботности. затраты, которые в итоге оказались более чем в 100 раз выше Короче говоря, бессерверные базы данных склонны к снижению производительности, непредсказуемым счетам и высоким затратам по мере масштабирования рабочих нагрузок. Они хорошо подходят только для периодических рабочих нагрузок, которые активируются лишь изредка, и могут переносить холодные запуски из-за отсутствия кэширования данных в памяти. Дилемма разработчика Вот где мы оказались: Многие разработчики по-прежнему выбирают традиционные сервисы DBaaS с предоставлением рабочих приложений из-за их надежной производительности, контроля и понятности, но ненавидят потери, возникающие из-за необходимости избыточного предоставления ресурсов. Некоторые разработчики выбирают бессерверные базы данных из-за их очевидной экономии средств, гибкости и простоты использования, но ненавидят снижение производительности и непредсказуемые, неясные цены (которые часто приводят к загадочным образом более высоким счетам, чем за подготовленный экземпляр). Нам самим разработчикам ни один из этих вариантов не кажется очень привлекательным! Есть возможность стать лучше. Решение: введение динамического PostgreSQL Вот почему мы разработали Dynamic PostgreSQL. Динамический PostgreSQL последовательно поддерживает ваши базовые показатели и плавно масштабирует вычисления, когда вам это необходимо, до определенного максимума. Это делает его идеальным для диапазона непрерывных рабочих нагрузок, которые обычно встречаются в производственных условиях (равномерных, переменных или периодических). Динамический PostgreSQL — это 100% PostgreSQL со всеми преимуществами сообщества и экосистемы PostgreSQL, а также . Чтобы создать динамический PostgreSQL, мы внесли новшества в управление нашей инфраструктурой PostgreSQL, а не модифицировали внутренние компоненты PostgreSQL. Это дает вам доступ ко всему, что предлагает PostgreSQL и платформа Timescale, не опасаясь запуска разветвленного запроса PostgreSQL или механизма хранения. зрелость платформы базы данных Timescale При использовании Dynamic PostgreSQL вы выбираете вычислений (минимальный и максимальный ЦП), соответствующий потребностям вашей рабочей нагрузки. Этот диапазон вычислений также имеет эффективную память, эквивалентную тому, что большинство служб DBaaS традиционно предлагают на «максимальном» конце диапазона вычислений. диапазон Базовый (минимальный) диапазон вашего ЦП действует точно так же, как предоставленная модель DBaaS: минимальный ЦП всегда выделяется вашей службе для запуска вашего приложения. По мере увеличения нагрузки — либо из-за требований вашего внешнего приложения, либо даже из-за периодических внутренних задач базы данных, таких как инкрементальное резервное копирование или автоматическая очистка таблиц — ваша база данных может использовать до пика (максимума) диапазона вашего ЦП с нулевой задержкой. Как добиться нулевой задержки? Динамические вычисления работают иначе, чем некоторые другие бессерверные или автоматически масштабируемые базы данных, поэтому они не требуют медленного масштабирования (и снижения производительности), которое обычно наблюдается при удаленной миграции. Вместо этого наши алгоритмы конфигурации инфраструктуры и размещения рабочей нагрузки гарантируют, что базы данных могут масштабироваться на своем базовом узле без перезапуска или реконфигурации. Ваш экземпляр всегда имеет доступ к максимальной вычислительной мощности по мере необходимости. И самое приятное то, что вы платите только за базу плюс то, что используете сверх нее. Мы называем эту модель выбора вычислительного диапазона и масштабирования между ним « ». покупай базу, арендуй пик Например, если вы выберете вариант с 4–8 ЦП, у вас всегда будет 4 ЦП, выделенных для вашей службы, и 32 ГБ эффективной памяти. Это обеспечивает постоянную хорошую базовую производительность. Когда нагрузка увеличивается, ваше приложение может использовать до 8 ЦП мгновенно по мере необходимости (измеряется и оплачивается на дробной основе ЦП) и не более 8 ЦП, если это ваш максимальный предел. Динамическая модель позволяет вам «размерить» вашу базу данных более экономично и без проблем. Вы можете выбрать диапазон вычислений, в котором ваши стандартные требования соответствуют минимуму, но при необходимости вы можете увеличить или увеличить их до пика (максимума). Этот максимум создает неотъемлемое ограничение на любое использование сверх базовых вычислительных ресурсов, что приводит к легкому для понимания потолку затрат. Кроме того, мы взимаем одинаковую плату за (дробный) час ЦП как для вашего базового, так и для любого дозированного использования: за использование сверх базового значения дополнительная плата не взимается, а следовательно, и за масштабирование. Наконец, если вы поймете, что предоставили слишком низкий или слишком высокий диапазон размеров, вы можете легко настроить диапазон вычислений так, чтобы он лучше соответствовал потребностям вашего приложения. Создано для экономии ваших денег В настоящее время мы предлагаем пять различных диапазонов вычислений в зависимости от размера вашей рабочей нагрузки с соответствующей эффективной памятью, которую вы получаете для этого диапазона независимо от мгновенного использования. Динамический PostgreSQL также использует хранилище Timescale, основанное на использовании, где вы платите только за объем хранимых данных (в ГБ-часах), а не за предоставленный размер диска. Не беспокойтесь о том, что вы зря потратите деньги на избыточно выделенный диск, или о том, что вам не хватит места на диске. Динамическая облачная инфраструктура Timescale гарантирует, что у вас будет достаточно места для хранения данных, когда оно вам понадобится, и что вы платите только за то, что используете. Мы разработали Dynamic PostgreSQL намеренно, чтобы сэкономить ваши деньги. Клиенты, выполняющие производственные рабочие нагрузки, обычно экономят 10–20 % при переходе с AWS RDS для PostgreSQL и 50–70 % при переходе с AWS Aurora Serverless. В конце месяца ваш счет состоит из двух простых и понятных показателей: (1) затраты на вычисления, учитываемые как базовые почасовые вычисления плюс любая дробная загрузка ЦП сверх этой суммы, но не более максимальной; и (2) ваши расходы на хранилище, оплачиваемые как потребление данных в ГБ-часах. Не существует новых показателей или производных единиц, которые можно было бы измерить или понять. Просто платите за то, чем пользуетесь. Ноль дополнительных затрат или скрытых платежей. Вычисление: предсказуемое, на основе определенного диапазона Хранение: платите только за то, что храните Никаких напрасных ресурсов. Никаких переплат. Не теряя сна по ночам. Законопроект, который вы можете объяснить своему боссу. Попробуйте сегодня Вы можете попробовать Dynamic PostgreSQL уже сегодня! — кредитная карта не требуется — это дает вам полный доступ к платформе в течение 30 дней. Чтобы создать службу динамического PostgreSQL, просто выберите опцию PostgreSQL при входе в Timescale: Timescale предлагает бесплатную пробную версию Платформа теперь предлагает два типа услуг для удовлетворения конкретных потребностей ваших баз данных: разработаны для повышения скорости запросов и масштабируемости для самых требовательных рабочих нагрузок, предлагая ключевые функции шкалы времени, такие как гипертаблицы, столбчатое сжатие, непрерывные агрегаты и многоуровневое хранилище. Используйте их для размещения данных датчиков, энергетических показателей, финансовых данных, событий и другой рабочей нагрузки, требующей больших объемов данных. Службы временных рядов — это динамические службы Postgres, оптимизированные для обеспечения экономической эффективности и простоты использования. Используйте их для своих реляционных баз данных, например, для деловых записей. Службы PostgreSQL После того, как вы выберете «PostgreSQL», настроить службу динамического PostgreSQL станет очень просто. Выберите свой регион, свой динамический вычислительный диапазон, а также параметры высокой доступности и пула подключений — бум! 💥 Теперь у вас есть динамическая база данных PostgreSQL, готовая к использованию в производстве. Если у вас есть вопросы, . Мы будем рады услышать ваши отзывы и помочь вам с вашим вариантом использования PostgreSQL (временными рядами или нет)! обратитесь к нам Это только начало. Мы находимся в середине трех последовательных недель запуска, и это только начало второй недели: Dynamic Infra Week. Следите за новостями на этой неделе, в этом месяце, в этом году и в последующие годы. 🙂 - Авторы сценария Майк Фридман и Грант Годеке. Также опубликовано здесь.