原文链接： https://www.cockroach labs.com/blog/hello-world /原作者： Spencer Kimball原文日期： jun 4，2015译： zifeiy
数据库是世界上所有企业的心脏，它支撑着几个小巧的简单表格，最大支撑着数千台服务器。
而且他们进化的速度非常快。
大多数在蟑螂实验室(Cockroach Labs )的工程师都通过他们的职业生涯来维护和观察这些数据库的运行状况。 一旦他们发现数据库出现了这样那样的瓶颈，他们就会致力于解决这些瓶颈问题。
首先，为什么要选择“COckroach”？
虽然外表荒诞，但请相信你有坚韧的心。
你听说过蟑螂会成为世纪末以后唯一的幸存者吗？
现代数据库系统通过模仿自然界中最古老、最成功的设计取得了很多成果。
生存，复制，扩散。
这是古老地质时代的蟑螂模型，当然是我们的。
“蟑螂”听起来好像被遗忘了，但无所谓。
20世纪初，当我们还在谷歌工作时，我们很快就遇到了行业中非常常见的数据库问题。 应用程序级别分片(application-level sharding )。
如何将大量数据(可能是TB级，也可能是PB级)存储在数据库中？
很简单。 解决办法是把蛋糕放在一个数据库里，另一个放在另一个数据库里，这样循环，尽可能多地分割蛋糕，分成不同的数据库，就像你分割这些数据，分割蛋糕一样当然，这里说的蛋糕是切片。
但是，如果数据增长速度非常快呢？
简单来说，大量数据面临的挑战是更多的分片、更多的问题，分片操作时客户无法访问数据库，服务器过载，安装复杂性也越来越大。
我们对大数据面临的困难提供了良好的识别能力。
快进到20世纪中期，那时谷歌迎来了NoSQL的运动。
为了简单起见，NoSQL牺牲了传统关系数据库(RDBMS )的性能。
更简单的设计允许商品硬件的透明可扩展性。
从那以后，数据库开发可以使用单个数据库，但此数据库后面的数据库集群可以支持的数据量可以达到前所未有的大小。
但是，我们观察到NoSQL的这些简化最终成为了开发人员的致命弱点。 这是因为在使用NoSQL的过程中，会使用越来越复杂的APP应用逻辑来处理NoSQL所缺少的功能，如事务。
NoSQL面临的这些问题需要新一代新的数据库系统设计来解决一致性和事务性问题。
2012年我们的团队离开谷歌，创建了图像共享平台Viewfinder。
这个时期，数十亿用户服务的梦想不是白天的梦想，我的梦想有很大的梦想。
但是，当我们为优秀的基础设施寻求开源解决方案时，我们发现理想和显示之间存在很大的鸿沟。
(译者理解：他们想在开源产品中寻找关于谷歌时常用的NewSQL产品，但没有发现它在开源界。 然后他们打算自己做)
我们(在使用这些市面上销售的开源无SQL产品时)犯过无知。 体面的构建在某些情况下也可以使用复杂的解决方案，在需要的地方使用管道胶带。
事实证明，调试这些NoSQL产品不是我们的首要目标，我们没有那么多时间来解决使用这些NoSQL产品时遇到的问题(！ 请参阅。
因此，我们决定把建立优秀的分布式数据库产品作为首要使命。
因此，我们建立了蟑螂实验室(Cockroach Labs )，建立了类似于我们多年来建立的数据库产品，并确立了使他从成立之初就开源的明确目标。
这个任务很简单，我们很自豪。让数据变得简单（Make Data Easy）。
我们想要的这个数据库支持伸缩性、容错性，始终保持一致，支持抽象，使他易于使用。
我们希望花时间快速构建和重复新产品。 我们也不希望工程解决方案解决现有数据库的缺陷。 (译者理解：作者再次看到你们这些开源的NoSQL产品错误太多了，该错误的时候最好重新建立没有错误的数据库。 ) )
此数据库(CockroachDB )是创建以下公司时使用的数据库：
然后，我们下一个公司，下一个公司……使用的数据库。
现在，我们为了构建而发售蟑螂数据库。
用他，
构建他，
为他制作Contribute吧！
本，Peter Spencer
转载于：https://www.cn blogs.com/zifeiy/p/9223905.html