Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 10Tb + FileStream  [new]
EvAlex
Member

Откуда: Israel
Сообщений: 1001
Зашёл тут один товарищ, который шибко считает себя умным.
Интересуется можно ли несколько сотен тысяч файлов засунуть в filestream (суммарный размер около 10 Tb).

Я послал конечно же ибо нафиг такие приключения.
А вот теперь думаю - не зря ли?
13 фев 14, 15:54    [15563593]     Ответить | Цитировать Сообщить модератору
 Re: 10Tb + FileStream  [new]
aleks2
Guest
Какбе, это прямое предназначение filestream.
13 фев 14, 15:58    [15563618]     Ответить | Цитировать Сообщить модератору
 Re: 10Tb + FileStream  [new]
EvAlex
Member

Откуда: Israel
Сообщений: 1001
aleks2,
в теории - да.
Но меня больше интересует работал ли кто реально с такими объёмами?
13 фев 14, 16:00    [15563629]     Ответить | Цитировать Сообщить модератору
 Re: 10Tb + FileStream  [new]
aleks2
Guest
Какбе, 10Тб файлопомойки не редкость в наши дни.

Тут все лимитируется NTFS, а MS SQL нипричем.
13 фев 14, 16:18    [15563724]     Ответить | Цитировать Сообщить модератору
 Re: 10Tb + FileStream  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Жаль что тему не посетил чувак которые в реале замутил похожее.
Так что да - приключение.

FileStream (при указании папки при создании) реально создаёт файлы, т.е. теже яйца только в профиль.
Какой профит получается при этом?
Согласованность данных? А какую согласованность данных вы хотите, какой ценой?
Что-то я плохо представляю бэкапирование такой базы. Точнее простоту, надёжность и универсальность сего действа.
Тем более FS это ещё дополнительные ограничения на версии скуля.
16 фев 14, 08:19    [15573234]     Ответить | Цитировать Сообщить модератору
 Re: 10Tb + FileStream  [new]
смотрю_тут
Member

Откуда:
Сообщений: 1368
10 TB файлов в бд, хоть в и в FileStreame?!
охренительная файлопомойка ms sql.
В бд хранить ссылки на файлы, а файлы где хочешь, потом просто дергай их оттуда.
17 фев 14, 12:38    [15576478]     Ответить | Цитировать Сообщить модератору
 Re: 10Tb + FileStream  [new]
EvAlex
Member

Откуда: Israel
Сообщений: 1001
смотрю_тут
В бд хранить ссылки на файлы, а файлы где хочешь, потом просто дергай их оттуда.

Хотят управлять (резервное копирование и т.д.) всем из MS SQL.
17 фев 14, 18:25    [15579005]     Ответить | Цитировать Сообщить модератору
 Re: 10Tb + FileStream  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
EvAlex
Хотятъ ...
И это не цирк?
А когда разговор по делу так сразу "флуд" ...

Управлять, говорите?
И что восстановление после сбоев уже налажено и регламентировано? И работает как часы.
IMXO, те которые реально это всё делают - им фиолетово какова структура, они любое потянут.

Но если найдётся гуру которые покажет что хранение файлов в БД оправдано - с радостью послушаю аргументы.
17 фев 14, 19:09    [15579203]     Ответить | Цитировать Сообщить модератору
 Re: 10Tb + FileStream  [new]
Crimzic
Member

Откуда: Sydney
Сообщений: 59
У нас есть такая база.

В настоящее время её размер 11 TB, содержит одну таблицу с 10 миллионами строк-файлов (filestream).
Для облегчения управления этим хозяйством таблица партицирована по Identity column, ~500 GB на каждую партицию. За счёт того, что старые файлы никогда не изменяются, файлгруппы старых партиций помечены как readonly.

