我们的数据集中的行与相邻行相比，高度可压缩。据我所知，Bigtable 支持自动压缩（通过 SSTable 块压缩）。如果 Spanner 在数据库级别支持类似的压缩，这将对我们产生巨大影响。我们预计这将使我们的成本结构降低 3-5 倍。虽然我们可以考虑在应用程序层面尝试这样做，但这真的不好玩...
1个回答
3
云Spanner按逻辑字节数收费，即您发送给我们的数据大小。类型的大小在此处列出：https://cloud.google.com/spanner/docs/data-types。
- Albert Cui
5
你好 - 是的，我们意识到这一点，但是数据库级别的压缩是否在路线图上呢？即使它将在未来一年内推出，这也将有助于我们决定是否花费XXX,XXX美元购买Spanner。客户端压缩对我们来说效果不佳，因为我们的单个行不可压缩，但是在100相邻行的基础上，它们是可以压缩的...（当然，客户端压缩严重限制了我们通过Spanner执行的操作）。 - spannerfan123
我们不会在StackOverflow上讨论路线图。存储成本可能是账单中最小的部分。如果您正在查看大规模Spanner部署，可以通过我的@google.com电子邮件与我联系，使用我的名字前3个字母和姓氏（总共6个字母）。 - Dan McGrath
自从 Spanner 发布以来，我们一直在进行实验，并探索各种成本权衡。正如您所指出的，直接存储价格只是一个因素；但还有最少需要的节点数来“管理”这个存储（每 2TB 需要 1 个节点），即使它是一个相对较冷的数据集，仍需要在同一事务域中。如果所需的事务 QPS 相对于语料库大小很低，则定价对存储的隐含成本非常敏感。例如，100TB 的成本可能为每年 75万美元。如果我们的数据集可以压缩 5 倍，则只需每年 15万美元。 - spannerfan123
那就假设压缩仍然保持每TB存储的节点1:1映射，但这并不一定正确。 - Dan McGrath
在这种情况下，我们将联系您（或通常是 Google），以讨论路线图、定价选项和灵活性；相对较冷和/或可压缩数据集的成本似乎很高，从基本面的角度来看（即对 Google 的成本），我认为这可能不必如此。我们很想使用 Spanner，但非常注重价值。 - spannerfan123
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接