Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 16
Как всегда - Можно обеспечить любое число IOPS даже на медленных дисках. Вопрос только в их количестве.
P.S. принято сначала указывать количество основных блоков данных, а уже потом число хэш сумм. Например EC 9+4.
Когда видишь во втором предложении три(!) сноски, становится тягостно. "Не нужно так плохо писать, писать нужно не так, писать нужно хорошо" Д.Трамп.
Запрос PUT выбирает произвольный набор дисков
Следующий PUT, даже если он нацелен на тот же ключ/бакет, выбирает другой набор почти случайных дисков.
Не знаю, как оно там на самом деле, но, вангую, что, чуть хитрее. Ибо вот такое, максимальное, шардирование не сильно эффективно в реальном продакшене, и ему предпочитают шардирование ренджей. Скорее всего, они будут пытаться напихать микрокластер близких данных по ключу и характеру записи рядом, ибо, с высокой вероятностью, клиент их придёт и читать одним куском тоже. И, в момент чтения можно будет хорошо сэкономить на ресурсах. Условно, если клиент хранит на с3 логи с 10 серверов в 1-минутных чанках по 1МБ каждый, и читает их сразу за день чем-то вроде хадупа, то, скажем, расбросать все чанки на 14400 серверов тупо. Ибо, когда он придёт читать, будет много возни ради 1МБ запросов. Хранить на одном тупо тоже - отдача будет болезненно медленной. Но, скажем, сбить их комками по 100МБ и распределить на 144 сервера - оптимум. И, если файлы ещё и уложить рядом, то, например, прочитав первый 1МБ, и понимая, что этот клиент любит читать файлы с похожим ключем на основе его статистики (а тут, уверен, что клиенты очень похожи за счёт ограниченности стеков и тулинга работы с данными), можно сразу прочитать и ещё 99 (ибо диску не сильно сложно) и положить в RAM.
Подозреваю, что тут речь идет о выборе диска для данных объекта, а не о списке/индексе. Для HDD проблема в основном в работе с данными
Ну да, разумеется. Но суть не меняется. Объекты в s3, как и строки в базе данных, редко читают по одной и совершенно рандомно. Условно, если есть бакет, в котором лежат объекты по путям вида 2025/05/05/server1/20_00.log, то логично, что обращаться к ним не будут рандомно, а будут, например, сразу тянуть объекты за 1 час. И тут можно сильно сэкономить, умея читать >1 объекта одной операцией линейного чтения
Случайный выбор по степеням двойки (Power of Two Random Choices): выбор между наименее нагруженными из двух совершенно случайных узлов
Обещали камерный оркестр, а рассмотрели только тривиальный случай k=3
Ниже показан пример такой стойки дисков. Она состоит из 1000 дисков по 20 ТБ каждый. Говорят, что эта стойка весит больше, чем автомобиль, поэтому Amazon вынуждена укреплять полы в своих дата-центрах.
Можно ведь легко проверить эту информацию. Вес одного 20 ТБ HDD - около 700 грамм. Поэтому стойка не может весить больше, чем автомобиль (кроме совсем маленького).
Хорошая статья, единственное что хочу заметить по 17 сноске. ЕС ничего не ускоряет, он всегда медленнее и на чтение и на запись - но очень значительно экономит. Если вам надо записать объект 100 Мб разбейте его на 10 чаанков по 10МБ, запишите 2 копии и сообщайте клиенту успех, третью копию сделаете постфактум. Читать данные ещё быстрей -не надо тратится на декодирование. Также ЕС создаёт Гораздо больше нагрузки в беке при проверке или восстановлении четностей
Спасибо за статью, как раз сейчас пытаюсь понять EC для своего S4Core (замена Minio) https://github.com/s4core/s4core (пока стабильная альфа single node), но уже в отдельной ветке локально живет версия s4-federation с распределенностью, на выходных будут тестировать. Далее EC после успешных тестов s4-federation ветки
Есть форк, https://github.com/pgsty/minio
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как AWS S3 обеспечивает скорость 1 петабайт в секунду при помощи медленных HDD