在我们深入研究CockroachDB和Google Cloud Spanner的比较之前，有一点需要注意。我不是Spanner的专家。我研究了他们的文档，试用了产品，并且对他们的使用情况非常了解，足以说明Spanner是一个了不起的数据库。在这篇博客中，我不打算解读Spanner的所有架构细节，因为那将是一篇更长的文章，我根本不愿意这么做。我只想指出CockroachDB与Spanner不同的有趣地方。这里有一个简短的视频，如果你想通过这种方式来了解信息。
谷歌云Spanner的起源
谷歌云Spanner是分布式SQL运动的先驱数据库，熟悉Spanner起源的最好方法是去阅读谷歌云Spanner白皮书。在该文件中，谷歌将Spanner描述为 "谷歌的可扩展、多版本、全球分布和同步复制的数据库"。它在全球范围内分布数据，并支持外部一致的分布式交易。基本上，他们以Bigtable的经验为基础，使其成为关系型数据库。这对于需要现代化的关键业务工作负载来说是一个惊人的时刻。
CockroachDB和Spanner的架构差异
如果不提及CockroachDB的三位创始人（Spencer Kimball、Peter Mattis和Ben Darnell）都是谷歌的300号员工，那就太失礼了。彼得和斯宾塞帮助建立了Colossus，它是谷歌的后台文件系统，本帮助设计和建立了Reader。作为他们工作的一部分，他们与正在建设Spanner的团队进行了互动和合作。当他们离开并转到新的项目时，他们错过了一些谷歌的工具。
虽然CockroachDB的架构受到Spanner的启发，但有几个关键的区别我想指出来。让我们来了解一下。
1.多云和云内部署
谷歌Spanner的架构依赖于硬件来同步集群内的时间，这反过来又把它与明确的GCP实例联系起来。因此，你不能在GCP之外真正使用它。相比之下，你可以在任何云提供商的多个不同的云提供商之间运行CockroachDB，或者真的在任何地方。CockroachDB不与任何明确的硬件相联系，而Spanner则与包括原子钟在内的硬件相联系。
2.2.多区域的简单性和控制
在这里，"多区域 "是指把数据放在不同的地方，以便在整个区域发生故障时也能幸存下来，或者出于性能考虑，把数据放在离用户近的地方。在CockroachDB中，数据的位置是在每个表的行级定义的。由于延迟和生存的原因，这种对数据位置的细化控制是非常强大的。另外，CockroachDB中的数据位置控制的粒度和简单性与Spanner中的数据位置控制有很大不同。
3.Kubernetes的自由和Anthos的可用性
Spanner与明确的硬件联系在一起，这使得在任何Kubernetes集群中临时部署它具有挑战性。相比之下，CockroachDB是作为一个分布式系统而建立的，它是开放的，可以在任何硬件和任何集群上运行，所以它在Kubernetes等这些分布式环境中运行得非常好。与Spanner不同，你可以在Anthos或红帽OpenShift等多云K8s环境中使用CockroachDB。如果你要运行Kubernetes，你会发现每个版本的CockroachDB都很适合直接在上面运行。
4.SQL覆盖率和数据类型
Spanner在过去几个月做了一些非常棒的工作，与PostgreSQL兼容。但有些领域，如空间数据和其他数据类型和语法，在谷歌Spanner中仍然没有覆盖。这对你来说可能不是什么大问题，因为这要看你的工作量和你想完成的任务。CockroachDB的文档是一个很好的地方，可以看到我们的SQL覆盖的全部范围。
