NoSQL 数据建模错误会降低性能

数据建模错误是破坏性能的最简单方法之一。当您使用 NoSQL 时，特别容易搞砸，（讽刺的是）NoSQL 往往用于对性能最敏感的工作负载。NoSQL 数据建模最初可能看起来非常简单：只需对数据进行建模以适应应用程序的访问模式。但实际上，说起来容易做起来难。

修复数据建模并不有趣，但它通常是一种不可避免的罪恶。如果您的数据建模从根本上来说效率低下，那么一旦扩展到某个临界点（根据您的特定工作负载和部署而变化），您的性能就会受到影响。即使您在最强大的基础设施上采用最快的数据库，除非您的数据建模正确，否则您将无法充分发挥其潜力。

本文探讨了破坏 NoSQL 数据库性能的三种最常见方法，以及有关如何避免或解决这些问题的提示。

不处理大分区

当团队扩展其分布式数据库时，通常会出现大型分区。大型分区是指变得太大以至于开始在集群副本中引入性能问题的分区。

我们经常听到的问题之一（至少每月一次）是"什么构成了大分区？" 这得看情况。需要考虑的一些事项：

• 延迟预期：分区越大，检索所需的时间就越长。考虑页面大小以及完全扫描分区所需的客户端-服务器往返次数。
• 平均有效负载大小：较大的有效负载通常会导致较高的延迟。它们需要更多的服务器端处理时间来进行序列化和反序列化，并且还会产生更高的网络数据传输开销。
• 工作负载需求：某些工作负载自然需要比其他工作负载更大的负载。例如，我曾与一家 Web3 区块链公司合作，该公司将多个交易存储为单个密钥下的 BLOB，并且每个密钥的大小很容易超过 1 MB。
• 如何从这些分区中读取：例如，时间序列用例通常具有时间戳集群组件。在这种情况下，从特定时间窗口读取将检索到的数据比扫描整个分区要少得多。

下表说明了大分区在不同负载大小（例如 1、2 和 4 KB）下的影响。

正如您所看到的，在相同的行数下，您的有效负载越高，您的分区就越大。但是，如果您的用例经常需要扫描整个分区，那么请注意数据库有限制以防止无限制的内存消耗。例如，ScyllaDB 每 1MB 就切断页面，以防止系统可能耗尽内存。其他数据库（甚至是关系数据库）也有类似的保护机制，以防止无限的错误查询导致数据库资源匮乏。要使用 ScyllaDB 检索 4KB 的负载大小和 10K 行，您需要检索至少 40 个页面才能使用单个查询扫描分区。乍一看这似乎没什么大不了的。但是，随着时间的推移进行扩展，它可能会影响整体客户端尾部延迟。

另一个考虑因素：对于 ScyllaDB 和 Cassandra 等数据库，写入数据库的数据存储在提交日志中和称为"memtable"的内存数据结构下。

提交日志是一种预写日志，除非服务器崩溃或服务中断，否则永远不会真正读取它。由于内存表存在于内存中，因此它最终会变满。为了释放内存空间，数据库将内存表刷新到磁盘。该过程会产生 SSTable（排序字符串表），这就是数据持久化的方式。

这一切与大分区有什么关系？嗯，SSTables 有特定的组件，需要在数据库启动时保存在内存中。这可确保读取始终高效，并最大限度地减少查找数据时存储磁盘 I/O 的浪费。当您拥有非常大的分区时（例如，我们最近有一个用户在 ScyllaDB 中拥有 2.5 TB 的分区），这些 SSTable 组件会带来沉重的内存压力，从而缩小数据库的缓存空间并进一步限制延迟。

如何通过数据建模解决大型分区问题？基本上，是时候重新考虑你的主键了。主键决定数据如何在集群中分布，从而提高性能和资源利用率。一个好的分区键应该具有高基数和大致均匀的分布。例如，用户名、用户 ID 或传感器 ID 等高基数属性可能是一个很好的分区键。像"州"这样的州将是一个糟糕的选择，因为加利福尼亚州和德克萨斯州等州可能比怀俄明州和佛蒙特州等人口较少的州拥有更多的数据。

或者考虑这个例子。下表可用于具有多个传感器的分布式空气质量监测系统：

CREATE TABLE air_quality_data (
​
   sensor_id text,
​
   time timestamp,
​
   co_ppm int,
​
   PRIMARY KEY (sensor_id, time)
​
);

由于时间 是我们表的聚类键，因此很容易想象每个传感器的分区可能会变得非常大，特别是如果每几毫秒收集一次数据。这张看似无辜的桌子最终可能会变得无法使用。在此示例中，仅需要大约 50 天。

