审校 | 孙淑娟
元数据过去对数据中心架构的影响很小。元数据是有关数据的数据，隐藏在某个地方以便检索和分析，对业务运营几乎没什么影响。随着大数据、人工智能、物联网和5G等应用系统规模扩大，它们积累了众多元数据，现在数据和元数据之间的传统关系已被颠覆。
十年前，数据和元数据的典型比率是1000：1。比如说，大小为32K的数据单元（文件、块或对象）将有大约32个字节的元数据。现有的数据引擎能够非常有效地处理这些数量的数据。如今，对象很小时，这个比率通常更像是1：10。许多组织现在发现元数据超过了所存储的数据量；随着非结构化数据的数量持续猛增，情形只会变得更糟。
元数据激增的这种状况引发了这些方面的问题：将元数据存储在何处、如何有效管理，最重要的是如何扩展底层架构以支持快速增长的元数据量和快速扩展的系统。除非元数据扩展问题得到了充分解决，否则保存元数据的系统最终会遇到可能影响业务运营和性能的问题。
扩展元数据的四个解决之道
处理元数据时，无法有效地运用这种传统做法：添加更多的计算资源及/或实施各种解决方案来监控和优化IT堆栈的不同层，从而解决可扩展性和性能问题。
组织通常使用RocksDB之类的键值存储（KVS）系统来管理元数据，KVS系统依赖存储引擎（又叫数据引擎），是对数据进行排序和索引的软件堆栈的一部分。
然而现有的数据引擎存在容量有限、CPU利用率高和内存消耗大等先天不足，这些都是无法通过单单添加计算能力就能解决的。通常，一系列运营任务在此时开始，其中很少有有效的长期解决方案。
1. 分片——该过程将数据集拆分为逻辑片段，并同时运行多个数据集。这是处理高度可扩展系统生成的元数据的一种方法——至少在短期内如此。然而，随着越来越多的数据流入系统，最初的分片方案常常出问题，在开发人员必须不断重新分片的情况下开始暴露出来，本身成为一项活动。
2. 数据库调优——即便使用灵活高效的NoSQL数据库，开发人员也常常难以为遇到需要调优的性能问题的应用程序专门创建不寻常的配置。如果工作负载或底层系统发生变化，这些实例就会遇到额外的、更大的性能问题。随着应用系统越来越庞大、越来越复杂，这可能会带来看似无穷无尽的进一步重新调优的循环，结果耗费开发人员的时间。
3. 数据引擎调优——存储管理的基本操作通常由数据引擎（即存储引擎）执行。数据引擎作为应用程序和存储层之间的软件层加以安装，这是一种嵌入式键值存储（KVS），用于对数据进行排序和索引。此外，KVS日益作为应用程序内部的软件层加以实施，以便在传输过程中对实时数据执行不同的动态活动。这种类型的部署常常旨在管理元数据密集型工作负载，并防止可能导致性能问题的元数据访问瓶颈。
数据引擎是复杂的构件，组织常常发现在根据特定的性能和可扩展性要求，调整和配置应用程序底部的数据引擎方面存在技能方面的缺口。就连熟练的开发人员也难以克服这一点。
4. 添加资源——解决任何性能问题的传统方法案都是添加额外的存储资源以解决问题。这常常是一种权宜之计，成本无以为继。
新的方法
当前的数据架构再也不能支持现代企业的需求，这促使企业需要从头开始设计新数据引擎，以跟上元数据增长的步伐。但随着开发人员开始深入数据引擎的底层，他们面临这一挑战：在不影响存储性能、敏捷性和成本效益的情况下，实现更大的规模。这就需要一种新的架构来支持新一代数据引擎，该引擎可以有效地处理海量元数据，仍能确保应用程序可以快速访问元数据。
下一代数据引擎可能是新兴用例的关键赋能因素，这些用例的特点是数据密集型工作负载需要前所未有的规模和性能。比如说，实施适当的数据基础设施来存储和管理物联网数据对于智慧城市项目的成功至关重要。该基础设施必须有足够的可扩展性，以便在不牺牲性能的情况下，处理来自交通管理、安全、智能照明、废物管理及许多其他系统的不断增多的元数据。这对响应时间和延迟高度敏感的应用程序而言尤为重要，比如交通优化和智能泊车。
元数据增长将继续是数据中心面临的问题，涉及越来越多的各种数据密集型用例。最近加大数据引擎创新力度的举措为致力于使应用程序能够扩展和增长的团队提供了选择。
原文How to Manage Metadata in a Highly Scalable System，作者：Adi Gelvan
