В общем-то про требования было сказано в самом начале, но без отдельного подзаголовка
удобный конструктор, который позволяет загружать файлы любого размера, легко масштабироваться без деградации скорости доступа и надёжно защищать данные от потерь. В статье рассказываю, каким должно быть идеальное S3-хранилище для миллионов файлов
и скорость важна, и возможность разные диски поставить, и данные хранить разнородные
Такой же график я предоставить не смогу, у SeaweedFS иначе устроено взаимодействие, там несколько метрик собирать нужно вместе, по каждому компоненту Кроме того там нет даже близко полной утилизации возможностей кластера относительно RPS Покажу поэтому другой график, который, по моему мнению, больше подходит для обнаружения деградации системы в которой хранится очень большое число файлов. Без подробностей по типам операций, но здесь и листинг файлов учтён
Как я уже сказал в статье, файлы могут быть самые разные, в том числе настолько, что их мета будет или около размера файла, или меньше Про соотношение размеров кластера к количеству файлов тоже есть в самом начале статьи
не совсем понял вопрос, но попробую дать ответ на проблему с поиском
Если файлов не очень много и прирост медленный, не хочется заниматься поддержанием нескольких продуктов — тот же MinIO будет отличным вариантом. Просто внимательно на него посмотрите прежде чем окончательно переехать, в том числе на ситуации с недоступностью оборудования
Если ищете вариант S3 API-совместимого хранилища для хранения большого (и очень большого) числа файлов, попробуйте SeaweedFS с SQL-базой в качестве хранилища меты. Получите преимущество от поиска по префиксам, операции LIST станут быстрее в ситуациях, когда файликов много и используется вложенность "директорий"
Как вариант БД, которой должно хватить на долгое время, могу предложить Percona XtraDB Cluster. Но возможно правильно начать с инструмента, с которым вы знакомы лучше
давайте определимся тогда "очень большим числом". Речь о миллионах, десятках миллионов, сотнях. Какой при этом метаданные должны обеспечивать request rate.
Minio уже на миллионах файлов начнёт деградировать, на десятках и сотнях миллионов лучше ему не станет. Это связано с изначальной архитектурной особенностью и я ещё раз скажу, что всё будет зависеть в том числе от конфигурации, но глобально ситуацию не поменяет
Я правильно понимаю, что вам важно получить какие-то численные показатели и этого будет достаточно чтобы согласиться с высказанной мыслью о замедлениях с ростом числа файлов? У меня нет цели дотошно доказывать вам недостатки Minio. Давайте обсудим ваш опыт работы с ним, замечали ли вы деградацию и в какой момент? Если у вас всё хорошо на любых объёмах данных, в любых сценариях — давайте обсудим это, мне будет интересно узнать как вы этого добились
вас устроит гарантированная работоспособность при потери 6 серверов в кластере при эффективной доступности данных от 70% объема? Или надо все же искать решение с репликаией х3?
Нет, не устроит. Я уже сказал, что это компромисс. Важно переживать не только потерю условного % серверов, а быть готовым к выходу целого датацентра. Предположим, что датацентров 3 штуки. Репликация х3 в данном случае идеальна, так как защитит дополнительно от проблем в оставшихся двух ДЦ. Но для экономии места и средств в качестве компромисса можно использовать и репликацию х2. Реплик будет всего 2 штуки, но они будут в разных локациях и для восстановления фактора репликации файл нужно будет просто скопировать в другую доступную зону
Здесь ещё очень сильная зависимость от того, какие именно данные планируется хранить. Какая скорость доступа к ним нужна. Насколько критичен простой. Критично ли всё это вообще))
Не зная этих условий нельзя точно сказать какой инструмент нужен
Мне кажется это не у меня подмена понятий, либо понятие нужно ввести. Если вы делаете георасрпеделенный кластер, то никакой репликации там быть не может. Просто обеспечьте достатчную пропускную способность сетевого канала.
With synchronous replication, MinIO attempts to replicate the object prior to completing the originating PUT operation. MinIO returns a successful PUT operation whether or not the replication attempt succeeds. This reduces the risk of slow write operations at a possible cost of stale or missing objects on the remote location.
Я правильно помню, что синхронная репликация должна гарантировать одинаковое состояние реплик? И что это мера защиты от таких случаев как потеря одной копии до того как будет создана вторая? Вспомните ситуацию с выходом датацентра или любой другой неприятный сценарий где по какой-то причине сломается не отдельный юнит, а будет потеряна логическая (физическая) зона доступности, в частности та, в которую изначально шла запись
Если вам нормально в новом релизе вашей БД узнать что синхронная репликация теперь асинхронная, и асинхронная тоже асинхронная — то нет никаких вопросов, давайте честно признаемся что это норма и перестанем продолжать мусолить тему которую я подал под видом "всё-таки у Minio что-то не так между словами и реальностью"
А вот бэкап - это выгрузка данных из s3 хранилища например на ленту или сетевой хранилище. Такое тоже бывает, хотя, кмк, бессмысленно. Реализуерся сторонними инструментами как правило
Лично я не вижу разницы между бэкапом и "репликацией" если процесс происходит не в реальном времени и в другую независимую систему
У нас с вами могут быть отличные мнения, это нормально )
Скажу только, что всё-таки хочу обсуждать не калькулятор и обещания создателей ПО, а реальный опыт эксплуатации. У нас хороший опыт получился когда был собран конструктор. И этот конструктор имеет хороший запас на рост в любом смысле этого слова
Я ещё раз хочу поблагодарить за технически насыщенный разбор — вы явно в теме, и такие комментарии дают возможность лучше раскрыть материал
Метаданные и данные на уровне файловой системы, ребалансировка и детали про Minio
Я не прав с фразой "в том виде, в котором были загружены" относительно Minio. Увлекся и упустил момент с ECC. Исправлю это высказывание на более точное. Речь шла о том, что MinIO хранит и объекты, и метаинформацию в виде файлов в файловой системе. Я несколько раз подчеркнул, что плохо станет только в случае с очень большим числом файлов, именно в этом сценарии такой подход превращается в "плохо"
Формулировки про триггеры я тоже пересмотрю, спасибо за это замечание
Вы используете “S3” строго как реализацию API — и в этом смысле MinIO действительно один из лучших, я отдельно подчеркнул это в статье
Что всё-таки не так и где происходит подмена понятий
Вы подаёте ECC как полностью надёжную замену репликации. Но на практике это компромисс. ECC требует пересборки данных при потере фрагментов и может быть чувствительна к распределению этих фрагментов по узлам. Например, если критическая масса фрагментов окажется в одном ЦОДе, выход его из строя может привести к временному или полному отсутствию доступа к объектам.
В статье S3 рассматривался как обобщённая архитектурная модель: масштабируемое, отказоустойчивое, надёжное, распределённое хранилище. Minio может им быть.
Как вы и подчеркнули, у Minio нет репликации. И раздел с названием "Site Replication" содержит очень странное утверждение о синхронной репликации. Комментарием выше вы акцентировали внимание на разницу между режимами в работе баз данных, но сейчас в контексте Minio почему-то закрыли глаза на явную подмену понятий. Это не репликация, а бэкап. И механизма репликации с гарантией записи в 2 и более зон доступности нет? Если так, то не знаю почему я должен записать это в плюсы и убрать из минусов
Я знаю что Minio написан на Go. И нигде не сказал обратного) как и не было сказано о том, что Minio нельзя использовать, он опасен и вообще плохой
"мы сперва все сделали, а потом выбираем задним числом"
Это эмоциональное обобщение. Я в статье честно делюсь нашим опытом и логикой выбора. Да, SeaweedFS был выбран давно. Да, с тех пор продукты развиваются, и какие-то ограничения могут уже быть неактуальны. Но статья в общем-то не про абсолютную “победу Seaweed”, а про то, что повлияло на выбор и решения.
Цель статьи — не “доказать правильность” выбранного, а показать, какие критерии мы использовали и почему приняли именно такое решение. Это практический опыт, а не академическое исследование
"Вы проводили нагрузочные тестирования? Поделитесь пжста результатами. Или вы просто сделали выводы по описанию"
Я старался в статье не делать оценку за читателей. Не додумывайте за меня и вы. Мне как автору статьи не было задачи проводить и публиковать собственные бенчмарки. Это не только трудозатратно, но и неизбежно субъективно: я, как и любой практикующий инженер, лучше знаком с одной системой, чем с другой. Любые результаты в таком случае будут отражать не только характеристики хранилища, но и мою экспертизу в его настройке и эксплуатации и вводить этим в сильное заблуждение
Статья изначально должна была мотивировать читателя самостоятельно проверить, подумать и выбрать. Я считаю что это получилось. Какие у систем есть особенности, ограничения, плюсы, с чем мы столкнулись на практике и почему выбрали то, что выбрали. Если после прочтения кто-то захочет самостоятельно сравнить MinIO и SeaweedFS в своём окружении — значит, статья сработала именно так, как я и задумывал
Я прочитаю статью ещё раз и внесу правки относительно резких упрощённых утверждений. Ваш отклик — отличный пример того, как техническое сообщество помогает авторам быть точнее и полезнее.
Спасибо ещё раз — буду рад, если вы и дальше поделитесь своим опытом, особенно если он отличается от нашего
Спасибо за развёрнутый комментарий и уточнения про СУБД. Вы полностью правы, все выше упомянутые вещи справедливы. Упущения в тексте не случайны, и я попробую дополнить свою позицию
Зачем в статье вообще базы данных? (и всё остальное) Понимаю вопрос. Но базы данных здесь не как альтернатива распределённым или объектным хранилищам. Скорее — как часть архитектурного конструктора: один из инструментов, который может быть полезен в определённом контексте. СУБД используют во множестве сценариев — в том числе как основу для построения собственных файловых или объектных хранилищ. Поэтому полностью игнорировать СУБД при проектировании отказоустойчивой системы хранения было бы, на мой взгляд, необоснованно. Задача статьи — не выстроить противопоставление, а показать, как разные технологии могут дополнять друг друга и создавать что-то новое
Репликация Конечно вы правы. Речь шла о синхронной репликации — в контексте сохранности данных асинхронный подход не рассматривался как потенциально небезопасный
Скорость доступа и распределение нагрузки Подразумевалось, что нагрузка на чтение может быть распределена между несколькими репликами, а не то, что одна сессия читает с нескольких одновременно. Статья в целом построена с точки зрения работы систем, а не клиентов
Нагрузка на сеть при репликации Вы снова правы, но я должен подчеркнуть здесь логический переход от предыдущих способов хранения данных. Современные СУБД действительно умеют передавать дельты и сжимать трафик. Однако принципиальная разница в том, что репликация в базах работает в постоянном режиме, в отличие от резервного копирования или RAID, где обмен либо отсутствует, либо происходит нерегулярно. Это создаёт сетевую нагрузку и влияет на инфраструктуру — особенно при интенсивной записи
Чувствительность к задержкам Этот пункт напрямую связан с синхронной репликацией. Приоритет был сделан на сохранность, а значит, задержки действительно становятся критичным параметром — как для СУБД, так и для распределённых файловых систем с таким же поведением
Шардирование Вы правы, конечно масштабирование упирается не только в диски. Но если говорить о хранении больших объёмов или миллионов файлов, то нагрузка на дисковую подсистему становится важным ограничивающим фактором, наряду с процессором, памятью и сетью. Шардирование в этом случае — способ не только масштабировать ресурсы, но и повысить отказоустойчивость: если один узел выходит из строя, это не означает потерю всего куска хранилища
Я понимаю о чём вы говорите, но в статье делаю упор именно на раскрытие темы про надёжное хранение данных в условиях невечности железа. Не идёт речи про максимально возможную высокую скорость работы или минимальный отклик с риском потерь. Здесь всё про вариации, и их слишком много чтобы досконально в рамках данной статьи упомянуть все нюансы
Статья в целом задумывалась как обзор разных подходов и эволюцию архитектур: от «традиционных» бэкапов и баз до специализированных решений вроде SeaweedFS. Я не ставил целью выдать универсальный рецепт — скорее поделился тем, какие варианты есть и как они складываются в более надёжную и гибкую систему хранения. Не всё в тексте получилось идеально — и конечно всегда есть что улучшить.
Спасибо что вы не были равнодушны и помогли это увидеть
В общем-то про требования было сказано в самом начале, но без отдельного подзаголовка
и скорость важна, и возможность разные диски поставить, и данные хранить разнородные
Такой же график я предоставить не смогу, у SeaweedFS иначе устроено взаимодействие, там несколько метрик собирать нужно вместе, по каждому компоненту
Кроме того там нет даже близко полной утилизации возможностей кластера относительно RPS
Покажу поэтому другой график, который, по моему мнению, больше подходит для обнаружения деградации системы в которой хранится очень большое число файлов. Без подробностей по типам операций, но здесь и листинг файлов учтён
Как я уже сказал в статье, файлы могут быть самые разные, в том числе настолько, что их мета будет или около размера файла, или меньше
Про соотношение размеров кластера к количеству файлов тоже есть в самом начале статьи
не совсем понял вопрос, но попробую дать ответ на проблему с поиском
Если файлов не очень много и прирост медленный, не хочется заниматься поддержанием нескольких продуктов — тот же MinIO будет отличным вариантом. Просто внимательно на него посмотрите прежде чем окончательно переехать, в том числе на ситуации с недоступностью оборудования
Если ищете вариант S3 API-совместимого хранилища для хранения большого (и очень большого) числа файлов, попробуйте SeaweedFS с SQL-базой в качестве хранилища меты. Получите преимущество от поиска по префиксам, операции LIST станут быстрее в ситуациях, когда файликов много и используется вложенность "директорий"
Как вариант БД, которой должно хватить на долгое время, могу предложить Percona XtraDB Cluster. Но возможно правильно начать с инструмента, с которым вы знакомы лучше
Minio уже на миллионах файлов начнёт деградировать, на десятках и сотнях миллионов лучше ему не станет. Это связано с изначальной архитектурной особенностью и я ещё раз скажу, что всё будет зависеть в том числе от конфигурации, но глобально ситуацию не поменяет
Я правильно понимаю, что вам важно получить какие-то численные показатели и этого будет достаточно чтобы согласиться с высказанной мыслью о замедлениях с ростом числа файлов? У меня нет цели дотошно доказывать вам недостатки Minio. Давайте обсудим ваш опыт работы с ним, замечали ли вы деградацию и в какой момент? Если у вас всё хорошо на любых объёмах данных, в любых сценариях — давайте обсудим это, мне будет интересно узнать как вы этого добились
Нет, не устроит. Я уже сказал, что это компромисс. Важно переживать не только потерю условного % серверов, а быть готовым к выходу целого датацентра. Предположим, что датацентров 3 штуки. Репликация х3 в данном случае идеальна, так как защитит дополнительно от проблем в оставшихся двух ДЦ. Но для экономии места и средств в качестве компромисса можно использовать и репликацию х2. Реплик будет всего 2 штуки, но они будут в разных локациях и для восстановления фактора репликации файл нужно будет просто скопировать в другую доступную зону
Здесь ещё очень сильная зависимость от того, какие именно данные планируется хранить. Какая скорость доступа к ним нужна. Насколько критичен простой. Критично ли всё это вообще))
Не зная этих условий нельзя точно сказать какой инструмент нужен
With synchronous replication, MinIO attempts to replicate the object prior to completing the originating PUT operation. MinIO returns a successful PUT operation whether or not the replication attempt succeeds. This reduces the risk of slow write operations at a possible cost of stale or missing objects on the remote location.
Я правильно помню, что синхронная репликация должна гарантировать одинаковое состояние реплик? И что это мера защиты от таких случаев как потеря одной копии до того как будет создана вторая? Вспомните ситуацию с выходом датацентра или любой другой неприятный сценарий где по какой-то причине сломается не отдельный юнит, а будет потеряна логическая (физическая) зона доступности, в частности та, в которую изначально шла запись
Если вам нормально в новом релизе вашей БД узнать что синхронная репликация теперь асинхронная, и асинхронная тоже асинхронная — то нет никаких вопросов, давайте честно признаемся что это норма и перестанем продолжать мусолить тему которую я подал под видом "всё-таки у Minio что-то не так между словами и реальностью"
Лично я не вижу разницы между бэкапом и "репликацией" если процесс происходит не в реальном времени и в другую независимую систему
У нас с вами могут быть отличные мнения, это нормально )
Скажу только, что всё-таки хочу обсуждать не калькулятор и обещания создателей ПО, а реальный опыт эксплуатации. У нас хороший опыт получился когда был собран конструктор. И этот конструктор имеет хороший запас на рост в любом смысле этого слова
всё пытаюсь вывести комментарии в продуктивный разговор — поделитесь своим опытом построения и эксплуатации распределённых систем хранения?)
Я ещё раз хочу поблагодарить за технически насыщенный разбор — вы явно в теме, и такие комментарии дают возможность лучше раскрыть материал
Метаданные и данные на уровне файловой системы, ребалансировка и детали про Minio
Я не прав с фразой "в том виде, в котором были загружены" относительно Minio. Увлекся и упустил момент с ECC. Исправлю это высказывание на более точное. Речь шла о том, что MinIO хранит и объекты, и метаинформацию в виде файлов в файловой системе. Я несколько раз подчеркнул, что плохо станет только в случае с очень большим числом файлов, именно в этом сценарии такой подход превращается в "плохо"
Формулировки про триггеры я тоже пересмотрю, спасибо за это замечание
Вы используете “S3” строго как реализацию API — и в этом смысле MinIO действительно один из лучших, я отдельно подчеркнул это в статье
Что всё-таки не так и где происходит подмена понятий
Вы подаёте ECC как полностью надёжную замену репликации. Но на практике это компромисс. ECC требует пересборки данных при потере фрагментов и может быть чувствительна к распределению этих фрагментов по узлам. Например, если критическая масса фрагментов окажется в одном ЦОДе, выход его из строя может привести к временному или полному отсутствию доступа к объектам.
В статье S3 рассматривался как обобщённая архитектурная модель: масштабируемое, отказоустойчивое, надёжное, распределённое хранилище. Minio может им быть.
Как вы и подчеркнули, у Minio нет репликации. И раздел с названием "Site Replication" содержит очень странное утверждение о синхронной репликации. Комментарием выше вы акцентировали внимание на разницу между режимами в работе баз данных, но сейчас в контексте Minio почему-то закрыли глаза на явную подмену понятий. Это не репликация, а бэкап. И механизма репликации с гарантией записи в 2 и более зон доступности нет? Если так, то не знаю почему я должен записать это в плюсы и убрать из минусов
Я знаю что Minio написан на Go. И нигде не сказал обратного) как и не было сказано о том, что Minio нельзя использовать, он опасен и вообще плохой
Это эмоциональное обобщение. Я в статье честно делюсь нашим опытом и логикой выбора. Да, SeaweedFS был выбран давно. Да, с тех пор продукты развиваются, и какие-то ограничения могут уже быть неактуальны. Но статья в общем-то не про абсолютную “победу Seaweed”, а про то, что повлияло на выбор и решения.
Цель статьи — не “доказать правильность” выбранного, а показать, какие критерии мы использовали и почему приняли именно такое решение. Это практический опыт, а не академическое исследование
Я старался в статье не делать оценку за читателей. Не додумывайте за меня и вы. Мне как автору статьи не было задачи проводить и публиковать собственные бенчмарки. Это не только трудозатратно, но и неизбежно субъективно: я, как и любой практикующий инженер, лучше знаком с одной системой, чем с другой. Любые результаты в таком случае будут отражать не только характеристики хранилища, но и мою экспертизу в его настройке и эксплуатации и вводить этим в сильное заблуждение
Статья изначально должна была мотивировать читателя самостоятельно проверить, подумать и выбрать. Я считаю что это получилось. Какие у систем есть особенности, ограничения, плюсы, с чем мы столкнулись на практике и почему выбрали то, что выбрали. Если после прочтения кто-то захочет самостоятельно сравнить MinIO и SeaweedFS в своём окружении — значит, статья сработала именно так, как я и задумывал
Я прочитаю статью ещё раз и внесу правки относительно резких упрощённых утверждений. Ваш отклик — отличный пример того, как техническое сообщество помогает авторам быть точнее и полезнее.
Спасибо ещё раз — буду рад, если вы и дальше поделитесь своим опытом, особенно если он отличается от нашего
Спасибо за развёрнутый комментарий и уточнения про СУБД. Вы полностью правы, все выше упомянутые вещи справедливы. Упущения в тексте не случайны, и я попробую дополнить свою позицию
Зачем в статье вообще базы данных? (и всё остальное)
Понимаю вопрос. Но базы данных здесь не как альтернатива распределённым или объектным хранилищам. Скорее — как часть архитектурного конструктора: один из инструментов, который может быть полезен в определённом контексте. СУБД используют во множестве сценариев — в том числе как основу для построения собственных файловых или объектных хранилищ.
Поэтому полностью игнорировать СУБД при проектировании отказоустойчивой системы хранения было бы, на мой взгляд, необоснованно. Задача статьи — не выстроить противопоставление, а показать, как разные технологии могут дополнять друг друга и создавать что-то новое
Репликация
Конечно вы правы. Речь шла о синхронной репликации — в контексте сохранности данных асинхронный подход не рассматривался как потенциально небезопасный
Скорость доступа и распределение нагрузки
Подразумевалось, что нагрузка на чтение может быть распределена между несколькими репликами, а не то, что одна сессия читает с нескольких одновременно. Статья в целом построена с точки зрения работы систем, а не клиентов
Нагрузка на сеть при репликации
Вы снова правы, но я должен подчеркнуть здесь логический переход от предыдущих способов хранения данных. Современные СУБД действительно умеют передавать дельты и сжимать трафик. Однако принципиальная разница в том, что репликация в базах работает в постоянном режиме, в отличие от резервного копирования или RAID, где обмен либо отсутствует, либо происходит нерегулярно. Это создаёт сетевую нагрузку и влияет на инфраструктуру — особенно при интенсивной записи
Чувствительность к задержкам
Этот пункт напрямую связан с синхронной репликацией. Приоритет был сделан на сохранность, а значит, задержки действительно становятся критичным параметром — как для СУБД, так и для распределённых файловых систем с таким же поведением
Шардирование
Вы правы, конечно масштабирование упирается не только в диски. Но если говорить о хранении больших объёмов или миллионов файлов, то нагрузка на дисковую подсистему становится важным ограничивающим фактором, наряду с процессором, памятью и сетью. Шардирование в этом случае — способ не только масштабировать ресурсы, но и повысить отказоустойчивость: если один узел выходит из строя, это не означает потерю всего куска хранилища
Я понимаю о чём вы говорите, но в статье делаю упор именно на раскрытие темы про надёжное хранение данных в условиях невечности железа. Не идёт речи про максимально возможную высокую скорость работы или минимальный отклик с риском потерь. Здесь всё про вариации, и их слишком много чтобы досконально в рамках данной статьи упомянуть все нюансы
Статья в целом задумывалась как обзор разных подходов и эволюцию архитектур: от «традиционных» бэкапов и баз до специализированных решений вроде SeaweedFS. Я не ставил целью выдать универсальный рецепт — скорее поделился тем, какие варианты есть и как они складываются в более надёжную и гибкую систему хранения. Не всё в тексте получилось идеально — и конечно всегда есть что улучшить.
Спасибо что вы не были равнодушны и помогли это увидеть