none
SharePoint 2013, SQL Server 2012, RBS + FILESTREAM вопрос по хранению файлов в хранилище RRS feed

  • Вопрос

  • Здравствуйте!

    Решил перенести файлы контента хранящиеся в базе данных во внешнее хранилище RBS. Выполнил все рекомендации и настройки согласно инструкции: http://technet.microsoft.com/ru-RU/library/ff629463%28v=office.15%29.aspx

    После этого все заработало. Файлы которые добавляю в библиотеку на сайте SharePoint появляются в хранилище, но есть одна странность. Прошу разъяснить ее.

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

    В инструкции по которой настраивал сервис RBS так же сказано, что для проверки необходимо:

    4. В ферме SharePoint отправьте файл размером не менее 100 КБ в библиотеку документов.

    6. Перейдите в каталог удаленного хранилища больших двоичных объектов.

    7. Перейдите к списку файлов и откройте файл, для которого указана самая поздняя дата изменения. Это должен быть отправленный вами файл.

    То есть файл должен быть один, а не разбить на большое количество мелких файлов?!

    В место одного сохраненного файла в библиотеке SharePoint в папке хранилища RBS появляется большое количество файлов, в место одного сохраненного.

    Кто сталкивался подскажите пожалуйста, в чем может быть проблема?

Ответы

  • Добрый день,

    у вас файл разбивается по размеру параметра max_size_inline_blob, который по умолчанию равен 61140 байт. RBS Filestream Provider Small Blob Optimization Settings

    Вот описание данного инцидента : Any way to change blob size 

  • Добрый день. Постараюсь немного прояснить.

    Получается так что с версии SQL 2012 server была заложена новая технология хранения данных в хранилище разбивая файлы на кусочки для лучшей индексации, поиска изменений в файлах и много потоковой передаче данных. Сервер сам автоматически подбирает размер кусочков, на которые дробятся файлы при сохранении в хранилище?!

    В данном случае мы работаем с технологией Shredded storage. Краткий экскурс (на русском информации нет):

    Overview of Shredded Storage in SharePoint 2013

    Shredded Storage and the Evolution of SharePoint’s Storage Architecture

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

    В данном случае это схожая функциональность с дедупликацией данных на СХД. Про производительность можете не волноваться, т.к. тесты показывают повышение! производительности и уменьшение занимаемого объема. Вариант с версионностью файлов - зачем хранить каждую версию отдельно, если можно хранить инкрементные апдейты. Вот так и поступили. Технология shredded storage пришла в дополнение к Cobalt для оптимизации транзакция между серверами (Cobalt же оптимизирует трафик между клиентом и сервером). Плюс увеличивается многопоточная производительность.

    Очевидные вопросы:

    Можно ли отключить Shredded storage? Ответ: нет, эта опция включена по умолчанию и не может быть отключена.

    Можно ли отключить разбиение файлов или изменить размер разбиения? Ответ: можно, но НЕ стоит так делать, т.к. потеряем в производительности.

    По существу для хранилища необходимо использовать "быстрые диски" в противном случае данные будут считываться очень медленно или нет?!

    Для SQL Server всегда была критична производительность дисковой подсистемы. Использование SAS дисков предпочтительно.

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

    Для себя я выбрал минимальный размер 20Мб. Но каждый определяет сам минимальный размер в зависимости от предполагаемого хранимого контента.

    В рекомендациях написано что базы данных для SharePoint не могут превышать 100Gb, но если учесть что файлов храниться много и еще есть поддержка версионности размер базы будет расти очень быстро к примеру если размер файлов 50Mb то всего их поместиться в базу 2000. или я не прав?!  

    RBS как раз и призван устранить лимиты по хранимому объему. К примеру, у меня в организации объем хранимой информации в SharePoint в данный момент составляет около 3Тб!!! 


