【发布时间】：2017-10-24 04:37:10
【问题描述】：
我们的数据集具有相对于相邻行高度可压缩的行。据我了解，Bigtable 支持自动压缩（通过 SSTable 块压缩）。如果 Spanner 能够或将支持数据库级别的类似压缩，这将对我们产生巨大的影响。我们预计这会使我们的成本结构产生 3-5 倍的差异。虽然我们可以考虑在应用层尝试这样做，但这一点也不好玩……
【问题讨论】：
标签： google-cloud-platform google-cloud-spanner
【发布时间】：2017-10-24 04:37:10
【问题描述】：
Cloud Spanner 对逻辑字节收费 - 您发送给我们的数据大小。此处列出了类型的大小：https://cloud.google.com/spanner/docs/data-types
【讨论】：
-
您好——是的，我们意识到了这一点，但是路线图上是否存在数据库级压缩？即使它会在一年内发布，这也将有助于我们决定是否在 Spanner 上花费 $XXX,XXX。客户端压缩对我们来说效果不佳，因为我们的各个行不可压缩，但是在 100 个相邻行的基础上它们是......（当然，客户端压缩严重限制了我们可以通过 Spanner 执行的操作）。
-
我们不讨论 StackOverflow 上的路线图。存储成本可能是账单中最小的部分。如果您正在查看大规模 Spanner 部署，您可以通过我的 @google.com 电子邮件与我联系，使用我的名字和姓氏的前 3 个字母（共 6 个字母）。
-
自 Spanner 发布以来，我们一直在对其进行试验，并探索各种成本权衡。正如您所指出的，直接存储价格只是一个因素；但也存在“管理”此存储所需的最小节点数（每 2 TB 1 个节点），即使它是一个相对冷的数据集，仍需要位于同一事务域中。如果所需的事务 QPS 相对于语料库大小较低，则定价对隐式存储成本高度敏感。例如，100TB 可能每年花费 75 万美元。如果我们的数据集可压缩 5 倍，则每年只需 15 万美元。
-
假设压缩仍然保持每 TB 存储节点的 1:1 映射，这不一定是真的。
-
在这种情况下，我们将与您（或一般 Google）联系，讨论路线图 + 定价选项 + 灵活性；相对冷和/或可压缩的数据集的成本似乎很高，恕我直言，从面向基本面的角度来看（即谷歌的成本）可能不必这样。我们很想使用 Spanner，但非常注重价值......