我们正在探索在 Spanner 中可靠地隔离客户数据的选项。最明显的解决方案是每个数据库一个客户，但是 100 个数据库/实例的限制使这种做法变得不切实际。过去的经验让我非常怀疑任何将客户 ID 字段添加到每个表的主键的计划，因为在 SQL 查询中很容易搞砸，从而导致危险的数据串扰。
我正在考虑奇怪的解决方案，例如使用所有 2k 表/实例，并为每个客户获取我们需要的约 32 个表并为 那些添加前缀。例如，[cust-id]-Table1、[cust-id]-Table2 等。至少可以将需要铁定的客户隔离逻辑放在一个很难在查询中搞砸的地方。但是有人知道一种不那么奇怪的方法吗？例如，“100”在技术限制中是一个可疑的非整数 - 是否可以以某种方式调整？
【问题讨论】：
标签： google-cloud-platform google-cloud-spanner
很遗憾，100 个数据库/实例不是一个可调整的值。
不过，我似乎并没有完全理解“非常怀疑将客户 ID 字段添加到每个表的主键的任何计划，因为在 SQL 查询中太容易搞砸了，导致危险数据串扰。”您是否关心查询性能、数据正确性、代码正确性或架构？
使用此架构，每个客户约 32 个表将仅允许您存储约 6000 个客户。虽然我建议使用 Spanner 公开的其他模式选择进行基准测试。
您能否提供这些客户表的高级架构以及您的查询模式？
另外，建议阅读更多更适合您的用例的想法：
【讨论】：
create table User ( custId int64, email string, ... ) primary key (custId, email) 这样的架构（其中custId 是客户租户，email 是他们的最终用户）。任何像select User.* from User where email [...] 这样的查询都会无意中混合客户数据。很难保证这永远不会在任意查询中搞砸。因此，我们希望有更强的隔离。