Хранение и запрос скользящих данных в PostgreSQL

У меня есть большое количество данных модели погоды, помещаемых в базу данных PostgreSQL. Машина имеет 8 ядер и 16 ГБ оперативной памяти. Я использую PostgreSQL 9.3 с PostGIS 2.1. Каждая таблица будет иметь различные данные о погоде (температура, точка росы, ветер и т. Д.). В каждой таблице будет 6-7 столбцов: широта, долгота, геометрия точек, высота, дата и время, к которым относится модель, и 1-2 значения данных, представляющих интерес. Данные будут в первую очередь запрашиваться для ограничительной рамки по времени и высоте. В таблице будет приблизительно 145 757 360 строк (данные, более старые, чем сейчас, более неактуальны, будут удалены). Я приблизительно оцениваю размер таблиц примерно в 10 ГБ каждая без индексов. (Это 52 байта данных плюс 23 байта служебной информации на строку). Данные будут регулярно обновляться / вставляться по мере поступления новых данных модели. Замечания:

Итак, я смотрю на эти два плана:

Просто индексируйте и группируйте по (datetime, elevation) с дополнительным индексом для геометрии точки. Запустите обычное задание cron, которое удаляет старые строки, запускает вакуум / анализ и повторную кластеризацию.
Разделение по дате и времени, затем кластеризация и индексирование по высоте для таблицы с индексом по геометрии. Запустите обычное задание cron для добавления новых таблиц и удаления старых таблиц.

Дальше,

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

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

Спасибо. Я надеюсь выложить все необходимые данные. Если нет, дайте мне знать, и я добавлю это.

— bshender
источник

Ох, эти узкие строки - то, где большие заголовки строк в PostgreSQL начинают действительно болеть. Жаль, что на самом деле не так много, что можно удалить; это не то, что мы можем проиграть xminили xmax, и т. д. Есть функция, которая может превратить вас в 9.4, которая, вероятно, заинтересует вас, называется minmax indexes, которая сделает такие вещи намного удобнее.

— Крейг Рингер

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

— AK

Только незначительно. Геометрия PostGIS - это двоичный массив, не читаемый человеком. Я мог бы получить эти значения на выходе, но тогда я не мог кластеризовать их. Я мог бы использовать GeoHash для кластеризации, но это уже не читабельно, чем в латоне. Но в любом случае космос не проблема. Они предложили столько террабайт, сколько я могу заполнить. Проблема в том, что я не могу запросить террабайты на скорости. Сама база данных будет в основном нетранзакционной. Только два сценария будут иметь доступ на запись вообще. Все остальное только для чтения.

— bshender

Крейг: Они кажутся интригующими, и я с нетерпением жду экспериментов с ними, когда они выйдут. Есть какие-нибудь мысли о моей настройке в 9.3?

— bshender

Не могли бы вы предоставить две части информации, пожалуйста: 1) Что для вас наиболее важно: скорость вставки или скорость запроса? 2) Какие запросы являются наиболее распространенными?

— Томас Кейсер,

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

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

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

— Карлос Буэно
источник