标准解决方案是修改数据模型以减少每个分区键的集群键数量。在这种情况下，我们来看看更新后的air_quality_data表：

CREATE TABLE air_quality_data (
​
   sensor_id text,
​
   date text,
​
   time timestamp,
​
   co_ppm int,
​
   PRIMARY KEY ((sensor_id, date), time)
​
);

更改后，一个分区保存一天收集的值，这使得它不太可能溢出。这种技术称为分桶，因为它允许我们控制分区中存储的数据量。

热点介绍

热点可能是大分区的副作用。如果您有一个大分区（存储大部分数据集），那么您的应用程序访问模式很可能会比其他分区更频繁地访问该分区。既然如此，它也成为热点。

只要有问题的数据访问模式导致集群中的数据访问方式不平衡，就会出现热点。罪魁祸首之一是应用程序未能对客户端施加任何限制，并允许租户潜在地向给定的密钥发送垃圾邮件。例如，考虑一下消息应用程序中的机器人经常在频道中发送垃圾邮件。不稳定的客户端配置也可能以重试风暴的形式引入热点。也就是说，客户端尝试查询特定数据，在数据库超时之前超时，并在数据库仍在处理前一个查询时重试查询。

监控仪表板应该可以让您轻松找到集群中的热点。例如，此仪表板显示分片 20 因读取而不堪重负。

再举一个例子，下图显示了三个利用率较高的分片，这与为相关键空间配置的三个分片的复制因子相关。

在这里，由于垃圾邮件，分片七引入了更高的负载。

如何解决热点问题？首先，在受影响的节点之一上使用供应商实用程序来对采样期间最常点击的键进行采样。您还可以使用跟踪（例如概率跟踪）来分析哪些查询正在命中哪些分片，然后从那里采取行动。

如果您发现热点，请考虑：

• 检查您的应用程序访问模式。您可能会发现需要更改数据建模，例如前面提到的分桶技术。如果需要排序，可以使用单调递增组件，例如 Snowflake。或者，也许最好应用并发限制器并限制潜在的不良行为者。
• 指定每个分区的速率限制，之后数据库将拒绝命中同一分区的任何查询。
• 确保客户端超时 高于服务器端超时，以防止客户端在服务器有机会处理查询之前重试查询（"重试风暴"）。

滥用集合

团队并不总是使用集合，但当他们使用集合时，他们经常会错误地使用它们。集合用于存储/反规范化相对少量的数据。它们本质上存储在单个单元中，这会使序列化/反序列化变得极其昂贵。

使用集合时，您可以定义相关字段是冻结还是非冻结。冻结集合只能作为一个整体来写；您不能从中添加或删除元素。可以附加非冻结集合，而这正是人们最常误用的集合类型。更糟糕的是，您甚至可以拥有嵌套集合，例如一个地图包含另一个地图，其中包含一个列表，等等。

例如，误用的集合会比大分区更快地引入性能问题。如果您关心性能，集合根本不能太大。例如，如果我们创建一个简单的键：值表，其中键是 sensor_id，值是随时间记录的样本集合，那么一旦开始提取数据，我们的性能将不是最佳的。

         CREATE TABLE IF NOT EXISTS {table} (
         ​               sensor_id uuid PRIMARY KEY,
         ​               events map<timestamp, FROZEN<map<text, int>>>,
         ​            )

以下监视快照显示了当您尝试一次将多个项目追加到集合时会发生什么情况。

您可以看到，虽然吞吐量下降，但 p99 延迟却增加。为什么会出现这种情况？

• 集合单元作为排序向量存储在内存中。
• 添加元素需要合并两个集合（旧的和新的）。
• 添加元素的成本与整个集合的大小成正比。
• 树（而不是向量）会提高性能，但是......
• 树会降低小集合的效率！

返回同一示例，解决方案是将时间戳移动到聚类键并将映射转换为 FROZEN 集合（因为您不再需要向其中附加数据）。这些非常简单的更改将极大地提高用例的性能。

    CREATE TABLE IF NOT EXISTS {table} (
    ​               sensor_id uuid,
    record_time timestamp,
    ​               events FROZEN<map<text, int>>,
    ​     PRIMARY KEY(sensor_id, record_time)​            )

作者：Felipe Mendes

更多技术干货请关注公号【云原生数据库】

squids.cn，云数据库RDS，迁移工具DBMotion，云备份DBTwin等数据库生态工具。

irds.cn，多数据库管理平台（私有云）。

​