Backup:
  • раз в месяц FULL всех readonly файлгрупп, каждую в отдельный файл (10.5 ТБ в месяц)
  • раз в неделю FULL read-write части БД (до ~500 GB)
  • ежедневно DIFF read-write части БД (до ~100 GB каждый)
  • каждые 15 мин LOG

    В случае восстановления из бэкапа (например, при настройке disaster recovery системы) используется piecemeal restore (PARTIAL) - восстановление файлгрупп в порядке новые -> старые, что позволяет сделать особо нужную новую часть БД доступной для чтения и записи достаточно быстро. Но на полный рестор из бекапа, конечно, уйдут примерно сутки.

    Почему выбрали именно SQL Server для хранения файлов: не знаю, что двигало теми товарищами 5+ лет назад, однако это позволяет достичь транзакционной целостности с другими БД на том же инстансе и надёжно хранить документы, которые недопустимо потерять.

    Недостаток, на мой взгляд, это
  • требование SQL Server Enterprise edition
  • больше работы для DBA
  • не подходят стандартные техники обслуживания и управления этой БД (как следствие - чуваки из Cloud Hosting не могут настроить её бекап так, как мы хотим)
  • не очень высокая гибкость (структуру такой таблицы, фактически, невозможно поменять)
  • высокие требования к объёму серверного дискового пространства (3 копии данных: Production, Backup, DR).

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

    Если у кого-то есть вопросы, готов ответить.
  • 18 фев 14, 07:08    [15580188]     Ответить | Цитировать Сообщить модератору
     Re: 10Tb + FileStream  [new]
    Andrey Sribnyak
    Member

    Откуда: Киев
    Сообщений: 599
    Crimzic
    У нас есть такая база.

    В настоящее время её размер 11 TB, содержит одну таблицу с 10 миллионами строк-файлов (filestream).
    ...
    В случае восстановления из бэкапа (например, при настройке disaster recovery системы) используется piecemeal restore (PARTIAL) - восстановление файлгрупп в порядке новые -> старые, что позволяет сделать особо нужную новую часть БД доступной для чтения и записи достаточно быстро. Но на полный рестор из бекапа, конечно, уйдут примерно сутки.


    А как вы сумели базу с Filestream настроить на частичное восстановление?


    http://technet.microsoft.com/en-us/library/ms177425.aspx
    цитата:
    If a partial restore sequence excludes any FILESTREAM filegroup, point-in-time restore is not supported.
    18 фев 14, 10:18    [15580669]     Ответить | Цитировать Сообщить модератору
     Re: 10Tb + FileStream  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6723
    Andrey Sribnyak
    Crimzic
    В случае восстановления из бэкапа (например, при настройке disaster recovery системы) используется piecemeal restore (PARTIAL)
    А как вы сумели базу с Filestream настроить на частичное восстановление?
    http://technet.microsoft.com/en-us/library/ms177425.aspx
    If a partial restore sequence excludes any FILESTREAM filegroup, point-in-time restore is not supported.
    1. Crimzic говорит не о частичном восстановлении, а способе полного восстановления.
    2. и явно не point-in-time и т.п.
    3. excludes это очепятка? (типа должно быть includes)
    Т.е. бэкап не хранит состояния файлов на каждый момент, а только на конец бэкапа. Типа накладно это всё. Я правильно понял? Поправьте если что.

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

    Если говорить о "стоит овчинка выделки", то добить это можно ещё и тем - а даёт ли преимущество.
    Т.е. для больших файлов оно да - работа как с файлами хорошо - блочно.
    Но когда файлы махонькие, то хранить VarBinary(max) может быть выгоднее. Ну в смысле несколько файлов в одном блоке.
    Ходила байка что NTFS такое умел сам по себе - но видимо как обычно в MS - недовнедрили, спасибо маркетологам.

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

    Коль есть наученые опытом (Crimzic) - и они воротят нос. То тогда вопрос - науя это активно пеарится уже не первую версию?
    Науя платить за дополнительный геморрой (ок, за замену одного геморроя другим)?

    Ещё не говоря о задаче: версионность файлов в бизнес процессе ...
    19 фев 14, 01:08    [15586472]     Ответить | Цитировать Сообщить модератору
     Re: 10Tb + FileStream  [new]
    Crimzic
    Member

    Откуда: Sydney
    Сообщений: 59
    [quot Mnior]
    Andrey Sribnyak
    1. Crimzic говорит не о частичном восстановлении, а способе полного восстановления.
    2. и явно не point-in-time и т.п.

    Да, к счастью, нам пока не требовалось делать point-in-time restore.

    Mnior
    3. excludes это очепятка? (типа должно быть includes)
    Т.е. бэкап не хранит состояния файлов на каждый момент, а только на конец бэкапа. Типа накладно это всё. Я правильно понял? Поправьте если что.

    Скорее всего, имелось в виду что для point in time restore требуется сначала восстановить все FILESTREAM файлгруппы. Хотя, по логике, это не нужно при наличии readonly filestream файлгрупп, если полный бэкап Read/Write файлгрупп и полный бекап readonly файлгрупп были сделаны после пометки их как readonly.
    Full & Diff - да, не содержат состояния на каждый момент, но вот LOG backup, по смыслу, должен содержать всю историю изменений (из которой можно получить состояния файлов на каждый момент). Иначе ведь из такого бэкапа невозможно было сделать Point in time restore.
    Mnior
    Если говорить о "стоит овчинка выделки", то добить это можно ещё и тем - а даёт ли преимущество.

    Преимущество перед чем? Если хранение данных в БД FILESTREAM vs not FILESTREAM, то, по-моему, если производительности при работе с маленькими файлами хватает, то стоит. Ведь в довесок мы получаем возможность работы с файлами через streaming API (почти) минуя SQL Server.
    Mnior
    Коль есть наученые опытом (Crimzic) - и они воротят нос. То тогда вопрос - науя это активно пеарится уже не первую версию?
    Науя платить за дополнительный геморрой (ок, за замену одного геморроя другим)?
    Ещё не говоря о задаче: версионность файлов в бизнес процессе ...

    Вообще, не так уж и плохо всё работает, в целом, нас устраивает, да и менять архитектуру на этом этапе будет слишком долго и дорого - не думаю, что на это пойдут. А работа с версионностью может быть обеспечена на уровне приложения.
    19 фев 14, 04:25    [15586782]     Ответить | Цитировать Сообщить модератору
     Re: 10Tb + FileStream  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6723
    Crimzic
    но вот LOG backup, по смыслу, должен содержать всю историю изменений (из которой можно получить состояния файлов на каждый момент). Иначе ведь из такого бэкапа невозможно было сделать Point in time restore
    Я думал вы это как раз и уточните. Point-in-time это и так только из бэкапа логов и восстанавливается и никак по другому. Всё остальное хранит состояние на момент.
    Так и не понял тогда в чём "ограничения". Или низя вообще или итак очевидная вещь что отсутствующая ФГ будет дальше отсутствовать (как и в случае обычной ФГ).
    Crimzic
    Ведь в довесок мы получаем возможность работы с файлами через streaming API (почти) минуя SQL Server.
    1. В случае FileTable не почти, как я понимаю - вешаете сетевой каталог и усё.
    2. FileStream vs работа с обычными файлами и/или обычный VarBinary(max).
    3. Не очень понял "минуя SQL Server", ведь мы говорим "Файлы в базе ради согласованности данных". Как бэ возни со скулем не избежать. А мороки с обычным FileStream ...
    Crimzic
    А работа с версионностью может быть обеспечена на уровне приложения.
    Т.е. придумывай свои костыли, хотя имею заведомо общие механизмы.
    19 фев 14, 12:31    [15588762]     Ответить | Цитировать Сообщить модератору
    Все форумы / Microsoft SQL Server Ответить