Стратегия ведения гигантской базы данных

Question

У нас есть гигантская база данных SQL Server 2005 (75 ГБ), которая в основном представляет собой просто данные в одной таблице со значениями продаж (за день, для магазина и статьи).Мы хотим сделать это, складывая объем продаж в неделю для каждой записи старше года (по-прежнему сгруппированы по магазинам и товарам).Таким образом, теоретически для данных старше года мы можем удалить 6 из 7 записей.

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

Чтобы дать вам представление: запуск SELECT count(*) выполняется более 4 минут

У нас есть несколько индексов (по дате (кластеризовано) и по комбинации магазина, статьи и даты).Добавление еще индексов также занимает вечность.

У кого-нибудь есть хорошая стратегия, как выполнить эту задачу?Есть предложения по методам TSQL, которые работают лучше, чем базовые операторы DML?

Answer 1

Если вы используете SQL Server 2005 Enterprise Edition, вам следует рассмотреть возможность использования разбиения .Преимущества:

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

Если вы не используете Enterprise Edition, используйте эту ссылку , чтобы увидеть возможности разделения (сегментирования или горизонтального разделения), не основанные на функции разделения SQL Server 2005.

Для оптимизации хранимых процедур:

• переоценить текущие индексы для вашего SP
• рассмотрите ежедневную-> недельную процедуру для выполнения в диапазонах дат, например, год за годом или месяц за месяцем - выполняетсяПроцедура на всей истории будет большой работой для SQL Server и базового оборудования
• , вероятно, лучший способ: foОбращаясь к предыдущему элементу о диапазонах дат, создайте новую таблицу на основе старых еженедельных данных и недавних ежедневных данных, затем создайте индексы, а затем в одной транзакции отбросьте исходную таблицу и используйте sp_rename для помещения старой таблицы вместо новой - переименование происходит практически мгновенно, поэтому никто не заметит задержку, если это важно
• рассмотрите возможность удаления индексов на целевой таблице, потому что вставки будут выполняться намного медленнее - только если вы работаете с исходной таблицей (delete + insert)

Не по теме подсказка: при использовании Enterprise Edition рассмотрите возможность сжатия таблицы, поскольку SQL Server 2005 обычно хорошо справляется со сжатием таблиц фактов - вероятно, вы получите как производительность, так и дисковое пространство, если у вас достаточноМощность процессора.

Answer 2

Не могли бы вы рассказать нам немного больше об оборудовании вашего сервера?В основном, когда данные становятся большими, они помещаются во множество быстрых дисков.

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

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

Несколько мыслей от меня,

Rgds Gert-Jan

Answer 3

Можете ли вы поделиться схемой?

Вы пытались использовать WITH (NOLOCK) или установить уровень изоляции для чтения некоммертным?

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

Мои предложения будут:

• Разделите таблицу.
• Пусть клиенты читают данные из представления, которое не изменяется.
• Пусть все операции с базой данных проходят через сохраненный процесс.
• Выполнить все оптимизации внутри хранимой процедуры.

Для кратковременного «исправления», чтобы облегчить некоторую боль, сейчас вы можете попробовать:

• Если у вас есть диски SATA, конвертируйте их в SAS. Это даст резкий импульс ввода-вывода.
• Используйте RAID 5, который лучше для чтения.
• Убедитесь, что MDF и LDF находятся на совершенно разных физических дисках. Если вы можете себе позволить, поместите их в отдельные контроллеры RAID 5. В противном случае поместите LDF в RAID 1 и MDF в RAID 5.
• Добавьте еще один диск и добавьте в него другой файл MDF. Это тогда распространит новую вставку, обновление, удаление по нескольким дискам. Таким образом, чтение будет выполняться с нескольких дисков и может дать вам лучшую производительность.
• Перестройте кластерный индекс.
• Используйте программу дефрагментации диска Windows Server для дефрагментации диска.
• Обновление до лучшего процессора с большим объемом кэш-памяти второго уровня.