MobilityDB: расширение PostgreSQL для управления мобильными данными

В ходе доклада мы представим MobilityDB - расширение PostgreSQL, которое раздвигает границы системы типов в PostgreSQL и PostGIS на абстрактные данные для адекватного представления изменяющихся данных об объектах. Эти типы данных могут представлять эволюцию во времени значений некоторого типа элементов, называемого базовым темпоральным типом. Например, темпоральный целочисленный тип данных может использоваться для демонстрации изменения во времени количества сотрудников департамента. В данном случае базовым типом данных будет целочисленный или темпоральный целочисленный. Аналогично, темпоральный тип данных с плавающей точкой может использоваться для записи изменения во времени температуры в помещении или местоположения автомобиля по GPS-координатам. Темпоральные типы данных оказываются полезны, поскольку для работы многих приложений, например, мобильных, принципиально необходимо обрабатывать изменяющиеся во времени величины.

В расширении MobilityDB темпоральные типы данных основаны на булевых, целочисленных, с плавающей точкой и текстовых типах данных от PostgreSQL, а также на геометрических и географических типах данных от PostGIS (ограниченных размерностью 2D или 3D). MobilityDB соответствует действующим стандартам по перемещаемым объектам OGC http://www.opengeospatial.org/standards/movingfeatures, в частности, OGC Moving Features Access, в котором определены операции, применимые к изменяющимся во времени геометриям.

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

• Пожизненные функции и операторы: операторы над базовыми типами (такие как арифметические операции над целыми числами и числами с плавающей точкой, пространственные отношения и расстояния для геометрий) интуитивно обобщаются на случай изменяющихся во времени значений. Пространственно-темпоральные функции в MobilityDB обобщают пространственные функции PostGIS как для геометрических, так и для географических типов данных, к примеру для "ST_Intersection". На базовом уровне, MobilityDB принимает в расчет аспект темпоральности и делегирует обработку пространственных данных в PostGIS.
• Темпоральные функции и операторы обрабатывают изменяющиеся во времени размерности величины, которая может представлять собой единичное значение, диапазон значений, массив значений или массив диапазонов. Примерами являются функции периодов, которые ограничивают темпоральный тип заданным массивом временных диапазонов, а также функции продолжительности, которые извлекают время определения значения величины.
• Пространственно-темпоральные функции и операторы - в эту категорию попадают все остальные функции. Примеры: speed(tgeompoint/tgeogpoint), azimuth(tgeompoint/tgeogpoint), maxValue(tfloat/tint), взвешенное по времени среднее twAvg(tfloat) и т.д.

Как GiST, так и SP-GiST индексы были расширены для поддержки темпоральных типов данных. Индекс GiST реализует R-дерево для темпоральных численно-буквенных типов данных, а TB-дерево - для темпоральных координат. Индекс SP-GiST реализует Quad-дерево для темпоральных численно-буквенных типов данных, а Oct-дерево - для темпоральных координат. Подход, использованный в MobilityDB при разработке SP-GIST индекса, позволил нам добавить индексы SP-GIST для двумерных, трехмерных и n-мерных геометрий в PostGIS.

Доступны два типа числовых функций аггрегирования. В дополнение к традиционным функциям min, max, count, sum, and avg, теперь есть и их оконные версии (также известные как кумулятивные). Для заданного промежутка времени w, оконная аггрегативная функция вычисляет значение функции в момент времени t, принимая в расчет значения на интервале [t − w, t]. В противоположность стандартной аггрегации, темпоральная аггрегация может возвращать результат большего размера, чем входящие данные. По этой причине темпоральные функции аггрегирования были подвергнуты жесткой оптимизации, чтобы обеспечить их эффективную работу.

В MobilityDB также есть предварительная реализация функций сбора статистики и селективности для темпоральных типов данных.

С точки зрения размера, расширение состоит из 67k строк кода на C, 19k строк SQL кода и 67k строк модульных тестов SQL. В нем определены 40 типов, 2300 функций и 1350 операторов.

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

Типичные ошибки при построении высокодоступных кластеров и как их избежать

Вы только что установили PostgreSQL и запустили ваш первый кластер, создали несколько таблиц, загрузили данные, и даже немного подкрутили конфигурацию Постгреса для улучшения производительности. Теперь вы думаете о том, как сделать ваш кластер высокодоступным. К сожалению, Постгрес не умеет сам выполнять автоматическое переключение при недоступности мастера, но, к счастью для нас, этого можно достичь с помощью сторонних утилит. Задача ясна, и вы начинаете изучать преимущества и недостатки всех утилит, чтобы выбрать лучшую. И... вы уже на неправильном пути, потому что в первую очередь вы должны определиться со значениями SLA, RTO и RPO. В этом докладе я планирую рассказать о ряде ошибок, которые допускают администраторы баз данных при настройке и эксплуатации высокодоступного кластера Постгреса с автоматическим переключением.

1С:Предприятие и PostgreSQL

• 1С:Предприятие -как среда кросс-платформенной разработки бизнес-приложений
• 1С и PostgreSQL - вместе с 2006 года
• Работа 1С с PostgreSQL в облачном сервисе 1cFresh
• Что улучшено в платформе 1С:Предприятие для работы с PostgreSQL - Общие рекомендации по работе 1С с PostgreSQL.

GreenHouseSQL - масштабируемая система аналитики на postgresql, greenplum и clickhouse

На pgconf’17 я рассказывал про нашу велосипедную систему аналитики на основе PostgreSQL. После этого мы посматривали в сторону хадупов, s3, престо, друидов, вертики, пентахо и прочих страшил. А потом перестали cтрадать и сомневаться и просто добавили к постгресу готовые Greenplum и Clickhouse. Получив в итоге потрясающую скорость, простую миграцию, простое обслуживание, надежность и горизонтальное масштабирование, восстановление после сбоев в две команды, уменьшение костов на инфрастуктуру и широкие функциональные возможности за счет сочетания ANSI SQL, MPP и In-memory. Оставаясь в парадигме Open-source и полноценного SQL. В итоге у нас получилось то, что мы назвали GreenHouseSQL - наша внутренняя платформа данных полного цикла. В докладе вскроем простоту внутренностей решения и рассмотрим компоненты стека под микроскопом, расскажем об их достоинствах и недостатках, фишках начала работы с Greenplum, зачем нам Clickhouse, что осталось PostgreSQL'у и как вообще все это работает.