Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Object Storage: AWS vs Google Cloud Storage vs Azure Storage vs DigitalOcean

chooseacloud.com

Post reply on HN
Print view View original

101–110 of 115 posts

Re: Object Storage: AWS vs Google Cloud Storage vs Azure Storage vs DigitalOcean

#101

Post by [deleted] »

toomuchtodo wrote: post #74
moondev wrote: post #56

Earlier quoted context omitted.

Backblaze is in only a single datacenter, so perhaps not quite fair to compare pricing between true multi-region competitors?

None of the other multi-region competitors provide multi-region durability "out of the box" (although S3 does offer cross region replication as an option), so you might consider distributing your data between two object stores if you need multi-region (AWS us-east-1 and Backblaze, for example). This ensure not only geographic redundancy, but also vendor redundancy (not to mention B2 is cheaper than S3). Disclaimer: I…

[deleted]

Re: Object Storage: AWS vs Google Cloud Storage vs Azure Storage vs DigitalOcean

#102

Post by manigandham »

arghwhat wrote: post #78
truetraveller wrote: post #48

Earlier quoted context omitted.

I really wanted to like B2. I love the docs and super-clean interface. But B2 was just too "weird" when it came to uploading an object. You can't replace an object key, so you always get a new object key when uploading. This is unlike any normal object store, where you can just upload to an existing key. Also, if you upload an object with the same name (e.g. myphoto.png) it creates a new version, and there's no way t…

If you upload an object with the same 'name' to S3, you also get a new version. When you say 'key', do you mean the opaque object ID granted to objects in B2 which object stores like S3 doesn't have at all? I don't understand the rant here. S3 only operate by 'name' (key). I have had no problem integrating B2 side-by-side with S3 and GCP in the products I have written. Their high-level models are largely compatible.

Why would you need a separate ID other than the actual filepath key? (and a metadata version number if you have versioning available)

Re: Object Storage: AWS vs Google Cloud Storage vs Azure Storage vs DigitalOcean

#103

Post by manigandham »

squid3 wrote: post #55

NodeChef's object storage is very attractive option especially with no data transfer charges. Available in two regions. https://nodechef.com/s3-compatible-object-storage

At $1/GB, it's the most expensive option mentioned on this page by far. Even with GCP's pricey storage, you would have to download your data 10x for this to make sense (or 88x with DO), and that's before considering cross-cloud/transit costs.

Also since you're the cofounder of nodechef, you should add a disclaimer when mentioning your own product.

Re: Object Storage: AWS vs Google Cloud Storage vs Azure Storage vs DigitalOcean

#104

Post by lobster_johnson »

toomuchtodo wrote: post #74
moondev wrote: post #56

Earlier quoted context omitted.

Backblaze is in only a single datacenter, so perhaps not quite fair to compare pricing between true multi-region competitors?

None of the other multi-region competitors provide multi-region durability "out of the box" (although S3 does offer cross region replication as an option), so you might consider distributing your data between two object stores if you need multi-region (AWS us-east-1 and Backblaze, for example). This ensure not only geographic redundancy, but also vendor redundancy (not to mention B2 is cheaper than S3). Disclaimer: I…

Not sure what you mean by "out of the box". Both Google Cloud Storage and Amazon S3 have cross-region replication built in. Something not "in the box" would imply you have to build it yourself, or buy a vendor product, to get it.

Google Cloud Storage's multi-regional support (asynchronously replicated to two or more geographic locations) is even easier than AWS: You simply specify, on bucket creation, whether the bucket should be regional or multi-regional.

Re: Object Storage: AWS vs Google Cloud Storage vs Azure Storage vs DigitalOcean

#105

Post by arghwhat »

manigandham wrote: post #102
arghwhat wrote: post #78

Earlier quoted context omitted.

If you upload an object with the same 'name' to S3, you also get a new version. When you say 'key', do you mean the opaque object ID granted to objects in B2 which object stores like S3 doesn't have at all? I don't understand the rant here. S3 only operate by 'name' (key). I have had no problem integrating B2 side-by-side with S3 and GCP in the products I have written. Their high-level models are largely compatible.

Why would you need a separate ID other than the actual filepath key? (and a metadata version number if you have versioning available)

B2 doesn't have metadata version numbers, but instead use the globally unique file identifier to refer to specific versions. When you list file versions, you're presented with file ids rather than version numbers.

It's only slightly different from the name+version approach, but I personally like the concept of unique identifiers better. It feels nicer.

Re: Object Storage: AWS vs Google Cloud Storage vs Azure Storage vs DigitalOcean

#106

Post by tobias3 »

icebraining wrote: post #19
tobias3 wrote: post #13

Earlier quoted context omitted.

OpenStack Swift or Ceph with Ceph Object Gateway. Don't use minio, it's a toy for testing.

I've never used it in production; in what ways is minio lacking compared to Swift and Ceph?

S3 is an abstraction that gives you a limited amount of operations with limited guarantees (e.g. eventual consistency, can only replace whole files). What you get in return is easier scalability and performance. If you use an S3 API to store files (like minio does) you give up power and gain nothing. So you are better off using NFS, samba, webdav, ftp, etc. Additionally minio doesn't seem to sync files to the file system, so you can't be sure a file is actually stored after a PUT operation (AWS S3 and swift have eventual consistency and Ceph has stronger guarantees).

Re: Object Storage: AWS vs Google Cloud Storage vs Azure Storage vs DigitalOcean

#107

Post by arghwhat »

mayank wrote: post #90
arghwhat wrote: post #78

