ScyllaDB适配Ruby驱动选型及Rails项目生产落地咨询

生产场景的实际应用情况 #

确实有不少在Ruby on Rails体系下处理高写入负载的团队（覆盖实时用户行为埋点、IoT设备上报、高并发交易流水等场景）在生产环境稳定运行ScyllaDB，并非小众试验性场景。

生产环境实际选用的驱动 #

目前生产环境基本已经淘汰了Datastax官方推出的已进入维护模式的Ruby驱动，主流选择分为两类：

• Scylla官方主推的scylla-ruby-driver：新落地的项目基本都选这个，目前处于积极维护状态，完整覆盖Scylla的全部能力，包括你关心的多列分区键、Group By聚合、轻量事务、分片感知路由，完全不会出现老Datastax驱动的兼容性问题。
• 社区维护的Datastax驱动fork分支：仅给早期已经上线老驱动的存量项目做维护用，分支是当年踩过老驱动坑的生产团队凑起来共同维护的，只修生产暴露的bug，不会跟进Scylla的新特性，新项目别碰。

驱动的真实生产性能表现 #

拿同机房3节点Scylla集群的生产实测数据说：

• 使用scylla-ruby-driver配合Puma多线程运行模式，单Rails进程的稳定写入QPS可达8k-12k，平均写入延迟稳定在1-3ms，相比老Datastax驱动，高写入下的性能提升约40%，延迟抖动幅度降低60%以上——老驱动在写入压力超过5k QPS时，经常出现平均延迟从2ms飙升至50ms以上的连接泄漏问题。
• 性能优势的核心来源是驱动内置的Scylla分片感知路由能力，可直接将请求路由到负责对应分区的节点分片，无需经过协调节点中转，大幅减少集群内部的网络开销。
• 客观存在的短板：作为纯Ruby实现的驱动，单进程并发请求超过5k时，CPU占用相比C扩展类驱动高15%-20%，但这个量级已经远超绝大多数Rails应用单进程的实际并发上限，对常规业务场景没有影响。

必须提前规避的落地坑点 #

• 别想着把ActiveRecord或者传统SQL系的ORM硬套到Scylla上：Scylla的CQL模型、分片路由逻辑和关系型数据库完全不同，强行套ORM会导致无法利用分片路由优化，直接造成50%以上的性能折损，直接使用驱动原生的PreparedStatement交互即可。
• 别直接用驱动默认的连接池参数：生产环境需要根据Puma的进程数、线程数配置匹配的连接池大小，同时开启固定间隔的连接心跳检测，否则高写入持续运行超过24小时，容易出现TCP连接僵死的问题。
• 注意查询条件与分片路由的匹配逻辑：驱动会根据分区键的哈希值自动计算路由目标，凡是不带完整分区键前缀的查询，都会触发跨分片的全节点扫描，在高写入场景下很容易直接打满集群负载。
• 别直接开启驱动默认的客户端重试策略：Scylla的高写入场景下，驱动自动重试会放大请求压力触发写入雪崩，需要把重试逻辑收敛到业务层，仅对读超时场景设置最多1次重试，写入请求完全依赖业务层幂等设计，不做驱动层自动重试。
• 注意Group By查询的分页边界：跨分页返回的Group By聚合结果是不连续的，生产中执行大范围聚合查询时，需要主动调大驱动的单页返回大小，避免用默认的100条分页参数导致聚合结果不准确。

内容的提问来源于stack exchange，提问作者Kaplan Ilya