Комментарии 9
Получается, результатом развития данной идеи должен явиться облачный провайдер, узлами облачного хранилища данных которого должны явиться аккаунты (хранилища данных) текущих облачных провайдеров. И чем больше уровней — тем надежнее получается, но… Салат: огурцы, помидоры, Салат:… ну вы понимаете.
Это должен быть не облачный сервис, а клиентское приложение… и самое сложное в нем — модули унифицированной работы с облачными сервисами хранения данных… и еще, далеко не все из них предоставляют API.
Как раз в соседней ветке про Я.Диск заходила речь о создании программы-аггрегатора для облачных хранилищ данных. Если её объединить с идеями из данного топика, то вышло бы ещё и более безопасное хранилище.
Если бы вы пошли по ссылкам, то увидели, что именно такие приложения я и привела в пример) Мне кажется, это очевидно, что городить огород из облаков разных иерархий смысла нет
Напомнило разговоры 15-летней давности «зеркало vs райд»
Очередной виток спирали.
Очередной виток спирали.
Я сознательно использую английский термин erasure codes в статье – я не нашла этого термина на русском языке. Это не коды корректирующие ошибки никоем образом.
почему?
При восстановлении в любом из случаев – используется ли репликация или erasure codes, размер данных, которые требуется передать будет равен размеру изначального файла, те L.
разве? это если использовать в качестве кодов RS или обычный XOR, но для других кодов можно сократить трафик
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О Чем Стоит Задуматься, Сохраняя Свои Данные в Облаке. Часть 2