И, пользуясь этой схемой, попробуйте запланировать событие, которое должно произойти в 5 часов по местному времени через полгода (а лучше — в период лага принятия решения о переводе часов).
В целом, у мужика всё хорошо, и Гугл в качестве работодателя вообще не сдался ему. Вот он и решил потроллить, и, надо сказать, у него отлично получилось.
Я специально на абзацы комментарий разбил, и про иерархию писал в контексте POSIX-совместимой распределённой ФС. Там нужна иерархия, как ни крути, а вот нужна ли такая ФС — большой вопрос. Про объектное хранилище вы, конечно, правильно пишете.
Очень, очень странный доклад. Зачем-то понятие объектного хранилища постоянно подменяется файловой системой. И вообще, всё выглядит как «мы пробовали сделать, но у нас не получилось, и поэтому мы считаем, что мир — вот такой, как в этом докладе».
Автор доклада не слышал о существовании таких сервисов, как Amazon S3, Dropbox (точнее, их Magick Pocket), MS Azure storage?
И, кстати, seek — вот вообще не проблема для распределённой POSIX-совместимой файловой системы. Иерархия директорий и особенно атомарность её изменений — намного бОльшая боль.
Думаю, аналогия такая: проверяй каждые 10 секунд (1 итерация), что ты движешься правильным курсом с правильными параметрами (горизонтальная/вертикальная скорости, механизация и т.д.), и тогда ты точно правильно сядешь.
Я недавно читал первый том Задача трёх тел Лю Цысиня, стиль описания с несколькими параллельно описываемыми временами сильно напомнил Криптономикон. Но, с точки зрения описания технологий, конечно, там всё намного проще.
Нет, все кандидаты, кроме LRC, отсеялись на стадии функциональных требований к ним. Проводили performance тестирование вычисления контрольных сумм и восстановления блоков данных. Точных цифр, к сожалению, не осталось, но получалось несколько гигабайт в секунду на одной машине — это сильно больше, чем пропускная способность 10G сетевых интерфейсов, на этом мы и успокоились.
Скорость восстановления при потере 1 блока данных (вырождается в обычный xor) в 3 раза выше, чем скорость восстановления при потере двух и более блоков данных в схемах с кодами Рида-Соломона и LRC, если пользоваться библиотекой jerasure со словом размером 1 байт.
Смысл, конечно же, имеет (во всяком случае, на наших данных), но, к сожалению, у нас такой фичи пока нету :( Исторически не было метабазы, и мы стараемся придерживаться этого курса развития, и именно поэтому дедупликацию пока не сделали, но регулярно про это думаем.
У отдельных сервисов дедупликация есть, например, у Диска, но сделано полностью на их стороне. Если говорить об абстрактном хранилище, то нужно сначала посчитать экономию от дедупликации, может так случиться, что на ваших данных большой пользы она не нанесёт.
А докладчик на хабре присутствует? Хотелось бы узнать, сколько питания приходит на стойку, и сколько потом тепла можно снять, ведь даже при 10кВт хорошо нагрузить 40 машин в стойке не получится — они раза в два больше электричества сожрут.
Старая привычка, ещё с тех времён, когда winarj все называли архиватором :) Но вы, конечно, правы, в данном случае правильно говорить компрессия.
С производительностью вопрос интересный. Если всё хорошо, и не надо ничего восстанавливать, то скорость скачивания практически не страдает, только увеличивается latency. Как только один парт данных теряется, сразу надо прокачивать много данных для восстановления, скорость падает. Но мы конвертируем в LRC только остывшие данные, и тут уже правильным словом будет архивация, т.к. от реплик мы не везде отказались. Запись всегда делаем в реплики, иначе совсем ахтунг с обработками ошибок. Про это буду рассказывать подробно 15 октября, с картинками.
Мне не попадалось прямой информации об этом. Неудобство ленты в том, что для чтения надо физически переместить кассету в считыватель, и потом надо перематывать ленту на нужную позицию. Вообще, 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 — единицы часов при наличии очереди на чтение.
Например, потому, что криптография — это сложно?
Вообще, делают то много всего, и разные команды. Иногда это стартапы, люди в которых до того делали сайты-визитки. Иногда — железячные фирмы, у которых тоже проблем не возникало — ну кому в голову придёт «взламывать» mp3-плеер? Иногда IoT — это вообще поделки на ардуине/esp, а авторы только учатся код писать, там уж совсем спрашивать глупо.
В целом, они все могли бы сделать всё хорошо, вот только готовых рецептов пока никто не написал. Ну нету пока условного магического слова https в мире IoT.
Кстати, ради интереса посмотрите на то, как заливаются приложения в фиатовских магнитолах с Blue'n'me — там софтовую часть активно помогала делать MS, и подписями всё обмазано густо, всякую левую хрень типа своими руками написанного кода фиг подсунешь.
Некоторые так и делают, ставят небольшую железку, которая работает файрволлом между CAN-шиной и мультимедийной частью. Даже в крайслере упомянутом в статье такая была. Они там, на сколько я помню, облажались только в том, что была возможность обновить прошивку этого файрволла со стороны магнитолы.
Можете привести схематичный рисунок, как ваш девайс должен располагаться относительно лобового стекла? Под каким углом, на каком расстоянии. Скажем, можно ли его расположить за приборным щитком, если там достаточно места? А расположить его вертикально внутри торпедо?
И было бы круто ещё второй рисунок, на фотографии «из глаз» (настоящий вид, когда край капота тоже в кадре) обвести примерно область, куда может выводиться картинка. А то вы про угловой размер всё говорите, что он больше, а какой — не говорите :)
Там же C++, можно наспециализировать шаблонов, да ещё и предложить компилятору делать инлайн — вот вам и будет выбор адреса и команды во время компиляции.
Автор доклада не слышал о существовании таких сервисов, как Amazon S3, Dropbox (точнее, их Magick Pocket), MS Azure storage?
И, кстати, seek — вот вообще не проблема для распределённой POSIX-совместимой файловой системы. Иерархия директорий и особенно атомарность её изменений — намного бОльшая боль.
Скорость восстановления при потере 1 блока данных (вырождается в обычный xor) в 3 раза выше, чем скорость восстановления при потере двух и более блоков данных в схемах с кодами Рида-Соломона и LRC, если пользоваться библиотекой jerasure со словом размером 1 байт.
У отдельных сервисов дедупликация есть, например, у Диска, но сделано полностью на их стороне. Если говорить об абстрактном хранилище, то нужно сначала посчитать экономию от дедупликации, может так случиться, что на ваших данных большой пользы она не нанесёт.
С производительностью вопрос интересный. Если всё хорошо, и не надо ничего восстанавливать, то скорость скачивания практически не страдает, только увеличивается latency. Как только один парт данных теряется, сразу надо прокачивать много данных для восстановления, скорость падает. Но мы конвертируем в LRC только остывшие данные, и тут уже правильным словом будет архивация, т.к. от реплик мы не везде отказались. Запись всегда делаем в реплики, иначе совсем ахтунг с обработками ошибок. Про это буду рассказывать подробно 15 октября, с картинками.
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 — единицы часов при наличии очереди на чтение.
Вообще, делают то много всего, и разные команды. Иногда это стартапы, люди в которых до того делали сайты-визитки. Иногда — железячные фирмы, у которых тоже проблем не возникало — ну кому в голову придёт «взламывать» mp3-плеер? Иногда IoT — это вообще поделки на ардуине/esp, а авторы только учатся код писать, там уж совсем спрашивать глупо.
В целом, они все могли бы сделать всё хорошо, вот только готовых рецептов пока никто не написал. Ну нету пока условного магического слова https в мире IoT.
Кстати, ради интереса посмотрите на то, как заливаются приложения в фиатовских магнитолах с Blue'n'me — там софтовую часть активно помогала делать MS, и подписями всё обмазано густо, всякую левую хрень типа своими руками написанного кода фиг подсунешь.
Новые процессоры используют только 10% своего потенциала. Только представьте что сможет сделать атом или арм, если подать питание сразу на все ножки!
И было бы круто ещё второй рисунок, на фотографии «из глаз» (настоящий вид, когда край капота тоже в кадре) обвести примерно область, куда может выводиться картинка. А то вы про угловой размер всё говорите, что он больше, а какой — не говорите :)