我们决定在我们的 Ruby on Rails 项目中使用 ScyllaDB 来处理一些重插入组件。但是，据说ruby driver 处于维护模式，而且我们几年前也听说过它的性能问题。
我的问题是，是否有人真的使用 Ruby 使用 ScyllaDB 进行生产？你用什么驱动？它的表现如何？有没有我们应该注意的陷阱？ 顺便说一句，我知道 DynamoDB 交流发电机，但我们真的更喜欢使用 CQL 而不是奇怪的 DynamoDB json 查询语法，并且需要额外的 Scylla 功能，如“分组依据”、多列分区键等等。
谢谢！
【问题讨论】：
另一种选择是使用Scylla Alternator（DynamoDB 兼容 API），在这种情况下，您可以使用 AWS DynamoDB 驱动程序。性能不如 CQL，但它仍然会非常快，并且您将能够使用像 Dynamoid 这样的库。
【讨论】：
我们目前结合使用 Cequel 和您链接的 Ruby 驱动程序（Cequel 在后台使用该驱动程序）。在我们的第一个 ScyllaDB/Cassandra 项目中，我们假设灵活的模式比实际更灵活（例如，您不能随意更改键），因此 Cequel 听起来很合适。在我们的第二个项目中，我们非常刻意地选择了密钥等，我们只是半直接地使用底层驱动程序（我们使用Cequel::Metal）。我们使用 Rake 任务处理迁移，因为迁移与使用 PostgreSQL 的工作方式不同（上/下在传统意义上没有意义 - 如果向下迁移，您不会丢失新列，只会丢失它们来自新条记录）。
Cassandra 社区中的默认答案似乎是“运行 JRuby，使用 JDBC 驱动程序”。不要那样做。对于合适的人来说，JRuby 可能很棒，但它并不完全兼容 MRI，而且它的性能也不一样。他们接下来会建议使用 ODBC。 ruby-odbc 应该被视为最后的兼容性库。它有很多未实现的 ODBC 特性。它可能会泄漏 ODBC 状态并锁定该线程，或者如果驱动程序不防范较差的线程安全性，则使进程崩溃（！）。它在 Rails 中的表现会非常差。也不要走那条路。
这两个建议是关于你所得到的一切，至少从我环顾四周时是这样。似乎在 Cassandra 社区中，很多人仍在将 10 年前的 Ruby 印象应用于现代 Ruby。我的意思是，他们认为由于 JVM，JRuby 比 MRI 更快，因为 Twitter 放弃了 Rails 并切换到了 JVM。现在不再是这种情况了（并且已经有一段时间没有了）。在某些情况下，JRuby 表现出色，但在很多情况下 MRI 胜过它。推荐 JDBC 的人可能是出于好意，但感觉很像“你的语言很烂，用我们的”。这种态度似乎导致他们花时间做 Python 或 Go 驱动程序，而不是 Ruby 驱动程序。
如果 ScyllaDB 付钱让我开发驱动程序，我会take their C/C++ driver 并使用 FFI 包装它并公开一个不错的 API。我可能不会编写 ActiveRecord 驱动程序，因为我不将 ScyllaDB/Cassandra 用于我们的主要数据对象，并且如果没有 WITH FILTERING，就不可能进行基于非键的查询（您使用 ActiveRecord 的主要原因），它您可能不想让 HTTP 客户端可用。您可以使用物化视图和所有这些，但是查询略有不同。在此之上的库可以将这些概念映射到 ActiveRecord。 FFI 包装器的难点在于精心设计一个惯用的界面；幸好，由于 FFI 项目的努力，其余的工作都很容易。
【讨论】：
如果有人有兴趣分叉 Ruby 驱动程序以与 Scylla 一起使用，请考虑如何继续。
如果您在此处没有关于用户体验的进一步答案，也请在 ScyllaDB user Slack 或 email list 上提问。
【讨论】：