为什么S3和谷歌存储桶名称的全局命名空间?全局、名称、空间

2023-09-11 23:39:57 作者:失去的温暖乱人心 °

这有我的疑惑。我能理解帐户ID的是全球性的,但为什么斗的名字呢?那岂不是更有意义碰到这样的:

https://accountID.storageservice.com/bucketName

这将命名空间帐户ID下的桶。

我在想什么,为什么这些明显的精英设计师选择处理桶的名字就这样?

解决方案   

“斗命名空间是全球性的 - 就像域名”的

     

— http://aws.amazon.com/articles/1109#02

这不仅仅是巧合。

原因似乎很简单:水桶和他们的对象可以通过自定义主机名是相同的桶名称访问...并且可以选择托管整个静态网站

入门 命名空间

在S3中,这三个URL中的斗bucket.example.com引用同一个对象上面的foo.txt。第一个适用于静态网站托管启用,并且需要一个DNS CNAME (或别名在路线53);别人不需要的配置:

  http://bucket.example.com/foo.txt
http://bucket.example.com.s3.amazonaws.com/foo.txt
http://s3.amazonaws.com/bucket.example.com/foo.txt
 

如果一个对象存储服务需要一种简单的机制来解决主持人:在HTTP传入的请求到水桶名头,桶的名字命名空间也需要全球。别的,现在看来,将显著复杂的实施。

有关主机名是可映射到斗名,的东西的必须是全球唯一的,因为显然没有任何两个水桶能以相同的主机名作出回应。该限制被施加到水桶名称本身没有留下余地歧义。

这也很可能是很多潜在的客户不希望在斗名他们的帐户标识。

This has me puzzled. I could understand account ID's being global, but why bucket names? Wouldn't it make more sense to have something like:

https://accountID.storageservice.com/bucketName

Which would namespace buckets under accountID.

What am I missing, why did these obviously elite architects choose to handle bucket names this way?

解决方案

“The bucket namespace is global - just like domain names”

— http://aws.amazon.com/articles/1109#02

That's more than coincidental.

The reason seems simple enough: buckets and their objects can be accessed through a custom hostname that's the same as the bucket name... and can optionally host entire static web sites.

In S3, these three URLs reference the same object "foo.txt" in the bucket "bucket.example.com". The first one works with static website hosting enabled and requires a DNS CNAME (or Alias in Route 53); the others require no configuration:

http://bucket.example.com/foo.txt
http://bucket.example.com.s3.amazonaws.com/foo.txt
http://s3.amazonaws.com/bucket.example.com/foo.txt   

If an object store service needs a simple mechanism to resolve the Host: header in an HTTP incoming request into a bucket name, the bucket name namespace also needs to be global. Anything else, it seems, would complicate the implementation significantly.

For hostnames to be mappable to bucket names, something has to be globally unique, since obviously no two buckets could respond to the same hostname. The restriction being applied to the bucket name itself leaves no room for ambiguity.

It also seems likely that many potential clients wouldn't like to have their account identified in bucket names.