Comments 111
Отличная идея! Последний раз про дедупликацию писали в блоге Яндекса про Яндекс.Диск, но он пока не дорос до коммерческого продукта.
Про регистрацию — почему бы не сделать регистрацию через соцсети, а WebDav сделать доступным только для тех, кто создал пароль?
Про регистрацию — почему бы не сделать регистрацию через соцсети, а WebDav сделать доступным только для тех, кто создал пароль?
Bitcasa, насколько помню, так же хранит файлы.
А ваша система похожа на сбор средств и потом «До свидания»:
MD5 File is Available “AS-IS”
Though we want to provide a great service, there are certain things about the service we can't promise. For example, THE SERVICES AND SOFTWARE ARE PROVIDED “AS IS”, AT YOUR OWN RISK, WITHOUT EXPRESS OR IMPLIED WARRANTY OR CONDITION OF ANY KIND. WE ALSO DISCLAIM ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT. (We are not shouting- it's just that these disclaimers are really important, so we want to highlight them). MD5 File will have no responsibility for any harm to your computer system, loss or corruption of data, or other harm that results from your access to or use of the Services or Software.
А ваша система похожа на сбор средств и потом «До свидания»:
MD5 File is Available “AS-IS”
Though we want to provide a great service, there are certain things about the service we can't promise. For example, THE SERVICES AND SOFTWARE ARE PROVIDED “AS IS”, AT YOUR OWN RISK, WITHOUT EXPRESS OR IMPLIED WARRANTY OR CONDITION OF ANY KIND. WE ALSO DISCLAIM ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT. (We are not shouting- it's just that these disclaimers are really important, so we want to highlight them). MD5 File will have no responsibility for any harm to your computer system, loss or corruption of data, or other harm that results from your access to or use of the Services or Software.
Скажите, а электричество для шпинделей однократно закупается? А зарплата для обслуживающего сервера персонала?
Согласно расчетам (в исследовании они есть), стоимость хранения будет уменьшаться со временем, а единовременная плата взимается с учетом длительного хранения.
Согласно этим рассчётом зарплата сотрудников будет уменьшаться со временем? Ну-ну. Осталось это донести до, и проблема решена. Ах, да, ещё с петроэлектросбытом надо договориться об индексации вниз стоимости кв*ч каждый год. Делов-то. Для всех растёт, для нас снижаться будет.
Честно говоря, я смотрю на стоимость хранения данных в облаках и стоимость аренды серверов по отношению на 1GB хранения данных. И да, стоимость хранения данных в облаке и стоимость хранения данных на арендованных серверах из расчета на 1GB падает ежегодно. В эти стоимости уже включено электричество и персонал обслуживающий сервера.
Вы говорите про один сервер или про три?
Немного не понял вопроса, я говорю про цены на сервера, в том числе managed, например, hetzner.de постоянно предлагает все больше места, за все меньшие деньги, тоже самое делает и Amazon. И я не вижу никаких препятствий, чтобы данная тенденция продолжалась даже при увеличении стоимость электроэнергии, так как новые сервера потребляют все меньше электроэнергии, а новые жесткие диски вмещают все больше и больше информации за те же деньги.
Просто для понимания — Hetzner — это low-end, то есть десктопное железо. С соответствующей наработкой на отказ и надёжностью (в частности, вероятности успешного ошибочного чтения).
Сравните с стоимостью аренды сервера на серверном железе (хотя бы ECC multibit память и диски, рассчитанные на аптайм 24/365).
Сравните с стоимостью аренды сервера на серверном железе (хотя бы ECC multibit память и диски, рассчитанные на аптайм 24/365).
Вы можете привести примеры хостингов или облачных решений, в том числе high-end, которые ежегодно поднимают цены? Или может Селектел планирует повышать цены ежегодно на облачное хранилище, также, как мосэнергосбыт, повышает цены на электроэнергию? Что-то не очень верю в это. Hetzner тут приведен только для примера, наши сервера все с ECC.
Нет, обычно наблюдается мягкий паритет между снижением цены с одной стороны, инфляцией и ростом операционных расходов с другой, объясняющийся постепенной оптимизацией процессов.
Железо, формально, дешевеет, на практике скорость снижения «типового конфига» практически не заметна (за 12 лет она упала примерно в полтора-два раза).
Ключевым же является простая вещь: возьмите стоимость аренды нормальных серверов (3шт), добавьте маржу поставщика (никто не будет работать в «ноль»), зарплату тех, кто пишет и обслуживает систему (сравнить с расходами на работу dedicated) — и получится как раз более-менее цена.
Железо, формально, дешевеет, на практике скорость снижения «типового конфига» практически не заметна (за 12 лет она упала примерно в полтора-два раза).
Ключевым же является простая вещь: возьмите стоимость аренды нормальных серверов (3шт), добавьте маржу поставщика (никто не будет работать в «ноль»), зарплату тех, кто пишет и обслуживает систему (сравнить с расходами на работу dedicated) — и получится как раз более-менее цена.
12 лет назад типовой конфиг включал в себя какой-нибудь Maxtor Ultra ATA 66 5400 rpm 80 гигов за $479.99, а сейчас за эти деньги можно купить минимум 4TB, даже предположим, что стоимость этих трех серверов осталась на том же уровне, хотя это и не так, но ведь и хранить вы сможете в нем в 50 раз больше.Эти файлы еще через 12 лет будут для вас пылинкой в море. Если вы посчитаете предел данной функции, а она сходится, это и будет цена за гигабайт сейчас, чтобы хранить потом бесплатно.
Я, как человек, покупавший эти диски 12 лет назад, могу сказать, что тогдашние диски стоили чуть дороже нынешних. тот мейнстрим, который сейчас по $70, тогда шёл примерно по $100. Разумеется с теми ёмкостями.
Далее. Вы говорите про гигабайты. А как насчёт иопсов? Вот раньше диск в 10Гб размером выдавал примерно 30 IOPS'ов. Сейчас диск в 4Тб размером выдаёт примерно 90-100. Итого: раньше мы получали около 3000 IOPS на терабайт, а сейчас 25 IOPS на терабайт.
Файлы-то вы хотите не только хранить, но и доступ получать.
Следующий вопрос: а на какие шиши будут покупаться следующие диски и следующие сервера, чтобы хранить то, за что уже (один раз) заплачено?
И, повторюсь, зарплаты и электричество съедают больше себестоимости.
Далее. Вы говорите про гигабайты. А как насчёт иопсов? Вот раньше диск в 10Гб размером выдавал примерно 30 IOPS'ов. Сейчас диск в 4Тб размером выдаёт примерно 90-100. Итого: раньше мы получали около 3000 IOPS на терабайт, а сейчас 25 IOPS на терабайт.
Файлы-то вы хотите не только хранить, но и доступ получать.
Следующий вопрос: а на какие шиши будут покупаться следующие диски и следующие сервера, чтобы хранить то, за что уже (один раз) заплачено?
И, повторюсь, зарплаты и электричество съедают больше себестоимости.
Как я уже говорил, у нас расчет по аренде серверов, а не покупке, соответственно никаких проблем поменять на новые, особенно более дешевые и вместительные, хоть каждый день можем переходить на облачное хранилище и обратно на выделенный сервер, в зависимости от коньюктуры рынка.
Электричество и обслуживание серверов (кроме администрирования, которое фактически автоматизировано) проблема хостинга, а не наша. Мы просто выбираем оптимальный хостинг по цене и всё.
Для загрузки мы в дальнейшем, при росте трафика, планируем использовать кеширующие сервера на SSD с 100TB трафика (на гигабите) (такие уже есть сейчас где-то за 100 евро в месяц с ECC, например в leaseweb и будет еще больше), хотя и сейчас проблем с IOPS не наблюдаем. А, вероятность попадания одновременно всех пользователей на один и тот же сервер хранилища минимальна, так как распределение идет по хешам файлов.
При падении трафика, пересадим всех на один сервер. Эта очень гибкая система, если не покупать серверов, а арендовать.
Т.е. у нас фиксированные постоянные (уменьшающиеся во времени) расходы даже при неизменном количестве пользователей.
Электричество и обслуживание серверов (кроме администрирования, которое фактически автоматизировано) проблема хостинга, а не наша. Мы просто выбираем оптимальный хостинг по цене и всё.
Для загрузки мы в дальнейшем, при росте трафика, планируем использовать кеширующие сервера на SSD с 100TB трафика (на гигабите) (такие уже есть сейчас где-то за 100 евро в месяц с ECC, например в leaseweb и будет еще больше), хотя и сейчас проблем с IOPS не наблюдаем. А, вероятность попадания одновременно всех пользователей на один и тот же сервер хранилища минимальна, так как распределение идет по хешам файлов.
При падении трафика, пересадим всех на один сервер. Эта очень гибкая система, если не покупать серверов, а арендовать.
Т.е. у нас фиксированные постоянные (уменьшающиеся во времени) расходы даже при неизменном количестве пользователей.
То есть подождите, у вас есть _ежемесячные_ расходы, а деньги вы собираете единократно? То есть я могу к вам положить, например, 12Тб хлама, почитывать постоянно (чтобы в оффлайн вынести нельзя было), и вы будете меня обслуживать бесплатно, не смотря на то, что я вам всю СХД на уши ставить буду? Из месяца в месяц, из года в год?
Я даже верю, что в начальный-средний период у вас всё будет хорошо. А вот что будет в тот момент, когда аренда серверов с уже оплаченными начнёт стоить больше, чем будут приносить новые пользователи в месяц?
Я даже верю, что в начальный-средний период у вас всё будет хорошо. А вот что будет в тот момент, когда аренда серверов с уже оплаченными начнёт стоить больше, чем будут приносить новые пользователи в месяц?
Да, но так как это персональный хостинг, а не система раздачи вашего контента, то сидеть вы будете на одном сервере (скажем, на гигабитном канале). Попробую объяснить как это работает:
12ТБ хлама это 12288 гигабайт, сервер для отдачи будет нам стоить около 100 баксов в месяц, соответственно вы нам заплатите $12288, т.е. 10 лет хостинга даже в таком жестком режиме. Никто не гарантирует ведь вам, что используя систему не по прямому назначению, будет обеспечена паралельная отдача всего вашего контента (всех 12ТБ) на большой скорости. Но скорость будет достаточна, чтобы быстро скачать файл (несколько файлов) в конкретный момент времени.
12ТБ хлама это 12288 гигабайт, сервер для отдачи будет нам стоить около 100 баксов в месяц, соответственно вы нам заплатите $12288, т.е. 10 лет хостинга даже в таком жестком режиме. Никто не гарантирует ведь вам, что используя систему не по прямому назначению, будет обеспечена паралельная отдача всего вашего контента (всех 12ТБ) на большой скорости. Но скорость будет достаточна, чтобы быстро скачать файл (несколько файлов) в конкретный момент времени.
Речь не про скорость канала, а про IO (то есть random access).
Вы будете ограничены по количеству одновременных загрузок, а так можете качать файлы в любом порядке. Хранилище рассчитано на определенное количество одновременных соединений и не имеет значения на сколько они случайны, конечно вы отъедите 0.001% емкости сервера, но это капля в море. Это ведь не Amazon S3, мы не гарантируем вам бесконечное количество одновременных соединений.
Если вы думаете про каплю в море, то ошибаетесь. Никто и ничто мне не мешает хранить мелкие файлы раз, два, закрывать соединение не докачав файл.
Итог — высокий random read.
Итог — высокий random read.
Согласен, убить можно практически любую систему, ну а с пользователями, которые будут стараться угробить систему, будем бороться ограничениями по скорости, очередью запросов и другими методами в зависимости от ситуации. Система для персонального хранения и профиль пользователей, которые просто хотят навредить проекту можно отследить. Кстати, одна из причин, почему мы не говорили о нашем сервисе рускоязычным пользователям, уж очень много сразу захотят проверить его на прочность, даже без злого умысла.
Единственное, радует, что сначала им все-таки надо будет заплатить за это нам немного денег.
Единственное, радует, что сначала им все-таки надо будет заплатить за это нам немного денег.
Сколько будет хранить 100500 файлов по 0 байт каждый?
Вот об этом я и говорю, русские они такие, сам такой :) 0 байт нельзя, а вот 1 байт, к сожалению, можно. Будем ограничивать по одновременным запросам таких пользователей, если сильно хранилище напрягать будут, что тут поделаешь.
А можно данные в именах файлов хранить?
Я пишу в имя файла фрагмент base64, сам файл размером в 1 байт, список файлов содержит в себе данные.
Я пишу в имя файла фрагмент base64, сам файл размером в 1 байт, список файлов содержит в себе данные.
Можно, но при определенном отношении среднего размера метаданных к среднему размеру всех файлов, система округлит это и прибавит к общему размеру хранилища.
По мотивам: предлагаю подождать хотя бы годик. Если этот стартап через год сумеет выжить то говорить о чём-то можно будет. А пока выглядит как пирамида.
Согласен, уже живем годик, еще через год посмотрим, как раз закончим остальные запланированные фичи для пользователей и напишу обзор по мотивам этого поста. Хотя возможно буду и раньше публиковать новости, мне очень нравится, когда со мной спорят конструктивно, в таких спорах рождаются идеи и обнаруживаются баги.
Ответил не в ту ветку habrahabr.ru/post/138080/#comment_5632773 или есть лимит на отступ в ветке хабра?
Хочу еще вот что добавить, наш бизнес-план, как раз наоборот, подразумевает минимальный прирост новых пользователей. Основная цель увеличение ARPU от уже привлеченных пользователей. Именно поэтому, только через год после начала работы мы решили привлечь немного новых клиентов из России (в настоящий момент большинство пользвателей нашей системы не из России).
При такой стратегии, новые пользователи не имеют значения, если старые покупают периодически немного места дополнительно (хотя-бы 1 раз в год, в среднем). А по текущему профилю пользвателей, так и происходит, если конечно, Вы нам не зальете 12ТБ :)
При такой стратегии, новые пользователи не имеют значения, если старые покупают периодически немного места дополнительно (хотя-бы 1 раз в год, в среднем). А по текущему профилю пользвателей, так и происходит, если конечно, Вы нам не зальете 12ТБ :)
Если бы я был уверен в вашей надёжности/долговечности, то залил бы. Терабайт 30-50. Шифрованных, то есть уникальных на пользователя. С обещанием «хранить вечно».
Но я вам просто не верю, потому что ваша экономическая модель — чистой воды пирамида, в которой обслуживание существующих клиентов осуществляется за счёт привлечения новых (или привлечения дополнительных средств существующих клиентов под обещание большего сервиса бесплатно в дальнейшем).
Но я вам просто не верю, потому что ваша экономическая модель — чистой воды пирамида, в которой обслуживание существующих клиентов осуществляется за счёт привлечения новых (или привлечения дополнительных средств существующих клиентов под обещание большего сервиса бесплатно в дальнейшем).
В настоящий момент, при отсутствии новых пользователей и покупок старыми пользователями нового места мы можем спокойно существовать 10 лет. Посчитайте, сколько вам будет стоить хранение 30ТБ в течении хотябы двух лет на другом хостинге и будет понятно, что вы будете в выгоде даже после года такого хранения (если, например, это нужно вам для бакапов быстрого восстановления).
Мы не обещаем хранить вечно, мы обещаем, что будем точно следовать разработанной модели хранения файлов, а в случае форсмажорных обстоятельств (например, фатальная ошибка в расчетах) обеспечим по крайней мере один сервер с гигабитным каналом для выгрузки всех ваших данных обратно.
Мы не обещаем хранить вечно, мы обещаем, что будем точно следовать разработанной модели хранения файлов, а в случае форсмажорных обстоятельств (например, фатальная ошибка в расчетах) обеспечим по крайней мере один сервер с гигабитным каналом для выгрузки всех ваших данных обратно.
UFO just landed and posted this here
UFO just landed and posted this here
Почитал. Они очень политкорректно не написали ни про материнскую плату, ни про модель диска, ни про количество БП в десктопе.
UFO just landed and posted this here
Согласен, думаю, что стоит вспомнить на чем, по-крайней мере раньше работал Google: «Servers are commodity-class x86 PCs running customized versions of Linux». Реально хорошие сервера у них были только хранящие метаданные.
Скажите, а как вы будете обеспечивать той штуки, которая решает, какая реплика живая, а какая нет?
UFO just landed and posted this here
Вся БД хешей хранится на Amazon, в России только фронтенд сервера для загрузки и DNS (пока). Все данные на серверах хранилища тоже зашифрованы AES-256 ключами (уникальными для каждого файла) и тоже не в России.
UFO just landed and posted this here
>Все данные на серверах хранилища тоже зашифрованы AES-256 ключами (уникальными для каждого файла)
>MD5 File это персональная система хранения файлов c дедупликацией
Что-то не сходится.
>MD5 File это персональная система хранения файлов c дедупликацией
Что-то не сходится.
Да, это действительно так, так как в генерации ключа шифрования файла, кроме общего ключа, используются хеши самого файла md5/sha1/sha256. Т.е. невозможно расшифровать все файлы взяв только общий ключ (ну или подобрав каким-то образом к какому-нибудь одному зашифрованному файлу), необходимо еще знать, какой именно файл зашифрован (его метаданные, которые находятся на другом сервере). Файлы шифруются на сервере, но метаданные содержат информацию, что это файл и таким образом можно найти дубликаты.
А в чем смысл тогда шифрования файлов? Маркетинг?
В том, что мы хотим, чтобы на арендованных серверах не было файлов пользователей. Жесткий диск может умереть, его могут заменить, а куда он после этого уйдет мы не знаем. Можно, конечно установить файловую систему с шифрованием, но от этого будет страдать отдача файлов кеширующим серверам.
А при чем тут кэширующий сервер? Хранение отдельно, раздача отдельно, к тому-же можно кэш и в RAM держать, она нынче дешевая.
Кеширующий сервер — это сервер отдачи контента. Т.е. схема выглядит так: сервера хранения (или облачный сервис) -> сервер раздачи контента (со своим кешем, раздает в потоковом режиме с сервера хранения и паралельно сохраняет себе копию) -> пользователь. Нужно это для того, чтобы можно было без проблем мигрировать на любую систему хранения, будь то новый облачный сервис или сервера, так как реально очень сложно управлять конфигурациями серверов хранения (точнее дороже, чем найти хорошие предложения с большим объемом места). Насчет RAM, к сожалению в настоящий момент арендуемые решения редко позволяют добавлять очень много памяти за приемлимые деньги, по-моему дешевле арендовать сервер с SSD.
Ваша главная проблема, это арендуемые сервера, дешевле и проще купить свои хотя-бы на раздачу.
В этом случае нам будет нужно нанимать дополнительных сотрудников для обслуживания серверов. Включать в затраты амортизацию. Пропадает возможность быстро переехать на лучше условия, сервер в другой стране, итд. По-моему на текущем этапе нет смысла вкладываться в инфраструктуру и привязывать себя к определенному региону. Такая оптимизация возможна при маштабировании сервиса на сотни тысяч пользователей, но это пока не наш случай.
Ясно, еще один мертворожденный сервис. С архитектурой defective-by-design из-за попыток «сэкономить сейчас».
Честно говоря непонятно, почему сервис использующий облачные хранилища и арендованные сервера мертворожденный? А как же Dropbox, который данные в Amazon S3 хранит, что если у него все пользователи платить перестанут, а будут только бесплатным местом пользоваться? Кто будет оплачивать счета? Что произойдет с данными? Понятно, что дробокс не очень хороший пример, так как копии данных у пользователя, но я бы не стал сразу бы так резко отзываться о сервисе, только потому, что сервис не покупает своих серверов.
Если я правильно понял, то под дедупликацией у вас подразумевается исключение дублей на файловом уровне путем вычисления хешей для каждого файла. Что-то как-то очень сомнительно, что то что ваш метод дедупликации является эффективным.
Можете привести статистику эффективности за то время, которое сервис уже работает?
Можете привести статистику эффективности за то время, которое сервис уже работает?
Яндекс.Диск точно не хранит одинаковых файлов :)
они их чекают по sha1 (верогятность сбоя одного бита оперативной памяти больше чем коллизия по sha1)
это так, к сравнению разных систем хранения файлов.
они их чекают по sha1 (верогятность сбоя одного бита оперативной памяти больше чем коллизия по sha1)
это так, к сравнению разных систем хранения файлов.
Мы одновременно проверяем md5/sha1/sha256 хеши и размер файла, для исключения коллизий. Также сайт умеет экспортировать хеши файлов непосредственно из браузера для проверки соответствия файла оригиналу пользователем.
Теги «париж» и т. п. берутся из EXIF?
а «жена» по распознованию лиц?
Есть список кто хранит тот же файл? Например «не_порно.avi» Храните вы и еще 356 человек [показать список]
Это можно узнать при загрузке файла на сервис, система покажет сколько реально места будет потрачено на сохранение файла. Если файл уже загружен вами, то сохранение будет бесплатно, если есть другие пользователи, то поделит размер файла на колличество пользователей. Конкретный список пользователей не раскрывается.
«показать, что еще хранят те, кто хранит то же, что и вы» ;)
Нет, в настоящий момент сервис ищет только по тегам пользователя, названию файла и не заглядывает в чужие файлы.
Можно было бы для веселости прикрутить rolling hash и дедуплицировать частично различающиеся файлы (храня оригинал и дельту, конечно). Однако я не могу придумать, кому это нужно, так как контент обычно или совпадает байт-в-байт (фильмы, etc), или полностью различается.
Но если борьба за место серьезная, можно и такое попробовать.
Но если борьба за место серьезная, можно и такое попробовать.
Основная идея сервиса — постоянное хранение файлов за фиксированную цену и удобство поиска, дедупликация по частям увеличит сложность системы и скорее всего потребует больше места под метаданные. Пока мы от этой идеи отказались, из за сложности реализации и последующего подсчета и деления между пользователями.
Вообще, если уж предполагается упор на долговременное хранение, то часть пользователей захочет использовать этот сервис для хранения бэкапов, где уж точно потребуется частичная дедупликация.
А вообще, подобных файловых хранилищ существует великое множество, и про дедупликацию даже не упоминается, как само собой разумеющееся решение для подобного рода систем. А у вас есть киллерфича или ниша какая-то?
А вообще, подобных файловых хранилищ существует великое множество, и про дедупликацию даже не упоминается, как само собой разумеющееся решение для подобного рода систем. А у вас есть киллерфича или ниша какая-то?
Основная фича — заплатил за хранение файла один раз и больше не платишь. Т.е. никакой абонентской платы. Я не знаю других проектов, где можно накопить, скажем, терабайт данных и не платить абонентскую плату за доступ к ним. Также я не знаю ни одного проекта, где дедупликация позволяет пользователю хранить больше файлов, т.е. где пользователю возвращается часть места, если данный файл хранят какие-либо еще пользователи системы.
Вы действительно считаете, что пользователи хоть где-то сейчас платят деньги за хранение неуникального контента? Разве что если используют сервис как хранилище для отдачи контента, но это уже совсем другой класс систем.
Ну и вообще, что будет с моим счетом за услуги, если изначально пользователь Петя загрузит файл А, затем я загружу файл А (как я понимаю, он не включится в стоимость), а потом Петя удалит файл А. С меня стоимость хранения этого файла снимут, при том в одностороннем порядке?
Ну и вообще, что будет с моим счетом за услуги, если изначально пользователь Петя загрузит файл А, затем я загружу файл А (как я понимаю, он не включится в стоимость), а потом Петя удалит файл А. С меня стоимость хранения этого файла снимут, при том в одностороннем порядке?
По-поводу неуникального контента, мы думаем, что часть пользователей будет объединяться в группы по интересам и хранить информацию совместно.
Насчет счета, Петя загрузит файл А в 1GB и потратит 1GB своего места, потом Вы загрузите файл A и потратите 0.5GB своего места, а Пете система автоматически вернет 0.5GB. Удаление файла не приводит к изменению данного расчета в сторону увеличения, так как это постоянное хранилище (файл сохраняется навсегда за фиксированную цену). Если после этого Вася загрузит тот же файл, то каждый будет использовать 1GB/3 места в своей учетной записи для хранения этого файла. Соответственно никаких дополнительных платежей нет и быть не может.
Насчет счета, Петя загрузит файл А в 1GB и потратит 1GB своего места, потом Вы загрузите файл A и потратите 0.5GB своего места, а Пете система автоматически вернет 0.5GB. Удаление файла не приводит к изменению данного расчета в сторону увеличения, так как это постоянное хранилище (файл сохраняется навсегда за фиксированную цену). Если после этого Вася загрузит тот же файл, то каждый будет использовать 1GB/3 места в своей учетной записи для хранения этого файла. Соответственно никаких дополнительных платежей нет и быть не может.
Допустим так — Петя загружает файл А в 1 Гб, с него списывается 1$. Я загружаю файл А, с меня списывается 0.5$ за 0.5 Гб, Пете возвращается 0.5$. Затем Петя удаляет файл А, ему возвращаются его оставшиеся 0.5$ (ну или эквивалент в объеме 0.5 Гб). В результате Петя с нейтральным балансом, а я храню полгига бесплатно. Система нагнута.
Или возврата денег за удаление файла не предусмотрено? Если так, то это растет только из поддержки дедупликации, которая может отработать допустим для 10% клиентов, а остальных только отпугнет невозможность возврата денег за удаление файла.
Или возврата денег за удаление файла не предусмотрено? Если так, то это растет только из поддержки дедупликации, которая может отработать допустим для 10% клиентов, а остальных только отпугнет невозможность возврата денег за удаление файла.
Немного не так, система не оперирует деньгами, пользователь покупает место, деньги не возвращаются, только место. И как я уже говорил, удаление файла не приводит к освобождению места за хранение данного файла у пользователя. Удаляется только метаинформация о том, как пользователь назвал файл и какие теги присвоил. В том то и дело, что система предназначена для постоянного хранения за фиксированную сумму. Для временного хранения файлов существует куча сервисов с абонентской платой. Данный сервис без абонентской платы, совсем.
Банально отказавшись от предложенной вами схемы пересчета места при дедупликации (не отключая её фактически), которая абсолютно непредсказуема и непланируема (откуда я могу знать, что там залито уже на сервисе? А что через месяц будет, если я планирую расходы?), можно сделать возврат места при удалении, что многократно увеличит привлекательность для пользователей.
Ну и опять же, кто целевая аудитория то? Какие юз-кейсы и так далее? Потому что некоторые описанные приемы значительно сужают перспективные аудитории.
Ну и опять же, кто целевая аудитория то? Какие юз-кейсы и так далее? Потому что некоторые описанные приемы значительно сужают перспективные аудитории.
Мы просчитывали этот вариант, к сожалению, если сделать возврат места при удалении, то фактически пользователь не будет покупать новое пространство, а постоянно использовать необходимый ему объем, скажем 100 гигабайт причем без абонентской платы, соответственно не будет средств на поддержку системы (ведь нужны постоянные платежи из расчета не менее 1-2 покупок в день, для поддержки серверов), а так их можно будет брать только с новых пользователей, что действительно начнет напоминать пирамиду.
Насчет того, как узнать, что залито, сервис сам сообщит, перед тем как предложить сохранить файл навсегда. Но данная фича будет работать только при большом количестве пользователей или если пользователи сами объединятся в группу (где-то вне сервиса), для хранения, скажем какой-либо документации совместно, или еще чего-нибудь.
Насчет того, как узнать, что залито, сервис сам сообщит, перед тем как предложить сохранить файл навсегда. Но данная фича будет работать только при большом количестве пользователей или если пользователи сами объединятся в группу (где-то вне сервиса), для хранения, скажем какой-либо документации совместно, или еще чего-нибудь.
Приведите все-таки реальные примеры случаев, в которых пользователям будет выгоднее использовать именно ваш сервис. Я сколько вариантов не перебираю — фиксированный объем, пусть и с помесячной оплатой, выходит предпочтительнее, кроме каких-то совсем уж вырожденных случаев.
Например, пользователи форума автомобиль.ру хотят создать коллекцию всех мануалов для всех автомобилей, таким образом, они объединяются и сохраняют совместно данные в нашем сервисе. Например 100 пользователей по 10 долларов каждый могут загрузить 1 TB данных и хранить бесплатно. В скором времени, можно будет передавать ссылку другому пользователю системы, чтобы он смог поучаствовать в хранении файла и таким образом распределять стоимость хранения на тех пользователей, которым они нужны.
Немного не понятно. Допустим, я загрузил один файл на 1Гб. Потом удалил его, потом загрузил другой, тоже на 1Гб. Сколько я буду вам должен? 1 или 2$
Удалить файл нельзя, удаление файла приводит только к удалению метаинформации. Если загрузить (после удаления) тот же файл, он ничего стоить не будет для пользователя. Т.е. ответ $1 за каждый файл (если есть N пользователей с таким же файлом, то в N раз меньше). Фактически сервис оперирует не деньгами, а местом, т.е. будет два пользователя сервис вернет каждому по 0.5GB за файл и это место можно использовать для загрузки другого файла.
UFO just landed and posted this here
Мы сказали, что храним метаданные в Amazon (Simple DB), все данные пользователя храняться на арендованных выделенных серверах. По текущим ценам, и уже полученному доходу, мы сможем хранить файлы в течении 10 лет (такой запас по цене за гигабайт) без убытка для нас. Данные деньги уже в резерве, и не будут потрачены. За это время стоимость хранения должна уменьшиться, таким образом мы можем обеспечить долгосрочное хранение.
UFO just landed and posted this here
Стоимость хранения уменьшится на столько, что не потребуется столько серверов, соответствено из резерва можно будет их оплатить. Это в случае, если совсем не будет никто ничего больше покупать. В противном случае, одна покупка через 10 лет окупить стоимость хранения 100 старых файлов, а может и больше.
На трех серверах.
Если я правильно понял вопрос, то, файл загружается на фронтенд (считается хеш), после чего загружается на три сервера, которые проверяют хеш суммы и отдают эту информацию скрипту загрузки на фронтенде.
На трех серверах.
Если я правильно понял вопрос, то, файл загружается на фронтенд (считается хеш), после чего загружается на три сервера, которые проверяют хеш суммы и отдают эту информацию скрипту загрузки на фронтенде.
UFO just landed and posted this here
Тем, что есть реальный расчет и резерв на непредвиденные расходы. Стоимость хранения старых файлов уменьшается с каждым годом, а текущая стоимость взята с запасом на хранения 1GB данных в течении 10 лет.
UFO just landed and posted this here
К сожалению, я не имею возможности раскрыть все подробности бизнес-кейса проекта, но достаточным, чтобы еще 5 лет хранить данные без дополнительных финансовых вливаний и без падения стоимости хранения, хотя этот вариант мне, как и многим другим, кажется маловероятным и за 15 лет стоимость станет такой, что это все можно будет сохранить на одном дешевом сервере (мы рассматриваем вариант, что пользователи сегодня придут на сайт, зальют файлы и уйдут навсегда и больше не будут покупать место и новых пользователей тоже не будет, но при этом они будут заходить каждый день на сайт и что-то качать).
Будет ли расшаривание папок между пользователями, aka Dropbox?
Если да, то как тогда будет считаться стоимость расшаренных файлов?
Если да, то как тогда будет считаться стоимость расшаренных файлов?
Сейчас планируется только расшаривание файлов между пользователями системы, т.е. пользователь А передает ссылку на файл пользователю B, пользователь B принимает ссылку на файл, а вместе с ней и делит расходы на хранение данного файла.
А если пользователь В потом удалит этот файл?
С пользователя А тогда нужно будет взять доп. плату?
С пользователя А тогда нужно будет взять доп. плату?
Нет, так как удаление не влияет на хранение. Т.е. фактически удаляя файл, пользователь удаляет только метаданные, но все равно остается ответственен за хранение данного файла частью своего купленного места и загрузив этот файл снова он не потратит дополнительного места, так как физически уже хранит его. Это преманентное хранилище, сохранил и забыл, часть места под файл может вернуться только если кто-то другой тоже сохранил себе этот файл.
Всё хорошо, но MD5 без TTH — зло. Крайне желательно, чтобы TTH был
Мы используем сравнение трех хешей одновременно md5, sha1, sha256, а также размер файла, для проверки целостности. Зачем еще Tyger Hash?
Вот лучше бы TTH, ED2K, AICH
Чтобы не устраивать Вавилонское столпотворение. Не для целостности, так для информации TTH крайне желательно, чтобы был, а если в виде магнитной ссылки — ещё лучше. А если HTTP сервер будет поддерживать расширения HTTP, которые позволяют Shareaza находить альтернативные источники в p2p сетях — вообще замечательно. Это поспособствует тому, чтобы эти расширения HTTP появились в других p2p–клиентах.
Чтобы не устраивать Вавилонское столпотворение. Не для целостности, так для информации TTH крайне желательно, чтобы был, а если в виде магнитной ссылки — ещё лучше. А если HTTP сервер будет поддерживать расширения HTTP, которые позволяют Shareaza находить альтернативные источники в p2p сетях — вообще замечательно. Это поспособствует тому, чтобы эти расширения HTTP появились в других p2p–клиентах.
Пока мы планируем добавить только BTIH. По-моему большинство уже давно в торрентах. Неужели есть еще кто-то использующий emule? Да, и DC, похоже, в России потихоньку региональные провайдеры прикрывают. Есть ли смысл поддерживать старые хеши?
А что толку от BTIH, если его каждый как хочет считает? BTIH как раз и старый. Надо было сделать proof of concept p2p, а какие через десять лет проблемы возникнут, было видно лишь смутно. В то время какое–то оправдание было, сейчас оправдания нет. RetroShare, maggot, Shareman, каждый со своими велосипедными хешами. Так нельзя.
Причина, по которой предпочтение отдаётся TTH — его технические особенности и его использование в двух независимых p2p протоколах. Собственно, в DC++ TTH появился как раз из–за того, что кто–то из разработчиков оценил TTH по достоинству. До этого NMDC был как FTP с поиском. Если копаться в старых клиентах, в каком–то консольном клиенте NMDC можно найти поддержку ED2K, то есть, такой однозначный выбор был хеша сделан не сразу.
Насчёт emule не знаю, но ED2K всяко полезней считать, чем MD5. Насколько я помню, Gnutella2 позволяет искать по ED2K
Если в клиентах BitTorrent появится поддержка списка файлов, пофайловый TTH и поиск по TTH, я не против BitTorrent.
Пока этого нет, всё это большинство пусть сидит в торрентах хоть до посинения, количество не перейдёт в качество. Прогресс для пользователей этого протокола заблокирован.
И, насколько я помню, некоторые сайты предлагают использовать собственные даунлодеры, и почему бы не Shareaza? Shareaza умеет работать HTTP качалкой и встраиваться в браузер как FlashGet. При этом через расширения HTTP можно получить хеши. В общем, если у юзера чего–то не стоит, я бы не сказал, что это большая проблема.
Унификацию хешей я считаю прогрессом. Многие хорошие вещи не случились потому что Яндекс.Диск пишет один хеш, open source дистрибутивы для проверки целостности пишут в checksum.sfv другой хеш, а среди p2p–клиентописатели слишком велики доли двух групп: первая группа по наивности использует цельнофайловый хеш, приглашая тем самым недоброжелателей безнаказанно отравлять раздачи, как это было в Gnutella1 до введения TTH. Вторая группа учитывает эту проблему, но как решение, велосипедит пи–хеши и BTIHи. Вместо того, чтобы всем дружно использовать TTH.
Причина, по которой предпочтение отдаётся TTH — его технические особенности и его использование в двух независимых p2p протоколах. Собственно, в DC++ TTH появился как раз из–за того, что кто–то из разработчиков оценил TTH по достоинству. До этого NMDC был как FTP с поиском. Если копаться в старых клиентах, в каком–то консольном клиенте NMDC можно найти поддержку ED2K, то есть, такой однозначный выбор был хеша сделан не сразу.
Насчёт emule не знаю, но ED2K всяко полезней считать, чем MD5. Насколько я помню, Gnutella2 позволяет искать по ED2K
По-моему большинство уже давно в торрентах
Если в клиентах BitTorrent появится поддержка списка файлов, пофайловый TTH и поиск по TTH, я не против BitTorrent.
Пока этого нет, всё это большинство пусть сидит в торрентах хоть до посинения, количество не перейдёт в качество. Прогресс для пользователей этого протокола заблокирован.
И, насколько я помню, некоторые сайты предлагают использовать собственные даунлодеры, и почему бы не Shareaza? Shareaza умеет работать HTTP качалкой и встраиваться в браузер как FlashGet. При этом через расширения HTTP можно получить хеши. В общем, если у юзера чего–то не стоит, я бы не сказал, что это большая проблема.
Унификацию хешей я считаю прогрессом. Многие хорошие вещи не случились потому что Яндекс.Диск пишет один хеш, open source дистрибутивы для проверки целостности пишут в checksum.sfv другой хеш, а среди p2p–клиентописатели слишком велики доли двух групп: первая группа по наивности использует цельнофайловый хеш, приглашая тем самым недоброжелателей безнаказанно отравлять раздачи, как это было в Gnutella1 до введения TTH. Вторая группа учитывает эту проблему, но как решение, велосипедит пи–хеши и BTIHи. Вместо того, чтобы всем дружно использовать TTH.
Да, и DC, похоже, в России потихоньку региональные провайдеры прикрываютDC есть и глобальные. DC вообще не в России зародился. Начиная со StrongDC++, есть DHT, хотя децентрализация пока не столь развита, как в Gnutella2. Как постоянный пользователь GreyLink, я могу сказать, что достойных альтернатив DC++ и Gnutella2 пока не состоялось. Чтобы они быстрее состоялись, хорошо бы, чтобы все использовали TTH. Даже там, где это не критично. Пусть программисты задумываются, а почему из всех хешей выбран именно TTH, обнаруживают, что, оказывается, без унификации хешей к TTH столько прогресса прошло стороной, запоминают и, может быть, на несколько велосипедов станет меньше, а прогресс станет ближе
Удивительно, что это так, лично я забросил Ed2k в тот момент когда появились первые торрент трекеры, да и хеш, по-моему в торрентах каждой части по-отдельности считается… Но в любом случае мы подумаем над реализацией TTH.
Вопрос, а разве Gnutella2 не умеет искать по SHA1 хешам?
Вопрос, а разве Gnutella2 не умеет искать по SHA1 хешам?
Я видел ED2K только сквозь Shareaza.
Недостаток BTIH — зависимость от размера минимально проверяемого блока. Разные размеры блоков, разные имена файлов, разная метаинформация — всё это меняет BTIH. TTH для файла определён жёстко, но при этом в силу своей древесной структуры позволяет варьировать размер минимально проверяемого блока по степеням двойки, не изменяя корневой хеш. Размер зависит от того, какой слой Merkle Tree передаётся между пирами. У разных протоколов могут слегка отличаться требования к степени детализации, но в случае с TTH можно увеличивать детализацию на лету.
Gnutella2 умеет искать и по SHA1, и по MD5, и по TTH, и по ED2K. Если у Shareaza не хватает важных хешей, она пытается узнать их от других узлов сети (Shareaza хранит метаинформацию даже после удаления файлов), но этой информации она может верить только на слово (по принципу большинства)
Недостаток BTIH — зависимость от размера минимально проверяемого блока. Разные размеры блоков, разные имена файлов, разная метаинформация — всё это меняет BTIH. TTH для файла определён жёстко, но при этом в силу своей древесной структуры позволяет варьировать размер минимально проверяемого блока по степеням двойки, не изменяя корневой хеш. Размер зависит от того, какой слой Merkle Tree передаётся между пирами. У разных протоколов могут слегка отличаться требования к степени детализации, но в случае с TTH можно увеличивать детализацию на лету.
Gnutella2 умеет искать и по SHA1, и по MD5, и по TTH, и по ED2K. Если у Shareaza не хватает важных хешей, она пытается узнать их от других узлов сети (Shareaza хранит метаинформацию даже после удаления файлов), но этой информации она может верить только на слово (по принципу большинства)
Почитайте про DropShip:
forwardfeed.pl/index.php/2011/04/24/dropship-successor-to-torrents-eng/
en.wikipedia.org/wiki/Dropship_%28software%29
Так, просто. Чтоб иметь в виду, и осознанно решать имеет это к вам отношение или нет. Применим ли такой «exploit» к вашей системе, стоит ли его закрывать и как именно, если да.
Насколько я понял, фишка была в том, что DropBox клиент вычислял хэши для дедупликации, и посылал только измененные куски файла, или вообще ничего не посылал, если такой файл уже был. Очевидно, что хитро модифицированный клиент может посылать хэши, даже если у него нет никакого файла — то есть у кого-то есть файл, он его заливает на DropBox, публикует хэши — и вперед, file sharing.
forwardfeed.pl/index.php/2011/04/24/dropship-successor-to-torrents-eng/
en.wikipedia.org/wiki/Dropship_%28software%29
Так, просто. Чтоб иметь в виду, и осознанно решать имеет это к вам отношение или нет. Применим ли такой «exploit» к вашей системе, стоит ли его закрывать и как именно, если да.
Насколько я понял, фишка была в том, что DropBox клиент вычислял хэши для дедупликации, и посылал только измененные куски файла, или вообще ничего не посылал, если такой файл уже был. Очевидно, что хитро модифицированный клиент может посылать хэши, даже если у него нет никакого файла — то есть у кого-то есть файл, он его заливает на DropBox, публикует хэши — и вперед, file sharing.
Sign up to leave a comment.
Система хранения файлов с дедупликацией между пользователями