У меня есть большое количество данных модели погоды, помещаемых в базу данных PostgreSQL. Машина имеет 8 ядер и 16 ГБ оперативной памяти. Я использую PostgreSQL 9.3 с PostGIS 2.1. Каждая таблица будет иметь различные данные о погоде (температура, точка росы, ветер и т. Д.). В каждой таблице будет 6-7 столбцов: широта, долгота, геометрия точек, высота, дата и время, к которым относится модель, и 1-2 значения данных, представляющих интерес. Данные будут в первую очередь запрашиваться для ограничительной рамки по времени и высоте. В таблице будет приблизительно 145 757 360 строк (данные, более старые, чем сейчас, более неактуальны, будут удалены). Я приблизительно оцениваю размер таблиц примерно в 10 ГБ каждая без индексов. (Это 52 байта данных плюс 23 байта служебной информации на строку). Данные будут регулярно обновляться / вставляться по мере поступления новых данных модели. Замечания:
Итак, я смотрю на эти два плана:
- Просто индексируйте и группируйте по (datetime, elevation) с дополнительным индексом для геометрии точки. Запустите обычное задание cron, которое удаляет старые строки, запускает вакуум / анализ и повторную кластеризацию.
- Разделение по дате и времени, затем кластеризация и индексирование по высоте для таблицы с индексом по геометрии. Запустите обычное задание cron для добавления новых таблиц и удаления старых таблиц.
Дальше,
- Итак, я знаю, что удаление таблицы намного эффективнее, удаление и очистка. Но в противном случае я бы увидел повышение производительности?
- Являются ли разделы подходящими, когда все таблицы будут равномерно обновляться и выбираться до тех пор, пока не будут удалены как неактуальные (в документации указывалось, что разделы работали лучше всего, когда только несколько из них были выбраны)?
При доставке данных выбор будет быстрее, чем кластерный индекс? Меняется ли ответ, если делается несколько запросов одновременно?
Спасибо. Я надеюсь выложить все необходимые данные. Если нет, дайте мне знать, и я добавлю это.
xminилиxmax, и т. д. Есть функция, которая может превратить вас в 9.4, которая, вероятно, заинтересует вас, называется minmax indexes, которая сделает такие вещи намного удобнее.Ответы:
Учитывая все вышесказанное, я бы выбрал вариант 2. Даты будут выбраны равномерно, но я собираюсь предположить, что для данного запроса будут задействованы только один или два раздела даты. Жаль, что вы не можете кластеризоваться на геолокации и разбивать на даты, что было бы идеально. Высота в любом случае имеет тенденцию коррелировать с геолокацией, если ограничивающие рамки достаточно малы.
С учетом имеющегося выбора хорошо иметь более чистые операции с данными и избегать ежедневного вакуума.
Доставка вариантов может быть быстрее с вариантом 1, хотя я подозреваю, что это, вероятно, будет стирка. При выборе варианта 1 записи с одинаковыми датой и высотой размещаются рядом друг с другом в одном большом кластерном индексе. При выборе варианта 2 записи с одинаковыми датой и высотой размещаются рядом друг с другом во многих небольших кластеризованных индексах.
источник