这里有一个数据，这是10%的增量，这是按照15%的增量，都到了万亿级别，所以我们当时在考虑解决这个问题的时候，可能跟你们在考虑解决你们问题的时候类似。这是其中一类的数据量，另外还有的数据量，就是到网上大量爬一些数据，跟某些特定用户关系的一些数据爬回来，还有大量的报表等等，它是一个金融机构，也要爬回来，所以这样的话就意味着，我们当时面对这些数据的类型跟你们今天面对的数据类型非常接近，这是为什么拿这个例子来讲的原因。
这是我们当时用来处理设计的目标，这里面有几个点想提醒一下。
一、数据规模。未来整个数据库最终会有多大规模。这个规模设计的目标是到几十万亿条规模设计的。100以上的PB，我们心目中的目标是按照EB这个级别来设计的，可以设想一下，如果一个节点10个硬盘，1个硬盘按照在2TB，可以看到这里要有多少个节点，如果再乘以3，或者再乘以1.75，就可以算出来。这是每一个物理的节点上面会有多少个数据，这是每一个系统里面对这些数据进行索引有多少个元数据。
二、带宽规模。在峰值的时候需要多大的带宽。
三、性能。每秒钟100K，10万到100多万的级别，同时它的响应必须在10个毫秒以内。这个地方是说，支撑的共识用户数几百万人，现在像腾讯都是几十个Million，已经是非常高的人数了。
四、高可用、弹性扩展、长期存储。一个数据能够在底下存多久，所以这个是我们当时对刚才那个需求的一个总结。
五、容错。这个系统必须是容错的。性价比要足够的低，如果成本太高了是没人用的。
刚才谈到，如果用低端的机器降低了成本，但错误率提升，错误可能发生在硬盘、机器、网络、机器和机器的交互上面。容错是必须面对的一个重要方面。用低成本的设备必须是容错的，无论是使用现存的云服务还是自己做，这一点都逃不掉。
No SPOF，讲容错是说一个数据进来，不管哪个环节出了问题，系统都能够自动地恢复，恢复是有度的，如果我存了三份，分别把三份存在不同的盘、不同的机器节点上面，在三个不同的机器分布在不同盘上面，同时出错的概率是非常低的，这里面很重要的节点，当我这个系统，如果我把一个提交给你在系统的每一个层次里面任何一层上面都不能只有一个单点来应对，在第一版的Hadoop上面就是一个单点，它的NameNode就是一个单点，二版的把它改变了Active/Passive，也会有一些问题，这个是说我这个节点死了，马上再启动另外一个节点，这中间对于规模比较大的，频度比较高的应用，这个中间启动切换的1秒钟或者0.5秒钟就有大量的数据传上来，就可能丢失了。
Facebook曾经做过一个，把HBase做成Active/Active，它专门有一支团队做这个事情，两边同时在写，对底下的存储层来说必须要处理，这两边同时写和原来系统里面写是什么关系，是不是需要注意到分布式过程中间的数据是不是能保持一致？这个是非常复杂的。
这几个数据大家一定要看。一次寻盘要10个毫秒，换句话说，如果数据在盘上，当你的请求是要来查这个数据的时候，假如一次读盘能把这个数据找到至少需要10个毫秒，这是什么意思呢？10毫秒×100就是1秒，假如这个盘上有你要的数据，每秒钟能够支撑的寻盘就只有100个，假如你的共识的并发是在每秒钟10万的话，数据分布在N个盘里面才能支持每秒钟10万。设想一下，在这种情形下，如果所有的东西都在盘里面是不是很困难，或者目前的盘是不是做不到。这个10毫秒还是说这个盘是空的，随着盘的数据存的越来越多，每次到盘上去读的，找到数据的可能性就越低。换句话说，有的时候高达10次读盘找不到你的数据，可能要多15次、20次，为什么呢？现在数据量都是几个T的，管理这个数据的文件系统会把其中一部分缓存起来，不会全部缓存起来，没有缓存起来就到盘上读，读的是倾向于某个地方存这个数据的地方，相关的质证是在10个地方，才能找到数据。这些基本的东西在你们考虑的时候一定要考虑进去。
考虑数据从备份到M/S、MM、2PC、Paxos，是说数据的一致性。也是谷歌的例子，这是经验性别东西在里面。一致性交易。这个一致性在Backups就是Weak，在Backups里面没有交易，比如你要做M/S里面，你只能做到Eventual Consistency，这是什么意思呢？最终一致性。最初的问题来源是同时往三个地方写了三份数据，这个三份数据之间是不是一致的我们不知道，需要通过一些特殊的方式来保证。往往这种情况下，构建新的数据时，传统要等三个一致的时候才能回过去说数据完整的写好了。现在可以是两个一致，或者是一个写进去，就可以知道数据写进去不会丢了，等到那两个再返还回来时再确定它是一致的。还有若干的细节，包括分布式的讨论。