Зберігання та запит прокручених даних у PostgreSQL

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

Тож я дивлюся на ці два плани:

1. Просто індексуйте та кластеризуйте (дату, висоту) з додатковим індексом для геометрії точки. Запустіть звичайну роботу cron, яка видаляє старі рядки, виконує вакуум / аналіз та повторно кластеризує.
2. Розділення за датою, а потім кластером та індексом по висоті в таблиці з індексом геометрії. Виконайте звичайну роботу cron, щоб додати нові таблиці вперед і скинути старі таблиці.

Далі,

• Отже, я знаю, що викидання таблиці набагато ефективніше, а також видалення та пилосос. Але я б побачив підвищення продуктивності в іншому випадку?
• Чи підходящі розділи, коли всі таблиці будуть рівномірно оновлюватися та вибиратись до тих пір, поки не будуть видалені як неактуальні (документація вказує на те, що розділи працювали найкраще, коли на них буде вибрано лише декілька)?

При наданні даних вибір буде швидше, ніж кластерний індекс? Чи змінюється відповідь, якщо одразу надходить кілька запитів?

Дякую. Я сподіваюся, що я зібрав усі необхідні дані. Якщо не дайте мені знати, я додам його.

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

З огляду на вибір, корисніше робити чистіші операції з передачею даних та уникати щоденного вакууму.

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