Как повысить производительность при ведении исторических и текущих данных? - PullRequest
2 голосов
/ 20 апреля 2009

Я хочу сохранить данные о фондовом рынке за последние десять лет в одной таблице. Для определенного анализа нужны только данные за последний месяц. Когда я делаю этот краткосрочный анализ, для завершения операции требуется много времени.

Чтобы преодолеть это, я создал еще одну таблицу для хранения данных за текущий год. Когда я выполняю анализ из этой таблицы, он в 20 раз быстрее предыдущего.

Теперь мой вопрос:

  1. Это правильный способ иметь отдельную таблицу для такого рода проблем. (Или мы используем отдельную базу данных вместо таблицы)
  2. Если у меня отдельная таблица. Есть ли способ автоматически обновить вторичную таблицу.
  3. Или мы можем использовать что-либо вроде дематериализованного представления или что-то подобное для повышения производительности.

Примечание: я использую базу данных Postgresql.

Ответы [ 5 ]

5 голосов
/ 20 апреля 2009

Вы хотите разбиение таблицы . Это автоматически разделит данные между несколькими таблицами и в целом будет работать намного лучше, чем делать это вручную.

4 голосов
/ 20 апреля 2009

Я работаю над тем же вопросом.
Разделение таблиц определенно является подходом. Я бы сегментировал более чем на год, но это дало бы вам большую степень контроля. Просто настройте свои разделы, а затем ограничьте их месяцами (или другой датой). В вашем postgresql.conf вам нужно включить constraint_exclusion =, чтобы действительно получить выгоду. Дополнительным преимуществом здесь является то, что вы можете индексировать только те таблицы, из которых вы действительно хотите получить информацию. Если вы выполняете пакетный импорт больших объемов данных в эту таблицу, вы можете получить несколько лучшие результаты: «Правило против триггера», а для разбиения я считаю, что правила проще поддерживать. Но для небольших транзакций триггеры гораздо быстрее. В руководстве по postgresql есть большой раздел, посвященный разделению с помощью наследования.

0 голосов
/ 21 апреля 2009

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

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

Другие меры, такие как разделение, идут после этого ...

0 голосов
/ 20 апреля 2009
  1. вполне разумно использовать отдельную таблицу для исторических записей. С отдельной базой данных гораздо сложнее, так как не так просто писать запросы к базе данных
  2. автоматические обновления - это инструмент для cronjob
  3. вы можете использовать частичные индексы для таких вещей - они прекрасно справляются с работой
0 голосов
/ 20 апреля 2009

Я не уверен насчет PostgreSQL, но могу подтвердить, что вы на правильном пути. Когда вы имеете дело с большими объемами данных, разделяя данные на несколько таблиц и затем используя какой-то генератор запросов для построения ваших запросов, это абсолютно правильный путь. Этот подход хорошо зарекомендовал себя в хранилищах данных, особенно в данных о вашем фондовом рынке.

Однако мне любопытно, зачем вам обновлять исторические данные? Если вы имеете дело с разделением акций, то обычно это реализуют, используя отдельную таблицу коэффициентов, которая используется вместе с необработанными историческими данными для получения точной цены / доли.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...