元数据管理是任何商业应用的一个关键部分。让我们快速看一下什么是元数据，为什么它很重要，以及你如何架构你的应用程序以确保在规模上高度可用、一致的元数据。
简单地说，元数据是关于其他数据的数据。
例如，考虑一个云照片存储应用程序。当用户上传照片时，图像文件本身可能被存储在对象存储数据库中，但应用程序也需要在元数据数据库中存储元数据--关于图像的较小数据。这个元数据将包括一些细节，例如。
- 上传照片的用户
- 照片上传的日期
- 照片的大小和分辨率
- 用户在照片中标记的人物或物体
- 任何用户对照片的描述或说明
- 该照片在对象存储数据库中的位置
...诸如此类。这些元数据对企业来说是非常有价值的，因为它们使其他数据更容易找到。
例如，有了上面列出的元数据，就可以很容易快速找到一个特定用户的所有照片。应用程序不必在对象存储数据库中搜索所有的图像文件，而是可以在元数据数据库中查询有特定用户的所有条目，然后它将有一个该特定用户上传的每个文件的位置列表。
在许多情况下，元数据的可用性对一个应用程序的功能至关重要。例如，我们的云照片存储应用程序将使用元数据来促进定位、排序和过滤照片。如果元数据数据库离线，照片仍然存在于应用程序的对象存储数据库中，但它们将无法被用户访问，因为应用程序将缺乏必要的元数据来定位该数据库中的特定照片。
一致性是公司在构建元数据管理系统时产生的另一个主要问题。元数据经常在多个数据库中重复使用--例如，相同的元数据可能同时存储在为应用程序服务的元数据数据库和用于分析、日志、审计合规性等的单独数据库中。公司必须确保这两个（或更多）数据库上的数据保持一致；如果出现不一致，就很难确定哪个数据库是正确的（这又会对审计、法规遵从等产生严重影响）。
跨区域的一致性也是多区域应用的一个重要考虑因素--如果一个区域发生故障，其他区域仍然需要访问正确的元数据，以便能够正常运行。此外，如果各区域之间不一致，灾难恢复就会变得非常具有挑战性。
让我们来看看一个简单的例子，这个应用程序处理元数据时不必担心可用性或一致性的问题。
在下图中，我们列出了一个简单的例子，说明一个微服务架构的应用如何整合CockroachDB作为元数据存储。请注意，我们在这里选择了多区域架构，因为多区域设置在用户延迟和（在某些情况下）法规遵从方面都有固有的优势。
请注意，在上面的图片中，为了视觉上的清晰，每个集群只有三个服务和一个数据库。真正的应用可能会有更多的服务，而且这些服务也会向其他数据库发送数据，而不仅仅是元数据数据库。例如，在一个照片存储应用中，图像文件本身可能会被发送到一个为大型对象存储而优化的不同数据库。
来自前端（可能是网络或移动应用程序）的请求和数据被发送到负载平衡器，该负载平衡器将它们分配到适当的Kubernetes集群，在那里它们被应用程序的微服务处理。
CockroachDB可以在Kubernetes中部署和管理（而不仅仅是在Kubernetes旁边），并像单实例Postgres数据库一样对待。但与单实例Postgres数据库不同，CockroachDB是分布式的，所以即使一个数据库节点离线，所有元数据仍然可以通过其他节点访问。事实上，根据它的配置方式，CockroachDB可以在AZ甚至云区域的中断中生存。
在上面的架构中，我们通过两种方式解决了为多区域应用构建元数据存储时固有的潜在一致性问题。
首先，为了解决双写问题可能产生的一致性问题，我们使用CockroachDB的变化数据捕获（CDC）功能，将元数据复制到Apache Kafka（或任何消息队列系统），然后再复制到分析数据库。我们可以在一个不包括CDC的数据库上使用事务性发件箱来完成同样的事情。
其次，为了解决多区域可能出现的一致性问题，我们利用了CockroachDB的多活动可用性模型，它避免了主动-被动和主动-主动配置中固有的一些问题，并允许跨区域的同步和高性能写入。
这里选择CockroachDB也为开发者提供了一条通往多区域的便捷之路，因为多区域的CockroachDB数据库仍然可以被应用程序视为一个单一的逻辑数据库。这确保了我们的元数据将是高度可用的，也允许 "数据归位 "到行级别，这对延迟（将数据定位在离用户最近的云区域）和监管合规都有帮助。
当然，现实世界的元数据架构可以变得更加复杂。在为你自己的应用设计架构时，看看公开的例子可能会有帮助，比如Netflix的设备管理架构，它使用CockroachDB来存储与Netflix应用兼容的所有不同硬件设备有关的元数据。
