Комментарии 13
К сожалению, по моему мнению, вы допустили слишком ошибок в вашей публикации, чтобы просто закрыть и пройти мимо. Поэтому возьмусь ответить и прокомментировать некоторые моменты. Намерено разделю часть про СУБД и про S3. В целом мне изначально вообще непонятно, что тут делает СУБД при выборе решения для распределенного файлового хранения, но раз написано, давайте исправляться.
Плюсов у баз данных много:
Репликация в реальном времени — клиенту не будет возвращён ответ «OK» до тех пор, пока мастер не сделает копию изменений на одну или две реплики.
только в синхронном режиме. в асинхронном режиме этот принцип не соблюдается
Высокая скорость доступа — большая часть горячих данных хранится в оперативной памяти.
мы про репликацию или про скорость доступа хотим читать? тут можно долго уйти в дискуссию что такое горячие данные, можно ли в конкретной субд сделать pin cache, или нужно кэш прогревать, есть ли встроенные механизмы прогрема, или надеемся что современем все что надо оно погорячеет в памяти, алгоритмы вытеснения (LRU) и тд и тп. зачем вообще тут про это?
Есть разные механизмы для ускорения работы, например, индексирование, защита от множественного изменения данных.
аналогично пункту выше. какое отношение индексирование имеет к решаемой задачи?
Высокая скорость чтения — читать можно не только с одной реплики, а с нескольких.
одна сессия читает с одной реплики. с нескольких реплик сессия читать не может. исключение - шардированные системы, но тогда при чем тут реплика?
Нет ограничения файловых систем — миллионы записей укомплектовываются, сжимаются и хранятся в нескольких файлах.
Минусы тоже есть:
Базы данных требуют больше трафика для синхронизации изменений.
с чего вдруг? 1. базы данных умеют сжимать сетевой трафик, 2. базы данных на подписчиков с мастера передают изменения, которые уже на локальной реплике (подписчике) пишутся на дисковую подсистему. Трафика не больше не меньше чем где бы то еще .
Чувствительны к задержкам сети.
СМ асинхронную репликацию
Не могут расти бесконечно без шардирования, так как диски под каждой репликой имеют ограничение.
Шардирование делают не потому что диски имеют ограничения, а потому что один вычислительный узел имеет ограничения и в какой то момент увеличение его мощности либо не дает никакого эффекта, либо просто невозможно физичеески, а вот дисковая подсистема то как раз может быть практически бесконечной.
итого:
подход мастер-стейндбай подписчики это - изначально про время переключения\восстановления при наступлении аварии. "быстрое чтение" - приятный побоный эффектн (доступный кстати не в каждой субд!). в зависимости от требований rto/pro вы выбираете себе подходящее решение для каждой конкретной субд
Спасибо за развёрнутый комментарий и уточнения про СУБД. Вы полностью правы, все выше упомянутые вещи справедливы. Упущения в тексте не случайны, и я попробую дополнить свою позицию
Зачем в статье вообще базы данных? (и всё остальное)
Понимаю вопрос. Но базы данных здесь не как альтернатива распределённым или объектным хранилищам. Скорее — как часть архитектурного конструктора: один из инструментов, который может быть полезен в определённом контексте. СУБД используют во множестве сценариев — в том числе как основу для построения собственных файловых или объектных хранилищ.
Поэтому полностью игнорировать СУБД при проектировании отказоустойчивой системы хранения было бы, на мой взгляд, необоснованно. Задача статьи — не выстроить противопоставление, а показать, как разные технологии могут дополнять друг друга и создавать что-то новое
Репликация
Конечно вы правы. Речь шла о синхронной репликации — в контексте сохранности данных асинхронный подход не рассматривался как потенциально небезопасный
Скорость доступа и распределение нагрузки
Подразумевалось, что нагрузка на чтение может быть распределена между несколькими репликами, а не то, что одна сессия читает с нескольких одновременно. Статья в целом построена с точки зрения работы систем, а не клиентов
Нагрузка на сеть при репликации
Вы снова правы, но я должен подчеркнуть здесь логический переход от предыдущих способов хранения данных. Современные СУБД действительно умеют передавать дельты и сжимать трафик. Однако принципиальная разница в том, что репликация в базах работает в постоянном режиме, в отличие от резервного копирования или RAID, где обмен либо отсутствует, либо происходит нерегулярно. Это создаёт сетевую нагрузку и влияет на инфраструктуру — особенно при интенсивной записи
Чувствительность к задержкам
Этот пункт напрямую связан с синхронной репликацией. Приоритет был сделан на сохранность, а значит, задержки действительно становятся критичным параметром — как для СУБД, так и для распределённых файловых систем с таким же поведением
Шардирование
Вы правы, конечно масштабирование упирается не только в диски. Но если говорить о хранении больших объёмов или миллионов файлов, то нагрузка на дисковую подсистему становится важным ограничивающим фактором, наряду с процессором, памятью и сетью. Шардирование в этом случае — способ не только масштабировать ресурсы, но и повысить отказоустойчивость: если один узел выходит из строя, это не означает потерю всего куска хранилища
Я понимаю о чём вы говорите, но в статье делаю упор именно на раскрытие темы про надёжное хранение данных в условиях невечности железа. Не идёт речи про максимально возможную высокую скорость работы или минимальный отклик с риском потерь. Здесь всё про вариации, и их слишком много чтобы досконально в рамках данной статьи упомянуть все нюансы
Статья в целом задумывалась как обзор разных подходов и эволюцию архитектур: от «традиционных» бэкапов и баз до специализированных решений вроде SeaweedFS. Я не ставил целью выдать универсальный рецепт — скорее поделился тем, какие варианты есть и как они складываются в более надёжную и гибкую систему хранения. Не всё в тексте получилось идеально — и конечно всегда есть что улучшить.
Спасибо что вы не были равнодушны и помогли это увидеть
Теперь давайте к S3.
"У Minio, который часто используется в качестве S3, всё хранится на дисках вместе — и мета, и данные. Он полностью зависит от файловой системы, и это плохо. С увеличением числа файлов скорость будет замедляться."
Вы проводили нагрузочные тестирования? Поделитесь пжста результатами. Или вы просто сделали выводы по описанию что внутренняя мета не хранится в СУБД, значит работать будет медленно и ненадежно?
"У Minio, несмотря на то, что реализовано больше опций, совместимых с S3 API, синхронная запись реплики не работает, даже если её включить (: "
Где вы в minio вообще реплики то нашли? Там нет фактора репликации и механизмом отказоустойчивости в одной серверной группе и кластере является использование ECC. При этом ЕСС позволяет обеспечить отказоустойчивость не хуже чем применение реплик с тз потери дисков или целых узлов. Чтобы разобраться детально советую посмотреть это https://min.io/product/erasure-code-calculator Заодно тут можно прикинуть насколько больше будет полезного доступного дискового пространства по сравнению с подходом Х реплик (а ведь это напрямую влияет на стоимость хранения!).
Скриншот с описанием репликации репликации хорошо, но вот только он относится к репликации С КЛАСТЕРА НА КЛАСТЕР minio на резервный контур (например в резервный ЦОД) https://min.io/docs/minio/linux/operations/install-deploy-manage/multi-site-replication.html раздел документа называется Site Replication
"Minio обрабатывает файлы последовательно: запись, репликация, удаление каждого файла происходят по отдельности. А ребалансировка — только по триггеру. Например, когда добавляется новое хранилище или изменяется нагрузка."
Фоновое отложенное обслуживание это как раз благо, гарантирующее высокую производительность на запись и сохранность дисков (для чего minio и создавался). Странно что вы это об этом пишите только в конце и по тексту как бы непонятно благо по вашему мнению это или нет
Далее, откуда вы это взяли что ребаланс только по триггеру? Ребаланс в minio доступен ручной, если вам так хочется. Это ведь легко проверяется даже простым фактчекингом поиском.
"Minio поддерживает только одинаковые диски внутри пула и замедляется с ростом файлов. Несмотря на то, что сервис позиционирует себя как S3, фактически он им не является. Это просто сетевое хранилище или сетевой диск."
Minio проектировался изначально как хранилище с гарантированной высокой производительностью, а не как файлопомойка "соберем из серваков которые насобирали с разными дисками". Именно поэтому minio предпочтителен для задач вроде lakehouse on prem или ML datalake.
Ну и гордое звание "S3" дается за поддержку стандарта AWS API а не потому что можно собрать из чего угодно
"У Minio все файлы хранятся «как есть» — в том виде, в котором были загружены. Ещё есть полная зависимость от файловой системы и нужен рестарт кластера при добавлении новых дисков. "
Что простите? Откуда вы это взяли?
Ещё SeaweedFS написан на Go, который очень любит наша команда инфраструктуры.
Угадайте, на чем написан minIO :)
Вы изначальное выбирали решение которое позволит вам: распределено организовать хранение файлов, которое можно собрать из какой угодно глиносоломы ("любые диски любого объема").
Сейчас публикация выглядит со стороны как "мы сперва все сделали, а потом выбираем задним числом", либо "хотели seaweed и придумали другим недостатки"
Я ещё раз хочу поблагодарить за технически насыщенный разбор — вы явно в теме, и такие комментарии дают возможность лучше раскрыть материал
Метаданные и данные на уровне файловой системы, ребалансировка и детали про Minio
Я не прав с фразой "в том виде, в котором были загружены" относительно Minio. Увлекся и упустил момент с ECC. Исправлю это высказывание на более точное. Речь шла о том, что MinIO хранит и объекты, и метаинформацию в виде файлов в файловой системе. Я несколько раз подчеркнул, что плохо станет только в случае с очень большим числом файлов, именно в этом сценарии такой подход превращается в "плохо"
Формулировки про триггеры я тоже пересмотрю, спасибо за это замечание
Вы используете “S3” строго как реализацию API — и в этом смысле MinIO действительно один из лучших, я отдельно подчеркнул это в статье
Что всё-таки не так и где происходит подмена понятий
Вы подаёте ECC как полностью надёжную замену репликации. Но на практике это компромисс. ECC требует пересборки данных при потере фрагментов и может быть чувствительна к распределению этих фрагментов по узлам. Например, если критическая масса фрагментов окажется в одном ЦОДе, выход его из строя может привести к временному или полному отсутствию доступа к объектам.
В статье S3 рассматривался как обобщённая архитектурная модель: масштабируемое, отказоустойчивое, надёжное, распределённое хранилище. Minio может им быть.
Как вы и подчеркнули, у Minio нет репликации. И раздел с названием "Site Replication" содержит очень странное утверждение о синхронной репликации. Комментарием выше вы акцентировали внимание на разницу между режимами в работе баз данных, но сейчас в контексте Minio почему-то закрыли глаза на явную подмену понятий. Это не репликация, а бэкап. И механизма репликации с гарантией записи в 2 и более зон доступности нет? Если так, то не знаю почему я должен записать это в плюсы и убрать из минусов
Я знаю что Minio написан на Go. И нигде не сказал обратного) как и не было сказано о том, что Minio нельзя использовать, он опасен и вообще плохой
"мы сперва все сделали, а потом выбираем задним числом"
Это эмоциональное обобщение. Я в статье честно делюсь нашим опытом и логикой выбора. Да, SeaweedFS был выбран давно. Да, с тех пор продукты развиваются, и какие-то ограничения могут уже быть неактуальны. Но статья в общем-то не про абсолютную “победу Seaweed”, а про то, что повлияло на выбор и решения.
Цель статьи — не “доказать правильность” выбранного, а показать, какие критерии мы использовали и почему приняли именно такое решение. Это практический опыт, а не академическое исследование
"Вы проводили нагрузочные тестирования? Поделитесь пжста результатами. Или вы просто сделали выводы по описанию"
Я старался в статье не делать оценку за читателей. Не додумывайте за меня и вы. Мне как автору статьи не было задачи проводить и публиковать собственные бенчмарки. Это не только трудозатратно, но и неизбежно субъективно: я, как и любой практикующий инженер, лучше знаком с одной системой, чем с другой. Любые результаты в таком случае будут отражать не только характеристики хранилища, но и мою экспертизу в его настройке и эксплуатации и вводить этим в сильное заблуждение
Статья изначально должна была мотивировать читателя самостоятельно проверить, подумать и выбрать. Я считаю что это получилось. Какие у систем есть особенности, ограничения, плюсы, с чем мы столкнулись на практике и почему выбрали то, что выбрали. Если после прочтения кто-то захочет самостоятельно сравнить MinIO и SeaweedFS в своём окружении — значит, статья сработала именно так, как я и задумывал
Я прочитаю статью ещё раз и внесу правки относительно резких упрощённых утверждений. Ваш отклик — отличный пример того, как техническое сообщество помогает авторам быть точнее и полезнее.
Спасибо ещё раз — буду рад, если вы и дальше поделитесь своим опытом, особенно если он отличается от нашего
Есть ли альтернативы GridFS? S3 API не заходит когда нужно много своих метаданных индексировать для поиска.
не совсем понял вопрос, но попробую дать ответ на проблему с поиском
Если файлов не очень много и прирост медленный, не хочется заниматься поддержанием нескольких продуктов — тот же MinIO будет отличным вариантом. Просто внимательно на него посмотрите прежде чем окончательно переехать, в том числе на ситуации с недоступностью оборудования
Если ищете вариант S3 API-совместимого хранилища для хранения большого (и очень большого) числа файлов, попробуйте SeaweedFS с SQL-базой в качестве хранилища меты. Получите преимущество от поиска по префиксам, операции LIST станут быстрее в ситуациях, когда файликов много и используется вложенность "директорий"
Как вариант БД, которой должно хватить на долгое время, могу предложить Percona XtraDB Cluster. Но возможно правильно начать с инструмента, с которым вы знакомы лучше
"Я несколько раз подчеркнул, что плохо станет только в случае с очень большим числом файлов, именно в этом сценарии такой подход превращается в "плохо"
давайте определимся тогда "очень большим числом". Речь о миллионах, десятках миллионов, сотнях. Какой при этом метаданные должны обеспечивать request rate.
"Вы подаёте ECC как полностью надёжную замену репликации. Но на практике это компромисс. ECC требует пересборки данных при потере фрагментов и может быть чувствительна к распределению этих фрагментов по узлам. Например, если критическая масса фрагментов окажется в одном ЦОДе, выход его из строя может привести к временному или полному отсутствию доступа к объектам."
Для того чтобы прикинуть что и как будет потеряно и может ли быть восстановлено вы выбираете тот уровень отказоустойчивости который вам необходим через. Также вы принимаете решение делать ли георасрпеделенный кластер минио или делать site to site репликацию межкластерную
вас устроит гарантированная работоспособность при потери 6 серверов в кластере при эффективной доступности данных от 70% объема? Или надо все же искать решение с репликаией х3?
"Как вы и подчеркнули, у Minio нет репликации. И раздел с названием "Site Replication" содержит очень странное утверждение о синхронной репликации. Комментарием выше вы акцентировали внимание на разницу между режимами в работе баз данных, но сейчас в контексте Minio почему-то закрыли глаза на явную подмену понятий. Это не репликация, а бэкап. И механизма репликации с гарантией записи в 2 и более зон доступности нет? Если так, то не знаю почему я должен записать это в плюсы и убрать из минусов"
Мне кажется это не у меня подмена понятий, либо понятие нужно ввести. Если вы делаете георасрпеделенный кластер, то никакой репликации там быть не может. Просто обеспечьте достатчную пропускную способность сетевого канала.
Если вы хотите сделать DR кластер (отдельный полноценный кластер в другом ЦОДе), то тут и нужно читать про варианты репликации. Там достаточно все вариативно от почти мнговенной, до отложенной, с ручным запуском и с выбором стратегии на каждом отдельном бакете в зависимости от критичности данных в бакете. Это и есть site to site.
А вот бэкап - это выгрузка данных из s3 хранилаща например на ленту или сетевой хранилище. Такое тоже бывает, хотя, кмк, бессмысленно. Реализуерся сторонними инструментами как правило.
давайте определимся тогда "очень большим числом". Речь о миллионах, десятках миллионов, сотнях. Какой при этом метаданные должны обеспечивать 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 уже на миллионах файлов начнёт деградировать, на десятках и сотнях миллионов лучше ему не станет. Это связано с изначальной архитектурной особенностью и я ещё раз скажу, что всё будет зависеть в том числе от конфигурации, но глобально ситуацию не поменяет "
Оставлю тут два графика "деградации".
25.5млн это усредненное значние на конец дня когда регламетные процессы приложения обслуживанию обслуживают свой дневной креатив. А в целом задача которую решает система - real time data hub. Целевой объем 600Тб, сейчас может половину уже имеют от целевого. Деградации пока не видно. Пока не встречалось еще решения лучше под указанную задачу.
Если у вас есть подобные метрики, поделитесь пжста.
"
Нет, не устроит. Я уже сказал, что это компромисс. Важно переживать не только потерю условного % серверов, а быть готовым к выходу целого датацентра. Предположим, что датацентров 3 штуки. Репликация х3 в данном случае идеальна, так как защитит дополнительно от проблем в оставшихся двух ДЦ. Но для экономии места и средств в качестве компромисса можно использовать и репликацию х2. Реплик будет всего 2 штуки, но они будут в разных локациях и для восстановления фактора репликации файл нужно будет просто скопировать в другую доступную зону
Здесь ещё очень сильная зависимость от того, какие именно данные планируется хранить. Какая скорость доступа к ним нужна. Насколько критичен простой. Критично ли всё это вообще))
Не зная этих условий нельзя точно сказать какой инструмент нужен
"
Золотые слова! Смотрите, в чем проблема материала, по моему мнению - Вы не обозначили требования которые выставляете, но начинаете сравнивать. Я вас уверяю, большинство прочте материал - все дураки кроме seaweed. Никто не будет фактчекингом заниматься даже. Это сейчас уже становится понятно что для вас например скорость не важна, хочется собирать на разном оборудовании без симметрии, наверняка не высокие сетевые требования, геораспределение с вероятностью прилет дрона как минимум в одни датацентр, RTO/RPO в конце концов какое должны обеспечивать.
В общем-то про требования было сказано в самом начале, но без отдельного подзаголовка
удобный конструктор, который позволяет загружать файлы любого размера, легко масштабироваться без деградации скорости доступа и надёжно защищать данные от потерь. В статье рассказываю, каким должно быть идеальное S3-хранилище для миллионов файлов
и скорость важна, и возможность разные диски поставить, и данные хранить разнородные
Такой же график я предоставить не смогу, у SeaweedFS иначе устроено взаимодействие, там несколько метрик собирать нужно вместе, по каждому компоненту
Кроме того там нет даже близко полной утилизации возможностей кластера относительно RPS
Покажу поэтому другой график, который, по моему мнению, больше подходит для обнаружения деградации системы в которой хранится очень большое число файлов. Без подробностей по типам операций, но здесь и листинг файлов учтён
Как я уже сказал в статье, файлы могут быть самые разные, в том числе настолько, что их мета будет или около размера файла, или меньше
Про соотношение размеров кластера к количеству файлов тоже есть в самом начале статьи
S3-совместимые хранилища: как собрать свой конструктор