Использовать Sql Server FileStream или традиционный файловый сервер? - PullRequest
2 голосов
/ 27 декабря 2010

Я проектирую систему, в которой будет около 10 миллионов пользователей, у каждого есть фотография, которая составляет около 1 ~ 2 МБ. Мы собираемся развернуть базу данных и веб-приложение с помощью Microsoft Azure. Мне интересно, как я должен хранить фотографии, в настоящее время есть два варианта,

1, Храните все фотографии, используя Sql Server FileStream

2, используйте файловый сервер

Я не сталкивался с такими крупномасштабными BLOB-данными при использовании FileStream.

Кто-нибудь может дать мне какое-нибудь предложение? Минусы и плюсы? И любой, у кого есть опыт работы с Microsoft Azure в отношении большого магазина фотографий, очень ценится!

Thx Райан.

Ответы [ 5 ]

5 голосов
/ 27 декабря 2010

Я голосую за ни одного. Используйте хранилище BLOB-объектов Windows Azure. Простой REST API, $ 0,15 / ГБ / мес. Вы даже можете обслуживать изображения непосредственно оттуда, если сделаете их общедоступными (например, image), то есть вам не нужно передавать их через веб-приложение.

4 голосов
/ 27 декабря 2010

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

  • Стоимость - SQL Azure стоит довольно дорого за ГБ хранилища и имеет небольшие ограничения хранилища (50 ГБ на базу данных), что делает его плохим выбором длядвоичные данные.Хранилище BLOB-объектов Windows Azure значительно дешевле для обслуживания бинарных объектов (хотя и имеет немного более сложную систему ценообразования, но все же значительно дешевле на ГБ).
  • Пропускная способность - SQL Azure имеет довольно хорошую пропускную способность, поскольку она хорошо масштабируется,однако хранилище блога Windows Azure имеет еще большую пропускную способность, поскольку оно может масштабироваться до любого количества узлов.
  • Сеть доставки контента - функция, недоступная для SQL Azure (хотя может быть создана сложная, настраиваемая оболочка), номожет быть легко настроен в течение нескольких минут, чтобы полностью освободить хранилище BLOB-объектов Windows Azure для обеспечения неограниченной пропускной способности для конечных пользователей, поэтому вам никогда не придется беспокоиться о том, что ваши двоичные объекты являются узким местом в вашей системе.Стоимость CDN аналогична стоимости хранилища BLOB-объектов, но все это можно найти здесь: http://www.microsoft.com/windowsazure/pricing/#windows

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

1 голос
/ 09 мая 2014

FILESTREAM - ужасная опция для хранения изображений. Я удивлен, что MS когда-либо продвигал это.

В настоящее время мы используем его для наших изображений на нашем сайте. В основном пользователь генерирует изображения и любые связанные с CMS вещи, которые создают администраторы. Решение использовать FILESTREAM было принято до того, как я начал. Самая большая проблема связана с подачей изображений. Вам лучше иметь CDN, сидящий впереди. Если нет, то планируйте, что ваша система остановится. Конечно, на большинстве сайтов есть CDN, но вы не хотите, чтобы эта служба выходила из строя, что означает, что ваша система будет перегружена. Количество стресса на вашем сервере sql является главной проблемой здесь.

С точки зрения простоты резервного копирования. Ваш компромисс заключается в том, что ваш БД НАМНОГО БОЛЬШЕ и, следовательно, резервное копирование занимает больше времени. Потенциально, намного дольше, и система работает медленнее во время резервного копирования. Не говоря уже о том, что перемещение резервных копий занимает больше времени (т. Е. Восстановление данных prod в среде разработчика или на локальных машинах для целей разработки). Не используйте это как решающий фактор.

Большинство облачных сервисов имеют автоматическое резервирование любых файлов, которые вы храните в своей системе (т. Е. AWS S3 и BLOB-объект Azure). Если вы находитесь на предпосылке, просто убедитесь, что вы используете общее расположение для изображений и убедитесь, что это место резервируется. Я думаю, что лучший вариант - это настроить его так, чтобы каждое изображение (и другие типы файлов UGC) имели запись в вашей базе данных с путем к этому файлу. Идя дальше, выделите корневой путь в настройку конфигурации и сохраните только оставшийся путь вместе с записью. Например, корневой путь в конфигурации может быть базовым URL, общим диском или виртуальным каталогом или пустой записью. Тогда ваша запись может иметь "/files/images/image.jpg". Таким образом, если вы перемещаете свое хранилище файлов, вы можете просто обновить конфигурацию root. Я бы также предложил создать интерфейс FileStoreProvider (Singleton), который можно использовать для управления (сохранения, удаления, обновления) этих файлов. Таким образом, если вы переключаетесь между AWS, Azure или в помещении, вы можете просто создать нового поставщика.

1 голос
/ 27 декабря 2010

Я не могу говорить ни о чем, касающемся Azure, но за мои деньги самое большое преимущество использования FILESTREAM состоит в том, что эти данные могут быть скопированы в процессе обычного резервного копирования SQL Server.Размер данных, о которых вы говорите, также говорит о том, что FILESTREAM также может быть хорошим выбором.

Я работал над системой SCM с серверной частью RDBMS, и одним из наших важных решений было:хранить файловые дельты в файловой системе или внутри самой БД.Поскольку это была кросс-реляционная СУБД, нам пришлось придумать общий способ, не связанный с FILESTREAM, но возможность делать одноразовое резервное копирование продавалась нам.

0 голосов
/ 11 сентября 2013

У меня есть клиент-серверная БД, я управляю многими файлами (doc, txt, pdf, ...), и все они идут в потоке файлов BLOB. Клиенты имеют 50+ МБ базы данных. Если в лазури вы можете сделать то же самое, сделайте это. Иметь все в БД - замечательная вещь. Это считается хорошей политикой также для Postgres и MySQL

...