Pull to refresh
0
0
qrasik @qrasik

User

Send message
Зачем?
Нет, если вам интересно, то 12-37% это при решении задачи через API и ухищрения.

При решении «в лоб» все гораздо скучнее получается. Как я говорил, в моем случае информация в виде архивов хранится, поэтому хранимый объем был бы разный для облака и для хранилища и разница достигала бы 3-4 раза минимум
А тут вы сами понимаете, хранилище для моей задачи совсем невыгодным становится.

С учетом же ухищрений (не учитывая стоимость миграции) исходящий трафик становится величиной значимой. И разница в 5-15копеек за месяц превращается уже в приличную сумму.
Все зависит от методики подсчета. Если хранить и отдавать допустим ISO и отдавать чем-нибудь «толстым» апачем, допустим, то да, ваши расчеты имеют право быть.

Насчет 256Мб для статики вы усложняете. Достаточно 64 и будет работать, но у вас 128 это минимум. Плюсуем сюда еще такую штуку как архивы. Информация хранится в архивах, отдается распакованной. Плюс забор файлов не рандомный, то есть 128Мб еще и на небольшой кеш хватает.

Так проценты и накапливаются.
P.S. Надо бы запретить сотрудникам фирмы выставлять оценки в блоге этой же фирмы. А то прям не хабр а рекламная площадка получается. :-)
Я не сравниваю стоимость хранения. Стоимость хранения, на текущий момент, одинаковая.

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

То есть в сумме, хранилище получается хоть немного но дороже. А где выгода? Надо же и стоимость миграции учитывать тоже…
Признаюсь, мне хранилище импонирует, но при его использовании я потеряю от 12 до 37%. И меня это печалит.
Облако:
Сеть: отправлено (исходящий трафик): 64 копейки за гигабайт
Диск: прочитанный/записанный объем: 10 копеек за гигабайт

Хранилище
Сеть (исходящий трафик): 0.8 руб. за Гб

Внимание вопрос, с чего вы взяли, что трафик в 2 раза дешевле? Написано же 0.8.
Кхм…
Насчет нецелевого использования облака оно может и верно, но по цене облако чуток но дешевле получается: 0.64-0.74 против 0.8.
Опять таки это сужает область применения хранилища. Довод про 3-х кратное резервирование конечно хорош, но после неприятной истории с Amazon панацеей я это не считаю, да и насколько помню, облаку тоже гарантировали что-то подобное.
Но в итоге, все-равно придется считать хеш для всех файлов. Если совпадают размеры, надо удостоверится и снять хеш, а если размеры не совпадают со списком… тоже надо сделать хеш, чтобы внести его в список. В итоге, те же яйца, только в профиль.
Упс… Да вы правы, это я ваш комментарий не правильно понял. :-(
Согласен, но от этой практики пришлось отказаться. Очень часто, из-за этого, проскакивали файлы с одинаковыми размерами, но разным содержимым. html-странички в основном. Исправишь что-нибудь, смотришь, а размер тот же получился.
Для упрощения задачи (только mp3) можно считать хеш не от всего mp3 файла, а только от тела, исключая ID3 теги. Но это на две строчки сложнее. :-) А программист существо ленивое экономное.
Ничего, вот соберусь писать web-интерфейс к «бекаперу», я у них и интерфейс экспроприирую.
вы дорогой, очень похожи на любителя, забивать гвозди микроскопами. :)
Java это не панацея.. Да и учить ее для парочки простеньких скриптов, на мой взгляд, весьма бессмысленно.

Information

Rating
Does not participate
Registered
Activity