在扳手中安全隔离客户数据

Question

我们正在探索在扳手中可靠地隔离客户数据的选择。最明显的解决方案是每个数据库都有一个客户，但是100个数据库/实例限制使得这种做法不切实际。过去的经验使我对在每个表的主键中添加一个customer id字段的任何计划都非常怀疑，因为在SQL查询中太容易搞砸这一点，从而导致危险的数据交叉交谈。

我正在考虑奇怪的解决方案，比如使用所有2k表/实例，并以每个客户需要的~32个表作为前缀。例如，[cust-id]-Table1、[cust-id]-Table2等，至少这样，需要铁板一块的客户隔离逻辑就可以放在一个在查询中很难搞砸的地方。但有没有人知道一种不那么奇怪的方法？例如，"100“是一个可疑的--技术限制中的非整数--它是可以调节的吗？

Answer 1

不幸的是，100个数据库/实例不是一个可调整的值。

不过，我似乎并不完全理解“对于在每个表的主键中添加一个customer id字段的任何计划都非常可疑，因为在SQL查询中搞砸这一点太容易了，会导致危险的数据交叉”。您是否关心查询性能、数据正确性、代码正确性或架构？

使用此模式，每个客户的~32个表将只允许您存储大约6000个客户。虽然我建议使用其他模式选择进行基准测试，但Spanner公开了。

您能提供这些客户表的高级架构以及查询模式吗？

此外，建议阅读更多适合你的想法-更好地使用：

• 扳手模式
• 交错表
• 次级指标
• SQL最佳实践