Привет! мы такой кейс рассматривали, чтобы такого не случилось была добавлена статусная модель и обязательное время нахождения в статусе. То есть из твоего примера будет так
rados object не имеет ссылок, его пометили к удалению
кто-то другой конкурентно с пометкой к удалению стал использовать этот rados object, ссылаться на него
новые объекты не могут ссылаться на этот rados object, потому что он уже помечен к удалению
GC фазы удаления проходит по объектам, помеченным к удалению. Проверяет, что прошло X времени с момента изменения статуса. И видит, что помеченный к удалению объект кем-то используется. И меняет статус обратно на ОК, не удаляя его
Мы как раз хотели избежать блокировок и таких атомарных изменений, потому что у нас eventual consistency база данных, сделать какую-то сложную логику атомарно бывает либо проблемно, либо плохо по производительности
Пожалуй основной критерий был возможность лёгкого масштабирования/шардирования. Мы подумали, что для нашей довольно таки простой предметной области не обязательны гарантии, которые предоставляют РСУБД, такие как PostgreSQL, поэтому смотрели и в сторону NoSQL. Ретроспективно, нам бы возможно подошёл какой-нибудь CockroachDB, по крайней мере из того поверхностного, что я читал, но ScyllaDB нам полностью подошла. Ещё и это был некий вектор для компании - у нас с тех пор в озоне появилась ScyllaDB платформа и всё больше сервисов начинают её использовать, то есть растёт экспертиза в компании в целом
Бэкапы мы делаем через стандартный ScyllaDB Manager. Бэкап происходит понодно и складывается тоже в S3, но в другой :)
Ты про Lightweight Transactions (LWT) или про транзакции через какой-то сторонний сервис? (в сцилле только LWT) но ответ - нет, мы строили архитектуру так, чтобы не пользоваться транзакциями, т.к опасались за производительность. Спорные ситуации разруливаются с помощью механизма Timestamp (время применения операции в сцилле), и статусные модели для объектов + фоновые джобы, которые могут чистить мусор
С SeaweedFS не было опыта работы, но навскидку показалось что это недостаточно крупный и развитый проект, как например тот же Ceph RGW, есть много мелких проблем. А ещё это проект одного человека, что на наших масштабах выглядит как большой риск. Но тем не менее, возможно это хорошая альтернатива MinIO, выглядит перспективно
У яндекса это коммерческое решение, которое они предоставляют в рамках облака, так что, боюсь, тут сложно будет :)
У нас были размышления про опенсорс, но тут тоже всё не так просто, нужна заинтересованность со стороны бизнеса выделять на это ресурсы, да и понимание, что вокруг этого продукта можно построить комьюнити, то есть нужна целевая аудитория крупных компаний, которые уже переросли открытые решения, но ещё не имеют своё. Так что вопросов много. Но со стороны инженера, конечно, было бы круто вынести такой продукт в опенсорс, я тут полностью согласен)
Раз тут все накидывают варианты с vpn, я тоже вклинюсь)
Для решения подобной проблемы (безопасный доступ к устройству в другой сети за NAT) сделал свой peer to peer vpn, opensource, есть удобные графические клиенты под windows, linux, android. По функционалу не так богато как tailscale, но зато полностью открытое решение, не нужны никакие аккаунты, не нужно поднимать сервер, настройка за пару минут
Привет! мы такой кейс рассматривали, чтобы такого не случилось была добавлена статусная модель и обязательное время нахождения в статусе. То есть из твоего примера будет так
rados object не имеет ссылок, его пометили к удалению
кто-то другой конкурентно с пометкой к удалению стал использовать этот rados object, ссылаться на него
новые объекты не могут ссылаться на этот rados object, потому что он уже помечен к удалению
GC фазы удаления проходит по объектам, помеченным к удалению. Проверяет, что прошло X времени с момента изменения статуса. И видит, что помеченный к удалению объект кем-то используется. И меняет статус обратно на ОК, не удаляя его
Мы как раз хотели избежать блокировок и таких атомарных изменений, потому что у нас eventual consistency база данных, сделать какую-то сложную логику атомарно бывает либо проблемно, либо плохо по производительности
Привет! рад, что понравилось)
Пожалуй основной критерий был возможность лёгкого масштабирования/шардирования. Мы подумали, что для нашей довольно таки простой предметной области не обязательны гарантии, которые предоставляют РСУБД, такие как PostgreSQL, поэтому смотрели и в сторону NoSQL. Ретроспективно, нам бы возможно подошёл какой-нибудь CockroachDB, по крайней мере из того поверхностного, что я читал, но ScyllaDB нам полностью подошла. Ещё и это был некий вектор для компании - у нас с тех пор в озоне появилась ScyllaDB платформа и всё больше сервисов начинают её использовать, то есть растёт экспертиза в компании в целом
Бэкапы мы делаем через стандартный ScyllaDB Manager. Бэкап происходит понодно и складывается тоже в S3, но в другой :)
Ты про Lightweight Transactions (LWT) или про транзакции через какой-то сторонний сервис? (в сцилле только LWT) но ответ - нет, мы строили архитектуру так, чтобы не пользоваться транзакциями, т.к опасались за производительность. Спорные ситуации разруливаются с помощью механизма Timestamp (время применения операции в сцилле), и статусные модели для объектов + фоновые джобы, которые могут чистить мусор
Пока только в нашей внутренней джире :)
С SeaweedFS не было опыта работы, но навскидку показалось что это недостаточно крупный и развитый проект, как например тот же Ceph RGW, есть много мелких проблем. А ещё это проект одного человека, что на наших масштабах выглядит как большой риск. Но тем не менее, возможно это хорошая альтернатива MinIO, выглядит перспективно
У яндекса это коммерческое решение, которое они предоставляют в рамках облака, так что, боюсь, тут сложно будет :)
У нас были размышления про опенсорс, но тут тоже всё не так просто, нужна заинтересованность со стороны бизнеса выделять на это ресурсы, да и понимание, что вокруг этого продукта можно построить комьюнити, то есть нужна целевая аудитория крупных компаний, которые уже переросли открытые решения, но ещё не имеют своё. Так что вопросов много. Но со стороны инженера, конечно, было бы круто вынести такой продукт в опенсорс, я тут полностью согласен)
Раз тут все накидывают варианты с vpn, я тоже вклинюсь)
Для решения подобной проблемы (безопасный доступ к устройству в другой сети за NAT) сделал свой peer to peer vpn, opensource, есть удобные графические клиенты под windows, linux, android. По функционалу не так богато как tailscale, но зато полностью открытое решение, не нужны никакие аккаунты, не нужно поднимать сервер, настройка за пару минут
https://github.com/anywherelan/awl