Лучшая практика для работы с большими объемами данных

Мне нужно много обработать таблицу, содержащую более 26 миллионов строк:

  1. Определите правильный размер каждого столбца на основе данных указанного столбца
  2. Определите и удалите повторяющиеся строки.
  3. Создайте первичный ключ (автоматически увеличивающийся идентификатор)
  4. Создайте естественный ключ (уникальное ограничение)
  5. Добавить и удалить столбцы

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

Большое спасибо.

ОБНОВЛЕНИЕ: не нужно беспокоиться о одновременных пользователях. Кроме того, в этой таблице нет индексов. Эта таблица была загружена из исходного файла. Когда все будет сказано и сделано, появятся указатели.

ОБНОВЛЕНИЕ: если вы используете список, отличный от того, что я перечислил, не стесняйтесь упоминать его.

На основе комментариев и того, что я обнаружил, сработало:

  1. Создайте подмножество строк из более чем 26 миллионов строк. Я обнаружил, что 500 000 строк работают хорошо.
  2. Удалить столбцы, которые не будут использоваться (если есть)
  3. Установите соответствующую длину типа данных для всех столбцов за одно сканирование, используя max (len ())
  4. Создайте (если возможно, уникальный) кластерный индекс для столбца / столбцов, который в конечном итоге станет естественным ключом.
  5. Повторите шаги 2-4 для всех рядов.

sql sql-server tsql etl
person O.O    schedule 13.08.2010    source источник
comment
Вам нужно беспокоиться о одновременных пользователях? Какова текущая структура таблицы, включая индексы?   -  person Martin Smith    schedule 14.08.2010
comment
Это то, что я делаю для нашего процесса ETL. Мне не придется беспокоиться о других пользователях.   -  person O.O    schedule 14.08.2010
comment
Что вы будете использовать в качестве кластерного индекса? Каков типичный размер и типы данных удаляемых столбцов?   -  person Martin Smith    schedule 14.08.2010
comment
@Martin: типичным типом данных столбца будет varchar. Типичный размер <50. Один столбец = 300. Я не буду знать об индексах, кроме тех, которые я перечислил на данном этапе.   -  person O.O    schedule 14.08.2010
comment
@ subt13 - Итак, в настоящее время таблица представляет собой кучу без индексов. Кластерный индекс определяет порядок, в котором хранятся данные. Если вы собираетесь иметь такой индекс, вам действительно нужно заранее решить, что это будет. Потому что, если вы хотите его изменить, вам нужно будет перестроить все остальные индексы.   -  person Martin Smith    schedule 14.08.2010
comment
@Martin - Понятно. Тогда имело бы смысл заранее создать кластерный индекс, если это возможно, для столбца / столбцов, который в конечном итоге станет естественным ключом (или определит уникальность)?   -  person O.O    schedule 14.08.2010
comment
Да, уникальный - это хорошо, потому что в противном случае SQL Server просто добавит уникальность в любом случае, узкий - это хорошо, потому что ключ кластеризованного индекса является локатором строк и появляется во всех некластеризованных индексах. table - вызовут ли они разделение страниц в кластеризованном индексе. Также, если у вас есть запросы, которые ищут по диапазонам, они также могут быть хорошо обслужены кластеризованным индексом (хотя покрывающий некластеризованный индекс может быть столь же хорош для этого)   -  person Martin Smith    schedule 14.08.2010
comment
Я не смогу заранее создать уникальный кластерный индекс, но смогу создать неуникальный кластерный индекс.   -  person O.O    schedule 14.08.2010
comment
И в качестве приблизительной оценки, какую долю строк нужно будет удалить как дубликаты - очень небольшое меньшинство?   -  person Martin Smith    schedule 14.08.2010
comment
На самом деле я ожидал, что будет от 500 000 до 1 000 000 дубликатов.   -  person O.O    schedule 14.08.2010
comment
И как вы определяете этих дураков? Дело в том, что они будут иметь то же значение для столбцов, которое вы предлагаете использовать для кластеризованного индекса? Если да, значит ли это, что, если эти дубликаты будут устранены, кластеризованный индекс может быть уникальным? Также на какой версии SQL Server вы работаете?   -  person Martin Smith    schedule 14.08.2010
comment
Если это так, мне интересно, может быть, вам лучше всего выполнить проверку длины данных за одно сканирование кучи, а затем создать новую таблицу с дополнительными столбцами, которые вам нужны, и минус те, которые вам не нужны, и кластеризованные индекс на месте, а затем загрузка данных в порядке кластеризованного индекса (операция сортировки для получения данных в правильном порядке для загрузки также может использоваться для возможного устранения дубликатов)   -  person Martin Smith    schedule 14.08.2010
comment
Да, те же столбцы, которые будут уникальным индексом. SQL Server 2008.   -  person O.O    schedule 16.08.2010

Ответы (2)


arrow_upward
2
arrow_downward

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

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

person Mark Byers    schedule 13.08.2010
comment
Это не уменьшит количество операций ввода-вывода. Удаление столбца - это всего лишь операция с метаданными в SQL Server. - person Martin Smith; 14.08.2010
comment
@Martin Smith: Шаг 1: Нет смысла знать правильный размер столбца, если вы собираетесь его удалить, поэтому вы сэкономите время на этом шаге, просто удалив этот столбец. Шаг 2: Его также не нужно будет читать, когда он сравнивает строки, чтобы увидеть, не дублируются ли они - здесь тоже экономится время. - person Mark Byers; 14.08.2010
comment
Это также может быть достигнуто, просто не выполняя эти шаги для столбцов, которые предназначены для удаления. Но я думаю, на самом деле это не имеет никакого значения. - person Martin Smith; 14.08.2010
comment
@ Мартин Смит: Я бы сказал, что проще удалить их с самого начала, чем постоянно не забывать их пропускать. Если вы пропустите столбцы, а затем удалите их в конце, это только добавит ненужного усложнения процессу без каких-либо преимуществ. - person Mark Byers; 14.08.2010
comment
Да, вообще-то я согласен. Я не вижу недостатков в их немедленном удалении, и в любом случае это обязательно нужно будет сделать перед добавлением кластеризованного индекса. - person Martin Smith; 14.08.2010

arrow_upward
0
arrow_downward

Порядок: 5, 2, 1, 3, 4

1: Ни в коем случае: выберите Max (Len (...)) From ...

2: Все зависит от того, что вы считаете дубликатом.

3: ALTER TABLE в электронной документации расскажет, как это сделать. На самом деле, нет способа ускорить это.

4: см. 3.

5: см. 3.

person Stu    schedule 13.08.2010