Оптимизация таблицы с огромным текстовым полем

Question

У меня есть проект, который генерирует снимки базы данных, преобразует ее в XML, а затем сохраняет XML в отдельной базе данных.К сожалению, эти снимки становятся огромными файлами, и теперь их размер составляет около 10 мегабайт каждый.К счастью, мне нужно хранить их только около месяца, прежде чем их можно будет снова удалить, но, тем не менее, месяц снимков оказывается очень плохим из-за его производительности ...Я думаю, что есть способ улучшить производительность.Нет, не храня XML в отдельной папке где-то, потому что у меня нет прав на запись в любое место на этом сервере.XML должен оставаться в базе данных.Но каким-то образом поле [Content] может быть как-то оптимизировано, чтобы все ускорилось ...Мне не нужны никакие опции полнотекстового поиска в этом поле.Я никогда не буду искать по этому полю.Так что, возможно, отключив это поле для инструкций поиска или что-то еще?Таблица не имеет ссылок на другие таблицы, но структура является фиксированной.Я не могу переименовать вещи или изменить типы полей.Поэтому мне интересно, возможна ли оптимизация.Ну так что?Структура, сгенерированная SQL Server:

CREATE TABLE [dbo].[Snapshots](
    [Identity] [int] IDENTITY(1,1) NOT NULL,
    [Header] [varchar](64) NOT NULL,
    [Machine] [varchar](64) NOT NULL,
    [User] [varchar](64) NOT NULL,
    [Timestamp] [datetime] NOT NULL,
    [Comment] [text] NOT NULL,
    [Content] [text] NOT NULL,
 CONSTRAINT [PK_SnapshotLog] 
    PRIMARY KEY CLUSTERED ([Identity] ASC) 
    WITH (PAD_INDEX  = OFF, 
    STATISTICS_NORECOMPUTE  = OFF, 
    IGNORE_DUP_KEY = OFF, 
    ALLOW_ROW_LOCKS  = ON, 
    ALLOW_PAGE_LOCKS  = ON, 
    FILLFACTOR = 90) ON [PRIMARY],
 CONSTRAINT [IX_SnapshotLog_Header] 
    UNIQUE NONCLUSTERED ([Header] ASC) 
    WITH (PAD_INDEX  = OFF, 
    STATISTICS_NORECOMPUTE  = OFF, 
    IGNORE_DUP_KEY = OFF, 
    ALLOW_ROW_LOCKS  = ON, 
    ALLOW_PAGE_LOCKS  = ON, 
    FILLFACTOR = 90) 
    ON [PRIMARY],
 CONSTRAINT [IX_SnapshotLog_Timestamp] 
    UNIQUE NONCLUSTERED ([Timestamp] ASC)
    WITH (PAD_INDEX = OFF, 
    STATISTICS_NORECOMPUTE = OFF, 
    IGNORE_DUP_KEY = OFF, 
    ALLOW_ROW_LOCKS = ON, 
    ALLOW_PAGE_LOCKS = ON, 
    FILLFACTOR = 90) 
    ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

Производительность не только низкая при выборе данных из этой таблицы, но также при выборе или вставке данных в одну из других таблиц в этой базе данных!Когда я удаляю все записи из этой таблицы, вся система работает быстро.Когда я начинаю добавлять снимки, производительность начинает снижаться.Приблизительно после 30 снимков производительность ухудшается, и риск превышения времени ожидания соединения увеличивается.Возможно, проблема не в самой базе данных, хотя она все еще медленная, когда используется через инструмент управления.(Быстро, когда моментальные снимки пусты.) В основном я использую ASP.NET 3.5 и Entity Framework для подключения к этой базе данных, а затем для чтения нескольких таблиц.Может быть, здесь можно добиться некоторой производительности, хотя это не объясняет, почему база данных также медленно работает с инструментами управления и при использовании через другие приложения с прямым подключением ...

Answer 1

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

Answer 2

Учитывая ваши ограничения, вы можете попробовать сжать XML перед вставкой в ​​БД в двоичном виде. Это должно значительно снизить стоимость хранения этих данных.

Вы упоминаете, что это плохо сказывается на производительности, как часто вы читаете из этой таблицы снимков? Если это просто сохранено, это должно повлиять только на производительность при записи. Если вы часто читаете это, уверены ли вы, что проблема производительности связана с хранилищем данных, а не с разбором 10 МБ XML?

Answer 3

Вся система стала намного быстрее, когда я заменил тип данных TEXT на тип данных NVARCHAR (MAX).HLGEM указал мне на то, что тип данных TEXT устарел и поэтому проблематичен.Однако все еще остается вопрос, можно ли так легко заменить тип данных этих столбцов на более современный тип данных.(Переведено: мне нужно проверить, будет ли код работать с измененным типом данных ...)
Итак, если бы я изменил тип данных с TEXT на NVARCHAR (MAX), есть ли что-нибудь, что могло бы сломаться из-за этого?Проблемы, которые я могу ожидать?
Прямо сейчас, это, кажется, решает проблему, но мне нужно провести некоторое лоббирование, прежде чем мне позволят сделать это изменение.Поэтому я должен быть уверен, что это не вызовет никаких (неожиданных) проблем.