Масштабирование баз данных PostgreSQL стало дешевле: многоуровневое хранилище Timescale стало общедоступным

Такие продукты, как Amazon RDS для PostgreSQL, подходят для небольших развертываний, но масштабирование PostgreSQL — это совсем другая история. Как только проект вырастет до многих терабайт, эти управляемые базы данных станут медленными и дорогими, что значительно усложнит управление данными.

Производительность снижается, когда таблицы достигают миллиардов строк. есть способы улучшить его , данные будут продолжать расти. Без надлежащего управления данными разработчики могут лишь наблюдать, как их диски (и счета) увеличиваются в размерах.

Но не больше. Сегодня мы рады объявить о доступности многоуровневого хранилища — многоуровневой архитектуры хранения, разработанной для обеспечения неограниченной и недорогой масштабируемости ваших временных рядов и аналитических баз данных на платформе Timescale. Теперь вы можете хранить свои старые, редко используемые данные на недорогом уровне хранения, сохраняя при этом доступ к ним, не жертвуя при этом производительностью для часто используемых данных.

Вот что происходит, когда вы вставляете данные в базу данных временных рядов Timescale с помощью нашего нового многоуровневого хранилища:

1. Ваши самые последние данные будут записаны на высокопроизводительный уровень хранения, оптимизированный для быстрых запросов и большого количества данных.

   
   

2. Если вы не часто получаете доступ к этим данным, вы можете автоматически перенести их на более дешевый уровень объектного хранилища , настроив политику многоуровневого хранения. Данные на недорогом уровне хранения остаются полностью доступными для запросов в вашей базе данных, и объем данных, которые вы можете хранить, не ограничен — до сотен ТБ и более. Наш недорогой уровень хранения данных имеет фиксированную цену 0,021 доллара США за ГБ/месяц — дешевле, чем у Amazon S3.

Разработчикам нужен дешевый способ масштабировать свои большие базы данных PostgreSQL в AWS без ущерба для производительности. Хотя хранилища объектов удивительно масштабируемы и доступны, они не самые быстрые, и разработчикам также необходимо получать миллисекундные ответы на запросы для своих приложений.

Однако, когда данные устаревают и к ним редко обращаются, производительность в реальном времени часто становится не столь важной. Разработчикам по-прежнему необходимо иметь доступ к этим историческим данным для специальных запросов, анализа данных или соблюдения нормативных требований, но они могут предполагать некоторую задержку для этих типов запросов. Теперь разработчики хотят иметь возможность хранить эти исторические данные максимально доступно и эффективно.

Эта новая архитектура многоуровневого хранилища освобождает разработчиков от выбора между затратами на хранение и компромиссом в производительности для приложений реального времени. Сохраняя свои последние и часто используемые данные на высокопроизводительном уровне, они будут использовать миллисекундную скорость запросов и возможности приема Timescale, а за счет многоуровневого хранения старых данных они смогут хранить столько ТБ, сколько им нужно, в своих базах данных PostgreSQL для меньше.

Управление данными PostgreSQL с помощью многоуровневого хранилища: что нужно знать

Архитектура многоуровневого хранилища Timescale использует гибкость PostgreSQL и гипертаблицы для эффективного управления данными. При создании гипертаблицы теперь ее можно легко растягивать на оба уровня хранения; когда вы запускаете запрос , Timescale легко определяет, к каким уровням хранения необходимо получить доступ для генерации ответа, повышая производительность для самых последних данных и снижая затраты на хранение для старых данных. Никакой дополнительной платы за каждый запрос или чтение данных, а также скрытых платежей не взимается, что обеспечивает простое и экономичное управление данными.

Эта архитектура хранения также устраняет любые ограничения хранилища в службах Timescale: поскольку наш недорогой уровень хранения бесконечен, вы можете хранить столько ТБ, сколько захотите. Например, мы используем внутреннее многоуровневое хранилище для хранения огромной базы данных Timescale, лежащей в основе нашего продукта Insights.

Эта база данных Insights постоянно собирает и анализирует статистику запросов со всего парка наших клиентов. Сегодня ее объем превысил 350 ТБ и быстро растет. Из этих 350 ТБ 250 ТБ относятся к недорогому хранилищу.

Давайте посчитаем:

• После сжатия мы храним 5 ТБ на нашем высокопроизводительном уровне хранения. Конечно, у нас включено сжатие, и мы получаем степень сжатия 20x — это означает, что то, что изначально составляло 100 ТБ данных Postgres, теперь помещается на диск емкостью 5 ТБ благодаря сжатию (!)

  
  

• Остальные 250 ТБ данных хранятся на недорогом уровне хранения. Это распределение по уровням происходит автоматически, когда данные достигают определенного возраста, который в настоящее время составляет несколько недель.

  
  

