原文地址：https://dzone.com/articles/debunking-four-myths-on-metadata
原文作者：Adi Gelvan
本文是关于元数据的四个误区，如果被忽视，可能会导致数据引擎这类的噩梦。为了更好地面对这些挑战，是时候揭露这些神话了！
由于非结构化数据的增长，数据量正在以惊人的速度激增。元数据，可以让我们通过标识某些属性来快速查找数据文件。直到最近，因为元数据对我们的数据引擎产生了颠覆性的影响，开发人员才不得不更关注此问题。元数据过去只是一个可以毫无顾虑地存储在内存中的信息，但现在，它的扩充速度使人们越来越关注它应该存在哪里以及如何管理它。
每个数据库系统，无论是SQL还是NoSQL，都使用数据库引擎（也称为存储引擎，无论是否嵌入）来管理数据存储。但是我们不断增长的数据量已经超出了存储引擎可承受范围内的基础配置，因此，存储引擎性能被扩展到极限，并被迫做出权衡，以支持现代数据集的规模和性能要求。
为了使我们的存储引擎平稳运行，我们必须了解元数据是如何影响它们的，以便将来进行正确的实践。本文介绍了有关元数据的一些最常见的神话。
神话 1：元数据不会占用太多存储空间
不被我们熟知的是，元数据占用的存储空间比人们想象的要大的多。由于非结构化数据（如文档、多媒体文件、物联网和传感器数据）的体量大，元数据在过去十年中显著增长。近年来增长最快的数据部分是以对象形式存储的非结构化数据，据估计，到2021年，全球可能80%的数据是非结构化的。
对象数据和元数据的比率过去约为1000：1。然而，随着过去十年数据的急剧增长，这一比率已经明显倾向于元数据。例如，大小为20K的对象可能有大约20个字节的元数据。因此元数据所占用的存储空间不再是微不足道的，在使用存储引擎时，元数据应该处于开发人员讨论的最前沿。
神话 2：元数据增长不会影响应用程序性能
处理增长的元数据量，最常见方法之一是将存储引擎实现在应用程序中的软件层，以对实时的元数据执行不同的动态活动。以嵌入式键值存储（KVS）部署，存储引擎通常使用日志结构的合并树（或LSM树）架构。与传统的关系数据库相比，这种方式灵活性更高，且速度更快，但是，由于高写入扩大，基于LSM树的KVS具有有限的容量，高的CPU利用率、和内存消耗。这会导致数据瓶颈，从而影响应用程序性能。
这就是开发人员的用武之地。当现有的存储引擎解决方案面临此问题时，开发人员被迫采用分片等解决方法，使用分片的地方解决了瓶颈，性能得到提高，但代价是产生了其他限制，例如可伸缩性可能会降低。
神话 3：元数据易于管理
不幸的是，当元数据增加时，现有的存储引擎无法自行管理。为了保持正常运行，应用程序开发人员发现自己需要花费越来越多的时间处理分片、进行数据库调优和其他耗时的操作任务，而不是提供真正的商业价值。且执行这些任务不是一次性的，而是需要持续监控的事情。这些繁琐的任务将成为开发人员日常工作的一部分，以确保系统继续以高性能标准运行，而不是专注于提供真正的商业价值。通常，当组织机构中没有足够熟练的开发人员来管理工作负载时，他们会倾向于使用默认设置，这些设置不会把问题拖太久。
神话 4：所有存储引擎都可以存储无限量的元数据，而无需做出牺牲
无论您选择使用哪种数据库系统，都需要存储引擎来管理数据存储。随着元数据的不断增长，现有的数据引擎可以不同的方式存储数据，每种方式都迫使人们在不同的问题上进行权衡，无论是容量、可伸缩性、成本还是性能。如果牺牲性能对我们的业务来说不是一种必要选择，那么现有的解决方案将使我们支付更多的钱，特别是对于超大规模的数据操作。或者，如果选择了像RocksDB这样经济高效的解决方案，那么我们必须学会管理I/O挂起、减小性能影响。
结束语
元数据正在以惊人的速度增长，且没有放缓的迹象。它凸显了我们当前技术的局限性，尤其是数据引擎。不要让这些神话蒙蔽我们的双眼，因为从选择正确的存储引擎开始，认识到我们可能面临的问题并直面问题至关重要。现在考虑这一点将确保以后生产线上的业务不会超负荷运行。
- 参考链接：元数据在非结构化数据管理中的价值
