简介这是一份聚焦ScyllaDB NoSQL数据库性能优化与落地实践的PDF资料适合数据库架构师、后端开发及运维人员阅读。文档梳理了ScyllaDB的起源、设计理念及高吞吐低延迟特性重点介绍其shard-per-core架构、自动调优与动态调度机制并对比传统Cassandra在多核利用、GC延迟、配置维护方面的不足。同时结合Outbrain实际案例展示无缓存直连Scylla后带来的请求量、延迟及硬件成本改善对需要处理大规模实时数据的场景有较强参考价值。包体为单个PDF文件大小1.24MB内容精炼但覆盖概念、对比与案例。目前已有95人学习便于想快速了解ScyllaDB应用加速方案、评估其替换或补充Cassandra可行性的技术人群取用。1. ScyllaDB NoSQL 应用加速的真相不是换个数据库那么简单很多团队把应用迁到 ScyllaDB 之后第一反应是给查询加二级索引、在数据库前面堆缓存中间层结果延迟没有降下来甚至比原来的 MongoDB 或 Cassandra 还差。ScyllaDB 是一个兼容 Cassandra CQL 协议的 NoSQL 数据库底层用 C 和 Seastar 框架重新实现了数据路径每个 CPU 核心都管理自己的一部分数据分片没有 JVM GC 带来的“卡顿”。但引擎快只是必要条件应用能不能吃到这波红利取决于表结构、查询模式、连接池和内核参数是不是按它的运行方式设计。这篇文章面向想把 ScyllaDB 用出低延迟和高吞吐的工程师从分片架构、CQL 数据建模、集群参数到验证工具把一条可落地的应用加速路径拆开讲清楚。2. ScyllaDB 的加速根基分片感知架构与无 GC 数据路径2.1 shard-per-core把数据库拆进 CPU 核心ScyllaDB 与 Cassandra 最大的区别不在 CQL 语法层而在引擎层。ScyllaDB 基于 Seastar 框架用 C 实现启动时会把每个 CPU 核心映射成一个独立数据库分片每个分片单独拥有自己的 memtable、SSTable 缓存、网络队列和磁盘 IO 队列。分片之间不共享可变状态也就避免了传统数据库里那把所有线程都要抢的锁。因为每一条数据都有稳定的分区键ScyllaDB 能通过一致性哈希算出它属于哪个分片并且大概率由本节点某个 CPU 核心处理。CPU 不需要跨 NUMA 访问远端内存内存分配与释放走 Seastar 自带的内存分配器所以读一个分区时响应时间比 Cassandra 在高并发下稳定得多不会因为某次 Full GC 把整段请求卡住几百毫秒。nodetool status Datacenter: DC1 StatusUp/Down |/ StateNormal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 192.168.1.11 312.4 GB 256 33.6% aaaa... rack1 UN 192.168.1.12 305.7 GB 256 33.3% bbbb... rack1 UN 192.168.1.13 309.1 GB 256 33.3% cccc... rack1用nodetool status检查集群状态时Tokens列显示每个节点默认有 256 个虚拟节点。虚拟节点把环切得很细节点加入或退出时数据迁移的粒度小应用侧不会突然出现明显的请求延迟波峰。Owns (effective)是有效拥有率三节点时三端都在 33% 左右代表数据均衡。如果某个节点长期超过 40% 而其余只有 25%说明分区键或者 token 分配出了问题这种负载不均不是单纯加机器就能解决的。2.2 LSM-Tree 和 Compaction读放大、写放大的平衡点ScyllaDB 的存储引擎沿用 LSM-Tree 思路写入先落在内存表再冻结成不可变的 SSTable后台 compaction 负责合并和清理。读取时要按顺序查看多个 SSTable因此调整 compaction 策略本质是在调“读一次要检查多少个文件”的代价。策略典型场景对延迟的影响SizeTieredCompactionStrategy通用、写多读少小文件积压时读放大明显延迟尖刺LeveledCompactionStrategy读延迟敏感、更新频繁读路径文件数少但写放大更高写吞吐下降TimeWindowCompactionStrategy时间序列、历史按窗口整理旧数据不反复合并适合 IoT 和日志场景我一般不会在应用上线后再频繁切换 compaction 策略而是建表时就按业务特征选好。时序场景用 TWCS配合覆盖窗口的 TTL让过期数据清理集中在窗口切换时发生交互式查询对读延迟更敏感LCS 更合适。查看已有表当前的策略可以直接查系统表SELECT table_name, compaction FROM system_schema.tables WHERE keyspace_name iot AND table_name sensor_reading;返回结果里的class字段就是当前 compaction 策略类名。切换策略用ALTER TABLE ... WITH compaction时ScyllaDB 会重建 SSTable短时间会带来额外 IO 和 CPU 消耗所以这类操作要放在低峰期做。2.3 行缓存与 memtable 容量的博弈ScyllaDB 不是纯内存数据库但也不是把所有热数据都放在同一块堆内存里。每个分片都有独立的 row cache 和 memtable。row_cache_size_in_mb控制行缓存总大小读请求命中缓存时不用碰磁盘memtable 决定写入在真正落到磁盘前可以攒多少数据。# /etc/scylla/scylla.yaml 片段 memtable_total_space_in_mb: 1024 row_cache_size_in_mb: 2048这两个值要配合数据量定。业务热数据全量只有 20GB给 row cache 分配 2GB 可能把热表装进内存如果数据总量有 1TB缓存只是杯水车薪不如把内存留给文件系统页面缓存。memtable_total_space_in_mb设太大会让 flush 变慢IO 高峰时出现积压。建议先用默认值跑一轮基准再用scyllatop观察缓存命中率和 flush 频率按实际曲线慢慢调整。3. 用数据模型换 ScyllaDB 速度主键、分页与热点规避3.1 分区键的设计直接决定 p99 延迟在 ScyllaDB 里一次高质量的读请求应该是“一个分区键加一个范围查询”这样才能命中某个节点的某个分片。很多应用从关系型数据库迁移过来习惯把唯一 ID 当主键却把查询条件放在二级索引列上结果每个查询都变成跨分区扫描延迟自然拉不住。一个典型的 IoT 温度表应该这样建CREATE TABLE iot.sensor_reading ( device_id uuid, hour_bucket int, reading_time timestamp, temperature double, humidity double, PRIMARY KEY ((device_id, hour_bucket), reading_time) ) WITH CLUSTERING ORDER BY (reading_time ASC);把device_id和hour_bucket组合成分区键目的是把单个设备一天的数据按小时拆成 24 个分区。这样写入分散查询“某设备某小时的数据”只需要扫描一个分区的有序行读取近似顺序 IO。如果只把device_id当分区键热点设备一天几千万行单个分区会变成延迟尖刺的生产源头ScyllaDB 在超大分区上的索引查找也会更慢。应用里查询“设备最近一条数据”时带上分区边界利用聚类键排序SELECT * FROM iot.sensor_reading WHERE device_id ? AND hour_bucket ? AND reading_time ? LIMIT 1;3.2 别急着建二级索引物化视图有代价二级索引是 NoSQL 应用加速里最常见的坑。ScyllaDB 的二级索引本质是一张隐藏表写入基表时同步更新索引。如果索引列基数很低比如city字段只有几十个值按城市查询会命中大量行隐藏索引表需要广播到所有节点效率反而不如建一张按城市组织的主表。替代方案之一是物化视图。比如按城市查询传感器数据CREATE MATERIALIZED VIEW iot.sensor_by_city AS SELECT city, device_id, hour_bucket, reading_time, temperature, humidity FROM iot.sensor_reading WHERE city IS NOT NULL AND device_id IS NOT NULL AND hour_bucket IS NOT NULL AND reading_time IS NOT NULL PRIMARY KEY (city, device_id, hour_bucket, reading_time);物化视图并不是免费的每次基表写入都会多触发一次视图写入。如果业务写入量本来就大还建了三个视图写放大就多三倍。写密集场景下我宁可让业务在写入时冗余一份专门查询用的表也不要让数据库替应用承担太多反向查找。设计项推荐做法不推荐做法分区键高基数、均匀分布例如 device_id 时间桶低基数字段、纯时间戳、自增 ID 单调递增查询字段分区键优先聚类键其次所有查询都依赖二级索引过滤集合类型用 Set/Map 或独立表无限增长的大 List容易造成超大分区TTL按业务设置过期时间帮助 SSTable 压缩永久不过期墓碑不断堆积这些设计决策对延迟的影响往往比加多少台机器都明显。一个无界分区会让单次请求扫描几百万行这时机器的 CPU 再快也扛不住。3.3 分页的正确打开方式数据建模过关后还有一个容易被忽略的性能杀手应用分页。ScyllaDB 的分布式偏移量不能靠OFFSET无限翻页。使用LIMIT做“跳过前 10 万条”的深分页实际会先扫描并丢弃前 10 万条越往后越慢。正确做法是每次基于上一次返回的最后一行继续往后取。from cassandra.cluster import Cluster from cassandra.query import SimpleStatement cluster Cluster([192.168.1.11, 192.168.1.12]) session cluster.connect(iot) stmt SimpleStatement( SELECT * FROM sensor_reading WHERE device_id ? AND hour_bucket ?, fetch_size500 ) device_id 550e8400-e29b-41d4-a716-446655440000 bucket 20251125 for page_rows in session.execute(stmt, [device_id, bucket]): for row in page_rows: # 当前页的数据在这里处理 pass这里的关键是fetch_size而不是LIMIT。驱动在后台维护游标迭代到当前页末尾时自动发起下一页请求应用代码感知不到分页过程。fetch_size调大能减少网络往返但单页过大同样会增加序列化耗时一般 500 到 1000 行是一个折中范围。项目中从业务输入得到的页码若直接作用于 LIMIT记得改成游标或者继续翻页的方式。4. 从连接池到内核参数ScyllaDB 应用加速调优清单4.1 先让操作系统把资源交给数据库很多部署将 ScyllaDB 装进通用 Linux 环境后没有做过 IRQ 与网络队列绑定。没有 IRQ 绑定网卡中断可能全部落在 CPU0分片设计再合理也会被中断处理抢走 CPU 时间。# 将网卡中断和 CPU 绑定到指定核心示意 /opt/scylladb/scripts/perftune.py --tune net --cpu 0-15 --nic ens160注意--cpu指定的是物理核心范围不要把超线程逻辑核算进去。执行后用top确认各个 CPU 都有任务而不是 CPU0 长时间接近 100%。ScyllaDB 安装时通常自动生成io.conf把concurrent_reads校准到适合当前硬件的值。如果换过磁盘从机械硬盘换成 NVMe需要重新执行校准否则参数还停留在旧磁盘的性能特征上。常见配置项的经验值如下配置项经验值注意事项concurrent_reads由 scylla_io_setup 自动生成手动调太大会让磁盘队列积压延迟反而升高memtable_total_space_in_mb内存的 1/16 到 1/8太小频繁 flush太大触发长时间 IO 峰值row_cache_size_in_mb不超过内存的 1/4超过业务热数据量即可没必要调满commitlog_sync_period_in_ms100 到 300放宽换吞吐但断电时可能丢失少量数据改完配置重启前先确认集群只有一个版本在运行避免一次重启触发长时间数据迁移。生产环境可以先在测试节点上改一组参数观察nodetool status和延迟曲线后再推广到全集群。4.2 连接池与一致性级别应用侧的加速阀服务端参数再快应用并发不足也是白搭。ScyllaDB 驱动基于连接池连接数太多会增加数据库调度负担太少则会让请求在队列里排队。from cassandra.cluster import Cluster, ExecutionProfile from cassandra.policies import DCAwareRoundRobinPolicy, TokenAwarePolicy from cassandra import ConsistencyLevel profile ExecutionProfile( load_balancing_policyTokenAwarePolicy(DCAwareRoundRobinPolicy(local_dcDC1)), consistency_levelConsistencyLevel.LOCAL_QUORUM, request_timeout3.0 ) cluster Cluster( [192.168.1.11, 192.168.1.12, 192.168.1.13], execution_profiles{default: profile}, connect_timeout10.0 ) session cluster.connect()TokenAwarePolicy让应用优先向持有目标数据的节点发请求避免每次请求都要协调节点转发DCAwareRoundRobinPolicy防止跨机房请求拉高延迟request_timeout是兜底值宁可快速失败也不让一条请求占住线程几十秒。一致性级别上读多写少的 key-value 场景可以用LOCAL_ONE降低延迟业务要求“读到刚才写入”时用LOCAL_QUORUM。跨数据中心强一致会显著放大延迟应用加速通常不会选择这种方案。4.3 批量写与请求合并写批量时尽量让批量数据落在一个分区内。ScyllaDB 的 batch 由协调者统一分发跨分区 batch 越多协调者负载越高吞吐反而下降。BEGIN UNLOGGED BATCH INSERT INTO iot.sensor_reading (device_id, hour_bucket, reading_time, temperature) VALUES (?, ?, ?, ?); INSERT INTO iot.sensor_reading (device_id, hour_bucket, reading_time, temperature) VALUES (?, ?, ?, ?); APPLY BATCH;UNLOGGED表示不记录 batch log减少额外写放大。代价是 batch 中部分语句如果失败可能出现部分成功应用需要写补偿逻辑。对物联网设备上报、日志批量导入这类场景把邻近数据合并到一个 batch 内网络往返会明显减少。5. 验证加速用 scyllatop 看长尾用 tablestats 找热点5.1 实时监控 ScyllaDB 加速有没有生效参数都调完后最怕的是“感觉快了点”但没有数据支撑。ScyllaDB 自带scyllatop在任一节点运行scyllatop -H 192.168.1.11它会实时显示延迟、缓存、读写请求等指标。重点看两个database/row_cache_hit_rate和transport/server_requests_served。缓存命中率低于 80% 时说明内存配置或数据模型还有优化空间请求曲线如果长时间逼近天花板说明服务端资源已经饱和再去调驱动没有意义。指标名代表含义cache/row_hit行缓存命中次数storage_proxy/replica_cross_shard_failures分片间协调异常scheduler/queue_length调度队列长度持续偏高说明 CPU 分片不足latency_write/latency_read读写中位延迟和 p99 延迟5.2 热点分区定位加速失败的最后一查如果 p99 延迟仍然高使用nodetool tablestats找到分区分布问题nodetool tablestats iot.sensor_reading重点看Mean partition size和Max partition size。如果两者相差两个数量级以上比如均值是 10KB最大值却是 1GB说明某些设备或小时桶写入了异常数据形成了热点分区。这时候加节点、加缓存都只是缓解正确做法是回到分区键设计把热点拆细或者把时间桶粒度再缩小。验证数据模型是否收敛时先在测试环境用相同的分区键重放一份数据观察tablestats的最大分区是否回到均值附近。稳定的分区分布才是 p99 延迟稳定的基础。本文还有配套的精品资源点击获取 ScyllaDB低延迟加速实战：分片架构与数据建模优化
简介这是一份聚焦ScyllaDB NoSQL数据库性能优化与落地实践的PDF资料适合数据库架构师、后端开发及运维人员阅读。文档梳理了ScyllaDB的起源、设计理念及高吞吐低延迟特性重点介绍其shard-per-core架构、自动调优与动态调度机制并对比传统Cassandra在多核利用、GC延迟、配置维护方面的不足。同时结合Outbrain实际案例展示无缓存直连Scylla后带来的请求量、延迟及硬件成本改善对需要处理大规模实时数据的场景有较强参考价值。包体为单个PDF文件大小1.24MB内容精炼但覆盖概念、对比与案例。目前已有95人学习便于想快速了解ScyllaDB应用加速方案、评估其替换或补充Cassandra可行性的技术人群取用。1. ScyllaDB NoSQL 应用加速的真相不是换个数据库那么简单很多团队把应用迁到 ScyllaDB 之后第一反应是给查询加二级索引、在数据库前面堆缓存中间层结果延迟没有降下来甚至比原来的 MongoDB 或 Cassandra 还差。ScyllaDB 是一个兼容 Cassandra CQL 协议的 NoSQL 数据库底层用 C 和 Seastar 框架重新实现了数据路径每个 CPU 核心都管理自己的一部分数据分片没有 JVM GC 带来的“卡顿”。但引擎快只是必要条件应用能不能吃到这波红利取决于表结构、查询模式、连接池和内核参数是不是按它的运行方式设计。这篇文章面向想把 ScyllaDB 用出低延迟和高吞吐的工程师从分片架构、CQL 数据建模、集群参数到验证工具把一条可落地的应用加速路径拆开讲清楚。2. ScyllaDB 的加速根基分片感知架构与无 GC 数据路径2.1 shard-per-core把数据库拆进 CPU 核心ScyllaDB 与 Cassandra 最大的区别不在 CQL 语法层而在引擎层。ScyllaDB 基于 Seastar 框架用 C 实现启动时会把每个 CPU 核心映射成一个独立数据库分片每个分片单独拥有自己的 memtable、SSTable 缓存、网络队列和磁盘 IO 队列。分片之间不共享可变状态也就避免了传统数据库里那把所有线程都要抢的锁。因为每一条数据都有稳定的分区键ScyllaDB 能通过一致性哈希算出它属于哪个分片并且大概率由本节点某个 CPU 核心处理。CPU 不需要跨 NUMA 访问远端内存内存分配与释放走 Seastar 自带的内存分配器所以读一个分区时响应时间比 Cassandra 在高并发下稳定得多不会因为某次 Full GC 把整段请求卡住几百毫秒。nodetool status Datacenter: DC1 StatusUp/Down |/ StateNormal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 192.168.1.11 312.4 GB 256 33.6% aaaa... rack1 UN 192.168.1.12 305.7 GB 256 33.3% bbbb... rack1 UN 192.168.1.13 309.1 GB 256 33.3% cccc... rack1用nodetool status检查集群状态时Tokens列显示每个节点默认有 256 个虚拟节点。虚拟节点把环切得很细节点加入或退出时数据迁移的粒度小应用侧不会突然出现明显的请求延迟波峰。Owns (effective)是有效拥有率三节点时三端都在 33% 左右代表数据均衡。如果某个节点长期超过 40% 而其余只有 25%说明分区键或者 token 分配出了问题这种负载不均不是单纯加机器就能解决的。2.2 LSM-Tree 和 Compaction读放大、写放大的平衡点ScyllaDB 的存储引擎沿用 LSM-Tree 思路写入先落在内存表再冻结成不可变的 SSTable后台 compaction 负责合并和清理。读取时要按顺序查看多个 SSTable因此调整 compaction 策略本质是在调“读一次要检查多少个文件”的代价。策略典型场景对延迟的影响SizeTieredCompactionStrategy通用、写多读少小文件积压时读放大明显延迟尖刺LeveledCompactionStrategy读延迟敏感、更新频繁读路径文件数少但写放大更高写吞吐下降TimeWindowCompactionStrategy时间序列、历史按窗口整理旧数据不反复合并适合 IoT 和日志场景我一般不会在应用上线后再频繁切换 compaction 策略而是建表时就按业务特征选好。时序场景用 TWCS配合覆盖窗口的 TTL让过期数据清理集中在窗口切换时发生交互式查询对读延迟更敏感LCS 更合适。查看已有表当前的策略可以直接查系统表SELECT table_name, compaction FROM system_schema.tables WHERE keyspace_name iot AND table_name sensor_reading;返回结果里的class字段就是当前 compaction 策略类名。切换策略用ALTER TABLE ... WITH compaction时ScyllaDB 会重建 SSTable短时间会带来额外 IO 和 CPU 消耗所以这类操作要放在低峰期做。2.3 行缓存与 memtable 容量的博弈ScyllaDB 不是纯内存数据库但也不是把所有热数据都放在同一块堆内存里。每个分片都有独立的 row cache 和 memtable。row_cache_size_in_mb控制行缓存总大小读请求命中缓存时不用碰磁盘memtable 决定写入在真正落到磁盘前可以攒多少数据。# /etc/scylla/scylla.yaml 片段 memtable_total_space_in_mb: 1024 row_cache_size_in_mb: 2048这两个值要配合数据量定。业务热数据全量只有 20GB给 row cache 分配 2GB 可能把热表装进内存如果数据总量有 1TB缓存只是杯水车薪不如把内存留给文件系统页面缓存。memtable_total_space_in_mb设太大会让 flush 变慢IO 高峰时出现积压。建议先用默认值跑一轮基准再用scyllatop观察缓存命中率和 flush 频率按实际曲线慢慢调整。3. 用数据模型换 ScyllaDB 速度主键、分页与热点规避3.1 分区键的设计直接决定 p99 延迟在 ScyllaDB 里一次高质量的读请求应该是“一个分区键加一个范围查询”这样才能命中某个节点的某个分片。很多应用从关系型数据库迁移过来习惯把唯一 ID 当主键却把查询条件放在二级索引列上结果每个查询都变成跨分区扫描延迟自然拉不住。一个典型的 IoT 温度表应该这样建CREATE TABLE iot.sensor_reading ( device_id uuid, hour_bucket int, reading_time timestamp, temperature double, humidity double, PRIMARY KEY ((device_id, hour_bucket), reading_time) ) WITH CLUSTERING ORDER BY (reading_time ASC);把device_id和hour_bucket组合成分区键目的是把单个设备一天的数据按小时拆成 24 个分区。这样写入分散查询“某设备某小时的数据”只需要扫描一个分区的有序行读取近似顺序 IO。如果只把device_id当分区键热点设备一天几千万行单个分区会变成延迟尖刺的生产源头ScyllaDB 在超大分区上的索引查找也会更慢。应用里查询“设备最近一条数据”时带上分区边界利用聚类键排序SELECT * FROM iot.sensor_reading WHERE device_id ? AND hour_bucket ? AND reading_time ? LIMIT 1;3.2 别急着建二级索引物化视图有代价二级索引是 NoSQL 应用加速里最常见的坑。ScyllaDB 的二级索引本质是一张隐藏表写入基表时同步更新索引。如果索引列基数很低比如city字段只有几十个值按城市查询会命中大量行隐藏索引表需要广播到所有节点效率反而不如建一张按城市组织的主表。替代方案之一是物化视图。比如按城市查询传感器数据CREATE MATERIALIZED VIEW iot.sensor_by_city AS SELECT city, device_id, hour_bucket, reading_time, temperature, humidity FROM iot.sensor_reading WHERE city IS NOT NULL AND device_id IS NOT NULL AND hour_bucket IS NOT NULL AND reading_time IS NOT NULL PRIMARY KEY (city, device_id, hour_bucket, reading_time);物化视图并不是免费的每次基表写入都会多触发一次视图写入。如果业务写入量本来就大还建了三个视图写放大就多三倍。写密集场景下我宁可让业务在写入时冗余一份专门查询用的表也不要让数据库替应用承担太多反向查找。设计项推荐做法不推荐做法分区键高基数、均匀分布例如 device_id 时间桶低基数字段、纯时间戳、自增 ID 单调递增查询字段分区键优先聚类键其次所有查询都依赖二级索引过滤集合类型用 Set/Map 或独立表无限增长的大 List容易造成超大分区TTL按业务设置过期时间帮助 SSTable 压缩永久不过期墓碑不断堆积这些设计决策对延迟的影响往往比加多少台机器都明显。一个无界分区会让单次请求扫描几百万行这时机器的 CPU 再快也扛不住。3.3 分页的正确打开方式数据建模过关后还有一个容易被忽略的性能杀手应用分页。ScyllaDB 的分布式偏移量不能靠OFFSET无限翻页。使用LIMIT做“跳过前 10 万条”的深分页实际会先扫描并丢弃前 10 万条越往后越慢。正确做法是每次基于上一次返回的最后一行继续往后取。from cassandra.cluster import Cluster from cassandra.query import SimpleStatement cluster Cluster([192.168.1.11, 192.168.1.12]) session cluster.connect(iot) stmt SimpleStatement( SELECT * FROM sensor_reading WHERE device_id ? AND hour_bucket ?, fetch_size500 ) device_id 550e8400-e29b-41d4-a716-446655440000 bucket 20251125 for page_rows in session.execute(stmt, [device_id, bucket]): for row in page_rows: # 当前页的数据在这里处理 pass这里的关键是fetch_size而不是LIMIT。驱动在后台维护游标迭代到当前页末尾时自动发起下一页请求应用代码感知不到分页过程。fetch_size调大能减少网络往返但单页过大同样会增加序列化耗时一般 500 到 1000 行是一个折中范围。项目中从业务输入得到的页码若直接作用于 LIMIT记得改成游标或者继续翻页的方式。4. 从连接池到内核参数ScyllaDB 应用加速调优清单4.1 先让操作系统把资源交给数据库很多部署将 ScyllaDB 装进通用 Linux 环境后没有做过 IRQ 与网络队列绑定。没有 IRQ 绑定网卡中断可能全部落在 CPU0分片设计再合理也会被中断处理抢走 CPU 时间。# 将网卡中断和 CPU 绑定到指定核心示意 /opt/scylladb/scripts/perftune.py --tune net --cpu 0-15 --nic ens160注意--cpu指定的是物理核心范围不要把超线程逻辑核算进去。执行后用top确认各个 CPU 都有任务而不是 CPU0 长时间接近 100%。ScyllaDB 安装时通常自动生成io.conf把concurrent_reads校准到适合当前硬件的值。如果换过磁盘从机械硬盘换成 NVMe需要重新执行校准否则参数还停留在旧磁盘的性能特征上。常见配置项的经验值如下配置项经验值注意事项concurrent_reads由 scylla_io_setup 自动生成手动调太大会让磁盘队列积压延迟反而升高memtable_total_space_in_mb内存的 1/16 到 1/8太小频繁 flush太大触发长时间 IO 峰值row_cache_size_in_mb不超过内存的 1/4超过业务热数据量即可没必要调满commitlog_sync_period_in_ms100 到 300放宽换吞吐但断电时可能丢失少量数据改完配置重启前先确认集群只有一个版本在运行避免一次重启触发长时间数据迁移。生产环境可以先在测试节点上改一组参数观察nodetool status和延迟曲线后再推广到全集群。4.2 连接池与一致性级别应用侧的加速阀服务端参数再快应用并发不足也是白搭。ScyllaDB 驱动基于连接池连接数太多会增加数据库调度负担太少则会让请求在队列里排队。from cassandra.cluster import Cluster, ExecutionProfile from cassandra.policies import DCAwareRoundRobinPolicy, TokenAwarePolicy from cassandra import ConsistencyLevel profile ExecutionProfile( load_balancing_policyTokenAwarePolicy(DCAwareRoundRobinPolicy(local_dcDC1)), consistency_levelConsistencyLevel.LOCAL_QUORUM, request_timeout3.0 ) cluster Cluster( [192.168.1.11, 192.168.1.12, 192.168.1.13], execution_profiles{default: profile}, connect_timeout10.0 ) session cluster.connect()TokenAwarePolicy让应用优先向持有目标数据的节点发请求避免每次请求都要协调节点转发DCAwareRoundRobinPolicy防止跨机房请求拉高延迟request_timeout是兜底值宁可快速失败也不让一条请求占住线程几十秒。一致性级别上读多写少的 key-value 场景可以用LOCAL_ONE降低延迟业务要求“读到刚才写入”时用LOCAL_QUORUM。跨数据中心强一致会显著放大延迟应用加速通常不会选择这种方案。4.3 批量写与请求合并写批量时尽量让批量数据落在一个分区内。ScyllaDB 的 batch 由协调者统一分发跨分区 batch 越多协调者负载越高吞吐反而下降。BEGIN UNLOGGED BATCH INSERT INTO iot.sensor_reading (device_id, hour_bucket, reading_time, temperature) VALUES (?, ?, ?, ?); INSERT INTO iot.sensor_reading (device_id, hour_bucket, reading_time, temperature) VALUES (?, ?, ?, ?); APPLY BATCH;UNLOGGED表示不记录 batch log减少额外写放大。代价是 batch 中部分语句如果失败可能出现部分成功应用需要写补偿逻辑。对物联网设备上报、日志批量导入这类场景把邻近数据合并到一个 batch 内网络往返会明显减少。5. 验证加速用 scyllatop 看长尾用 tablestats 找热点5.1 实时监控 ScyllaDB 加速有没有生效参数都调完后最怕的是“感觉快了点”但没有数据支撑。ScyllaDB 自带scyllatop在任一节点运行scyllatop -H 192.168.1.11它会实时显示延迟、缓存、读写请求等指标。重点看两个database/row_cache_hit_rate和transport/server_requests_served。缓存命中率低于 80% 时说明内存配置或数据模型还有优化空间请求曲线如果长时间逼近天花板说明服务端资源已经饱和再去调驱动没有意义。指标名代表含义cache/row_hit行缓存命中次数storage_proxy/replica_cross_shard_failures分片间协调异常scheduler/queue_length调度队列长度持续偏高说明 CPU 分片不足latency_write/latency_read读写中位延迟和 p99 延迟5.2 热点分区定位加速失败的最后一查如果 p99 延迟仍然高使用nodetool tablestats找到分区分布问题nodetool tablestats iot.sensor_reading重点看Mean partition size和Max partition size。如果两者相差两个数量级以上比如均值是 10KB最大值却是 1GB说明某些设备或小时桶写入了异常数据形成了热点分区。这时候加节点、加缓存都只是缓解正确做法是回到分区键设计把热点拆细或者把时间桶粒度再缩小。验证数据模型是否收敛时先在测试环境用相同的分区键重放一份数据观察tablestats的最大分区是否回到均值附近。稳定的分区分布才是 p99 延迟稳定的基础。本文还有配套的精品资源点击获取