* дедупликация определяется по sha и ставится линк (но в кластерном режиме будет репликация по шардам, то есть если нода умрёт - данные не потеряются)
2)Битый сектор затронет только тот объект, в чьи байты он попал. Остальные объекты в том же volume остаются целыми, а метаданные хранятся отдельно
3) На текущий момент S4 это single-node (сейчас уже почти завершена миграция с redb на fjall - были проблемы с multipart upload, поэтому долго релизится s4core-fjall). Дедупликация будет работать внутри каждого шарда в кластерном режиме
4) Отдача полностью стриминговая , сервер не грузит весь объект в ram. Ну и все ограничение только в скорости диска, никак иначе
Пользуюсь Zarub (в тг можно найти), оплачивал и claude и гугл клауд и aws, и даже небольшого провайдера baremetal серваков в канзасе, где виртуалки не принимались, но именно zarub отлично оплатилось. Если что это не реклама, просто поделился
Спасибо за дельный советы! Както общался с разработчиком блокчейнов на Rust. Вероятно продолжу поиски таких спецов) Пока изучаю книгу "Распределенные данные. .." от Алекс Петров, ну и deepresearch от гугла тоже хорошо помогает понять все алгоритмы и поиск новых
Спасибо за ответ. Коннект по публичному IP это антипаттерн безопасности, даже на маленьких проектах, хотя может в dev/stage окружении это еще может место быть, но точно не в проде
С агентом кстати идея довольно не плохая, но я бы поставил zabbix для этого и через action можно делать) А вообще с databasus выбрал бы путь - отдельный сервер бэкапов в закрытом контуре с доступом ко всем базам в приват сети
Привет. Интересное приложение databasus, очень понравился дизайн, влепил звезду) Единственное не понял, БД это всегда закрытый контур, и таких БД по проектам может быть несколько, придется ставить в каждое окружение по databasus'у? И на сайте databasus'а заметил скрин с открытым коннектом к базе через публичный IP, это прикол 😁 ?
ИМХО страшновато ставить рядом с БД сторонние приложения с неизвестными библиотеками. Я все же доверяю скриптам, репликации и s3cmd, но возможно я параноик)
Привет, идея переписать Minio на раст возможно имеет место быть, но Minio это не просто бинарник, а целая экосистема, сюда же накладывается слой совместимости с версией на Go, и соотвесттвенно весь этот зоопарк придется поддерживать, и этот проект придется вести, а иначе и начинать не стоило. По архитектуре и надежности Minio не самое лучшее решение, и я изначально хотел убежать от этой архитектуры, и чтобы в моем решении была обязательно дедупликация с каким то уровнем безопасности данных, отсутвием проблемы с inode, наличие краш рекавери плана при сбоях, сингл нода на старте, и новый, достаточно быстрый вариант хранения данных. Стартовал я этот проект только ради спортивного интереса и с желанием углубленного знакомства с rust.
По поводу Enterprise согласен на 100%, не хочется идти по дороге rustfs) Но у проекта должна быть цель, я считаю это главное в его развитии, к примеру можно взять Gitlab, их модель для меня идеал.
Привет, все-таки когда писал статью, были раздумья, чего можно опасаться в архитектуре. И пока нет распределенности/репликации/масштабирования, думать что single нода это что-то супер надежное - както слишком наивно, лично для меня. Для текущей версии, стабильность можно проверить только краш рекавери на сложных смешанных данных . Вчера увидел комментарий от @hapcode про fjall , и стало интересно, и сегодня весь день провел на чтение этой темы про fjall + lsm tree, вероятно это будет следующим шагом для дальнейшего апгрейда архитектуры S4Core.
Привет. Да, изначально это только single node, про масштабирование даже не зарекался) Сейчас много чего в процессе и "на бумаге", вероятно через пару месяцев что-то получится реализовать с маштабированием
Согласен, все хотят простым путем пойти) "Я подрублю тыщу агентов и завтра с утра у меня будет супер проект, я сам не буду ничего писать, буду пить пина коладу и вайбкодить!". Но так не работает, когда начинаешь писать с нуля, появляются слишком много сложных вопросов по архитектуре и не только, которые ИИ не сможет нормально найти и обьяснить, разгрести все и принять решение. У меня только неделя минимум ушла на исследование по Минио и aws s3 sdk с signature v2 и signature v4, куча документации пришлось лопатить, я не вылазил до 2 ночи из компа, и к концу недели уже почти пропало желание чтото создавать с нуля, понимая фронт работы 😁 А еще куча других вопросов и сотни тестов по каждому чиху) Если где-то поправил, главное чтобы это не отразилось на другом функционале, просто это не реально для одного человека.
Сейчас вот только в 20:00 я подготовил новую альфу более стабильную, которая прошла все тысячу тестов, включая mint от minio на s3 full compatibility, и уже готовлю к публикации)
Изначально архитектура на этом и основывалась, что все что меньше 4кб это в основном метаданные (теги, acl и тд). Возможно, все таки стоит добавить флаг strick_wal, при котором абсолютно все файлы (даже < 4KB) будут дублироваться в append-only , но тут есть подводный камень - падение IOPS, ну и перерасход места, компактор(мусоросборщик) ахренеет от таких мелких файлов, чтение упадет. Но как вариант можно такое сделать как альтернативу если ваши данные настолько мелкозернистые
Привет, нет. Посмотрел сейчас, это отличия lsm дерево vs b дерево, немного не моя архитектура - у меня B) разница в скорости чтения и записи, по факту примерно одинаково, только в первом случае скорость чтения будет ниже, а во втором быстрее, ну и другие подводные камни тоже. Попробую изучить на выходных
я использовал miniapp, а чреез сайт не в курсе
это и есть базы, лишние слои не нужны
fjall используется для индекса метаданных, и дает чтение без локов, атомарные batch-записи, lsm-tree
Привет.
1) Миграция делается стандартными средствами, так как S4Core полностью совместим с S3 API:
aws s3 sync s3://source-bucket s3://dest-bucket --endpoint-url http://s4-server
или
rclone copy s3:source s4:dest
* дедупликация определяется по sha и ставится линк (но в кластерном режиме будет репликация по шардам, то есть если нода умрёт - данные не потеряются)
2)Битый сектор затронет только тот объект, в чьи байты он попал. Остальные объекты в том же volume остаются целыми, а метаданные хранятся отдельно
3) На текущий момент S4 это single-node (сейчас уже почти завершена миграция с redb на fjall - были проблемы с multipart upload, поэтому долго релизится s4core-fjall). Дедупликация будет работать внутри каждого шарда в кластерном режиме
4) Отдача полностью стриминговая , сервер не грузит весь объект в ram. Ну и все ограничение только в скорости диска, никак иначе
Привет! Спасибо почитаю о нем
>>наткнулся на связку «node_exporter → Prometheus → Grafana»
Это другая половина планеты)
Пользуюсь Zarub (в тг можно найти), оплачивал и claude и гугл клауд и aws, и даже небольшого провайдера baremetal серваков в канзасе, где виртуалки не принимались, но именно zarub отлично оплатилось. Если что это не реклама, просто поделился
Спасибо за дельный советы! Както общался с разработчиком блокчейнов на Rust. Вероятно продолжу поиски таких спецов) Пока изучаю книгу "Распределенные данные. .." от Алекс Петров, ну и deepresearch от гугла тоже хорошо помогает понять все алгоритмы и поиск новых
Спасибо за ответ. Коннект по публичному IP это антипаттерн безопасности, даже на маленьких проектах, хотя может в dev/stage окружении это еще может место быть, но точно не в проде
С агентом кстати идея довольно не плохая, но я бы поставил zabbix для этого и через action можно делать) А вообще с databasus выбрал бы путь - отдельный сервер бэкапов в закрытом контуре с доступом ко всем базам в приват сети
Привет. Интересное приложение databasus, очень понравился дизайн, влепил звезду)
Единственное не понял, БД это всегда закрытый контур, и таких БД по проектам может быть несколько, придется ставить в каждое окружение по databasus'у? И на сайте databasus'а заметил скрин с открытым коннектом к базе через публичный IP, это прикол 😁 ?
ИМХО страшновато ставить рядом с БД сторонние приложения с неизвестными библиотеками. Я все же доверяю скриптам, репликации и s3cmd, но возможно я параноик)
Привет, идея переписать Minio на раст возможно имеет место быть, но Minio это не просто бинарник, а целая экосистема, сюда же накладывается слой совместимости с версией на Go, и соотвесттвенно весь этот зоопарк придется поддерживать, и этот проект придется вести, а иначе и начинать не стоило. По архитектуре и надежности Minio не самое лучшее решение, и я изначально хотел убежать от этой архитектуры, и чтобы в моем решении была обязательно дедупликация с каким то уровнем безопасности данных, отсутвием проблемы с inode, наличие краш рекавери плана при сбоях, сингл нода на старте, и новый, достаточно быстрый вариант хранения данных. Стартовал я этот проект только ради спортивного интереса и с желанием углубленного знакомства с rust.
По поводу Enterprise согласен на 100%, не хочется идти по дороге rustfs) Но у проекта должна быть цель, я считаю это главное в его развитии, к примеру можно взять Gitlab, их модель для меня идеал.
Привет, все-таки когда писал статью, были раздумья, чего можно опасаться в архитектуре. И пока нет распределенности/репликации/масштабирования, думать что single нода это что-то супер надежное - както слишком наивно, лично для меня. Для текущей версии, стабильность можно проверить только краш рекавери на сложных смешанных данных .
Вчера увидел комментарий от @hapcode про fjall , и стало интересно, и сегодня весь день провел на чтение этой темы про fjall + lsm tree, вероятно это будет следующим шагом для дальнейшего апгрейда архитектуры S4Core.
Если есть какие-либо предложения, буду рад помощи
Привет еще раз) Мне понравилась архитектура fjall и его подход, пока в раздумьях перейти на этот вариант
Мне понравился rust, у меня уже были несколько проектов на нем. Может быть это даже дань моде) а так скорость, надежность, работа с памятью отличная
Привет. Да, изначально это только single node, про масштабирование даже не зарекался) Сейчас много чего в процессе и "на бумаге", вероятно через пару месяцев что-то получится реализовать с маштабированием
Согласен, все хотят простым путем пойти) "Я подрублю тыщу агентов и завтра с утра у меня будет супер проект, я сам не буду ничего писать, буду пить пина коладу и вайбкодить!". Но так не работает, когда начинаешь писать с нуля, появляются слишком много сложных вопросов по архитектуре и не только, которые ИИ не сможет нормально найти и обьяснить, разгрести все и принять решение. У меня только неделя минимум ушла на исследование по Минио и aws s3 sdk с signature v2 и signature v4, куча документации пришлось лопатить, я не вылазил до 2 ночи из компа, и к концу недели уже почти пропало желание чтото создавать с нуля, понимая фронт работы 😁 А еще куча других вопросов и сотни тестов по каждому чиху) Если где-то поправил, главное чтобы это не отразилось на другом функционале, просто это не реально для одного человека.
Сейчас вот только в 20:00 я подготовил новую альфу более стабильную, которая прошла все тысячу тестов, включая mint от minio на s3 full compatibility, и уже готовлю к публикации)
Спасибо!
Привет. Хороший вопрос, я подумаю на счет этого, вероятно сделаю отдельный флаг и может быть еще чтото интересное)
Спасибо за поддержку проекта!
Изначально архитектура на этом и основывалась, что все что меньше 4кб это в основном метаданные (теги, acl и тд). Возможно, все таки стоит добавить флаг strick_wal, при котором абсолютно все файлы (даже < 4KB) будут дублироваться в append-only , но тут есть подводный камень - падение IOPS, ну и перерасход места, компактор(мусоросборщик) ахренеет от таких мелких файлов, чтение упадет. Но как вариант можно такое сделать как альтернативу если ваши данные настолько мелкозернистые
Привет, нет. Посмотрел сейчас, это отличия lsm дерево vs b дерево, немного не моя архитектура - у меня B)
разница в скорости чтения и записи, по факту примерно одинаково, только в первом случае скорость чтения будет ниже, а во втором быстрее, ну и другие подводные камни тоже. Попробую изучить на выходных