В этом случае нам будет нужно нанимать дополнительных сотрудников для обслуживания серверов. Включать в затраты амортизацию. Пропадает возможность быстро переехать на лучше условия, сервер в другой стране, итд. По-моему на текущем этапе нет смысла вкладываться в инфраструктуру и привязывать себя к определенному региону. Такая оптимизация возможна при маштабировании сервиса на сотни тысяч пользователей, но это пока не наш случай.
Пока мы планируем добавить только BTIH. По-моему большинство уже давно в торрентах. Неужели есть еще кто-то использующий emule? Да, и DC, похоже, в России потихоньку региональные провайдеры прикрывают. Есть ли смысл поддерживать старые хеши?
Хочу еще вот что добавить, наш бизнес-план, как раз наоборот, подразумевает минимальный прирост новых пользователей. Основная цель увеличение ARPU от уже привлеченных пользователей. Именно поэтому, только через год после начала работы мы решили привлечь немного новых клиентов из России (в настоящий момент большинство пользвателей нашей системы не из России).
При такой стратегии, новые пользователи не имеют значения, если старые покупают периодически немного места дополнительно (хотя-бы 1 раз в год, в среднем). А по текущему профилю пользвателей, так и происходит, если конечно, Вы нам не зальете 12ТБ :)
Да, но так как это персональный хостинг, а не система раздачи вашего контента, то сидеть вы будете на одном сервере (скажем, на гигабитном канале). Попробую объяснить как это работает:
12ТБ хлама это 12288 гигабайт, сервер для отдачи будет нам стоить около 100 баксов в месяц, соответственно вы нам заплатите $12288, т.е. 10 лет хостинга даже в таком жестком режиме. Никто не гарантирует ведь вам, что используя систему не по прямому назначению, будет обеспечена паралельная отдача всего вашего контента (всех 12ТБ) на большой скорости. Но скорость будет достаточна, чтобы быстро скачать файл (несколько файлов) в конкретный момент времени.
Кеширующий сервер — это сервер отдачи контента. Т.е. схема выглядит так: сервера хранения (или облачный сервис) -> сервер раздачи контента (со своим кешем, раздает в потоковом режиме с сервера хранения и паралельно сохраняет себе копию) -> пользователь. Нужно это для того, чтобы можно было без проблем мигрировать на любую систему хранения, будь то новый облачный сервис или сервера, так как реально очень сложно управлять конфигурациями серверов хранения (точнее дороже, чем найти хорошие предложения с большим объемом места). Насчет RAM, к сожалению в настоящий момент арендуемые решения редко позволяют добавлять очень много памяти за приемлимые деньги, по-моему дешевле арендовать сервер с SSD.
В том, что мы хотим, чтобы на арендованных серверах не было файлов пользователей. Жесткий диск может умереть, его могут заменить, а куда он после этого уйдет мы не знаем. Можно, конечно установить файловую систему с шифрованием, но от этого будет страдать отдача файлов кеширующим серверам.
Да, это действительно так, так как в генерации ключа шифрования файла, кроме общего ключа, используются хеши самого файла md5/sha1/sha256. Т.е. невозможно расшифровать все файлы взяв только общий ключ (ну или подобрав каким-то образом к какому-нибудь одному зашифрованному файлу), необходимо еще знать, какой именно файл зашифрован (его метаданные, которые находятся на другом сервере). Файлы шифруются на сервере, но метаданные содержат информацию, что это файл и таким образом можно найти дубликаты.
Как я уже говорил, у нас расчет по аренде серверов, а не покупке, соответственно никаких проблем поменять на новые, особенно более дешевые и вместительные, хоть каждый день можем переходить на облачное хранилище и обратно на выделенный сервер, в зависимости от коньюктуры рынка.
Электричество и обслуживание серверов (кроме администрирования, которое фактически автоматизировано) проблема хостинга, а не наша. Мы просто выбираем оптимальный хостинг по цене и всё.
Для загрузки мы в дальнейшем, при росте трафика, планируем использовать кеширующие сервера на SSD с 100TB трафика (на гигабите) (такие уже есть сейчас где-то за 100 евро в месяц с ECC, например в leaseweb и будет еще больше), хотя и сейчас проблем с IOPS не наблюдаем. А, вероятность попадания одновременно всех пользователей на один и тот же сервер хранилища минимальна, так как распределение идет по хешам файлов.
При падении трафика, пересадим всех на один сервер. Эта очень гибкая система, если не покупать серверов, а арендовать.
Т.е. у нас фиксированные постоянные (уменьшающиеся во времени) расходы даже при неизменном количестве пользователей.
Нет, так как удаление не влияет на хранение. Т.е. фактически удаляя файл, пользователь удаляет только метаданные, но все равно остается ответственен за хранение данного файла частью своего купленного места и загрузив этот файл снова он не потратит дополнительного места, так как физически уже хранит его. Это преманентное хранилище, сохранил и забыл, часть места под файл может вернуться только если кто-то другой тоже сохранил себе этот файл.
Сейчас планируется только расшаривание файлов между пользователями системы, т.е. пользователь А передает ссылку на файл пользователю B, пользователь B принимает ссылку на файл, а вместе с ней и делит расходы на хранение данного файла.
12 лет назад типовой конфиг включал в себя какой-нибудь Maxtor Ultra ATA 66 5400 rpm 80 гигов за $479.99, а сейчас за эти деньги можно купить минимум 4TB, даже предположим, что стоимость этих трех серверов осталась на том же уровне, хотя это и не так, но ведь и хранить вы сможете в нем в 50 раз больше.Эти файлы еще через 12 лет будут для вас пылинкой в море. Если вы посчитаете предел данной функции, а она сходится, это и будет цена за гигабайт сейчас, чтобы хранить потом бесплатно.
Вы можете привести примеры хостингов или облачных решений, в том числе high-end, которые ежегодно поднимают цены? Или может Селектел планирует повышать цены ежегодно на облачное хранилище, также, как мосэнергосбыт, повышает цены на электроэнергию? Что-то не очень верю в это. Hetzner тут приведен только для примера, наши сервера все с ECC.
К сожалению, я не имею возможности раскрыть все подробности бизнес-кейса проекта, но достаточным, чтобы еще 5 лет хранить данные без дополнительных финансовых вливаний и без падения стоимости хранения, хотя этот вариант мне, как и многим другим, кажется маловероятным и за 15 лет стоимость станет такой, что это все можно будет сохранить на одном дешевом сервере (мы рассматриваем вариант, что пользователи сегодня придут на сайт, зальют файлы и уйдут навсегда и больше не будут покупать место и новых пользователей тоже не будет, но при этом они будут заходить каждый день на сайт и что-то качать).
Стоимость хранения уменьшится на столько, что не потребуется столько серверов, соответствено из резерва можно будет их оплатить. Это в случае, если совсем не будет никто ничего больше покупать. В противном случае, одна покупка через 10 лет окупить стоимость хранения 100 старых файлов, а может и больше.
На трех серверах.
Если я правильно понял вопрос, то, файл загружается на фронтенд (считается хеш), после чего загружается на три сервера, которые проверяют хеш суммы и отдают эту информацию скрипту загрузки на фронтенде.
Немного не понял вопроса, я говорю про цены на сервера, в том числе managed, например, hetzner.de постоянно предлагает все больше места, за все меньшие деньги, тоже самое делает и Amazon. И я не вижу никаких препятствий, чтобы данная тенденция продолжалась даже при увеличении стоимость электроэнергии, так как новые сервера потребляют все меньше электроэнергии, а новые жесткие диски вмещают все больше и больше информации за те же деньги.
Например, пользователи форума автомобиль.ру хотят создать коллекцию всех мануалов для всех автомобилей, таким образом, они объединяются и сохраняют совместно данные в нашем сервисе. Например 100 пользователей по 10 долларов каждый могут загрузить 1 TB данных и хранить бесплатно. В скором времени, можно будет передавать ссылку другому пользователю системы, чтобы он смог поучаствовать в хранении файла и таким образом распределять стоимость хранения на тех пользователей, которым они нужны.
Тем, что есть реальный расчет и резерв на непредвиденные расходы. Стоимость хранения старых файлов уменьшается с каждым годом, а текущая стоимость взята с запасом на хранения 1GB данных в течении 10 лет.
При такой стратегии, новые пользователи не имеют значения, если старые покупают периодически немного места дополнительно (хотя-бы 1 раз в год, в среднем). А по текущему профилю пользвателей, так и происходит, если конечно, Вы нам не зальете 12ТБ :)
12ТБ хлама это 12288 гигабайт, сервер для отдачи будет нам стоить около 100 баксов в месяц, соответственно вы нам заплатите $12288, т.е. 10 лет хостинга даже в таком жестком режиме. Никто не гарантирует ведь вам, что используя систему не по прямому назначению, будет обеспечена паралельная отдача всего вашего контента (всех 12ТБ) на большой скорости. Но скорость будет достаточна, чтобы быстро скачать файл (несколько файлов) в конкретный момент времени.
Электричество и обслуживание серверов (кроме администрирования, которое фактически автоматизировано) проблема хостинга, а не наша. Мы просто выбираем оптимальный хостинг по цене и всё.
Для загрузки мы в дальнейшем, при росте трафика, планируем использовать кеширующие сервера на SSD с 100TB трафика (на гигабите) (такие уже есть сейчас где-то за 100 евро в месяц с ECC, например в leaseweb и будет еще больше), хотя и сейчас проблем с IOPS не наблюдаем. А, вероятность попадания одновременно всех пользователей на один и тот же сервер хранилища минимальна, так как распределение идет по хешам файлов.
При падении трафика, пересадим всех на один сервер. Эта очень гибкая система, если не покупать серверов, а арендовать.
Т.е. у нас фиксированные постоянные (уменьшающиеся во времени) расходы даже при неизменном количестве пользователей.
На трех серверах.
Если я правильно понял вопрос, то, файл загружается на фронтенд (считается хеш), после чего загружается на три сервера, которые проверяют хеш суммы и отдают эту информацию скрипту загрузки на фронтенде.