Лучшая практика для хранения миллионов строк с помощью TSQL (Sql Server 2008)

Question

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

Что я хочу сделать, так это сохранить некоторую информацию в базе данных.По сути, данные будут выглядеть так:

• SensorNumber (int)

• Чтение (int)

• Метка времени (Datetime?) (Я просто хочу отследить до минуты, больше ничего не нужно)

Единственное, в этом заключается то, что за несколько месяцев отслеживания у меня будет миллионы строк (~ 5 миллионов строк).

Меня действительно интересует только поиск по метке времени и / или номеру датчика.Приведенные здесь данные практически никогда не будут редактироваться (вставить один раз, прочитать много раз).

Как мне построить это?Есть что-то особенное, что я должен сделать, кроме создания таблицы?и создать один индекс для SensorNumber и Temp?

Answer 1

Исходя из вашего комментария, я бы поставил кластеризованный индекс на (Sensor, Timestamp).

Это всегда будет охватывать, когда вы хотите искать только SENSOR, но также охватывать оба поля, отмеченные в комбинации.

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

Одна из проблем, с которой вы столкнетесь в этом проекте, - это необходимость перестроить таблицу, поскольку выбудет вставлять строки не последовательно - новые строки не всегда будут принадлежать в конце индекса.

Также, пожалуйста, не называйте поле timestamp - это ключевое слово в SQL Server иможет вызвать у вас всевозможные проблемы, если вы не разграничите его повсюду.

Answer 2

Вы определенно хотите использовать SQL-сервер " кластеризованный индекс " для наиболее избирательных данных, по которым вы, вероятно, будете искать.

Вот больше информации:

• http://www.sql -server-performance.com / 2007 / кластерный-индексы /

• http://odetocode.com/articles/70.aspx

• http://www.sql -server-performance.com / 2002 / индекс-не равно /

РАЗРАБОТКА:

• «Датчик» был бы плохим выбором - у вас, вероятно, мало датчиков, много рядов. Это не будет отличительным показателем.

• «Время» будет отличительным ... но это также будет плохой выбор. Поскольку само время, независимо от датчика, температуры и т. Д., Вероятно, не имеет смысла для вашего запроса.

• Кластерный индекс «датчик, время» может быть идеальным. А может и нет - это зависит от того, что вы ищете.

• Пожалуйста, просмотрите вышеуказанные ссылки.

PS:

Пожалуйста, также рассмотрите возможность использования "datetime" вместо "timestamp". Это два совершенно разных типа в MSSQL ... и «datetime», пожалуй, лучший, более гибкий выбор:

http://www.sqlteam.com/article/timestamps-vs-datetime-data-types

Answer 3

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

Кластерный индекс определяет порядок хранения данных, добавление в конец дешевле, чем вставка в середину.

Подумайте о колоде карт, которую вы пытаетесь держать в порядке ранга, когда добавляете карты. Если самый высокий ранг 8, добавление 9 тривиально - поместите его наверх. Если вы добавляете 5, он становится более сложным, вам нужно решить, где его поставить, а затем вставить.

Таким образом, добавление элементов с кластеризованным индексом по порядку является оптимальным.

Учитывая, что я хотел бы предложить кластерный индекс в (Timestamp, Sensor).

Включение кластеризации (датчик, метка времени) создаст МНОГО изменений физического порядка данных, что очень дорого (даже при использовании SSD).

Если временная метка, комбинированный датчик является уникальным, то определите его как УНИКАЛЬНЫЙ, в противном случае Sql Server добавит в индекс уникальный идентификатор для устранения дубликатов.

Первичные ключи автоматически уникальны, почти все таблицы должны иметь первичный ключ.

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

Удачи!