我们决定在我们的 Ruby on Rails 项目中使用 ScyllaDB 来处理一些重插入组件。然而，据说ruby 驱动程序处于维护模式，几年前我们也听说过它的性能问题。
我的问题是，是否有人真的使用 ruby 使用 ScyllaDB 进行生产？你用什么驱动？它的表现如何？有什么我们应该注意的陷阱吗？顺便说一句，我知道 DynamoDB 发电机，但我们真的更喜欢使用 CQL，而不是奇怪的 DynamoDB json 查询语法，并且需要额外的 Scylla 功能，如“分组依据”、多列分区键等。
谢谢！
我们目前使用 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 付钱让我在驱动程序上工作，我会使用他们的 C/C++ 驱动程序并使用 FFI 来包装它并公开一个像样的 API。我可能不会编写 ActiveRecord 驱动程序，因为我不将 ScyllaDB/Cassandra 用于我们的主要数据对象，并且没有基于键的查询（您使用 ActiveRecord 的主要原因）是不可能的WITH FILTERING，您可能会这样做不想让 HTTP 客户端可用。您可以使用物化视图和所有这些，但查询会略有不同。在此之上的库可以将这些概念映射到 ActiveRecord。FFI 包装器的难点在于精心设计一个惯用的界面；幸运的是，由于 FFI 项目的努力，剩下的事情非常容易。