谷歌(Google)到底用的什么数据库，谷歌的架构是什么样的
Google是伸缩性的王者。Google一直的目标就是构建高性能高伸缩性的基础组织来支持它们的产品。
平台
Linux
大量语言：Python，Java，C++
状态
在2006年大约有450,000台廉价服务器
在2005年Google索引了80亿Web页面，现在没有人知道数目
目前在Google有超过200个GFS集群。一个集群可以有1000或者甚至5000台机器。成千上万的机器从运行着5000000000000000字节存储的GFS集群获取数据，集群总的读写吞吐量可以达到每秒40兆字节
目前在Google有6000个MapReduce程序，而且每个月都写成百个新程序
BigTable伸缩存储几十亿的URL，几百千千兆的卫星图片和几亿用户的参数选择
堆栈
Google形象化它们的基础组织为三层架构：
可信赖的存储机制GFS(Google File System)
1，可信赖的伸缩性存储是任何程序的核心需求。GFS就是Google的核心存储平台
2，Google File System - 大型分布式结构化日志文件系统，Google在里面扔了大量的数据
3，为什么构建GFS而不是利用已有的东西？因为可以自己控制一切并且这个平台与别的不一样，Google需要：
-跨数据中心的高可靠性
-成千上万的网络节点的伸缩性
-大读写带宽的需求
-支持大块的数据，可能为上千兆字节
-高效的跨节点操作分发来减少瓶颈
4，系统有Master和Chunk服务器
-Master服务器在不同的数据文件里保持元数据。数据以64MB为单位存储在文件系统中。客户端与Master服务器交流来在文件上做元数据操作并且找到包含用户需要数据的那些Chunk服务器
-Chunk服务器在硬盘上存储实际数据。每个Chunk服务器跨越3个不同的Chunk服务器备份以创建冗余来避免服务器崩溃。一旦被Master服务器指明，客户端程序就会直接从Chunk服务器读取文件
6，一个上线的新程序可以使用已有的GFS集群或者可以制作自己的GFS集群
7，关键点在于有足够的基础组织来让人们对自己的程序有所选择，GFS可以调整来适应个别程序的需求
使用MapReduce来处理数据
1，现在你已经有了一个很好的存储系统，你该怎样处理如此多的数据呢？比如你有许多TB的数据存储在1000台机器上。数据库不能伸缩或者伸缩到这种级别花费极大，这就是MapReduce出现的原因
2，MapReduce是一个处理和生成大量数据集的编程模型和相关实现。用户指定一个map方法来处理一个键/值对来生成一个中间的键/值对，还有一个reduce方法来合并所有关联到同样的中间键的中间值。许多真实世界的任务都可以使用这种模型来表现。以这种风格来写的程序会自动并行的在一个大量机器的集群里运行。运行时系统照顾输入数据划分、程序在机器集之间执行的调度、机器失败处理和必需的内部机器交流等细节。这允许程序员没有多少并行和分布式系统的经验就可以很容易使用一个大型分布式系统资源
3，为什么使用MapReduce？
-跨越大量机器分割任务的好方式
-处理机器失败
-可以与不同类型的程序工作，例如搜索和广告。几乎任何程序都有map和reduce类型的操作。你可以预先计算有用的数据、查询字数统计、对TB的数据排序等等
4，MapReduce系统有三种不同类型的服务器
-Master服务器分配用户任务到Map和Reduce服务器。它也跟踪任务的状态
-Map服务器接收用户输入并在其基础上处理map操作。结果写入中间文件
-Reduce服务器接收Map服务器产生的中间文件并在其基础上处理reduce操作
5，例如，你想在所有Web页面里的字数。你将存储在GFS里的所有页面抛入MapReduce。这将在成千上万台机器上同时进行并且所有的调整、工作调度、失败处理和数据传输将自动完成
-步骤类似于：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS
-在MapReduce里一个map操作将一些数据映射到另一个中，产生一个键值对，在我们的例子里就是字和字数
-Shuffling操作聚集键类型
-Reduction操作计算所有键值对的综合并产生最终的结果
6，Google索引操作管道有大约20个不同的map和reduction。
7，程序可以非常小，如20到50行代码
8，一个问题是掉队者。掉队者是一个比其他程序慢的计算，它阻塞了其他程序。掉队者可能因为缓慢的IO或者临时的CPU不能使用而发生。解决方案是运行多个同样的计算并且当一个完成后杀死所有其他的
9，数据在Map和Reduce服务器之间传输时被压缩了。这可以节省带宽和I/O。
在BigTable里存储结构化数据
1，BigTable是一个大伸缩性、错误容忍、自管理的系统，它包含千千兆的内存和1000000000000000的存储。它可以每秒钟处理百万的读写
2，BigTable是一个构建于GFS之上的分布式哈希机制。它不是关系型数据库。它不支持join或者SQL类型查询
3，它提供查询机制来通过键访问结构化数据。GFS存储存储不透明的数据而许多程序需求有结构化数据
4，商业数据库不能达到这种级别的伸缩性并且不能在成千上万台机器上工作
5，通过控制它们自己的低级存储系统Google得到更多的控制权来改进它们的系统。例如，如果它们想让跨数据中心的操作更简单这个特性，它们可以内建它
6，系统运行时机器可以自由的增删而整个系统保持工作
7，每个数据条目存储在一个格子里，它可以通过一个行key和列key或者时间戳来访问
8，每一行存储在一个或多个tablet中。一个tablet是一个64KB块的数据序列并且格式为SSTable
9，BigTable有三种类型的服务器：
-Master服务器分配tablet服务器，它跟踪tablet在哪里并且如果需要则重新分配任务
-Tablet服务器为tablet处理读写请求。当tablet超过大小限制(通常是100MB-200MB)时它们拆开tablet。当一个Tablet服务器失败时，则100个Tablet服务器各自挑选一个新的tablet然后系统恢复。
-Lock服务器形成一个分布式锁服务。像打开一个tablet来写、Master调整和访问控制检查等都需要互斥
10，一个locality组可以用来在物理上将相关的数据存储在一起来得到更好的locality选择
11，tablet尽可能的缓存在RAM里
硬件
1，当你有很多机器时你怎样组织它们来使得使用和花费有效？
2，使用非常廉价的硬件
3，A 1,000-fold computer power increase can be had for a 33 times lower cost if you you use a failure-prone infrastructure rather than an infrastructure built on highly reliable components. You must build reliability on top of unreliability for this strategy to work.
4，Linux，in-house rack design，PC主板，低端存储
5，Price per wattage on performance basis isn't getting better. Have huge power and cooling issues
6，使用一些collocation和Google自己的数据中心
其他
1，迅速更改而不是等待QA
2，库是构建程序的卓越方式
3，一些程序作为服务提供
4，一个基础组织处理程序的版本，这样它们可以发布而不用害怕会破坏什么东西
Google将来的方向
1，支持地理位置分布的集群
2，为所有数据创建一个单独的全局名字空间。当前的数据由集群分离
3，更多和更好的自动化数据迁移和计算
4，解决当使用网络划分来做广阔区域的备份时的一致性问题(例如保持服务即使一个集群离线维护或由于一些损耗问题)
学到的东西
1，基础组织是有竞争性的优势。特别是对Google而言。Google可以很快很廉价的推出新服务，并且伸缩性其他人很难达到。许多公司采取完全不同的方式。许多公司认为基础组织开销太大。Google认为自己是一个系统工程公司，这是一个新的看待软件构建的方式
2，跨越多个数据中心仍然是一个未解决的问题。大部分网站都是一个或者最多两个数据中心。我们不得不承认怎样在一些数据中心之间完整的分布网站是很需要技巧的
3，如果你自己没有时间从零开始重新构建所有这些基础组织你可以看看Hadoop。Hadoop是这里很多同样的主意的一个开源实现
4，平台的一个优点是初级开发人员可以在平台的基础上快速并且放心的创建健全的程序。如果每个项目都需要发明同样的分布式基础组织的轮子，那么你将陷入困境因为知道怎样完成这项工作的人相对较少
5，协同工作不一直是掷骰子。通过让系统中的所有部分一起工作则一个部分的改进将帮助所有的部分。改进文件系统则每个人从中受益而且是透明的。如果每个项目使用不同的文件系统则在整个堆栈中享受不到持续增加的改进
6，构建自管理系统让你没必要让系统关机。这允许你更容易在服务器之间平衡资源、动态添加更大的容量、让机器离线和优雅的处理升级
7，创建可进化的基础组织，并行的执行消耗时间的操作并采取较好的方案
8，不要忽略学院。学院有许多没有转变为产品的好主意。Most of what Google has done has prior art, just not prior large scale deployment.
9，考虑压缩。当你有许多CPU而IO有限时压缩是一个好的选择。
