一英里不是个很长的距离，一立方英里相对于地球也不会让人觉得是个很大的空间。然后我说，这个空间内能装下全世界所有人，你会不会觉到很惊讶？其实不过这话不是我说的，是美国作家房龙写的。
业内有个著名的数据仓库产品，叫 Teradata，30 多年前起这个名字，显然是想给人能处理海量数据的感觉。然而现在，很多数据库厂商谈起可处理数据量时，TB 已经是最小单位了，经常说到 PB 甚至 ZB 级别。似乎 T 不是个多大的数，几百 T 上 P 也没什么大不了的。
其实 T 有点象上面说的立方英里，是个挺大的数。很多人对它没有多深的感性认识，我们要换个角度来看 1T 数据对于数据库意味着什么。
数据库主要处理结构化数据，其中占据空间最大的是不断增长的交易类数据，这种数据每条并不大，精简地存储大概只要几十到 100 字节，比如银行交易只要记下帐号、日期、金额；电信的通话记录也只是通话号码、时刻、时长等。先按 100 字节算，也就是 0.1K，那么 1T 空间就可以放下多少呢，大概 100 亿条！
这是什么概念呢？一年大概是 3000 多万秒，如果用一年时间来积累 1T 数据，那意味着每秒要产生约 300 笔记录，24 小时不停息！
这个数也不算大，象中国这样的大国，电信运营商、全国级银行以及大型互联公司都不难有这种规模的业务量。但对于一个城市级别以及有些省级机构就是个不小的数了，比如税务部门采集的企业交税信息、连锁超市的商品购买数据、城市商业银行的交易记录等，要达到平均 300 笔 / 秒并不容易，很多机构只有白天或工作日才能产生数据。而且这还只是 1T，要搞到几十几百 T，那就得让业务量再上一两个数量级才行。
简单说有多少 T 数据是没什么感觉的，换算成每秒对应的业务量后，才知道到底意味着什么。
有些不算顶级头部的机构确实也有几百 T 以及 PB 级的数据量，这又是怎么回事呢？
图像音视频这种非结构化数据，随便一条就几 M 几十 M，冲到 PB 很容易；但这些数据不会放在数据库中计算。
机构中各个业务系统 N 年的数据，这个一年二百 G，那个一年五十 G，再有些计算出来的冗余中间结果，东加西加，积累到几百 TB 上 PB 的总量也是可能的。这些数据可能存储在数据库中，但通常并不会在同一个计算任务中同时出现。
设备自动采集的数据或者用户的行为数据，每秒产生几百条甚至上万条也正常，一年下来也可能有几百 T 到 PB 级。这个场景确实需要数据库能处理比 TB 级以及更大的数据量了，但这种平凡数据用处很少，计算逻辑也非常简单，基本上就是找到取出。
那么我们再来看看，能处理 TB 级数据量的数据库会什么样子的呢？有些数据库厂商宣称能在数秒内处理 TB 甚至 PB 级数据，用户经常也这样期望，这是真地吗？
要处理数据，起码都要读一遍吧。我们按高速的固态硬盘计算，每秒能读 300M（不能看硬盘厂商标的数，在操作系统中根本达不到），那么 1T 数据只是读取不做任何运算也需要 3000 秒，接近一小时！怎么可能数秒内处理 1T 数据呢？很简单，搞 1000 块硬盘，就可以在 3 秒左右读出 1T 数据了。
这是理想的估算。实际上数据不大可能存放着那么整齐，硬盘不连续读取时性能下降严重；1000 块硬盘显然不会在一台机器上，那集群还有网络延迟，有些运算可能还有回写动作，比如排序和关联等，秒级访问常常还会有并发需求，这些因素综合起来，再慢几倍也是正常的。
也就是说，1T 数据可能意味着几个小时，或者几千块硬盘。而且还是前面的话，这只算了 1T，可想而知几十上百 T 会是什么概念了。
大家如果有网上传输文件的经验也能知道，搬动 1T 数据现在也是很难的，最快的办法很可能是拿着硬盘走。这也能体会到 1T 真地很大。
其实，绝大多数用户的绝大多数计算任务涉及的数据量上限也就是几十 G 到几百 G 的规模，达到 TB 级的很少，而这，也常常会让分布式数据库跑出几个小时了，大家可以回看一下自己手上那么跑得很慢的任务是不是这样。因为计算逻辑可能很复杂，出现反复遍历和回写的情况并不罕见，实际在跑的分布式数据库节点数通常就几个到十几个而已，真不容易造出几千块硬盘的环境。这时候算上几个小时一点也不奇怪，这几乎是金融业跑批任务的常态。
即使那些头部大机构，总数据量真有 N 个 PB 的，计算中心也有几千上万个节点，但大部分任务也还是这种几十到几百 G 规模的，分配给某个任务的虚拟机数量也还是 10 个左右，机构大了，事也多，不可能把资源都分给一个任务了。
PB 级数据量在许多机构中是真实存在的，但主要是个存储概念，而不是计算需求。总数据量达到 PB 级，就需要 PB 级处理能力的数据库，这是数据库封闭性缺陷导致的恶果，存在并不意味着合理，事实上是个糟糕的解决方案，这个话题我们以后再专门讲。
1TB 对于用于分析计算的数据库来讲，是个很大的数据量，Teradata 这个名字，今天也不算过时。能流畅计算 TB 级规模的数据量，比如能把几小时缩减到几分钟，优化用户体验；或者能把小规模分布式环境简化到单机，从而大幅降低运维成本，已经很有意义了。嗯，这就是 esProc SPL。
追求 PB 级的计算能力，对于绝大多数用户场景而言，即没必要也不现实。
