Комментарии 19
НЛО прилетело и опубликовало эту надпись здесь
Мне не попадалось прямой информации об этом. Неудобство ленты в том, что для чтения надо физически переместить кассету в считыватель, и потом надо перематывать ленту на нужную позицию. Вообще, 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 — единицы часов при наличии очереди на чтение.
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 — единицы часов при наличии очереди на чтение.
+2
Статья и обсуждение диски против лент было на Хабре здесь, интересно, что поменялось за 3 года…
0
+1
гугл использует ленты для gmail точно
+1
А зачем вы компрессию называете архивированием? Это же разные понятия.
Как обстоят дела с производительностью после того как вы отказались от множества реплик?
0
Старая привычка, ещё с тех времён, когда winarj все называли архиватором :) Но вы, конечно, правы, в данном случае правильно говорить компрессия.
С производительностью вопрос интересный. Если всё хорошо, и не надо ничего восстанавливать, то скорость скачивания практически не страдает, только увеличивается latency. Как только один парт данных теряется, сразу надо прокачивать много данных для восстановления, скорость падает. Но мы конвертируем в LRC только остывшие данные, и тут уже правильным словом будет архивация, т.к. от реплик мы не везде отказались. Запись всегда делаем в реплики, иначе совсем ахтунг с обработками ошибок. Про это буду рассказывать подробно 15 октября, с картинками.
С производительностью вопрос интересный. Если всё хорошо, и не надо ничего восстанавливать, то скорость скачивания практически не страдает, только увеличивается latency. Как только один парт данных теряется, сразу надо прокачивать много данных для восстановления, скорость падает. Но мы конвертируем в LRC только остывшие данные, и тут уже правильным словом будет архивация, т.к. от реплик мы не везде отказались. Запись всегда делаем в реплики, иначе совсем ахтунг с обработками ошибок. Про это буду рассказывать подробно 15 октября, с картинками.
+4
Скажите, пожалуйста, перед компрессией проводится ли каким нибудь способом поиск дублирующихся данных? На уровне файлов или на уровне битовых последовательностей?
Или это не имеет смысла?
Или это не имеет смысла?
0
Смысл, конечно же, имеет (во всяком случае, на наших данных), но, к сожалению, у нас такой фичи пока нету :( Исторически не было метабазы, и мы стараемся придерживаться этого курса развития, и именно поэтому дедупликацию пока не сделали, но регулярно про это думаем.
У отдельных сервисов дедупликация есть, например, у Диска, но сделано полностью на их стороне. Если говорить об абстрактном хранилище, то нужно сначала посчитать экономию от дедупликации, может так случиться, что на ваших данных большой пользы она не нанесёт.
У отдельных сервисов дедупликация есть, например, у Диска, но сделано полностью на их стороне. Если говорить об абстрактном хранилище, то нужно сначала посчитать экономию от дедупликации, может так случиться, что на ваших данных большой пользы она не нанесёт.
0
В 2015 году, как вы все помните, сильно вырос курс доллара.
Скорее просел рубль…
+4
Статья интересная, но не могу не сделать замечание
Уже все давно считают терабайты в 10тичной системе исчисления (СИ), только программисты никак не могут согласиться и делают по своему, из-за чего потом же сами программисты и страдают, что кол-во ожидаемого места не совпадает. По факту 10 TB = 10^12, а вот 10 TiB = 2^40.
(производители дисков, в свою очередь, любят маркетинг и считают объём в десятичных терабайтах)
Уже все давно считают терабайты в 10тичной системе исчисления (СИ), только программисты никак не могут согласиться и делают по своему, из-за чего потом же сами программисты и страдают, что кол-во ожидаемого места не совпадает. По факту 10 TB = 10^12, а вот 10 TiB = 2^40.
0
То что «уже давно все считают всех IT-инженеров программистами» ещё не о чём не говорит…
Даже самая «пользователе-ориентированная», «яблочная корпорация» указывает занимаемое место файлом используя двоичную систему, вот и возникает вопрос, кто эти мифические «все».
Да и вообще, одну многим известную башню с часами никто не спешит переименовывать в Биг Бен, почему с терабайтом должны поступить иначе?
Даже самая «пользователе-ориентированная», «яблочная корпорация» указывает занимаемое место файлом используя двоичную систему, вот и возникает вопрос, кто эти мифические «все».
Да и вообще, одну многим известную башню с часами никто не спешит переименовывать в Биг Бен, почему с терабайтом должны поступить иначе?
+1
Скажите, пожалуйста, а вы проводили какие-то перфоманс тесты для разных типов избыточности? Поделитесь результатами?
0
Нет, все кандидаты, кроме LRC, отсеялись на стадии функциональных требований к ним. Проводили performance тестирование вычисления контрольных сумм и восстановления блоков данных. Точных цифр, к сожалению, не осталось, но получалось несколько гигабайт в секунду на одной машине — это сильно больше, чем пропускная способность 10G сетевых интерфейсов, на этом мы и успокоились.
Скорость восстановления при потере 1 блока данных (вырождается в обычный xor) в 3 раза выше, чем скорость восстановления при потере двух и более блоков данных в схемах с кодами Рида-Соломона и LRC, если пользоваться библиотекой jerasure со словом размером 1 байт.
Скорость восстановления при потере 1 блока данных (вырождается в обычный xor) в 3 раза выше, чем скорость восстановления при потере двух и более блоков данных в схемах с кодами Рида-Соломона и LRC, если пользоваться библиотекой jerasure со словом размером 1 байт.
0
Кажется, на картинке с результатами 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
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как применение кодов избыточности в SDS помогает Яндексу дёшево и надёжно хранить данные