2015-06-03 3 views
2

Я пытаюсь хранить большое количество ежедневных данных о погоде в базе данных postgreSQL. Возможно, это не так, как было бы много данных, но есть примерно 95 000 станций с ежедневными данными, возвращающимися на целых 100 лет. Это может означать много миллионов записей (95 000 * 365 * 100) = 3 467 500 000. Хотя это переоценка, мне все же кажется нецелесообразным хранить все ежедневные данные в одной таблице с идентификаторами станций как сопоставление внешнего ключа в другой таблице с информацией о станции. Каким будет лучший способ структурировать эти данные для запроса серии данных по станции? Должен ли я создать таблицу для каждой станции (привел бы к 95 000 таблиц), или я должен попробовать что-то более широкое, как таблица для каждого региона? Какие преимущества и недостатки? Любая помощь приветствуется.SQL Оптимальная структура базы данных: данные NOAA

Мои данные выглядит следующим образом:

Stations 
*ID 
-longitude 
-latitude 
-elevation 
-country 
-state 
-name 
... 

Weather 
*Station ID 
*Date 
-Precipitation 
-High Temp 
-Low Temp 
+0

Почему бы не использовать разбивку таблиц? База данных заботится о создании и обслуживании 95000 отдельных таблиц для вас: http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html –

+1

Увы, в PostgreSQL нет встроенного разбиения на разделы, вы должны в основном сворачивать свои собственные или использовать внешние инструменты, такие как pg_partman. Он также плохо масштабируется для многих сотен или тысяч таблиц. Я сильно подозреваю, что лучший вариант - это упростить вещи с помощью нескольких больших таблиц. –

+0

Разделение по дате кажется наиболее логичным. В 34M строк/год; это может быть в год или на 5 или 10 лет. – wildplasser

ответ

2

Это на самом деле не хватает информации.

Что вы оптимизируете для: производительности запросов, использования диска, скорости обновления?

  • Какие у вас есть вопросы?
  • Вы обычно выбираете все данные для станции (кажется маловероятной)? Диапазон дат?
  • Если вы запрашиваете по дате, каково обычно разрешение: день, месяц, год?
  • Это все поля в таблице «погода», или это просто образец?
  • Обычно вы извлекаете одно значение или много разных?
  • Вы просто извлекаете эти значения или выполняете агрегацию/аналитику в базе данных?
  • Что такое приемлемая производительность запроса для вас?

В зависимости от ваших ответов на это может иметь смысл «связывать» ваши данные (хранить больше одного дня за запись, я предполагаю, что «дата» означает, что это один день, или это более гранулированный?), чтобы уменьшить общее количество строк. Postgres имеет относительно высокие накладные расходы на строку - по вашим оценкам, только заголовки строк будут занимать ~ 75 ГБ.

В качестве альтернативы, вы можете исследовать что-то вроде этого: https://github.com/citusdata/cstore_fdw

Преимущества использования более таблиц меньшего размера индекса и (возможно) физическое местонахождение данных. В крайнем случае одной таблицы на станцию_ид (не практично в вашем случае), вам не понадобится индекс на station_id вообще, и запрос может оказаться простым сканированием seq по необходимым вам данным.

Недостатки в том, что многие операции db связаны с линейным сканированием по всем таблицам (особенно во время планирования) и большей сложностью управления базой данных.

Типичным советом является сохранение количества столов в несколько сотен до , возможно, несколько тысяч. Если, конечно, у вас нетипичный случай, и вы его протестировали, и он работает для вас.

Смежные вопросы