Pull to refresh

Comments 19

UFO just landed and posted this here
Мне не попадалось прямой информации об этом. Неудобство ленты в том, что для чтения надо физически переместить кассету в считыватель, и потом надо перематывать ленту на нужную позицию. Вообще, Facebook и Amazon, по слухам, используют не ленту, но BlueRay диски формата BDXL с плотностью записи 100 Гб на диск. Время доступа к данным в Amazon Glacier можете сами посмотреть — обещают единицы часов. Вот статья про Facebook: http://datacenterfrontier.com/inside-facebooks-blu-ray-cold-storage-data-center/

Facebook ещё предлагал выключать жёсткие диски с холодными данными, и включать только когда поступают запросы на чтение, причём включать не больше 1 диска на лоток из 15 дисков (это нужно уже, чтобы не превысить максимальный ток на стойку). Статья: https://code.facebook.com/posts/1433093613662262/-under-the-hood-facebook-s-cold-storage-system-/

Dropbox использует SMR диски — это диски с черепичной записью, у них очень плохие показатели случайной записи, но в остальном они похожи на обычные жёсткие диски, только объём на четверть (а то и на треть) больше при той же цене. На хабре была статья про такие диски: https://geektimes.ru/company/seagate/blog/270740/

В общем, все пытаются сделать хранение как можно более дешёвым, и часто всё упирается в показатели времени доступа, которые хочется получить. В случае с SMR дисками — вообще всё отлично, с выключаемыми дисками нужны уже единицы секунд, ленты/BD — единицы часов при наличии очереди на чтение.
Статья и обсуждение диски против лент было на Хабре здесь, интересно, что поменялось за 3 года…
гугл использует ленты для gmail точно
Откуда такие сведения, да еще и «точно»? ;)
В том году была статья о проблемах с gmail, и гугл писал об ее решении, что проблема с хранением и все потери были восстановлены с лент, на которых (как минимум gmail) у них дублируется.
Ещё в роликах из датацентров засветились библиотеки от StorageTek.

А зачем вы компрессию называете архивированием? Это же разные понятия.


Как обстоят дела с производительностью после того как вы отказались от множества реплик?

Старая привычка, ещё с тех времён, когда winarj все называли архиватором :) Но вы, конечно, правы, в данном случае правильно говорить компрессия.

С производительностью вопрос интересный. Если всё хорошо, и не надо ничего восстанавливать, то скорость скачивания практически не страдает, только увеличивается latency. Как только один парт данных теряется, сразу надо прокачивать много данных для восстановления, скорость падает. Но мы конвертируем в LRC только остывшие данные, и тут уже правильным словом будет архивация, т.к. от реплик мы не везде отказались. Запись всегда делаем в реплики, иначе совсем ахтунг с обработками ошибок. Про это буду рассказывать подробно 15 октября, с картинками.
Скажите, пожалуйста, перед компрессией проводится ли каким нибудь способом поиск дублирующихся данных? На уровне файлов или на уровне битовых последовательностей?
Или это не имеет смысла?
Смысл, конечно же, имеет (во всяком случае, на наших данных), но, к сожалению, у нас такой фичи пока нету :( Исторически не было метабазы, и мы стараемся придерживаться этого курса развития, и именно поэтому дедупликацию пока не сделали, но регулярно про это думаем.

У отдельных сервисов дедупликация есть, например, у Диска, но сделано полностью на их стороне. Если говорить об абстрактном хранилище, то нужно сначала посчитать экономию от дедупликации, может так случиться, что на ваших данных большой пользы она не нанесёт.
В 2015 году, как вы все помните, сильно вырос курс доллара.

Скорее просел рубль…
Статья интересная, но не могу не сделать замечание
(производители дисков, в свою очередь, любят маркетинг и считают объём в десятичных терабайтах)

Уже все давно считают терабайты в 10тичной системе исчисления (СИ), только программисты никак не могут согласиться и делают по своему, из-за чего потом же сами программисты и страдают, что кол-во ожидаемого места не совпадает. По факту 10 TB = 10^12, а вот 10 TiB = 2^40.
То что «уже давно все считают всех IT-инженеров программистами» ещё не о чём не говорит…

Даже самая «пользователе-ориентированная», «яблочная корпорация» указывает занимаемое место файлом используя двоичную систему, вот и возникает вопрос, кто эти мифические «все».

Да и вообще, одну многим известную башню с часами никто не спешит переименовывать в Биг Бен, почему с терабайтом должны поступить иначе?
Скажите, пожалуйста, а вы проводили какие-то перфоманс тесты для разных типов избыточности? Поделитесь результатами?
Нет, все кандидаты, кроме LRC, отсеялись на стадии функциональных требований к ним. Проводили performance тестирование вычисления контрольных сумм и восстановления блоков данных. Точных цифр, к сожалению, не осталось, но получалось несколько гигабайт в секунду на одной машине — это сильно больше, чем пропускная способность 10G сетевых интерфейсов, на этом мы и успокоились.

Скорость восстановления при потере 1 блока данных (вырождается в обычный xor) в 3 раза выше, чем скорость восстановления при потере двух и более блоков данных в схемах с кодами Рида-Соломона и LRC, если пользоваться библиотекой jerasure со словом размером 1 байт.

Кажется, на картинке с результатами XOR двух частей фразы Hello, habrahabr ошибка: H ^ a = 41, а не 47.
Ну, или, я ничего не понял )))


H ^ a = 41
e ^ b = 7
l ^ r = 30
l ^ a = 13
o ^ h = 7
, ^ a = 77
  ^ b = 66
h ^ r = 26
Действительно, вкралась опечатка. Спасибо за внимательность!
Sign up to leave a comment.