Стратегии уменьшения размера базы данных в PostgreSQL: подход, основанный на использовании

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

Помимо нюансов при оценке цен на базы данных (например, «Насколько увеличивается счет по мере роста моих данных?», «Взимается ли с меня плата за запись или чтение?» и «Придется ли мне платить больше за резервное копирование?» ), разработчики склонны упускать из виду один аспект: то, как структурирована модель ценообразования базы данных, будет влиять на то, как вы управляете своими данными и оцениваете размер базы данных Postgres.

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

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

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

Модели хранения на основе использования становятся все более популярными в мире баз данных — кто захочет платить за неиспользуемое дисковое пространство? Тем не менее, модель, основанная на использовании, не обходится без последствий, и вам необходимо учитывать некоторые передовые методы для эффективной работы с ней.

Краткий обзор моделей хранения данных PostgreSQL

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

Начиная со вчерашнего дня (💥), мы предлагаем два типа услуг баз данных на платформе Timescale:

• Динамические службы PostgreSQL , где разработчики могут создавать базы данных PostgreSQL с динамическими вычислениями, чтобы сэкономить деньги без ущерба для производительности.

  
  

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

  
  

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

• Разработчики платят за объем, который они используют, без мелкого шрифта — без минимального размера базы данных и минимальных шагов масштабирования. Если к концу месяца вы израсходуете 128 ГБ, вам будет выставлен счет за эту сумму. Вы можете начать с 1 ГБ и увеличить до ТБ.

• Плата за запись данных, передачу данных или выполнение запросов не взимается.

• Нет необходимости выделять хранилище при создании базы данных или масштабировании.

• Нет необходимости вручную уменьшать размер дисков.

  
  

Чтобы лучше понять это, давайте рассмотрим различия между этой моделью, Amazon RDS PostgreSQL и Amazon Aurora:

Подводя итог, вот три основных вывода из нашего сравнения:

• И Timescale, и Aurora взимают плату за фактический размер базы данных. Напротив, RDS PostgreSQL взимает плату за выделенное хранилище. Вы не можете уменьшить размеры томов в RDS.

  
  

• Timescale не взимает плату за запись данных, передачу данных или операции запросов. И RDS, и Aurora взимают плату за передачу данных, дополнительное хранилище резервных копий, и вы можете понести некоторые дополнительные расходы на ввод-вывод, в зависимости от того, какой тип хранилища вы выбираете.

  
  

• Timescale не имеет минимальных шагов масштабирования, тогда как Aurora масштабируется с шагом 10 ГБ после начала с 10 ГБ.

  
  

Как видите, модель Timescale ближе к Aurora, оптимизированная для ввода-вывода с той разницей, что в Timescale отсутствуют этапы масштабирования и дополнительная плата за такие вещи, как передача данных. Напротив, RDS является хорошим представлением модели, основанной на распределении, даже если В RDS отсутствуют «уровни хранения» традиционно встречается у поставщиков баз данных, работающих по этой модели.

Как ценообразование на основе использования улучшает управление хранилищем PostgreSQL

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

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

Модели, основанные на использовании, устраняют проблему избыточного выделения ресурсов хранилища.

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

Вам не нужно думать о хранилище при масштабировании

«Хранилище Timescale, основанное на использовании, означает, что мне больше не нужно думать о размере диска. Наши затраты на хранение снизились на 30 %, и мне не пришлось ничего делать!»

Адам МакКри, Дзюдомасштаб (Сроки клиента)

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

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

Вы можете уменьшить масштаб (перестать платить за удаленные данные)

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

Как эффективно использовать модель, основанную на использовании: советы по уменьшению размера базы данных Postgres

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

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

В каком-то смысле это можно считать «недостатком» моделей, основанных на использовании, и это требует некоторой работы, но на самом деле это скрытое благо. В традиционных моделях, основанных на распределении данных, гигиеной данных можно несколько пренебрегать, поскольку затраты фиксированы: если вы привязаны к диску емкостью 500 ГБ в RDS, а размер вашей базы данных составляет 200 ГБ, у вас, похоже, нет большого стимула сделать использование хранилища более эффективным.

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

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

Уменьшите раздувание базы данных PostgreSQL.

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

• Отслеживайте мертвые кортежи. Проактивный подход к оптимизации хранилища PostgreSQL начинается с пристального наблюдения за мертвыми кортежами. Мертвые кортежи, если их не контролировать, могут накапливаться и приводить к ненужным затратам на хранение. Расширение pgstattuple() может оказаться отличным помощником в понимании того, как таблицы управляют этими кортежами.

  
  

