Is this something that they are currently working on? Is there any public Roadmap people could see t
Is this something that they are currently working on? Is there any public Roadmap people could see to track such things?
Ceven if we tried to shard to lowest possible way for our architecture (per client), it will be more 1200 buckets, but errors coming for small traffic of our actual traffic, we didn't even had a chance to put all traffic.
Calso per account 1000 bucket limit is there
EIt's being worked on but there's no public roadmap or ETA
EIt's not a quick fix, its a longer term project
EYes though you can request an increase if need be
UThey charge per operation instead which will cover the cost of any bandwidth they need to in addition to other things.
UI mean AWS is way more mature so can scale better. If you look up a bit a single bucket on R2 can do about 300ish concurrent. But also AWS just has really high profit margins.
UYou could shard across many buckets instead.
HThought I definitely would not recommend using KV to cache images from R2. It effectively generates double the cost for basically the same performance. If you do find that KV is faster for your usecase, and all your images fit in KV, then you can just store them in KV, omitting R2 entirely
DCouldn’t he use public buckets with caching and a WAF HMAC on top?
DJust note that caching will not work if you use presigned URLs on R2.
Dis r2 having issues right now?
JHi. I'm looking at moving from Google Cloud Storage to R2, primarily for the cost difference. Currently with Google we create a bucket per user but this isn't supported by default with R2 due to the inital bucket limit per account. I found this message (r2) stating that the current recommended way to achieve this in R2 is to use a UID prefix to create a "folder" per user however this presents issues when you want to delete a user's data and puts the burden of user usage collection on us.
Is this still the recommended way to structure user data in R2 and how likely are Cloudflare to increase the bucket limit for reasons such as this?
Also as I understand it at the moment there is no data replication with R2. Does this mean there is no protection against datacenter disasters?
Is this still the recommended way to structure user data in R2 and how likely are Cloudflare to increase the bucket limit for reasons such as this?
Also as I understand it at the moment there is no data replication with R2. Does this mean there is no protection against datacenter disasters?
KCreating a bucket per user sounds like a bad idea in every blob storage service, not just R2. The prefixes are exactly what you should do. Deleting the user data should be easy since you can delete based on a prefix.
R2 does have disaster recovery internally, we don't have user-facing replication (like you can't have two buckets on your account that automatically copy each other)
R2 does have disaster recovery internally, we don't have user-facing replication (like you can't have two buckets on your account that automatically copy each other)
KR2 analytics can also be filtered on the prefix. If each user has a UUID, there would be no possibility of overlap
JThat sounds perfect. I've not used the S3 API properly before. Is the only way to delete the files by prefix by using a lifecycle configuration? I couldn't see anything related to it on the standard delete object requests.
