本文来自开源云中文社区。
元数据过去对数据中心架构的影响很小。元数据是关于数据的数据，这些数据被隐藏在某个地方进行检索和分析，对操作几乎没有影响。随着大数据、人工智能、物联网和5G应用程序的扩展，积累了大量元数据，数据和元数据之间的传统关系已经被颠覆。
十年前，数据和元数据之间的典型比率是1000:1。例如，大小为32K的数据单元（文件、块或对象）的元数据大约为32字节。现有的数据引擎能够非常有效地处理这些数据量。今天，当对象很小时，比率通常更接近1:10。许多组织现在发现，他们的元数据超过了存储的数据量，而且随着非结构化数据量的持续爆炸，情况只会变得更糟。
元数据的激增引发了以下问题：在何处存储元数据，如何有效管理元数据，最重要的是，如何扩展底层架构以支持快速增长的元数据量以及快速扩展的系统。除非元数据扩展问题得到充分解决，否则保存元数据的系统最终将遇到可能影响业务运营和性能的问题。
缩放元数据的四个答案
在处理元数据时，无法有效地应用通过添加更多计算资源和/或实施各种解决方案来监控和优化IT堆栈不同层来解决可伸缩性和性能问题的传统方法。
组织通常使用键值存储（KVS）来管理元数据，如RocksDB，它依赖于存储引擎（也称为数据引擎），数据引擎是软件堆栈中对数据进行排序和索引的部分。
然而，现有的数据引擎存在着容量有限、CPU利用率高和内存消耗大等固有的缺点，这无法通过简单地增加计算能力来解决。通常，一系列操作任务从这一点开始，其中很少有提出有效的长期解决方案。
切分——此过程将数据集拆分为逻辑块，并同时运行多个数据集。这是处理高度可伸缩系统生成的元数据的一种方法（至少在短期内是这样）。然而，随着流入系统的数据量的不断增加，最初的分片计划经常会中断，开发人员必须不断地重新分片，从而成为自己的一项活动。
数据库优化——即使使用灵活高效的NoSQL数据库，开发人员也常常难以为遇到需要优化的性能问题的应用程序创建特殊的配置。然而，如果工作负载或底层系统发生变化，这些实例就会遇到更多更大的性能问题。随着应用程序的规模和复杂性的增长，这可能会建立一个似乎无休止的进一步重新调整循环，从而消耗开发人员的时间。
数据引擎优化——存储管理的基本操作通常由数据引擎（又名存储引擎）执行。数据引擎作为应用程序层和存储层之间的软件层安装，是一个嵌入式键值存储（KVS），用于对数据进行排序和索引。此外，KVS越来越多地被实现为应用程序中的软件层，以便在传输过程中对实时数据执行不同的动态活动。这种类型的部署通常旨在管理元数据密集型工作负载，并防止可能导致性能问题的元数据访问瓶颈。
数据引擎是一种复杂的结构，组织通常会发现，在根据特定的性能和可伸缩性要求在应用程序的引擎罩下调整和配置数据引擎时，存在技能差距。即使是熟练的开发人员也可能难以实现这一点。
添加资源——解决任何性能问题的由来已久的答案就是为问题投入额外的存储资源。这通常被证明是一个暂时的解决方案，其成本无法长期维持。
新选项
意识到当前的数据架构不再能够支持现代企业的需求，这促使人们需要从头开始设计新的数据引擎，以跟上元数据的增长。但是，随着开发人员开始深入研究数据引擎，他们面临的挑战是实现更大的规模，同时又不会影响存储性能、灵活性和成本效益。这就需要一种新的架构来支撑新一代的数据引擎，该引擎可以有效地处理元数据海啸，同时确保应用程序能够快速访问元数据。
新一代数据引擎可能是以数据密集型工作负载为特征的新兴用例的关键推动者，这些数据密集型工作负载需要前所未有的规模和性能。例如，实施适当的数据基础设施来存储和管理物联网数据对于智能城市计划的成功至关重要。此基础设施必须具有足够的可扩展性，以在不牺牲性能的情况下处理来自交通管理、安全、智能照明、废物管理和许多其他系统的不断增加的元数据。这对于对响应时间和延迟高度敏感的应用程序尤其重要，例如交通优化和智能停车。
元数据增长将继续加速，成为数据中心关注的问题，它跨越了越来越多的数据密集型用例。最近开放数据引擎进行创新的举措为专注于使应用程序能够扩展和增长的团队提供了选择。
原文链接：
https://thenewstack.io/how-to-manage-metadata-in-a-highly-scalable-system/