Наши клиенты с крупными развертываниями также уже используют многоуровневое хранилище:

«Мы проводим много анализа рыночных данных, и огромный объем данных, который нам необходимо хранить, делает невозможным использование обычного дискового решения базы данных (это слишком дорого). Многоуровневое хранилище Timescale позволяет нам беспрепятственно перемещать большие объемы данных в уровень хранения объектов. Это отличное решение для хранения больших объемов исторических данных и выполнения пост-анализа. Без этого нам пришлось бы разрабатывать решение собственными силами».

- Главный технический директор собственной компании по торговле цифровыми активами

Простота — ключевая особенность многоуровневого хранилища. Чтобы переместить ваши данные с высокопроизводительного уровня на недорогой объектный уровень, все, что вам нужно сделать, это использовать наш простой API определить политики для распределения ваших данных по мере их устаревания в конкретной гипертаблице. Политики многоуровневого хранения данных работают на основе фрагментов (политика будет распределять полные фрагменты по уровням, как только они достигнут возраста, определенного политикой). Нет необходимости в каких-либо процессах ETL (извлечение-преобразование-загрузка) или изменениях инфраструктуры.

Например, эта политика переместит все данные старше одного месяца в хранилище объектов в гипертаблице events :

 SELECT add_tiering_policy('events', INTERVAL '1 month');

Это все, что вам нужно! Все остальное происходит автоматически, включая интеллектуальное планирование запросов, при котором любые SQL-запросы выполняются только на соответствующем уровне.

Чтобы удалить данные, хранящиеся в настоящее время на недорогом уровне хранения, вы можете определить политику хранения данных, чтобы данные автоматически удалялись через определенный период (например, через пять лет). Вы также можете вручную удалить определенные фрагменты. .

Кроме того, если вы хотите «переместить назад» определенный фрагмент с недорогого уровня хранилища на высокопроизводительный уровень ( например, если вам нужно заполнить или обновить данные ), вы можете легко «развязать» его.

 -- Untier a particular chunk CALL untier_chunk('_hyper_1_1_chunk');

Вы можете отслеживать, сколько данных было распределено по уровням (и сколько это будет стоить в конце месяца) в консоли Timescale:

Говоря об оценках счетов…

Сколько я могу сэкономить с помощью многоуровневого хранилища?

Эффективная цена нашего высокопроизводительного уровня хранения составляет 0,177 доллара США за ГБ данных в месяц. после сжатия (учитывая ожидаемую степень сжатия, которую мы видим во всем нашем парке). Теперь к этому добавляется недорогой уровень хранения с фиксированной оплатой в размере 0,021 доллара США за ГБ/месяц данных и одинаковой ценой во всех облачных регионах.

При многоуровневом распределении данных вы платите только за хранящиеся данные , а не за выполненные запросы или объем сканированных данных: это действительно фиксированная цена. Наша цель при создании такой структуры ценообразования заключалась в том, чтобы предоставить прозрачный, однозначный и простой способ расчета общей стоимости хранения данных, что упростило бы управление вашими данными.

В качестве быстрого примера предположим, что у вас есть гипертаблица с объемом памяти 5,2 ТБ, причем недавние фрагменты гипертаблицы и другие таблицы Postgres занимают примерно 200 ГБ и около 5 ТБ данных гипертаблицы старше месяца. Вы не часто получаете доступ к этим старым данным и не запрашиваете их, а это означает, что они вам не нужны для повседневной работы вашего приложения. Тем не менее, вы хотели бы, чтобы он был доступен в вашей базе данных для специальных запросов или требований соответствия (мы видим много таких случаев среди наших клиентов).

В качестве экономически эффективной стратегии управления данными вы можете отнести все фрагменты старше месяца к низкозатратному уровню и снизить стоимость хранения этих 5 ТБ данных примерно с 478 долларов США в месяц до примерно 105 долларов США в месяц, что означает снижение на 78%. в вашем счете за хранение. ( Для этой оценки мы предполагаем, что вы включили сжатие для своей гипертаблицы и учитываете медианное общее сжатие во всех службах Timescale).

Экономия будет увеличиваться вместе с вашими данными: при перемещении нескольких терабайт на этот недорогой уровень ваш счет за хранилище уменьшится с тысяч долларов до нескольких сотен. В следующей справочной таблице показано, насколько доступен наш недорогой уровень хранения.

Вы поняли суть!

Эффект мультипликации экономии от многоуровневого хранилища

Есть еще одна вещь, которая делает многоуровневое хранилище еще более удивительным: когда вы храните данные на недорогом уровне хранения, вы платите за эти данные только один раз, независимо от того, есть ли у вас реплика высокой доступности или реплики чтения, работающие в вашем сервисе. .