Earlier quoted context omitted.

If you upload an object with the same 'name' to S3, you also get a new version. When you say 'key', do you mean the opaque object ID granted to objects in B2 which object stores like S3 doesn't have at all? I don't understand the rant here. S3 only operate by 'name' (key). I have had no problem integrating B2 side-by-side with S3 and GCP in the products I have written. Their high-level models are largely compatible.

S3 versioning is optional and off by default. Writes (including rewrites) to S3 are also atomic, so you’ll never see partial writes.

Ah, fair enough. I have oddly enough never in my life written to the same key twice, so I hadn't noticed it was off by default for S3.

Just to clarify you statement about atomicity: All writes to S3 and B2 are 'atomic' (and B2 can also verify the hash and reject on failure for an extra layer of security). The difference you mention is just that you can superficially "disable" versioning for S3, so that each key only stores one object version at a given time.

The only difference to the upload when S3 versioning is disabled is what happens during the metadata update: With versioning, a version is appended. Without, the version is replaced.

For B2, simulating disabled versioning is two operations: Upload a new object, and delete the old one. As long as the object is only referenced by name, this will also be atomic.

Re: Object Storage: AWS vs Google Cloud Storage vs Azure Storage vs DigitalOcean

#108

Post by arghwhat »

zedpm wrote: post #87
arghwhat wrote: post #78

Earlier quoted context omitted.

If you upload an object with the same 'name' to S3, you also get a new version. When you say 'key', do you mean the opaque object ID granted to objects in B2 which object stores like S3 doesn't have at all? I don't understand the rant here. S3 only operate by 'name' (key). I have had no problem integrating B2 side-by-side with S3 and GCP in the products I have written. Their high-level models are largely compatible.

S3 allows you to turn versioning on and off for a bucket; my understanding is that B2 does not.

Yeah, that's correct. You have to delete old versions manually after upload if you want to simulate an "overwrite".

It would be quite simple for backblaze to implement, though, so I guess it might come as a future option.

Re: Object Storage: AWS vs Google Cloud Storage vs Azure Storage vs DigitalOcean

#109

Post by toomuchtodo »

lobster_johnson wrote: post #104
toomuchtodo wrote: post #74

Earlier quoted context omitted.

None of the other multi-region competitors provide multi-region durability "out of the box" (although S3 does offer cross region replication as an option), so you might consider distributing your data between two object stores if you need multi-region (AWS us-east-1 and Backblaze, for example). This ensure not only geographic redundancy, but also vendor redundancy (not to mention B2 is cheaper than S3). Disclaimer: I…

Not sure what you mean by "out of the box". Both Google Cloud Storage and Amazon S3 have cross-region replication built in. Something not "in the box" would imply you have to build it yourself, or buy a vendor product, to get it. Google Cloud Storage's multi-regional support (asynchronously replicated to two or more geographic locations) is even easier than AWS: You simply specify, on bucket creation, whether the buc…

Thanks for correcting me on Google Cloud! I wasn't aware, as I work exclusively in AWS.

I stand by my statement about the benefit of multi vendor object replication.

Re: Object Storage: AWS vs Google Cloud Storage vs Azure Storage vs DigitalOcean

#110

Post by _hyn3 »

aclelland wrote: post #39
truetraveller wrote: post #4

I was really excited about DO spaces. I compared every major Object Storage (OVH,B2,Wasabi,S3,Azure). DO spaces came out much ahead. I did dozens of hours of research. I was a customer (and I still am). But I am less excited now. Basically, there are loads of issues with rejected requests because of rate limiting (returns a lot of 503 "slow down" responses). Basically, I don't recall ever receiving this from S3. You…

S3 will sometimes return a "503 temporary error" response if you start writing lots of files per second. From my understanding, if they see that your bucket has a constant high write rate they'll make some configuration changes in the background to accommodate the higher write rate. That being said, last month I wrote over 60 million files to S3 and the number of failed writes were tiny (solved by simply retrying the…

S3 will automatically shard your bucket evenly across your sub-namespace if you use pre-shardable names whenever possible.

This sounds complex but is actually fairly easy to do. For example, if you are not dealing with randomly generated ID's, try using Base64 encoded keynames rather than the keynames themselves. (A more limited character set is helpful, though.)

A better name than user_f38c9123 is f38c9123_user, which will allow a statistically even shard size across the full 16 character range of the first character. As more performance is needed, S3 will automatically shard the second character into 16x16 (256) possible shards, etc.

Also, using a more limited character set such as hexadecimal (that is, [[a-f][0-8]]*) (or just numberic digits) for the first characters of a filename will shard more evenly than a full alphanumeric [A-z][0-9][etc].

Jeff Barr had a blog post on this a while ago.. here it is:

https://aws.amazon.com/blogs/aws/amazon-s3-performance-tips-...

"By the way: two or three prefix characters in your hash are really all you need: here’s why. If we target conservative targets of 100 operations per second and 20 million stored objects per partition, a four character hex hash partition set in a bucket or sub-bucket namespace could theoretically grow to support millions of operations per second and over a trillion unique keys before we’d need a fifth character in the hash."

We actually do exactly this in Userify (blatant plug, SSH key management, sudo, etc https://userify.com) by just switching the ID type to the end of the string: company_[shortuuid] becomes [shortuuid]_company. It makes full bucket scans for a single keyname a bit easier and faster if you use different buckets for each type of data, but you actually will get better sharding overall by mixing all of your data types together in a single bucket. The trade-off is worth it for the general case.

Post reply on HN