Comments 37
неплохо придумано. Вообще, технология применима, как мне кажется, к большинству контента в сети, наверняка к этому так или иначе придут все крупные корпорации
У меня facebook тормозил и тормозит. Что в Москве, что в Вильнюсе. Вконтакт по сравнению с ним летает.
Вы наверное неслишком популярные фоточки из холодных копий просматриваете. Один диск, все дела… Зато экономия.
Так тормозит ведь актуальная лента, а не архив. Отмотать же фейсбук на несколько дней назад — мучение то ещё.
Мне лично подгрузка страницы снизу никогда не нравилась: и когда я юзером сижу и наматываю километры мышиным колесом, и когда мне приходилось такое поведение в коде реализовывать.
Мне лично подгрузка страницы снизу никогда не нравилась: и когда я юзером сижу и наматываю километры мышиным колесом, и когда мне приходилось такое поведение в коде реализовывать.
Мне лично подгрузка страницы снизу никогда не нравилась:
Отмотать же фейсбук на несколько дней назад
Проблема не в infinity-scroll, а в отсутствии доп. навигации. В Яндекс.Почте например и то и то есть. Скроллом удобно последовательно идти по списку, он не создан для поиска. Или вы знаете какое-то универсальное решение лучше?
Например, в системах хранения данных используется технология исправления ошибок, которая называется Reed-Solomon. Она позволяет снизить объем памяти, требуемый для сохранения копий медиафайлов.
Исправление ошибок наоборот требует внесения некоторой избыточности в исходные данные. Помехоустойчивое кодирование Рида-Соломона, которое, вероятно, вы пытались описать никак не может снизить объем памяти, требуемый для сохранения копий медиафайлов.
Так оно и не снижает. В статье указано, что, первоначально, файл имеет размер 10 «частей». И они экономят на том, что хранят 2 копии не как 20 частей, а только как 14
Смысл в том, что сравнивать резервирование и кодирование некорректно. Файл увеличился на 1,4 — это факт.
Избыточное кодирование как альтернативный репликации способ обеспечить отказоустойчивость? Если требование «отказоустойчивость» является обязательным то 2х и 1,4х к размеру файла вполне себе профит.
Да, но если основная копия умрёт полностью, то эти 0.4 ничем не помогут.
Не существует основной копии, есть 10 частей + 4 части дополнительно. И все они раскиданы по 14 разным носителям. Для восстановления нужно всего 10 частей, ЛЮБЫХ. может умереть 4 диска и файл всё равно будет доступен. ну вычислить недостающие 4 части снова не составляет трудности. И у нас снова 14 частей на разных носителях.
Но тогда это простой RAID5.
Вообще, RAID5 + «размазывание» меня несколько пугает:
Пусть вероятность «смерти» диска за оцениваемый период — 1%. Тогда вероятность смерти одного из 14 дисков — 14%. Вероятность смерти 5 из 14 дисков (точка отказа) — 0.145 = 0.0000537824, при этом умрёт безвозвратно весь массив.
Если добиваться того же простым зеркалированием каждого диска (без объединения зеркал в RAID0), то понадобилось бы 20 дисков. Из которых может отказать до 10 без потерь вообще. С вероятностью 0.012 = 0.0001 откажут именно два диска зеркалирующие друг друга. С одной стороны, вероятность вдвое больше, чем отказ массива RAID5, с другой — потеряется только информация с этих двух дисков, т.е., только 10% от всего массива.
Вообще, RAID5 + «размазывание» меня несколько пугает:
Пусть вероятность «смерти» диска за оцениваемый период — 1%. Тогда вероятность смерти одного из 14 дисков — 14%. Вероятность смерти 5 из 14 дисков (точка отказа) — 0.145 = 0.0000537824, при этом умрёт безвозвратно весь массив.
Если добиваться того же простым зеркалированием каждого диска (без объединения зеркал в RAID0), то понадобилось бы 20 дисков. Из которых может отказать до 10 без потерь вообще. С вероятностью 0.012 = 0.0001 откажут именно два диска зеркалирующие друг друга. С одной стороны, вероятность вдвое больше, чем отказ массива RAID5, с другой — потеряется только информация с этих двух дисков, т.е., только 10% от всего массива.
Расчёты выше ↑ можно не читать, там ошибки.
Правильный расчёт
Пусть вероятность отказа одного диска = Р. Вероятность смерти хотя бы одного из 14 дисков = 14·Р.
Вероятность отказа 5 из 14 дисков (точка отказа массива RAID5) = 14!/9! ×P5 = 240240·P5.
Вероятность отказа 2 дисков, зеркалирующих друг друга, из 10 (точка отказа RAID1) = 14·P2. Итого, RAID1 надёжнее при Pотказа > ∛(14/240240) ≈ 4%.
Вероятность отказа 5 из 14 дисков (точка отказа массива RAID5) = 14!/9! ×P5 = 240240·P5.
Вероятность отказа 2 дисков, зеркалирующих друг друга, из 10 (точка отказа RAID1) = 14·P2. Итого, RAID1 надёжнее при Pотказа > ∛(14/240240) ≈ 4%.
Надо уточнить что такое P. это должна быть вероятность отказа за срок который пройдет после сигнализации отказа и замены диска в массиве. В большем датацентре за день наверно не заменят. Пусть будет неделя. Так вот вероятность отказа диска в течении недели = равно 1 / среднее время жизни дисков этой партии в неделях. Тут был недавно обзор дисков от какого то хостера — там диски в среднем живут 4 года. это 200 недель то вероятность отказа P ≈ 0.5%.
Ну а при холодном режиме работы, как тут описывается — наверно ещё меньше.
А экономия в размере массива 60%.
Ну а при холодном режиме работы, как тут описывается — наверно ещё меньше.
А экономия в размере массива 60%.
Вообще да это и есть аналог рейда, но только на уровне частей файлов. И размазаный по датацентру, а не на одном контроллере.
Я бы сказал, что это попытка использовать помехоустойчивое кодирование (а конкретно — «кодирование с перемежением», к которому относится кодек Рида-Соломона) для нетрадиционного решения задачи по оптимизации.
Естественно, что (дополнительное) кодирование информации — увеличивает ее объем. Но нетрудно догадаться, что профит от этого увеличения — заведомо больше, чем негативный эффект роста объема информации. В противном случае — никто бы не заморачивался использованием «помехоустойчивого кодирования», и все ограничивалось бы более простыми решениями (переповтор, к примеру).
Я могу предположить, что такой хитрый способ хранения — еще и как-то увязан с идеей отключения не использующихся в данный момент дисковых носителей. Ведь для сборки файла — нужно не пробуждать все диски, где он лежит: в идеале, файл можно попытаться собрать с тех дисков, которые уже крутятся. Ну и бонусом — идут менее жесткие требования к резервировнию самих дисков.
В итоге — получается очень нетривиальное, но очень красивое с инженерной точки зрения решение.
Естественно, что (дополнительное) кодирование информации — увеличивает ее объем. Но нетрудно догадаться, что профит от этого увеличения — заведомо больше, чем негативный эффект роста объема информации. В противном случае — никто бы не заморачивался использованием «помехоустойчивого кодирования», и все ограничивалось бы более простыми решениями (переповтор, к примеру).
Я могу предположить, что такой хитрый способ хранения — еще и как-то увязан с идеей отключения не использующихся в данный момент дисковых носителей. Ведь для сборки файла — нужно не пробуждать все диски, где он лежит: в идеале, файл можно попытаться собрать с тех дисков, которые уже крутятся. Ну и бонусом — идут менее жесткие требования к резервировнию самих дисков.
В итоге — получается очень нетривиальное, но очень красивое с инженерной точки зрения решение.
Насколько я понимаю изначальная цель — сделать так, чтобы при креше данных можно было восстановить файл. Поэтому если использовать коды Рида-Соломона, то размер файла увеличивается в 1.4 раза; а если делать по тупому, то размер файла увеличивается в 2 раза.
Но если мы потеряем файл целиком, то уже не сможем его восстановить из такой «копии».
Не совсем.
Разбиваем файл на 10 частей, 5 частей на один жесткий диск, 5 частей на другой. Таким образом добиваемся того, что каждая часть хранится более-менее независимо и при возникновении бедов некорректные данные появляются только в некоторых, а не во всех частях.
С некорректными данными (шумами) можно бороться или избыточным дублированием или помехоустойчивым кодированием (и коды Рида-Соломона это один из вариантов такого кодирования).
Частичная утеря данных — это тоже вариант помех. Допустим мы знаем вероятность того, что может посыпаться жесткий диск абсолютно полностью. Исходя из этой вероятности и необходимой вероятности выживания медиа рассчитываем на сколько жестких дисков нужно раскидывать файл.
Чаще всего срок жизни оборудования известен, поэтому где-то перед его предпологаемой смертью можно забекапить все на следующую жертву. И скорее всего оборудование просто так не сыпется полностью, а начинает распадаться по частям — появляется все больше и больше бедов. Беды отслеживаются, данные восстанавливаются, данные бекапятся.
Судя по всему инженеры фейсбука грамотно рассчитали вероятности и обеспечили необходимую отказоустойчивость. Хотя схема выглядит довольно сложной, но тем не менее основана на банальном теорвере поверх сложного проверенного работающего мат. аппарата и статистики смерти жестких дисков — продажной девки имперализма
Разбиваем файл на 10 частей, 5 частей на один жесткий диск, 5 частей на другой. Таким образом добиваемся того, что каждая часть хранится более-менее независимо и при возникновении бедов некорректные данные появляются только в некоторых, а не во всех частях.
С некорректными данными (шумами) можно бороться или избыточным дублированием или помехоустойчивым кодированием (и коды Рида-Соломона это один из вариантов такого кодирования).
Частичная утеря данных — это тоже вариант помех. Допустим мы знаем вероятность того, что может посыпаться жесткий диск абсолютно полностью. Исходя из этой вероятности и необходимой вероятности выживания медиа рассчитываем на сколько жестких дисков нужно раскидывать файл.
Чаще всего срок жизни оборудования известен, поэтому где-то перед его предпологаемой смертью можно забекапить все на следующую жертву. И скорее всего оборудование просто так не сыпется полностью, а начинает распадаться по частям — появляется все больше и больше бедов. Беды отслеживаются, данные восстанавливаются, данные бекапятся.
Судя по всему инженеры фейсбука грамотно рассчитали вероятности и обеспечили необходимую отказоустойчивость. Хотя схема выглядит довольно сложной, но тем не менее основана на банальном теорвере поверх сложного проверенного работающего мат. аппарата и статистики смерти жестких дисков — продажной девки имперализма
Что-то мне подсказывает, что переводчик-интерпретатор даже не понмал, что пишет. Технология «Бойль и Мариотт» )
Не совсем понятно зачем использовать в тексте «Reed Solomon», если есть устоявшийся перевод: Код Рида — Соломона
Facebook решает проблему экономного хранения данных на всех уровнях:
— Оригинал статьи o Cold Storage code.facebook.com/posts/1433093613662262/-under-the-hood-facebook-s-cold-storage-system-
— F4 («Warm» storage для фотографий) code.facebook.com/videos/334113483447122/f4-photo-storage-at-facebook-scale-presentation
— Haystack («Hot» storage для фотографий) www.facebook.com/notes/facebook-engineering/needle-in-a-haystack-efficient-storage-of-billions-of-photos/76191543919
— Оригинал статьи o Cold Storage code.facebook.com/posts/1433093613662262/-under-the-hood-facebook-s-cold-storage-system-
— F4 («Warm» storage для фотографий) code.facebook.com/videos/334113483447122/f4-photo-storage-at-facebook-scale-presentation
— Haystack («Hot» storage для фотографий) www.facebook.com/notes/facebook-engineering/needle-in-a-haystack-efficient-storage-of-billions-of-photos/76191543919
Наводит на мысль о потенциальных DDoS использующих такие особоенности инфраструктуры.
Хм, быть может мне стоит поудалять данные с фейсбука, гугл драйва и прочих сервисов облачного хранения данных во имя окружающей среды?
В литературе код Рида-Соломона обычно переводится, а не spelling 'as is', because it is much easer to stop translate anything and just switch to the default language.
Отвратительный перевод.
Перевожу на русский: «мы включили парковки головки диска, и перешли с RAID1 на RAID5/6».
Перевожу на русский: «мы включили парковки головки диска, и перешли с RAID1 на RAID5/6».
Я думал они горячий контент стали раздавать через p2p. Для видео уже вроде кто-то сделал. Вот думал и до фоточек добрались.
Sign up to leave a comment.
Как Facebook сэкономил 75% энергии, которая требуется для хранения фоточек котиков и селфи пользователей