保持 SQLAlchemy 会话对 GCP/Spanner 有效

如何解决保持 SQLAlchemy 会话对 GCP/Spanner 有效

tl;dr：尝试将会话保持在 Spanner (GCP) 上是否是个好主意（我认为不是，fwiw），如果是这样，关于如何配置 SQLAlchemy 引擎有什么建议/ sessionmaker 要这样做吗？

我们已经在一个非常小的数据库中使用 SQLAlchemy 好几年了，在经典设置中 - 本地托管。在其中，我们基本上存储有关用户的 RBAC 相关数据，以便我们可以即时确保用户会话有权访问某些端点。这很有效，而且因为数据库是本地的，所以保持会话打开很长时间效果很好。即使是网络问题/关闭的套接字，我们也只是捕获异常并打开一个新会话，将旧的/过时的会话返回到池中。

我最近开始使用 spanner，并且正在使用开发中的 SQLAlchemy 方言（它运行良好）。但是，所有连接都是到谷歌云的 gRPC，因此会话在 10 秒后超时。重新创建会话的成本似乎相当高（启动的等待时间很长 [2-3 秒]）。这显然是有意的行为，但我想知道我是否遗漏了 Spanner 会话管理的某些内容，或者这是否是尝试确保 sqlalchemy 保持会话活动的用例。

鉴于 gRPC 会话的预期性质，我是否只是忽略了在会话创建过程中导致如此长时间延迟的某些事情？ 通过 CLI 运行手动查询具有相同的初始查询延迟较长的问题。有问题的数据集是四个表，大小为 KB，因此这不是复杂性或数据大小问题。

解决方法

我想澄清一个我注意到的困惑：Cloud Spanner 会话不是事务。

Spanner 会话代表与 Cloud Spanner 数据库服务的通信渠道，并且可以一次执行一个事务。正如您正确指出的，创建新会话的成本很高，这就是我们缓存会话以在客户端库的会话池中重用的原因。但是，会话仅在闲置一小时后才会被清除。

可以在此处找到有关 Spanner 会话管理的更多信息： https://cloud.google.com/spanner/docs/sessions#performance_benefits_of_a_session_cache

Spanner 事务在 10 秒不活动后中止。这是因为事务锁定了整个表。可以通过定期执行 SELECT 1 来避免这种情况，但不建议这样做，除非您了解保持事务打开的缺点。

请注意，我们有一个 Cloud Spanner SQLAlchemy 方言，目前处于预览阶段，可在此处找到： https://github.com/cloudspannerecosystem/python-spanner-sqlalchemy