Гидроликс спонсировал этот пост.
На постоянно развивающемся рынке баз данных одна вещь постоянна: цены, как правило, растут со временем. Продавцы настраивают свои модели ценообразования, вводят новые уровни и — чаще всего — повышают затраты по мере взросления их продуктов. Если вы разработчик, инженер данных или архитектор, понимание этих тенденций может помочь вам принять более разумные решения о том, где и как хранить и обрабатывать данные.
Ваша любимая база данных стала дороже (снова)
Помните, когда Clickhouse был быстрым, экономически эффективным любимым аналитикой? Ну, даже это недавно повысило цены на 30%. (Читать далее.)
Amazon RDS следует за аналогичной схемой. Несмотря на то, что цены EC2 остаются относительно стабильными, AWS увеличила маржу RDS с течением времени, что означает, что управляемые услуги базы данных становятся более дорогими, а Raw Compute — нет. (См. Анализ.)
И давайте не будем забывать об коллективном ПТСР отрасли от агрессивной тактики ценообразования Oracle. НАСА, например, в конечном итоге переплачивало Oracle на десятки миллионов из -за запутанных и хищных структур лицензий. (Тематическое исследование.)
Не так давно Planetscale сбросил свой дешевый план хобби, потому что он не был финансово жизнеспособным. Генеральный директор Сэм Ламберт объяснил, что, хотя он привлек большое количество пользователей, это не приводило к конверсии, которые превратились в оплату клиентов по устойчивому курсу. Он также отметил, что затраты на облачную инфраструктуру, особенно выходные взносы, сделали план экономически невозможным в масштабе. (Подробности здесь.)
Это схема в отрасли-бесплатные уровни и недорогие планы способствуют принятию, но часто не могут превратиться в значимый доход, если он не будет тщательно структурирован.
AutoScaling: удобно, но и бюджет Autocale тоже?
Многие современные поставщики баз данных теперь предлагают модели ценообразования на основе использования, которые автоматически масштабируются с спросом. Хотя эта гибкость великолепна, она также может привести к неожиданным затратам.
- BigQuery стоимостью: ловушки: BigQuery от 5 долларов за сканируемый туберкулез звучит дешево — пока вы не поймете, что запрос большой набор данных без надлежащего контроля затрат может привести к шокирующе высоким счетам. В одном из заметных случаев пользователь Archive HTTP, пытающийся запросить большой набор данных, накапливал заряд в размере 14 000 долларов сша после того, как забыл применить ограничения на размер сканирования. (Читать далее.)
- Транзакционные базы данных, такие как Supabase и Neon: Эти услуги масштабируются до нуля, что позволяет экономить затраты на простоя работных нагрузок. Однако, как только рабочие нагрузки увеличиваются, ценообразование быстро прыгает. Например, самый низкий уровень оплачивания Neon начинается с 0 долларов сша, но план масштаба стоит от 69 долларов в месяц до 870 долларов в месяц, в зависимости от того, сколько вы используете. (Неоновая цена.)
- Аналитические базы данных, такие как Snowflake, DataBricks, Clickhouse и BigQuery: Доминируют расчеты. Снежинка, например, взимает приблизительно 2 долл. сша за кредит, при этом склады значительно увеличивают затраты при выполнении сложных запросов. Один неоптимизированный запрос может стоить сотни или даже тысячи долларов.
Автомаскарирование по своей природе не плохо — это мощный инструмент в сочетании с правильным контролем затрат. Реальная проблема заключается в том, когда платформы определяют гибкость, не предоставляя пользователям достаточную видимость или гарантии для предотвращения безудержных счетов.
Еще один случай, вызванном автоматическим ударом наклеек, исходит из баз данных без серверов. Несмотря на то, что они продаются как экономически эффективные и очень гибкие, многие предложения без серверов, такие как режим DynamoDB по требованию, могут стать чрезвычайно дорогими по сравнению с предоставленными альтернативами.
DynamoDB по требованию за запрос, что делает его примерно в пять-семь раз дороже, чем предоставленная мощность для приложений с высоким трафиком. Например, на пост пишутся, что выставляется в размере 1,25 долл. сша за миллион запросов, тогда как предварительные записи могут стоить всего 0,18 долл. сша за миллион. (См. Цены AWS.)
Хотя эта модель имеет смысл для непредсказуемых рабочих нагрузок, приложения с устойчивыми моделями трафика могут без необходимости увеличить значительные затраты. Выбор предоставления мощности с помощью автоматических гарантий часто является лучшей альтернативой для контроля затрат.
Укрощение автомассалирования: уроки из разных подходов
Не все реализации автоматического мастерства одинаковы. Некоторые поставщики позволяют повысить предсказуемость затрат, разрабатывая свою архитектуру вокруг принципов хранилища, а не на вычислительной обработке.
Например, Hydrolix, вилка Clickhouse, фокусируется на проверке расчета затрат путем оптимизации выполнения запросов и тесной интеграции с экономически эффективным хранилищем облачных объектов, такими как AWS S3. Вместо того, чтобы постоянно раскручивать дорогие вычислительные ресурсы, он минимизирует необходимость масштабирования по требованию за счет лучшей индексации и эффективной фильтрации запросов.
Скрытые платы за передачу данных и блокировка поставщика
Вычислительные и автоматические затраты имеют тенденцию привлекать внимание, но плата за передачу данных является еще одним основным источником неожиданных расходов. Перемещение данных между регионами, услугами или сетью облачного провайдера может тихо увеличить затраты способами, которые не всегда очевидны заранее.
- Выходные сборы складываются быстро: AWS предоставляет 100 ГБ бесплатной передачи данных в Интернет в месяц; Помимо этого, заряды применяются. Например, передача данных из AWS в Интернет выставляется в размере 0,09 долл. сша за ГБ для большинства регионов. Таким образом, регулярное перемещение больших наборов данных может привести к значительным затратам.
- Межрегиональные трансферы не бесплатны: Даже оставаться в пределах одного и того же облачного провайдера не всегда защищает вас. AWS взимает 0,02 долл. сша за ГБ за межрегиональные переводы, что означает перекрестную репликацию или аналитические трубопроводы, которые охватывают несколько областей, могут молча питаться в вашем бюджете.
- Поставщики прибыли от блокировки: После того, как вы начнете накапливать петабайты данных внутри облачной экосистемы, затраты на передачу данных действуют в качестве сдерживающего фактора для переключения поставщиков. Чем больше вы двигаетесь, тем больше вы платите, создавая дорогую форму блокировки поставщиков, которую немногие организации считают достаточно рано.
Были заметные инциденты, когда организации столкнулись с неожиданными и существенными обвинениями из -за неправильных конфигураций передачи данных. Например, неправильно сконфигурированное ведро AWS S3 обнаружило конфиденциальные данные клиента, что привело к массовому устранению данных. Компания, ответственная за неправильную конфигурацию, должна была покрыть расходы на нарушение и понесла счет в размере 2,3 млн. Долл. сша на оплату передачи данных и хранения.
Как контролировать расходы на передачу данных:
- Оптимизировать движение данных: Создайте свою архитектуру, чтобы минимизировать ненужные передачи данных. Сохраняйте обработку и хранение данных в том же регионе, чтобы избежать сборов за региона.
- Используйте инструменты мониторинга затрат: AWS, Google Cloud и Microsoft Azure предлагают инструменты для отслеживания затрат на передачу данных. Настройка оповещений может помочь предотвратить выбросы бюджета до того, как они произойдут. (Проверьте NetApp Bluexp для углубленного анализа.)
- Партия и сжатие данных: Вместо непрерывно потоковой передачи данных, пакетные передачи и используйте сжатие, чтобы сократить количество перемещенных данных.
Облачные провайдеры не делают плату за передачу данных очевидной линейной позицией в моделях ценообразования, но игнорирование их может быть дорогостоящей ошибкой. Решения с интеллектуальной архитектурой и упреждающий мониторинг имеют большое значение во избежание ненужных расходов.
Хранение против вычислительных затрат: что на самом деле приводит к вашему счету?
Исторически, поставщики баз данных использовали различные модели ценообразования. В 1980-х годах Oracle представила модель лицензирования для каждого сервера, позволяя неограниченным пользователям получить доступ к базе данных на одном сервере. По мере того, как многоядерные процессоры стали распространенными, лицензионные модели развивались для учета повышенной мощности обработки, что приводит к структурам ценообразования на одно ядро.
Сегодня этот подход остается распространенным среди основных платформ данных, таких как Snowflake, Bigquery и Databricks:
- Хранение доступно: Платформы, которые отделяют хранение и вычисление, такие как Snowflake, Bigquery и Databricks, обычно взимаются рядом с ценами на хранение в облаке, обычно от 20 до 40 долларов за терабайт (ТБ) в месяц. Тем не менее, поставщики с связанным хранением и вычислительными моделями могут наладить более высокие затраты, особенно для крупных наборов данных, которые требуют минимальных вычислительных ресурсов (см. Цены на хранение Google Cloud BigQuery.)
- Вычислитель — это драйвер прибыли: Поставщики облачных данных используют мощность обработки. Например, снежинка и данные Databricks на основе «кредитов» или «DBU» (единицы DataBricks), в то время как BigQuery взимает плату за количество отсканированных данных, по 5 долларов сша за туберкулез. Затраты на вычислитель могут быстро опережать хранилище, особенно для нептимизированных рабочих нагрузок. (Ценообразование DataBricks, ценообразование снежинки)
- DataBricks против Snowflake Compute затраты:
- DataBricks: DataBricks использует единицы DataBricks (DBU) для измерения возможностей обработки на единицу времени. Стоимость на DBU варьируется в зависимости от типа рабочей нагрузки, от около 0,07 долл. сша для легких заданий до 0,95 долл. сша для интерактивной аналитики. Например, выполнение работы, которая потребляет 10 дбус в течение часа, будет стоить от 0,70 до 9,50 долл. сша, в зависимости от категории рабочей нагрузки. Точечные экземпляры и зарезервированная мощность могут обеспечить экономию, но без оптимизации затраты могут спираль. (См. Ценообразование DataBricks.)
- Снежинка: Вычислительные затраты основаны на виртуальных складах, начиная с 2 долл. сша в час для экземпляра X-Small. Затраты масштабируют в геометрической прогрессии с размером склада. Выбор правильного размера склада, использование функций автоматического выплаты и предотвращение чрезмерного обеспечения является ключом к контролю затрат снежинки. (См. Советы по оптимизации снежинки.)
- BigQuery: другой подход к вычислению цены: Google BigQuery предлагает план фиксированной ставки в размере 2000 долларов в месяц за 100 слотов (приблизительно 20 долларов за слот в месяц). Это приносит пользу организациям с устойчивыми нагрузками запросов, но может быть неэффективным для переменных рабочих нагрузок. Пользователи, сознательные, должны контролировать шаблоны запросов и оптимизировать структуры данных, чтобы минимизировать затраты на обработку. (См. BigQuery Pricing.)
Если вы не оптимизируете запросы и рабочие нагрузки, затраты могут взлететь. Например, маржа Snowflake связана в основном из вычислительного потребления, а не хранения.
Поиск экономически эффективных решений баз данных
Учитывая постоянно растущие затраты на аналитику и транзакционные рабочие нагрузки, компаниям необходимо изучить альтернативы, которые обеспечивают одинаковую функциональность, не нарушая банк. Одним из основных затрат драйвера является Elasticsearch, на который полагаются многие организации для журнала и поисковой аналитики, но в масштабе это может стать чрезмерно дорогим.
Именно здесь появляется Quesma. Например, если вы боретесь с растущими затратами Elasticsearch, Quesma предоставляет альтернативный подход с прокси -сервером базы данных. Бесполезно переводить упругие запросы в SQL, он позволяет организациям использовать более экономичные бэкэнды базы данных, включая Clickhouse и Hydrolix. Это означает, что вы можете сохранить гибкость Elasticsearch, значительно сокращая расходы на инфраструктуру.
Выберите своего продавца или своего продавца, выбирая ваш кошелек
Сход на основе использования ценообразования означает, что вам нужно быть стратегическим. Ключевые выводы:
- Ожидайте повышения цен, когда поставщики созревают: Что дешево сегодня не может быть завтра.
- Автоскалирование ценообразования мощно, но опасно: Установите гарантии, чтобы избежать неожиданных счетов.
- Вычисление — это реальная стоимость: Хранение дешево, но данные обработки — это то, где поставщики зарабатывают свои деньги.
- Плата за передачу данных складывается быстро: Минимизировать ненужное движение данных, чтобы контролировать затраты.
- Выберите правильного поставщика для своей рабочей нагрузки: Вместо того, чтобы выбрасывать данные, оптимизируйте, как и где вы их храните и обрабатываете.
Выбор правильной базы данных — это не только производительность, а в том, чтобы убедиться, что ваша модель ценообразования работает для вас, а не против вас.
Озеро потоковой передачи гидроликс обеспечивает наиболее быстро растущие продукты наблюдения и безопасность отрасли, трансформируя экономику управления высокой кардинальностью, данные журнала высокой размерности. Узнайте больше последних из Hydrolix Trending Stories YouTube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Antoni Olendzki-это лидерство на рынке основания в Quesma, работающая с инженерами, клиентами и партнерами для навигации по развивающемуся ландшафту базы данных. Ранее он был начальником штаба в Choco на фазе гипер-роста. Он сосредоточен на стартапах на ранней стадии, масштабируя выступление на рынке … Подробнее от Antoni Olendzki
