Рекомендации по дублированию таблиц базы данных

Question

У меня постоянный поток данных. Все данные должны храниться в базе данных с отметкой времени. Данные поступают с интервалом в 5 минут, и за тот же интервал производится выбор последних данных в псевдо-SQL-коде:

SELECT * FROM TB_TABLE WHERE TIMESTAMP = MAX(TIMESTAMP)

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

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

Обновление Кстати, я использую MS SQL Server 2005 и .NET C # Linq-To-Sql

Answer 1

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

Предполагая, что вашей главной заботой является производительность выбора для большой таблицы, такие шаги, как применение хороших индексов и замена "select *" только теми столбцами, которые вы хотите, лучше начать, чем дублирование данных в нескольких таблицах. Если бы в ваших запросах было значительное количество объединений, я бы заметил, что это отрицательно сказывается на вашей эффективности. В этом случае хорошей дополнительной оптимизацией будет создание дополнительной таблицы, исключающей необходимость объединений в ваших запросах.

Answer 2

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

Answer 3

Интересно, было бы полезно разбиение таблицы? Я лично не использовал его, поэтому не могу сказать по опыту, но это похоже на соответствующую ситуацию, в которой его можно использовать.

Answer 4

Вы не упомянули, какую базу данных вы используете, но я могу вспомнить пару возможных быстрых оптимизаций. Сколько гигабайт мы говорим?

1) Расчет max (отметка времени) может быть дорогим, учитывая большое количество строк. Вы, наверное, уже знаете, что это за значение, сохраните его в другой таблице, в файле конфигурации или в другом месте. Это, вероятно, будет вашей самой большой оптимизацией.

2) Добавьте еще один столбец, чтобы отметить последние обновления. Когда вы начнете обновление SET недавний = false, ГДЕ недавний = true, запишите все свои записи с последним = true. Вы можете ограничить размер вашего индекса, добавив к нему условие where CREATE INDEX foo_index для "TB_TABLE" (недавний), ГДЕ недавний = true;

3) Убедитесь, что ваш сервер БД правильно оптимизирован. Убедитесь, что ваш ключевой и сортировочный буферы имеют соответствующий размер для вашего набора данных. Большинство баз данных с открытым исходным кодом предварительно настроены для рабочей станции разработчика, а не для рабочей нагрузки.

4) Пересмотрите свою схему. Вы уверены, что вам нужны все ваши записи? Вы записываете все данные, а не только данные, которые изменились? В этой ситуации я хорошо использовал две временные метки: одну временную метку для последней загрузки и одну временную метку для последнего изменения.