База данных SQL Server на SSD - есть ли преимущество для отдельного файла для каждой таблицы?

19

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

Поскольку я действительно хочу выжать каждую последнюю потерю производительности из имеющегося у меня оборудования (около 64 ГБ ОЗУ, очень быстрый SSD и 16 ядер), я подумывал о том, чтобы каждая таблица имела свой собственный файл, так что независимо от того, Я присоединяюсь к 2, 3, 4, 5 или более таблицам, каждая таблица всегда будет читаться с использованием отдельного потока, и структура каждого файла будет тесно выровнена с содержимым таблицы, что, как мы надеемся, минимизирует фрагментацию и сделает ее быстрее для SQL Server, чтобы добавить к содержанию любой данной таблицы.

Одно предупреждение, я застрял на SQL Server 2008 R2 Web Edition . Это означает, что я не могу использовать автоматическое горизонтальное разбиение, что исключает это как повышение производительности.

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

Во-вторых, если выгодно использовать один файл на таблицу, почему create tableмне дается только возможность выделить таблицу для группы файлов, а не для конкретного логического файла? Это потребовало бы от меня создания отдельной файловой группы для каждого файла в моем сценарии, что наводит меня на мысль о том, что, возможно, SQL Server не предусматривает преимуществ, которые я предполагаю получить от выполнения того, что я предлагаю.

— Натан Ридли
источник

18

Я думал о том, чтобы каждая таблица имела свой собственный файл, так что независимо от того, присоединяюсь ли я к 2, 3, 4, 5 или более таблицам, каждая таблица всегда будет читаться с использованием отдельного потока, и структура каждого файла будет быть тесно выровненным с содержимым таблицы, что, мы надеемся, минимизирует фрагментацию и ускорит добавление SQL Server к содержимому любой таблицы

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

Если вы хотите прочитать хорошее обсуждение производительности SSD для SQL Server, есть несколько серий блогов. Как обычно, Пол Пол Рэндал гласит:

У Брента также есть хорошая презентация на тему: SQL на твердотельных накопителях: горячая и сумасшедшая любовь и многое другое.

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

— Ремус Русану
источник

1

Да, мне дали неверную информацию где-то вдоль линии, но, как я прокомментировал ответ Стюарта, я задал вопрос, чтобы убедиться, что я не основываю свои решения на неверной информации. Спасибо за ссылки, проверю их.

17

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

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

Наконец, когда дело доходит до вытеснения каждого снижения производительности из Sql Server, я отсылаю вас к следующей диаграмме (при условии, что мой Microsoft):

введите описание изображения здесь

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

— Майкл Фредриксон
источник

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

@NathanRidley Хорошо, понял ... Я думаю, что реальный ответ, если у кого-то нет ресурса, говорящего «никогда не делай этого», что лучшим способом было бы сравнить две конфигурации с вашей типичной рабочей нагрузкой и посмотреть, есть ли измеримая разница.

— Майкл Фредриксон

4

Как отметили другие, нет прямой выгоды от одного файла на таблицу; Вот отличный обзор Стива Джонса о том, как возник этот миф: http://www.sqlservercentral.com/blogs/steve_jones/2009/10/13/sql-server-legend-data-files-and-threads/

Возможно, вы также захотите изучить секционированное представление, которое, я считаю, поддерживается 2008 Web Edition. Существуют некоторые приемы кодирования в секционированном представлении, но вы можете относительно легко имитировать многие функции секционированных таблиц.

— Стюарт Эйнсворт
источник

2

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

SQL Server 2008 R2 поддерживает сжатие? Если да, включите это.

Поправьте меня если я ошибаюсь.

— Питер Кисс
источник

Не могли бы вы пояснить, почему не будет выигрыша в производительности? По крайней мере, объясните, почему это так, когда отдельные файлы позволяют SQL Server использовать несколько потоков для чтения.

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

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

И я рекомендую вам приобрести RAID-массив Stronge для этой базы данных, потому что SSD скоро умрет.