Поможет ли наличие нескольких файловых групп ускорить работу моей базы данных?
В настоящее время я разрабатываю продукт, который выполняет довольно интенсивные вычисления с использованием MS SQL Server 2005. На высоком уровне архитектура моего продукта основана на концепции «прогонов», когда каждый раз, когда я выполняю некоторую аналитику, она сохраняется в серии таблиц прогонов (~ 100 таблиц за прогон).
Проблема, с которой я сталкиваюсь, заключается в том, что когда количество запусков вырастает примерно до 1000 или около того через несколько месяцев, производительность в базе данных действительно падает, и, в частности, простые запросы, такие как проверка существования таблиц или создание представлений, могут займет от секунды до двух.
Я слышал, что может помочь использование нескольких файловых групп, чего я сейчас не делаю. Верно ли это, и если да, то почему / как это могло бы помочь? Кроме того, если есть другие предложения, даже такие, как использование меньшего числа таблиц, я открыт для них. Я просто хочу ускорить базу данных и, надеюсь, привести ее в состояние, при котором она будет масштабироваться.
Ответы 7
Возможно, если вы разместите их на разных дисках - не логических, а физических, чтобы ввод-вывод не сильно замедлял вас.
Группы файлов, расположенные на разных физических дисках, - это то, что даст вам наибольший прирост производительности. Кроме того, их можно разделить по месту размещения индексов, чтобы записи в таблицы и доступ к индексам выполнялись на разных дисках. С разделением можно многое сделать, но наибольшее влияние на скорость оказывает именно эта общая концепция.
Это может помочь с производительностью. перемещение определенных таблиц / элементов в отдельные файловые области / части диска. это может до некоторой степени уменьшить степень внешней фрагментации, влияющей на базу данных.
Я бы также посмотрел на другие факторы, такие как tracesql, чтобы определить, почему запросы и т. д. Замедляются - могут быть другие факторы, такие как статистика запросов, перекомпиляция SP и т. д., Которые легче исправить и которые могут дать вам больший выигрыш в производительности.
Примерно 1000 чего? Одна строка пишет? Многострочные транзакции? Удаляет?
Общий совет - разместить файлы данных и файлы журналов на отдельных физических дисках. SQL Server отслеживает каждую запись в журнал, поэтому размещение этих записей на разных дисках должно улучшить общую производительность.
Но настройка SQL Server зависит от того, что на самом деле делает приложение. Есть общие советы, но вы должны сами измерить ...
С точки зрения производительности большое преимущество использования отдельных файлов / файловых групп заключается в том, что они позволяют распределять данные по нескольким физическим дискам. Это полезно, потому что с несколькими дисками можно обрабатывать несколько запросов данных одновременно (параллельный, как правило, быстрее, чем последовательный). При прочих равных условиях это будет способствовать повышению производительности, но вопрос о том, насколько сильно зависит от вашего конкретного набора данных и выполняемых вами запросов.
Судя по вашему описанию, вас беспокоят медленные операции, связанные с созданием таблиц и проверкой их существования. Если вы создаете 100 таблиц за запуск, то после 1000 запусков у вас будет 100 000 таблиц. У меня нет большого опыта создания такого количества таблиц в одной базе данных, но вы можете ограничивать системные таблицы, отслеживающие схему базы данных. В этом случае вы можете увидеть некоторую выгоду, распределив свои таблицы по нескольким базам данных (все эти базы данных могут по-прежнему находиться в одном экземпляре SQL Server).
В общем, инструмент SQL Profiler - лучшая отправная точка для поиска медленных запросов. Есть столбцы данных, которые показывают затраты ЦП и ввода-вывода для каждого пакета SQL, что должно указать вам на худших нарушителей. Как только вы найдете проблемные запросы, я буду использовать Query Analyzer для создания планов запросов для каждого из этих запросов и посмотреть, сможете ли вы определить, что их замедляет. Для этого откройте окно запроса, введите свой запрос и нажмите Ctrl + L. Полное обсуждение того, что может быть медленным, займет целую книгу, но стоит обратить внимание на сканирование таблиц (очень медленное для больших таблиц) и неэффективные соединения.
В конце концов, вы можете улучшить ситуацию, просто переписав свои запросы, или вам, возможно, придется внести более широкие изменения в схему таблицы. Например, может быть, есть способ создать только одну или несколько таблиц за запуск вместо 1000. Более подробные сведения о вашей конкретной настройке помогут нам дать более подробный ответ.
Я также рекомендую этот сайт, чтобы получить множество советов о том, как сделать работу быстрее:
Когда вы говорите о 100 таблицах за запуск, вы действительно имеете в виду, что создаете новые таблицы SQL? Если это так, я думаю, что проблема может быть в архитектуре вашего приложения. Я не могу представить себе ситуацию, когда вам понадобится столько новых таблиц, а не повторное использование одних и тех же таблиц несколько раз и простое добавление одного или двух столбцов, чтобы различать прогоны.
Если вы уже повторно используете одну и ту же группу таблиц, а новые прогоны означают просто дополнительные строки в этих таблицах, тогда проблема может заключаться просто в том, что новые данные с течением времени снижают производительность одним из нескольких способов. Например:
- Таблицы / индексы могут быть фрагментированы через некоторое время. Убедитесь, что все ваши таблицы имеют кластерный индекс. Проверьте фрагментацию с помощью sys.DM_DB_INDEX_PHYSICAL_STATS и выполните ALTER INDEX с опцией REBUILD, если необходимо их дефрагментировать.
- Таблицы могут быть слишком большими, так что неэффективность на маленьких таблицах теперь очевидна на больших таблицах. Посмотрите на правильные индексы в таблицах, чтобы повысить производительность.
- SQL Server будет кэшировать планы запросов (особенно для хранимых процедур), но если данные в таблице значительно изменяются со временем, этот план запроса может больше не подходить. Загляните в sp_recompile для ваших хранимых процедур, чтобы узнать, нужно ли это.
№2 - это виновник, которого я чаще всего вижу в реальных ситуациях. Разработчики склонны использовать только небольшой набор тестовых данных и упускать из виду правильную индексацию, потому что с таблицей из 20 строк можно делать почти все, и она будет выглядеть быстро.
Надеюсь это поможет
Разделите таблицы по отдельным физическим дискам. Если у вас такой объем дискового ввода-вывода, вам нужно достойное решение для ввода-вывода. Raid 10, быстрые диски, разбивает журналы и БД на отдельные диски.
Пересмотрите свою архитектуру - можете ли вы использовать несколько баз данных? Если вы создадите тысячи таблиц за раз, вы скоро столкнетесь с некоторыми интересными узкими местами, с которыми мне раньше не приходилось сталкиваться. Это должно решить несколько БД. Подумайте о том, чтобы иметь одну «Контрольную» базу данных, содержащую все ваши основные метаданные, а затем дополнительные базы данных, содержащие фактические данные.
Вы не упоминаете никаких спецификаций своего сервера, но мы увидели приличное увеличение производительности, когда мы перешли с 8 ГБ на 20 ГБ ОЗУ.