SQL Server 2016 - сжатие до или после массовой загрузки

Question

У меня есть примерно 90 ГБ несжатых данных .csv для импорта в SQL Server. В зависимости от конечных требований интерфейса я могу или не могу разбить эти данные - но могу ли я это сделать или нет, это будут некоторые большие таблицы. Хотя большая в общей сложности, строки относительно просты:

[Exchange] [Symbol] [Compare_To_Exchange] [Compare_To_Symbol] [Date] [Correlation] 
NYSE   ZTS  INDEX     DCXE    12/9/2013 0:00 -0.5521076 

Я не знаком с сжатия таблиц SQL Server, и я читать вверх. Один из вопросов, который у меня есть, что я не могу найти ответ, - это то, лучше или не лучше (производительность или любой другой способ) сжать таблицу, пока она пуста, и позволить массовой транзакции выполнить сжатие или вставить все данные и затем сжать?

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

Answer 1

Важно помнить, что вы создаете базу данных здесь, а не файл CSV. Сжатие имеет большой смысл в CSV-файле, но не в хорошо продуманной модели данных. Сжатие имеет смысл при неструктурированных данных, но у вас есть структурированные данные.

Если вы нормализуете данные, которые вам вообще не нужно сжимать. В вашем примере вы показываете 4 или 5 слов данных плюс отметку времени плюс то, что, вероятно, 32-битное числовое. Таким образом, менее 160 бит на строку.

Чтобы быть более ясным ->

[Exchange]   -> 16 bit index to look up in exchange table. 
[Symbol]    -> 16 bit index to look up in symbol table 
[Compare_To_Exchange] -> 16 bit index to look up in compare table 
[Compare_To_Symbol] -> 16 bit index to look up in compare table 
[Date]    -> 64 bit timestamp 
[Correlation]   -> 32 bit numeric 

Это будет гораздо меньше, чем CSV

Вы могли бы даже быть в состоянии сделать некоторые из этих 8 битовых индексов, если таблицы поиска невелики. Если это дата, а не метка времени, которая намного меньше.

Или если вы ленивы, вы можете использовать 32-битные целые числа или даже 64 - все же строки будут небольшими. Если вы используете структуру данных в своем дизайне.