• Часто пылесосьте. Чтобы эффективно бороться с раздуванием таблицы, возможно, вам захочется настроить более частый запуск автоочистки. Вместо глобальной настройки параметров автоочистки в postgresql.conf более точно настроить эти параметры для каждой таблицы. Это учитывает тот факт, что разные таблицы могут иметь разные тенденции к накоплению мертвых кортежей. Также крайне важно отслеживать длительные транзакции, которые могут препятствовать операциям автоочистки.

  
  

• Восстановите неиспользуемые страницы. Хотя автоочистка и вакуумирование устраняют мертвые кортежи, восстановление неиспользуемых страниц требует другого подхода. Хотя для этой цели можно использовать команду VACUUM FULL, она имеет неотъемлемое ограничение, связанное с блокировкой всей таблицы. Pg_repack может помочь вам в этом.

Выполните тонкую настройку PostgreSQL

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

• shared_buffers : управляет памятью, используемой для страничного кэша PostgreSQL, и обычно составляет 25 % от общего объема оперативной памяти системы.

  
  

• work_mem : устанавливает объем памяти, выделяемой для каждой операции в запросе. В Timescale рекомендуемая настройка — (25 % of RAM) / max_connections .

  
  

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

  
  

• max_worker_processes : определяет максимальное количество рабочих процессов, которые PostgreSQL может инициировать. При использовании Timescale формула для установки этого параметра следующая: max_worker_processes = 3 + timescaledb.max_background_workers + max_parallel_workers .

  
  

• max_parallel_workers : указывает максимальное количество рабочих процессов, поддерживающих параллельные запросы. По умолчанию это значение равно количеству доступных процессоров.

  
  

• autovacuum_max_workers : определяет максимальное количество одновременных процессов автоочистки. В шкале времени по умолчанию установлено значение 10.

Практикуйте гигиену индексации

Регулярная оптимизация индексов поможет поддерживать эффективность вашего PostgreSQL, особенно при масштабировании базы данных. Хотя индексы могут помочь вам повысить производительность запросов при разумном использовании, чрезмерные индексы могут создать проблемы в больших развертываниях PostgreSQL.

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

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

Один из способов сделать это — использовать pg_stat_user_indexes :

 -- Retrieve indexes that might not be used or are infrequently used SELECT schemaname, relname AS table_name, indexrelname AS index_name, idx_scan AS times_used FROM pg_stat_user_indexes WHERE idx_scan = 0 OR idx_scan < some_low_threshold -- replace 'some_low_threshold' with a value that makes sense for your context ORDER BY idx_scan ASC, schemaname, relname;

Если индекс имеет значение 0 в столбце idx_scan, это означает, что он не использовался с момента последнего сброса статистики, а это означает, что он может быть кандидатом на оптимизацию. Установив низкий порог для idx_scan , вы также можете идентифицировать редко используемые индексы.

Уменьшите большие таблицы с помощью сжатия шкалы времени.

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

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

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

 -- Enable compression on the hypertable ALTER TABLE your_hypertable SET ( timescaledb.compress, timescaledb.compress_segmentby = 'some_column' ); -- Set a compression policy to compress data older than two weeks SELECT add_compression_policy('your_hypertable', INTERVAL '2 weeks');

Чтобы узнать больше о сжатии, ознакомьтесь с нашей документацией .

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

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

Создав простую политику многоуровневого хранения, вы можете переместить старые, менее доступные данные на бездонный уровень хранения объектов:

 -- This policy moves all data older than one month to object storage SELECT add_tiering_policy('example', INTERVAL '1 month);

Это хранилище объектов имеет следующие характеристики:

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

Эта многоуровневая архитектура хранения встроена в серверную часть Timescale. Объектное хранилище — это не «корзина», отделенная от вашей базы данных, а ее неотъемлемая часть. Запросы будут прозрачно обращаться к обоим уровням хранения без каких-либо действий с вашей стороны — вы можете просто продолжать использовать стандартный SQL в той же схеме. После того как ваша политика многоуровневого распределения установлена, вам больше не о чем думать!

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

Помимо предложения этого недорогого уровня хранения, Timescale позволяет легко настроить политики хранения данных для удаления ненужных данных:

 -- Set a data retention policy to drop data older than 10 months SELECT add_retention_policy('your_hypertable', INTERVAL '10 months');

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

Модели, основанные на использовании, и парадигма управления данными

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

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

В Timescale есть ценные инструменты, которые помогут вам систематически уменьшать размер базы данных PostgreSQL, такие как сжатие, многоуровневое хранение и политики хранения данных. Это позволяет вам эффективно масштабировать базы данных PostgreSQL в модели, основанной на использовании. Чтобы испытать это на себе, зарегистрируйтесь в Timescale — вы можете использовать его бесплатно в течение первых 30 дней. .

- Автор Карлота Сота .