То же самое касается и вилок. В Timescale вы можете создавать копии вашей основной базы данных (мы называем их ветвями), нажав одну кнопку в пользовательском интерфейсе, например, для запуска тестов или создания сред разработки. При создании одной (или нескольких) вилок вам не будет взиматься плата за данные, совместно используемые с основным хранилищем с низкой стоимостью . Если вы решите разместить больше данных, которых нет на основном уровне, вы заплатите за их хранение на низкозатратном уровне, но вы все равно получите существенную экономию, переместив их с высокопроизводительного уровня вилки на более дешевый уровень. .

Чтобы сделать это кристально ясным, давайте рассмотрим пример. Представьте, что у вас есть основной сервис с 6,5 ТБ данных и вы также установили:

• Реплика высокой доступности, позволяющая значительно снизить риск простоев и потери данных из-за сбоев.

  
  

• Реплика чтения для обслуживания ваших запросов на чтение и позволяет основному серверу полностью посвятить себя записи.

  
  

• Ответвление этого сервиса для целей разработки и тестирования.

  
  

С точки зрения выставления счетов, если вы сохранили 6,5 ТБ данных в своей основной службе на уровне высокопроизводительного хранилища, в счете за хранилище вы увидите отражение [6,5 ТБ x 4] для учета двух реплик, разветвления и основная услуга — всего 26 ТБ. Учитывая нашу среднюю степень сжатия, это будет дорого: около 4602 долларов в месяц.

Но что произойдет, если вашему приложению потребуется активный доступ только к самым последним 500 ГБ данных? Вы можете выделить 6 ТБ на уровне недорогого хранилища и оставить только 500 ГБ на уровне высокопроизводительного хранилища. А поскольку вы платите за данные на недорогом уровне хранения только один раз, ваш новый счет за хранилище будет выглядеть следующим образом:

• [500 ГБ x 4] = 2 ТБ в высокопроизводительном хранилище (вместо 26 ТБ)

  
  

• [6 ТБ x 1] на уровне недорогого хранилища

  
  

Вышеуказанный счет за хранение составит примерно 480 долларов в месяц: вы сэкономите более 4000 долларов в месяц! Это эффект увеличения экономии многоуровневого хранилища. Особенно если вы используете реплики или вилки, это отличная идея — воспользоваться преимуществами недорогого уровня хранения — экономия, которую вы увидите в общем счете, будет очень значительной.

Наше многоуровневое хранилище данных

В марте мы выпустили раннюю версию нашей функции многоуровневого хранилища на платформе Timescale в раннем доступе. После многих улучшений он теперь стал общедоступным. С момента его первого выпуска мы усердно работали над тем, чтобы сделать многоуровневое хранилище стабильным, надежным и быстрым.

Мы также долго и усердно думали о нашей модели ценообразования, последовательно перебирая несколько способов определения цены на наш недорогой уровень хранения данных. Наконец, мы склонились к самому простому: фиксированной ставке за предварительное сжатие объема данных. Мы уже упоминали, что ценим простоту и предсказуемость цен, но для нас также было важно обеспечить как можно более низкую цену за ГБ/месяц. Наша цена составила 0,021 доллара США — для сравнения, хранение файлов на Amazon S3 обходится дешевле. 0,023 доллара США за ГБ/месяц .

Лично я (Яннис) должен признать, что после того, как я возглавлял команды, создающие облачные решения на протяжении более десяти лет, мне все еще приходится возвращаться и время от времени перепроверять несколько таблиц тарифов на различных страницах облачных цен, особенно в поисках дополнительных комиссий, каждый раз, когда Я хочу точно рассчитать общую стоимость наших услуг.

Мы в Timescale считаем, что вам не нужно создавать сложную электронную таблицу, чтобы иметь возможность запускать службу базы данных или делать осознанный выбор уровней хранения.

Наше стремление облегчить жизнь разработчиков привело нас к фиксированной ставке 0,021 доллара США за ГБ в месяц — без догадок, скрытых затрат или платежей за запрос или чтение данных.

Как работает многоуровневое хранилище: за кулисами

Все данные, вставленные в Timescale, изначально записываются на наш высокопроизводительный уровень хранения. Использование более быстрых дисков для самых последних данных обеспечит максимальную производительность вставки и запроса самых последних значений — шаблон использования, который соответствует потребностям приложений с интенсивным использованием данных.

Напротив, недорогой уровень хранения представляет собой объектное хранилище, построенное на Amazon S3. Однако это хранилище объектов — это нечто большее, чем просто внешняя корзина для архивирования ваших данных: это неотъемлемая часть вашей базы данных. Когда вы перемещаете данные на этот уровень хранения объектов, ваша база данных будет полностью осведомлена обо всей семантике и метаданных, и вы сможете продолжать выполнять запросы, как обычно, с помощью стандартного SQL (хотя и с более низкой производительностью).

