我正在将应用程序从Oracle迁移到Google Spanner。 我们遇到的一个案例是同一个表中各行之间的关系。
这些关系具有树状结构，总是有一个父级和一个层次结构。可以自下而上和从上到下的查询模式。
在某些情况下，我们希望能够有效访问整个记录树。此数据访问模式对延迟至关重要。
该应用程序以前使用过Oracle及其分层查询（connect by），并且针对该供应商进行了高度优化。
一次树获取中的行数介于1-2000之间。 表将有数百万个sych行。
该表的行确实存在交错的子表行。
通过对模型进行非规范化并冗余地添加根记录的id来优化表以获得更好的数据局部性是否有意义 作为该表的主键的第一列，用于更快速的自上而下查询？
会是这样的：
root_id | own_id | parent_id
1 | 1 | 1
1 | 2 | 1
1 | 3 | 2
4 | 4 | 4
4 | 5 | 4
4 | 5 | 4
IE中。我们正在考虑让PK由（root_id，own_id）组成。 （价值观是肤浅的，我们可以在真实场景中展开它们。）
这些行的可能性是多少，其中包含相同的第一个元素来进行相同的拆分？这样做会有实际好处吗？
答案 0 :(得分：1)
Cloud Spanner支持父子表关系，以声明两个逻辑上独立的表之间的数据位置关系，并在物理上共同定位它们的行以进行有效检索。 有关详细信息，请参阅此链接：https://cloud.google.com/spanner/docs/schema-and-data-model#parent-child_table_relationships
例如，假设我们有一张表＆＃39; Root＆＃39;使用主键＆＃39; root_id＆＃39;，我们可以声明表格＆＃39;拥有＆＃39;成为＆＃39; Root＆＃39;表。父表的主键成为子表的主键的前缀。所以表＆＃39;拥有＆＃39;可以有一个主键（root_id，own_id）。所有表格的行都是“拥有”的。拥有相同的root_id＆＃39;将位于相同的分裂。
拆分确实有最大尺寸限制。根据经验，父子表层次结构中每组相关行的大小应小于几个GiB。