Что считается "большой" таблицей в SQL Server?

Ответ 1

"Большой" похож на "умный" - он относительный. 10 миллионов строк являются хорошим размером, но зависит ли таблица от ряда факторов:

• сколько столбцов и каковы их типы данных?
• сколько индексов?
• каков фактический размер таблицы (например, количество страниц * 8kb, которые вы можете получить от sys.dm_db_partition_stats)?
• какой тип запросов выполняется против него?
• - отдельные индексы, хранящиеся в памяти, или большинство запросов извлекают выгоду из кластерного сканирования индекса (где, по существу, вся таблица должна быть в памяти)?
• сколько памяти на компьютере?
• Что вы считаете большим?

Время поиска не обязательно определяется размером как таковым, а скорее эффективностью вашей стратегии индексирования и типами запросов, которые вы выполняете для поиска. Если у вас есть такие вещи, как:

WHERE description LIKE '%foo%'

Тогда нормальный индекс не поможет вам, и вы должны начать беспокоиться. Вы можете рассмотреть полнотекстовый поиск для таких случаев.

10 миллионов строк в таблице с одним столбцом INT (например, таблица Numbers) ничего. 10 миллионов строк продуктов с длинными описаниями, XML, географическими данными, изображениями и т.д. - совсем другое.

Существует причина, согласно которой спецификации максимальной емкости для SQL Server не документируют верхнюю границу для количества строк в таблице.

Ответ 2

large - не полезная концепция в дизайне db.

Производительность определяется многими вещами, но метка large не является одной из них. Вместо этого позаботься о себе:

• аппаратное обеспечение
• Конфигурация ОС и db
• схема проектирования
• индексирование
• оптимизация запросов
• самое главное, тестирование для себя на эквивалентном оборудовании с эквивалентным объемом данных и при одновременном использовании

Только тогда у вас будет ответ, имеющий отношение к вам. Помимо этого, дизайн приложения также является огромным фактором. N + 1 запросов и кеширование могут иметь огромное влияние на воспринимаемую (и реальную) производительность.

Ответ 3

Как сказал Аарон, он относительный. Но, может быть, я смогу разработать некоторые из них.

Во-первых, одним из основных факторов является то, насколько велики столбцы. Если у вас есть таблица из 10 миллионов целых чисел (и есть причины, по которым вам просто нужно что-то подобное, посмотрите Таблицы таблиц.) он невелик. С другой стороны, денормализованная таблица всего в сотни строк может занимать много места и иметь серьезные проблемы с производительностью, если каждая строка содержит поле id с целым числом, действующим в качестве первичного ключа, за которым следует varchar (max) с html а затем последовательность столбцов varbinary (max), в которых хранятся jpg, используемые этим html.

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

Конечно, его еще трудно сказать, когда это начнет влиять на производительность. Вы обязательно заметите изменения в производительности, как только таблица станет слишком большой, чтобы помещаться внутри ОЗУ, но это может часто случаться с наборами данных с достаточным размером, особенно если вы решите частично денормализовать и не вызывают беспокойства. Наличие индексов, которые слишком велики для размещения внутри ОЗУ, может вызвать большую проблему с производительностью, и это может быть причиной для оценки. Но это не обязательно проблема, особенно если она предназначена для индекса покрытия для некоторого запроса и вы работаете с средой с ограниченным ОЗУ (то, что ограничено средствами RAM, также относительно, но для грубого эмпирического правила я попытался бы поставил не менее 8 ГБ на даже рабочий стол, который будет серьезно работать с SQL Server).

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

Но, если вы хотите уменьшить размер таблицы:

• Normalize. На самом деле это может иметь некоторые большие недостатки производительности, но может иметь некоторые преимущества в производительности и имеет большие преимущества в отношении согласованности данных, а также преимущества хранения.
• Рассмотрим ваши типы данных. Если вам нужен NVarchar, вам нужен NVarchar. Но если varchar будет работать, тогда он будет использовать меньше места. То же самое с int vs bigint.
• Partition. Опять же, сделано неправильно, это может ухудшить производительность, а не улучшать ее, но сделано правильно, это может помочь в производительности. Это может быть несколько сложно сделать правильно, поэтому подходите с осторожностью.
• Переместить старые, ненужные данные в архивный склад и из основной системы. Конечно, это зависит от правильного определения определения ненужных данных.

Резюме:

Это было больше, чем я ожидал, поэтому резюмируем:

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

Ответ 4

Все относительно...

Раньше я был администратором баз данных для компании, которая проектировала, создавала и размещала маркетинговые базы данных, и нередко существовали базы данных с миллиардами строк. Таким образом, наши меньшие базы данных с миллионами строк считались небольшими.

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

То, что я получаю, это то, что нет смысла, чтобы таблица становилась "большой".

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

Ответ 5

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

Но здесь один способ определить "большой": "большая" таблица - это та, которая превышает объем реальной памяти, которую хост может выделить для SQL Server. SQL Server отлично работает с таблицами, которые значительно превышают физическую память по размеру, но в любое время, когда запрос требует сканирование таблицы (т.е. Чтение каждой записи) такой таблицы, вы получите clobbered. В идеале вы хотите сохранить всю таблицу в памяти; если это невозможно, вы по крайней мере хотите сохранить необходимые индексы в памяти. Если у вас есть индекс, который поддерживает ваш запрос, и вы можете сохранить этот индекс в ОЗУ, производительность будет по-прежнему масштабироваться довольно хорошо.

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

Наконец, подумайте о том, чтобы бросить оборудование в проблему. Производительность SQL Server почти всегда привязана к памяти, а не cpu-bound, поэтому не покупайте быструю 8-ядерную машину и нанесите ее 4 ГБ физической памяти. Если вам нужна достоверно низкая латентность из базы данных 100 ГБ, подумайте о размещении на компьютере с 64 ГБ или даже 128 ГБ.

Ответ 6

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