Повреждение данных: как его избежать, обнаружить и обеспечить восстановление

Повреждение данных в PostgreSQL может происходить по ряду причин, в числе которых аппаратные ошибки, программные сбои и ошибки пользователя. В данном докладе я расскажу о своём опыте работы с повреждёнными базами. В частности, я упомяну о частых причинах повреждения данных в базе, среди которых процедурные ошибки при снятии резервных копий или восстановлении из них. Также я остановлюсь на частых последствиях повреждения данных в базе - например, ошибках, которые говорят о несоответствии между таблицей и ее индексами либо таблицей и TOAST-таблицей. Также я уделю некоторое внимание техникам, которые используют для восстановления базы или исправления ошибок после повреждения данных, в том числе моему опыту использования pg_resetxlog. Основой для данного доклада послужили реальные кейсы, с которыми я сталкивался в ходе работы с клиентами EnterpriseDB. Надеюсь, что они будут полезны разработчикам PostgreSQL для возможных улучшений этой СУБД, а пользователи получат представление о том, как избежать повреждения данных, обнаруживать его, если оно произошло, и справляться с ним.

Шардман - естественный подход к шардингу в PostgreSQL

Объем данных, с которым работают современные корпоративные и интернет системы, постоянно растет. При этом все сложнее становится иметь и синхронизировать несколько копий данных в разных системах. Возникает необходимость работать с большими объемами данных непосредственно в транзакционной СУБД, Часто такое требование накладывает и логика приложений, которым необходимы результаты в реальном времени. В докладе рассмотрим какой может быть универсальная распределенная транзакционная СУБД. Разберем такие аспекты как типы нагрузки и их приоритизация, динамическое выделение ресурсов, уровень консистентности. Расскажем на каких инструментах в PostgreSQL можно построить такую систему, что у нас уже получилось и какие задачи еще предстоит решить.

NORM - фреймворк без ORM

Хорошо известно, что, хотя производительность базы данных велика и каждый запрос выполняется за миллисекунды, общее время отклика приложения может быть медленным, поэтому пользователи могут долго ждать ответа. Мы знаем, что проблема не в базе данных, а в том, как разработчики приложений с ней общаются. В частности, речь идет об ORM - Object-Relational Mappers. Разработчики баз данных ненавидят их, но разработчики приложений любят их, потому что они позволяют разрабатывать приложения без каких-либо знаний о внутреннем устройстве СУБД. В результате производительность системы часто оказывается неприемлемо низкой.

Единственный способ изменить это - предоставить разработчикам приложений такой же простой в использовании инструмент, как ORM, но позволяющий избежать распространенных ошибок ORM. Вот почему мы разработали NORM - No-ORM Framework. Во время этой презентации мы рассмотрим примеры кода из репозитория https://github.com/hettie-d/NORM и узнаем, как создавать «транспортные объекты» для эффективной передачи данных между приложениями и базами данных.

Управление данными подвижных объектов с MobilityDB

MobilityDB - это расширение PostgreSQL and PostGIS для работы с движущимися объектами. В нём определяются типы данных и функции для полноценной работы с геопространственными траекториями. Основной тип данных - tgeompoint (темпоральная геометрическая точка). Она представляет собой полную траекторию движения точки - автомобиля, птицы или человека. Функция speed(tgeompoint) вычисляет скорость точки как функцию времени, в форме tfloat (темпоральное число с плавающей точкой). Подобным образом в MobilityDB определяется 6 темпоральных типов и около 300 функций. Благодаря этому, MobilityDB представляет собой весьма функциональную платформу для управления подвижными данными.

В этом мастер-классе Вы:

• узнаете о базах данных подвижных объектов
• напишете SQL запросы для MobilityDB для изучения базы траекторий объектов
• ознакомитесь с типами данных, функциями и индексами MobilityDB.