导致数据库磨损的不是数据，而是元数据。与此同时，用于描述和通知其他数据的元数据的数量急剧增长。虽然元数据一直存在，但它曾经存储在内存中和幕后，其大小只是今天的一小部分。十年前，数据和元数据之间的典型比例是1000:1。这意味着大小为32k的数据单元（文件、块或对象）具有大约32字节的元数据。现有的数据引擎可以非常有效地处理这些数据量。然而，数据和元数据之间的比例已经发生了显着变化，如今根据对象大小，比例可以从1000:1到1:10不等。元数据的爆炸式增长对我们的数据基础架构产生了直接而巨大的影响。随着云应用程序、云基础设施服务、物联网、大数据分析和其他数据密集型工作负载的大规模采用，非结构化数据量在未来几年只会继续增长，而当前的数据架构不能满足现代商业需求。为了迎接不断增长的元数据的挑战，我们需要一种新的架构来支持新一代的数据引擎，以有效地处理元数据的激增，同时允许应用程序快速访问元数据。了解元数据：沉默的数据引擎杀手无论是SQL还是NoSQL，每个数据库系统都使用存储引擎或数据引擎（无论是否嵌入）来管理数据的存储方式。在我们的日常生活中，我们很少关注这些让世界运转的引擎，通常只有在它们突然失效时才会注意到它们。同样，我们大多数人直到最近才听说过“数据引擎”一词。他们运行我们的数据库、存储系统，以及基本上任何处理大量数据的应用程序。就像汽车引擎一样，我们似乎只有在它们发生故障时才会意识到它们。毕竟，我们不会期望汽车发动机为大卡车提供动力，并且在某些时候它会在压力下破裂。那么是什么导致了数据引擎负担的加重呢？主要原因是数据增长速度过快。尤其是元数据，简直就是无声的数据引擎杀手。元数据是指关于数据的任何信息，例如使查找和处理数据更容易的索引，这意味着元数据没有预先固定的模式来适应数据库（通常是键值格式）；相反，它是由各种系统和设备创建的通用数据创建的。这些需要存储在某个地方并且通常隐藏在缓存RAM内存中的数据变得越来越大。除了文档和音频/视频文件等非结构化数据量不断增加之外，连接设备和物联网传感器的快速发展也导致元数据量的增加，并且这种趋势将逐渐加速。数据本身通常很小（例如来自传感器的字母数字读数），但伴随着大量的元数据（位置、时间戳、描述），这些元数据甚至可能比数据本身更大。现有数据引擎基于无法支持现代数据集规模的架构。为了跟上不断增长的数据量，它们已经被推到了极限。这包括基于SQL的键值存储、时间序列数据，甚至是像MongoDB这样的非结构化数据引擎。它们都使用一个底层存储引擎（无论是否嵌入），该引擎并非为支持当今的数据大小而构建。由于元数据更大并且暴露了对底层媒体的内存不足访问可能会很慢并影响性能。对应用程序的性能影响直接取决于数据大小和对象数量。随着这种趋势的继续，数据引擎必须适应才能有效支持现代企业的元数据处理和管理需求。数据引擎的底层数据引擎作为应用程序层和存储层之间的软件层安装，是一个嵌入式键值存储(KVS)，用于对数据进行排序和索引。从历史上看，数据引擎主要用于处理存储管理的基本操作，尤其是创建、读取、更新和删除(CRUD)数据。如今，KVS越来越多地作为应用程序中的软件层实施，以在传输过程中对实时数据执行各种即时活动。虽然现有的数据引擎（如RocksDB）正用于处理CRUD之外的应用程序内操作，但它们仍然受到设计的限制。这种类型的部署通常旨在管理元数据密集型工作负载并防止可能导致性能问题的元数据访问瓶颈。随着KVS超越其作为存储引擎的传统角色，术语“数据引擎”被用来描述更广泛的用例。传统的KVS基于为快速写入速度或快速读取速度而优化的数据结构。为了将元数据存储在内存中，数据引擎通常采用基于日志结构合并树（LSM树）的KVS。基于LSM树的KVS相对于B树（KVS中另一种流行的数据结构）的优势在于，由于使用了不可变的SST文件，它可以非常快速地存储数据而无需更改数据结构。虽然可以调整现有的KVS数据结构以获得足够好的写入和读取速度，但它们无法同时为这两种操作提供高性能。当您的数据引擎过热时随着数据引擎越来越多地用于处理和映射数万亿个对象，传统KVS的局限性变得显而易见。基于LSM的KVS虽然比传统关系型数据库具有更高的灵活性和速度，但由于写入放大率高，容量有限，CPU利用率和内存消耗高，影响其固态存储介质的性能。开发人员必须在写入性能和读取性能之间做出权衡。然而，配置KVS以满足这些要求不仅是一项长期任务，而且由于其内部结构复杂，也将是一项具有挑战性和劳动强度大的工作。为了维持生计，应用程序开发人员会发现自己花费越来越多的时间来处理分片、数据库调优和其他耗时的操作任务。这些限制将迫使许多缺乏开发人员资源的组织使用不满足数据引擎需求的默认设置。显然，这种方法不能长期持续。由于现有KVS产品的固有缺陷，当前可用的数据引擎难以在保持足够性能的同时进行扩展，更不用说以经济高效的方式进行扩展了。一种新的数据架构认??识到元数据生成的问题和当前数据引擎的局限性，促使我们创建了Speedb，这是一种可大规模提供更快性能的数据引擎。我和我的合作伙伴认识到我们当前数据架构的局限性，并决定从头开始构建一个新的数据引擎来处理元数据爆炸，避免在可伸缩性、性能和成本之间进行权衡，同时提供卓越的读写速度。为此，我们重新设计了KVS的基础组件。我们开发了一种新的压缩方法，可以显着降低大规模LSM的写入放大；一种新的流量控制机制，可以消除用户延迟中的峰值；每个对象最多占用3个字节，可大规模提供极高的性能。Speedb是一款兼容RocksDB存储引擎的嵌入式解决方案，可以满足云规模日益增长的高性能需求。元数据的增长并未放缓，但有了这种新架构，我们至少能够满足需求。译者介绍杨小娟，51CTO社区编辑，西安电子科技大学计算机专业硕士研究生，高级研发工程师，信息系统项目经理，近20年Java开发经验。在NEC、Oracle、英方从事过Oracle数据库的数据存储、数据迁移、同构/异构数据库复制工作，尤其对数据库和数据编码有深入的学习和理解。原标题：拖累你数据库的是元数据，不是数据，作者：AdiGelvan
