Данные BLOB-объектов в огромной базе данных SQL Server

Каждый год у нас создается 20 000 000 текстовых файлов, средний размер которых составляет около 250 КБ каждый (35 КБ заархивировано).

Мы должны положить эти файлы в какой-то архив на 10 лет. Нет необходимости искать внутри текстовых файлов, но мы должны иметь возможность найти один текстовый файл, выполнив поиск по 5-10 полям метаданных, таким как «название продукта», «дата создания» и т. д.

Я рассматриваю возможность заархивировать каждый файл и сохранить их в базе данных SQL Server с 5-10 доступными для поиска (индексированными) столбцами и столбцом varbinary (MAX) для данных заархивированного файла.

База данных будет расти с годами; 5-10 Тб. Поэтому я думаю, что нам нужно разделить данные, например, сохраняя одну базу данных в год.

Я изучал использование FILESTREAM в SQL Server для столбца varbinary, в котором хранятся данные, но кажется, что это больше подходит для больших двоичных объектов> 1 МБ?

Любые другие предложения о том, как управлять такими объемами данных?


database architecture sql-server storage filestream
person Poppert    schedule 23.06.2011    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Я бы сказал, что лучше хранить файлы в файловой системе. И вы можете сохранить имя файла и путь в БД. Вот похожий вопрос .

person Eugene Mayevski 'Callback    schedule 23.06.2011
comment
Что он делает, когда кто-то перемещает файл, не регистрируя его в базе данных? - person JNK; 23.06.2011
comment
@JNK См. обсуждение аналогичного вопроса для ответов на ваш вопрос. - person Eugene Mayevski 'Callback; 23.06.2011

arrow_upward
1
arrow_downward

Filestream определенно больше подходит для больших больших двоичных объектов (750 КБ–1 МБ), так как накладные расходы, необходимые для открытия внешнего файла, начинают влиять на производительность чтения и записи по сравнению с хранилищем больших двоичных объектов vb(max) для небольших файлов. Если это не такая большая проблема (т. е. чтение данных больших двоичных объектов после начальной записи происходит нечасто, а большие двоичные объекты практически неизменяемы), то это определенно вариант.

Я, вероятно, предложил бы хранить файлы непосредственно в столбце vb(max), если вы можете гарантировать, что они не станут намного больше по размеру, но сохранить эту таблицу в отдельной файловой группе, используя параметр TEXTIMAGE_ON, который позволит вам переместить его в хранилище, отличное от остальных метаданных, если это необходимо. Кроме того, не забудьте спроектировать схему так, чтобы фактическое хранилище BLOB-объектов можно было разделить на несколько файловых групп либо с помощью разделов, либо с помощью какой-либо схемы с несколькими таблицами, чтобы при необходимости в будущем вы могли масштабироваться на разные диски.

Хранение BLOB-объектов, напрямую связанных с метаданными SQL либо через Filestream, либо напрямую через хранилище vb(max), имеет много преимуществ по сравнению с несоответствиями файловой системы/SQL, не ограничиваясь простотой резервного копирования и других операций управления.

person MikeW    schedule 23.06.2011
comment
Привет, спасибо за ваш ответ. Мы ожидаем, что поиск и открытие данных больших двоичных объектов происходит очень редко. Будет, но не очень часто. Это больше о том, как выделить хранилище на физических дисках или SAN и т. д. Я обязательно рассмотрю файловые группы и TEXTIMAGE_ON. - person Poppert; 27.06.2011

arrow_upward
0
arrow_downward

Я предполагаю, что под «сгенерированным» вы подразумеваете что-то вроде того, что данные вводятся в шаблоны документов, и поэтому текстовое содержимое часто повторяется, то есть «шаблон»?

20 миллионов таких "сгенерированных" файлов в год - это ~55 000 в день, ~2300 в час!

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

Если вы имеете в виду что-то другое под «сгенерированным», не могли бы вы уточнить?

person Tim    schedule 23.06.2011
comment
Привет, спасибо за ваш ответ. Текстовые файлы создаются для определенной цели. Не нами, это вне нашего контроля. Они у нас есть, и мы должны с ними бороться. - person Poppert; 23.06.2011