蟑螂是这个地球上生命力最强的生物之一。没有空气情况下可以存活 45 分钟，没有食物时甚至可以存活超过一个月。砍下头颅都不能杀死它们，至少不是立刻死亡，它们在没有头的情况下还能存活好几天。
在 Google、亚马逊以及 Facebook 等科技巨人里面，工程师们先进的技术同样是在帮助它们网站不那么容易被停掉。他们必须做到，在一个/多个服务器，甚至整个数据中心丢失的情况下，站点仍然 能继续运转。这个至关重要，因为每一秒的停机时间都意味着巨额收入损失。
Google、亚马逊以及Facebook等科技巨人，工程师们革新的技术同样帮助网站不那么容易被停掉。
现在，一个开源的开发团队希望让所有的公司都能够很容易的构建这种适应力强大的云计算系统，这样就可以像 Google 一样运行在线系统了。他们将这个项目叫做 CockroachDB，将它宣传为一个能够持久运行的数据库。对软件来说这个名字听起来有些古怪，但是 Spencer Kimball(创始合伙人，Google 前工程师)认为它非常合适，“这个名字代表了它的非常重要的两个特性：当然有残存性，还有基本上能够自发地扩展到可用的硬件。”
跟很多其他的设计用来驱动大型在线操作的开源项目类似，CockroachDB 同样基于 Google 的大数据论文—— Spanner。Spanner 是一个影响广泛的软件，最终允许 Goolge 在全世界范围内上百个数据中心的数以百万计的服务器间传播数据，Google 花费了不止 5 年的时间来构建它。即使已经有 Google 的论文，CockroachDB 的程序员仍然有很多的工作要面对，这是一个很伟大的蓝图。
散布各地的Google前雇员
截至当下，这个项目还在“alpha”开发阶段，远远没有准备好用作产品服务。Spanner 作为计算历史上让人印象最为深刻的系统之一，如果真能得到开源实现，或许就只有 CockroachDB 团队了。他们中相当一部分是 Google 前工程师，即使不是 Spanner 项目组成员。Kimball 和 Peter Mattis，作为 Photoshop 的开源替代品 GIMP 的创始合伙人，帮助创立了 Google 的大文件存储系统 Colossus。Ben Darnell 在 Google Reader 工作过，Andy Bonventre 则曾经为 Chrome 和 Google Tasks 工作过。
团队中的大部分成员现在为支付新贵 Square(Viewfinder 被收购后)工作，包括 including Kimball、Andy Kimball、Darnell、Mattis 以及 Shawn Morel。但是 Kimball 指出 Square 不支持 CockroachDB。他和他的同事只能利用业余时间在开发。有些人，比如 Bonventre 和 Tobias Schottdorf，则非 Square 员工。
只在晚上以及周末来重构 Spanner 听起来有点天方夜谭了，即使是地球上最好的工程师。然而，并不是每一个公司都需要达到 Google 的级别，但是 Kimball 指出 Viewfinder 团队已经使用了一些 Google 的技术，在 Square 渐入佳境并且很快就能派上用场。并且因为在市场上还没有类似 Spanner 的产品，Kimball 和他们的公司才下决心自己创建它。
CockroachDB 并不试图复制 Spanner 最引人注目的部分——使用原子钟(atomic clock)来同步跨全球网络的数据中心的时间。考虑到大部分的在线运营商不太可能达到 Google 的规模(同时运行成千上万的服务器)，他们并不需要这个。Kimball 指出，这些公司实际需要一种非常可靠的方式用来自动在不同的数据中心间复制信息，以保证某个数据中心丢失不会造成服务中断，这样一来，服务就像还在那个地 方运行一样，这就是 CockroachDB 旨在提供的功能。
更大的表
Spanner 是另一个 Google 数据库 BigTable 的继任者，它打破了数据库行业的很多悠久的传统，开辟了新的途径来创立高度可缩放的软件。Google 在 2006 年发表了一个关于 BigTable 的白皮书之后，它的想法很快被开源克隆所采用，比如 Cassandra 和 Hbase 迅速成为一些公司的核心技术，像 Facebook、Twitter 和 Netflix，开启了所谓“NoSQL”的改革浪潮。
但是当 NoSQL 数据库帮助公司将信息存储到大量的机器上时，也在某些方面制造了一些麻烦。像 BigTable 这个数据库就牺牲了一致性这个古老的数据库概念，这是指当你在数据库的某一个部分做修改时，无须关心另一个部分在做什么。
问题是当数据库就运行在一台机器上时，一致性是相当容易的，但是当规模扩大并扩展到不同的数据中心时，一致性就变得更加困难了。对很多应用来 说，比如即时消息，这不是一个大问题。但是如果你做些类似于在线银行的事情，这就是个很大的问题了。数据库的一部分可能会认为某人的帐户上有很多的钱，没 有意识到所有的钱已经在另一部分被取走了。另外，缺少一致性，当部分数据库出现故障了也会引起问题。Spanner 解决了这些问题，CockroachDB 追随了它的脚步。
与蟑螂一样的生命力
Spanner 在不牺牲性能的同时保证了跨数据中心的一致性。另外通过 F1，使得公司可以使用标准的 SQL 语句查询数据库(通用语就是信息检索)。尽管运行了成千上万的服务器，Spanner 数据库就像是在一台单独的机器上运行一样。如果数据中心故障了，应用可以通过简单的 ping 另一个数据中心来获取需要的信息，因为所有的数据是跨数据中心无缝同步。CouchroachDB 可以做一些类似的事情，尽管没有原子钟，它可能没有那么快完成或者同步那么多数据。
Kimball 和他的同事的目标是创建些比 Google 的产品更容易建立的东西，Google 的基础项目倾向于相互依赖。Spanner 需要 Colossus，而 Colossus 也需要称之为 Chubby 的维护系统。但是 CockroachDB 的目标是创建一个独立的系统，它不需要依靠某些特定的文件系统或者文件管理器。这个团队同样计划添加 F1 这个 SQL 查询工具到这个项目。Kimball 指出如果亚马逊或者其他的云主机公司开始添加原子钟到他们的数据中心，CockroachDB 最终也可以利用起来。
Kimball 指出，如果这个数据库最终超越了一些有内部资源来管理的大公司，一些商业公司将需要为软件提供支持。但是 Kimball 也指出需要早点考虑这个问题。如果这些确实发生了，这个计划是否需要寻找一个更好听的名字呢?Kimball 不这样认为。“人们更容易记住一些带有强烈正面或者负面情绪的东西，这个已经得到了证明。”他说，“我也想找到一个带有超强正面情绪冲击的名字，但是我没 有找到，“RainbowDB”听起来就很没劲。
