ruby - ScyllaDB 的正确 ruby​​ 驱动程序

Question

我们决定在我们的 Ruby on Rails 项目中使用 ScyllaDB 来处理一些重插入组件。然而，ruby driver据说处于维护模式，而且我们在几年前就听说过它的性能问题。

我的问题是，是否有人真的使用带有 ruby​​ 的 ScyllaDB 进行生产？你用什么驱动程序？它的表现如何？有什么陷阱是我们应该注意的吗？顺便说一句，我知道 DynamoDB alternator，但我们更喜欢使用 CQL 而不是怪异的 DynamoDB json 查询语法，并且需要额外的 Scylla 功能，如“分组依据”、多列分区键等。

谢谢!

Answer 1

我们目前结合使用 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。我的意思是，由于 Twitter 放弃了 Rails 并转而使用 JVM，因此他们认为 JRuby 比 MRI 更快是因为 JVM。事实已不再如此(并且已经有一段时间没有了)。在某些情况下 JRuby 表现出色，但在很多情况下 MRI 胜过它。推荐 JDBC 的人可能是出于好意，但感觉很像“你的语言很烂，用我们的”。这种态度似乎导致他们花时间做 Python 或 Go 驱动程序，而不是 Ruby 驱动程序。

如果 ScyllaDB 付钱给我做驱动程序，我会 take their C/C++ driver并使用 FFI 包装它并公开一个像样的 API。我可能不会编写 ActiveRecord 驱动程序，因为我不将 ScyllaDB/Cassandra 用于我们的主要数据对象，并且如果没有 WITH FILTERING，则不可能进行非基于键的查询(您使用 ActiveRecord 的主要原因) ，您可能不想让 HTTP 客户端可用。您可以使用物化 View 等等，但是查询会略有不同。在此之上的库可以将这些概念映射到 ActiveRecord。 FFI 包装器的难点在于精心设计一个惯用的界面；由于 FFI 项目的努力，剩下的事情非常容易。