Моделирование временных рядов SQL Server Огромное количество данных

Question

Я должен реализовать сбор данных для воспроизведения для электрических параметров для устройств 100-1000 с не менее 20 параметрами для мониторинга. Это означает огромный сбор данных, поскольку он будет очень похож на временные ряды. Я должен поддерживать разрешение в течение 1 секунды. думая около 1 года [365 * 24 * 60 * 60 * 1000] = 31536000000 строк. Я сделал свое исследование, но все еще есть несколько вопросов

1. Поскольку данные будут огромны это хорошо, чтобы хранить данные в одной таблице или если таблицы будут сплюнул. [структура данных такая же] или я должен полагаться на индексы?

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

3. Имеет ли SQL Server определенную рекомендацию схемы для оптимизации временных рядов для выбора, обновления и вставки? любой из ящиков помогает в среднем за день? или конкретные общие агрегатные функции я могу написать мой собственный, но только знать, как это стандартная проблема, таким образом они могут иметь некоторые практические советы и примеры из коробки. **

пожалуйста, дайте мне знать, любая помощь приветствуется, заранее спасибо

Answer 1

1) Вы, вероятно, захотите изучить использование разделов. Это позволит использовать очень эффективные вставки (это мета-операция, если вы правильно выполняете разбиение) и очень быстро (2). Вы можете захотеть изучить индексы столбцов, поскольку данные (после их сбора) никогда не будут меняться, и у вас будут очень большие наборы данных. Для разбиения на разделы и столбца требуется кривая обучения, но это очень удобно. В Интернете есть много кода, описывающих использование функций даты в SQL Server.

Answer 2

Это большое количество, но я бы начал с одного стола, если он задержит. Если вы разделите его на несколько таблиц, то все равно останется тот же объем данных.

Нужно ли вам искать устройства? Если нет, у вас может быть отдельная таблица для каждого устройства.

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

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

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

У меня есть несколько таблиц 3 000 000 000, и у меня есть роскошь загрузки ПК без каких-либо других указателей. Нет никакого измеримого ухудшения при вставке из строки 1 в строку 3 000 000 000.