对象标签和对象元数据之间的区别? [英] Difference between object tags and object metadata?
问题描述
我正在寻找一种在上传过程中将小块数据(来自服务器)与对象一起包含的方法(例如，用户ID，文件ID等).在查看了S3文档之后，我不确定将这些数据作为对象标记或对象元数据包括进来是否更合适.
I'm looking for a way to include small pieces of data (from my server) with objects during the upload process (e.g. User ID, File ID, etc). After looking at S3 documentation, I'm not sure whether it's more appropriate to include this data as object tags or object metadata.
标签的用途是分类吗?还有每个对象数据的元数据?
Is the purpose of tags for categorization? And metadata for per-object data?
有什么区别?您认为哪种方式更适合这种情况?
What are the differences? What do you think would be more appropriate for this situation?
推荐答案
元数据和标签本质上都是元数据"，但是在如何使用(或不能使用)它们来修改服务行为方面存在重要差异.以及如何(或不能)访问它们的值.
Both metadata and tags are essentially "metadata" but there are important differences in how they can (or can't) be used to modify the behavior of the service and how their values can (or can't) be accessed.
严格来说，S3中的对象(包括其元数据)是不可变的.控制台使您能够编辑"元数据，但这并不是正在发生的事情的精确描述.编辑对象的元数据时，实际上是使用对象本身的副本覆盖了对象，并修改了其元数据.如果存储分区是版本控制的，那么您现在将拥有该对象的两个副本，其中包含两个不同的日期和已修改的元数据.
An object in S3, including its metadata, is -- strictly speaking -- immutable. The console gives you the ability to "edit" metadata, but that's not a precise description of what's happening. When you edit an object's metadata, you are actually overwriting the object with a copy of itself, with its metadata modified. If the bucket is versioned, you now have two copies of the object with two different dates and modified metadata.
标签是一种子资源"，从某种意义上说，是偏离对象"的一种，它们是分开管理的，可以在不修改对象本身的情况下进行修改.
Tags are a "subresource" -- in a sense, "off to the side" of an object -- they are managed separately and can be modified without modifying the object itself.
元数据作为HTTP标头包含在PUT请求中. 通过发送第二个请求来存储标签.完全支持不超过数量和大小限制的标签(如下所示)，需要向API端点上的?tagging子资源发送第二个请求，但是x-amz-tagging HTTP PUT请求标头中提交最多2K的url编码，查询参数样式的标记键和值.例如，x-amz-tagging: hipaa_restrict=false&pci_restrict=true&owner=Accounting%20and%20Payroll.关于2K是否包含标头名称本身的字节长度，还是2K与x-amz-meta-*用户元数据标签相同的2K，文档尚不清楚.大概这是两个不同的2K限制，但是2K标签限制可能包括键和值的URL编码形式以及标头的长度.
Metadata is included in the PUT request as HTTP headers when the object is created. Tags are stored by sending a second request. Full support for tags up to the count and size limits, below, requires sending a second request to the ?tagging subresource on the API endpoint, but the PUT (Object) REST call also has limited support for tags, allowing up to 2K of url-encoded, query parameter-style tag keys and values to be submitted in a single x-amz-tagging HTTP PUT request header. For example, x-amz-tagging: hipaa_restrict=false&pci_restrict=true&owner=Accounting%20and%20Payroll. The documentation is unclear with regard to whether the 2K includes the byte length of the header name, itself, or whether this 2K is the same 2K as the x-amz-meta-* user metadata tags. Presumably, it's two different 2K limits, but the 2K tag limit likely includes the url-encoded form of the keys and values, as well as the length of the header.
您可以通过策略分别控制IAM用户是否可以读取或写入对象+元数据或标签.对象和元数据在权限中一起处理(如果可以执行，则始终可以对其他权限进行处理)，但是标记是单独的权限.
You can control, separately via policy, whether an IAM user can read or write objects+metadata or tags. Objects and metadata are handled together in permissions (if you can do one, you can always to the other) but tags are separate permissions.
当您GET一个对象时，实际的元数据将在HTTP响应标头中返回.这意味着下载对象的用户如果知道如何检查HTTP标头，则可以看到元数据.
When you GET an object, the actual metadata is returned in the HTTP response headers. This means a user downloading an object can see the metadata if they know how to inspect the HTTP headers.
请求不会在标头中返回标签.相反，仅返回x-amz-tagging-count:标头，如果该对象的标签数量非零，则报告该数量.但是请注意，虽然标签更适合存储专有数据，但它们不适合存储未加密的敏感数据.
Conversely, tags are not returned in the headers in response to a GET request; instead, only the x-amz-tagging-count: header is returned, reporting the number of tags on the object if it is non-zero. Note, however, that while tags are more appropriate for storing proprietary data, they are not appropriate for storing unencrypted sensitive data.
每个对象的所有元数据键和值的总和为 2KB .请注意，限制以字节表示，因此多字节字符朝着限制消耗的每个字符多于一个字节.元数据密钥的数量没有限制-用户元数据的总限制为2KB. 对象元数据键和值和元数据必须包含作为HTTP标头有效的字符，因为这是对象元数据的发送方式.
The total of all metadata keys and values for each object is limited to 2KB. Note that the limit is expressed in bytes, so multibyte characters consume more than one byte per character toward the limit. There is no limit on the number of metadata keys -- only the 2KB total limit for user metadata. Only US-ASCII characters are fully supported in object metadata keys and values and metadata must be comprised of characters that are valid as HTTP headers, since that's how object metadata is sent.
标签的限制不同.每个对象最多可以包含10个标签，每个标签键限制为128个字符(不是字节)，并且每个标签值限制为256个字符(不是字节)，如上所述，虽然这些限制较低，但是当标签与PUT请求一起骑行时，限制较低.与元数据不同，标签支持UTF-8.
The limits on tags are different. Each object can have up to 10 tags, each tag key is limited to 128 characters (not bytes), and each tag value is limited to 256 characters (not bytes), although the limits are lower, as noted above, when the tags ride along with the PUT request. Unlike metadata, tags support UTF-8.
元数据键和值被计为有助于对象存储的已计费大小的可计费字节.标签是通过不同的论坛单独计费的.
Metadata keys and values are counted as billable bytes contributing to the billed size of object storage. Tags are billed separately with a different forumula.
标签和元数据都不能用于扫描"对象.不能向S3服务请求带有特定标签或特定元数据的对象列表.
Neither tags nor metadata can be used for "scanning" objects. It is not possible to ask the S3 service for a list of objects with specific tags or with specific metadata.
标签可以至少通过两种重要的方式来修改服务的行为，而元数据则不能这样做(实际上，这可能是我目前未想到的其他方式):
Tags can be used to modify the behavior of the service in at least two important ways that metadata cannot (and, in fact, here may be others that I'm not thinking of at the moment):
存储桶/用户/角色上的IAM策略可以测试标签值以进行访问控制，但不能测试元数据值.
有IAM政策条件键，它允许对对象
There are IAM policy condition keys that allow access control on objects based on tags. There are no similar access control features based on metadata.
存储桶生命周期策略可以测试标记值，但不能测试元数据值.
生命周期策略可用于在可配置的时间间隔后，修改对象的存储类(以标准/不经常访问或冰川形式)或清除对象或版本.在引入对象标签之前，这些规则适用于整个存储桶或特定的前缀，例如images/.现在，标签允许基于对象标签应用生命周期策略，因此(例如)可以将瞬态数据与性能数据混合，同时以不同的方式应用生命周期策略，而无需将对象存储在不同的关键字层次结构中以进行前缀匹配.
Lifecycle policies can be used to modify an object's storage class (to standard/infrequent-access or glacier) or purge objects or versions after a configurable time interval. Before the introduction of object tags, these rules applied either to the entire bucket or to a certain prefix, such as images/. Now, tags allow lifecycle policies to be applied based on object tags, so (for example) transient data can be mixed with permament data while applying lifecycle policies differently without the need to store the objects in different key hierarchies for prefix matching.
在问题所述的情况下，除非您认为安全性在HTTP响应标头中可见，否则我倾向于将这些值存储在元数据中.
In the situation described in the question, I would be inclined to store these values in metadata unless the fact that they are visible in HTTP response headers is something you see as a security concern.
如果您将S3与CloudFront结合使用，则可以使用 Lambda @ Edge原点响应触发器，用于在进行中的编辑中删除或删除对象元数据，以使浏览器看不到它们.源响应触发器是用Node.js编写的Lambda函数，可以在将响应存储在CloudFront缓存中之前以编程方式修改响应，这意味着它仅需要在缓存未命中时运行.通过将请求通过EC2中的代理服务器(例如HAProxy或Nginx)通过路由到存储桶的方式也可以实现类似的功能，但是如果直接访问存储桶则不能. S3服务将始终返回HTTP响应标头中的元数据，但是在下载对象时，它仅返回标签计数(如果对象具有标签)，而不返回标签本身.
If you are using S3 in conjunction with CloudFront, you can use a Lambda@Edge Origin Response trigger to redact or delete the object metadata from responses in-flight so they are not visible to the browser. An Origin Response trigger is a Lambda function written in Node.js that can programmatically modify responses before they are stored in the CloudFront cache, which means it only needs to run on cache misses. Similar functionality can also be accomplished by routing requests to the bucket through a proxy server in EC2 such as HAProxy or Nginx, but not if the bucket is accessed directly. The S3 service will always return the metadata in the HTTP response headers, but it only returns a count of tags (if the object has tags) and not the tags themselves, when an object is downloaded.
这篇关于对象标签和对象元数据之间的区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
