Есть ли способ использовать символические ссылки на данные больших двоичных объектов при использовании хранилища Azure, чтобы избежать дублирования больших двоичных объектов?

Question

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

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

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

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

Я что-то упустил или мне следует просто воспользоваться методом filesize_hash и сохранить свою иерархию, используя альтернативный метод.

Answer 1

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

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

Недостатком поддержки всего этого в табличном хранилище является то, что вы получаете ограниченный API-запрос для ваших больших двоичных объектов.Вместо этого я бы предложил использовать метаданные на блобах для создания ссылок.(при использовании REST-метаданных метаданные превращаются в обычные заголовки).

Так что для дублирующих BLOB-объектов просто оставьте один из них и сохраните заголовок ссылки, указывающий, где находятся данные.*

на данный момент большой двоичный объект теперь не принимает данные, но все еще присутствует в хранилище и будет возвращен при перечислении больших двоичных объектов.

Тогда при доступе к данным вам просто нужно будет проверить, есть ли у большого двоичного объекта "link "набор метаданных или с помощью rest, проверьте, присутствует ли заголовок x-ms-meta-link, а затем вместо этого прочитайте данные.

 blob.Container.GetBlockBlobReference(blob.Metadata["link"]).DownloadTextAsync()

или любой другой метод доступа к данным.

Выше приведены только основы, и я уверен, что вы можете выяснить остальное, если это будет использовано.

Answer 2

Нет, символических ссылок нет (источник: http://social.msdn.microsoft.com/Forums/vi-VN/windowsazuredata/thread/6e5fa93a-0d09-44a8-82cf-a3403a695922).

Хорошее решение зависит от ожидаемого размера файлов и количества дубликатов. Если дубликатов не будет много или файлы небольшие, на самом деле жить с ними может быть быстрее и дешевле - 0,15 долл. США за гигабайт в месяц - не так уж и много по сравнению с затратами на разработку! (Это подход, который мы используем.)

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

Если вы сделаете это, вы захотите сохранить имя файла (так как это будет то, что видимо пользователю), но вы можете назвать местоположение «папки» как хотите.