«За кулисами» мы храним данные в сжатом столбчатом формате (в частности, Apache Parquet ). Когда данные многоуровневые, фрагменты хранятся в собственном внутреннем формате базы данных Timescale (обычно в нашем формате). родное столбчатое сжатие ) асинхронно преобразуются в формат Parquet и сохраняются в базовом объекте S3. Мы создали несколько механизмов, гарантирующих, что многоуровневые фрагменты будут надежно храниться на недорогом уровне хранения перед транзакционным удалением их с высокопроизводительного уровня.

Когда вы запускаете запрос SQL, он прозрачно извлекает данные из уровня высокопроизводительного хранилища, уровня объектного хранилища или обоих, в зависимости от необходимости. Когда мы говорим «прозрачно», мы имеем в виду прозрачность: Timescale поддерживает произвольно сложные запросы к своим стандартным и многоуровневым данным, включая сложные предикаты, JOIN, CTE, оконные функции, гиперфункции и многое другое.

В приведенном ниже примере запроса (с предложением EXPLAIN ) вы можете увидеть, как план запроса включает Foreign Scan , когда база данных обращается к данным с уровня хранилища объектов. В этом примере devices и sites представляют собой стандартные таблицы Postgres (находящиеся только в высокопроизводительном хранилище), а metrics — это гипертаблица, охватывающая оба уровня хранилища. При выполнении этого запроса к гипертаблице metrics три ее фрагмента были прочитаны из стандартного хранилища, а пять фрагментов — из объектного хранилища.

 EXPLAIN SELECT time_bucket('1 day', ts) as day, max(value) as max_reading, device_id FROM metrics JOIN devices ON metrics.device_id = devices.id JOIN sites ON devices.site_id = sites.id WHERE sites.name = 'DC-1b' GROUP BY day, device_id ORDER BY day; QUERY PLAN ---------------------------------------------------------- GroupAggregate Group Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Sort Sort Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Hash Join Hash Cond: (_hyper_5666_706386_chunk.device_id = devices.id) -> Append -> Seq Scan on _hyper_5666_706386_chunk -> Seq Scan on _hyper_5666_706387_chunk -> Seq Scan on _hyper_5666_706388_chunk -> Foreign Scan on osm_chunk_3334 -> Hash -> Hash Join Hash Cond: (devices.site_id = sites.id) -> Seq Scan on devices -> Hash -> Seq Scan on sites Filter: (name = 'DC-1b'::text)

В приведенном выше плане запроса Foreign Scan on osm_chunk_3334 соответствует выборке данных из бездонного уровня хранилища объектов.

Чтобы избежать обработки фрагментов, выходящих за пределы временного окна запроса, мы выполняем исключение фрагментов, чтобы затрагивать только те фрагменты, которые необходимы для удовлетворения запроса. В базе данных хранятся различные формы метаданных для построения «карты» групп строк и смещений столбцов в хранилище объектов.

Более того, когда запрос выполняется, он дополнительно избирательно относится к считываемым данным. Если ваш запрос затрагивает только диапазон строк и несколько столбцов, из объекта S3 за недорогим уровнем хранения считывается только это подмножество данных.

Например, в приведенном выше примере с уровня хранилища объектов считываются только столбцы device_id и value . Если бы был включен дополнительный фильтр WHERE , основанный на времени, база данных сначала использовала бы свои метаданные (хранящиеся в высокопроизводительном хранилище и кэшированные в памяти), чтобы дополнительно сократить количество файлов Parquet и групп строк, которые необходимо прочитать для выполнения запроса. И все это для того, чтобы уменьшить задержку запросов даже при прозрачном доступе к этому бездонному хранилищу через PostgreSQL.

Попробуйте многоуровневое хранилище

Решения о хранении исторических данных не обязательно должны быть дорогостоящими. В Timescale у вас теперь есть доступ к недорогому бесконечному уровню хранения без каких-либо ценовых ошибок, который позволяет масштабировать хранилище базы данных по доступной цене без ущерба для производительности вашего приложения.

Если вам интересно, подойдет ли это решение для вашего случая использования, ознакомьтесь с нашей документацией для получения дополнительной информации и вариантов использования. Если вы ищете более практичную перспективу, вы также можете поэкспериментировать с Многоуровневое хранилище самостоятельно бесплатно на платформе Timescale с помощью нашей бесплатной пробной версии (кредитная карта не требуется) .

- Авторы сценария Яннис Руссос, Карлота Сото и Ана Таварес.