Все ответы

  • Добрый день,

    у вас файл разбивается по размеру параметра max_size_inline_blob, который по умолчанию равен 61140 байт. RBS Filestream Provider Small Blob Optimization Settings

    Вот описание данного инцидента : Any way to change blob size 

  • Максим, большое спасибо за оперативный ответ.

    Получается так что с версии SQL 2012 server была заложена новая технология хранения данных в хранилище разбивая файлы на кусочки для лучшей индексации, поиска изменений в файлах и много потоковой передаче данных. Сервер сам автоматически подбирает размер кусочков, на которые дробятся файлы при сохранении в хранилище?!

    У меня возникло ряд вопросов по использованию данной технологии, буду признателен если сможете мне на них ответить.

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

    По существу для хранилища необходимо использовать "быстрые диски" в противном случае данные будут считываться очень медленно или нет?!

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

    В рекомендациях написано что базы данных для SharePoint не могут превышать 100Gb, но если учесть что файлов храниться много и еще есть поддержка версионности размер базы будет расти очень быстро к примеру если размер файлов 50Mb то всего их поместиться в базу 2000. или я не прав?! 

  • Добрый день. Постараюсь немного прояснить.

    Получается так что с версии SQL 2012 server была заложена новая технология хранения данных в хранилище разбивая файлы на кусочки для лучшей индексации, поиска изменений в файлах и много потоковой передаче данных. Сервер сам автоматически подбирает размер кусочков, на которые дробятся файлы при сохранении в хранилище?!

    В данном случае мы работаем с технологией Shredded storage. Краткий экскурс (на русском информации нет):

    Overview of Shredded Storage in SharePoint 2013

    Shredded Storage and the Evolution of SharePoint’s Storage Architecture

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

    В данном случае это схожая функциональность с дедупликацией данных на СХД. Про производительность можете не волноваться, т.к. тесты показывают повышение! производительности и уменьшение занимаемого объема. Вариант с версионностью файлов - зачем хранить каждую версию отдельно, если можно хранить инкрементные апдейты. Вот так и поступили. Технология shredded storage пришла в дополнение к Cobalt для оптимизации транзакция между серверами (Cobalt же оптимизирует трафик между клиентом и сервером). Плюс увеличивается многопоточная производительность.

    Очевидные вопросы:

    Можно ли отключить Shredded storage? Ответ: нет, эта опция включена по умолчанию и не может быть отключена.

    Можно ли отключить разбиение файлов или изменить размер разбиения? Ответ: можно, но НЕ стоит так делать, т.к. потеряем в производительности.

    По существу для хранилища необходимо использовать "быстрые диски" в противном случае данные будут считываться очень медленно или нет?!

    Для SQL Server всегда была критична производительность дисковой подсистемы. Использование SAS дисков предпочтительно.

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

    Для себя я выбрал минимальный размер 20Мб. Но каждый определяет сам минимальный размер в зависимости от предполагаемого хранимого контента.

    В рекомендациях написано что базы данных для SharePoint не могут превышать 100Gb, но если учесть что файлов храниться много и еще есть поддержка версионности размер базы будет расти очень быстро к примеру если размер файлов 50Mb то всего их поместиться в базу 2000. или я не прав?!  

    RBS как раз и призван устранить лимиты по хранимому объему. К примеру, у меня в организации объем хранимой информации в SharePoint в данный момент составляет около 3Тб!!! 


  • Я тоже не так давно занимался вопросом настройки RBS и столкнулся с аналогичной ситуацией. Спасибо за разъяснения!

    У меня остался единственный вопрос: как вы бэкапите данные? и как производить восстановление в будущем? Без RBS все просто, можно контентную БД забэкапить и из неё сделать тестовый портал, а в случае с RBS - как все это делать? Как вы делаете?

  • Максим, большое спасибо за ответ.

    Все стало предельно понятно, в плане работы технологии хранилища в SQL 2012 server.

    Еще в дополнении два уточняющих вопроса:

    1. При Backup Баз данных - базы данных и файлы в хранилище резервируются вместе, в один файл?!Если да то можно ли их резервировать раздельно?!

    2. При переносе баз данных контента с настроенным внешних хранилищем на другой сервер, всегда необходимо перемещать фалы из внешнего хранилища в базу. Или можно забекапить базу данных  с внешним хранилищем и потом развернуть ее на новом сервере из бекапа?!


    • Изменено Serg777msk 7 мая 2014 г. 10:00