拖垮数据库的不是数据，而是元数据

译者 | 杨晓娟

审校 | 梁策 孙淑娟

近年来，由于连接设备和物联网 (IoT) 不断发展，数据量呈指数级增加。与此同时，用来描述和提供其他数据信息的元数据也增长惊人。尽管元数据一直存在，但由于其规模只是如今的一小部分，因此曾一度被存储于内存及幕后。

十年前，数据和元数据之间的典型比率是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数据库的数据迁移以及同构/异构数据库复制等研发工作，尤其在数据库、数据编码等方面有深入钻研和了解。

原文标题：​​metadata, not data, is what drags your database down​​，作者：Adi Gelvan