CockroachDB学习笔记——[译]Hello World

• 原文链接：https://www.cockroachlabs.com/blog/hello-world/
• 原作者：Spencer Kimball
• 原文日期：Jun 4, 2015
• 译：zifeiy

数据库是世界上每个企业的心脏，支撑着小至几个简单的表格，大到成千上万台服务器。
并且他们进化的速度非常快。
在蟑螂实验室（Cockroach Labs）的大多数工程师在他们的职业生涯中都一直在维护并观察这些数据库的运行状态，当他们发现数据库出现这样或那样的瓶颈的时候，他们便会着力解决这些出现的瓶颈问题。

但是首先，为什么要选择“COckroach”？
虽然他的外表长的很荒诞，但是请相信他有一个强韧的内心。
你听说过蟑螂会是世纪末日后唯一的幸存者吗？
现代数据库系统通过模仿自然界最古老和最成功的设计而获得了很多收获。
生存，复制，扩散。
这是古老的地质时代中蟑螂的模型，当然也是我们的。
即使“蟑螂”这个听上去感觉会被遗忘，但是也无所谓啦。

在20世纪初，当我们还在Google工作的时候，我们很快就遇到了在行业当中非常普遍的数据库的问题：应用程序级别的分片（application-level sharding）。
如果你有大量的数据（可能是TB级别的甚至是PB级别的）要存储到数据库中应该怎么办呢？
很简单，解决的办法就是：你把这些数据切分出来，就像切分蛋糕一样，然后把一块蛋糕放到一个数据库里，再把另一块蛋糕放到另一个数据库里，如此循环，尽量多地切分蛋糕，然后分到不同的数据库里（当然我这里说的蛋糕就是分片）。
但是如果数据的增长速度非常快怎么办？
简而言之，大量的数据面临的挑战是：更多的分片，更多的问题，在分片操作时客户将不能访问数据库，服务器过载，安装复杂度也会越来越大。
我们对大规模数据面临的困难提供了良好的鉴别能力。

快进到20世纪中期，那个时候Google迎来了NoSQL的运动。
为了简单起见，NoSQL牺牲了传统关系型数据库(RDBMS)的一些性能。
一个更简单的设计允许商品硬件透明的可扩展性。
自此数据库开发可以像使用单个数据库一样，但是这个数据库背后的数据库集群所能支持的数据量却能达到闻所未闻的大小。
但是我们观察到，NoSQL的这些简化最终成为了开发人员的致命弱点，因为在使用NoSQL的过程中，将使用越来越复杂的应用程序逻辑来处理NoSQL所缺失的一些功能，比如事务。
NoSQL面临的这些问题需要下一代的新的数据库系统设计来解决一致性和事务性的问题。

在2012年我们团队离开了Google取创建一个图片共享平台Viewfinder。
在这段时期，为数十亿用户提供服务的梦想并不是白日做梦，我梦有一个远大的梦想。
但是当我们为我们优秀的基础设施寻求一种开源的解决方案的时候，才发现理想和显示之间存在着一条宏大的沟。
（译者的理解：他们想在开源产品中寻找一款跟在Google的时候用起来很好的NewSQL产品，但是没有发现开源界有，然后他们就准备自己造一个）
我们（在使用市面上的这些开源NoSQL产品时）犯过懵逼，体面的搭建，有的时候使用复杂的解决办法也是可能的，在必要的地方使用管道胶带。
事实证明，调试这些NoSQL产品并不是我们的首要目标，我们根本没有那么多时间来解决使用这些NoSQL产品时遇到的问题（破产品bug太多了!!!）。

所以我们决定以建立一款优秀的分布式数据库产品为我们的首要使命。
于是乎我们建立了蟑螂实验室（Cockroach Labs）并且确立了一个明确的目标：建立一个我们多年以来就像建立的数据库产品，并且使他在建立之初就是开源的。
这项任务很简单，并且我们非常骄傲的承诺：让数据变得简单（Make Data Easy）。

我们想要的这个数据库支持伸缩性，容灾性，始终是一致的，并且支持抽象，以使得他更易于使用。
我们宁愿花时间来快速构建及迭代一个新的产品，也不愿意对现有数据库的缺陷进行工程解决方案。（译者的理解：作者再次强调你们这些开源NoSQL产品bug太多了，该bug的时候还不如重新做一个没啥bug的数据库呢）
而这个数据库(CockroachDB)将会是我们在成立下一家公司时所使用的数据库。
并且时我们下下个公司，下下下个公司……所使用的数据库。

如今，我们为搭建推出蟑螂DB。
使用他，
构建他，
为他做出Contribute吧！

Ben, Peter & Spencer

转载于:https://www.cnblogs.com/zifeiy/p/9223905.html