先来一个数据量运算关系。
1 kilobyte kB = 1000 (103) byte
1 megabyte MB = 1 000 000 (106) byte
1 gigabyte GB = 1 000 000 000 (109) byte
1 terabyte TB = 1 000 000 000 000 (1012) byte
1 petabyte PB = 1 000 000 000 000 000 (1015) byte
1 exabyte EB = 1 000 000 000 000 000 000 (1018) byte
1 zettabyte ZB = 1 000 000 000 000 000 000 000 (1021) byte
1 yottabyte YB = 1 000 000 000 000 000 000 000 000 (1024) byte
1 nonabyte NB = 1 000 000 000 000 000 000 000 000 000 (1027) byte
1 doggabyte DB = 1 000 000 000 000 000 000 000 000 000 000 (1030) byte
迄今为止似乎达到PB级别的就是大的系统了。（我们说的是结构化数据，因为非结构化数据，比如视频，一个电影好几个GB这个不是一个数量级别的）以前有人问过数据量多大时候选什么数据库？其实就是为什么时候选择关系型数据库什么时候选择大数据（hadoop）等。就我个人而言我觉得100TB到500T这个区间是单机、分布式共同的选择。1PB以上单机数据库不太适应。Oracle的exadata能不能搞好我没试过，我本人仅仅有过单表100TB的处理经验。没做过的我不好说，但是单机100TB，对于Oracle MySQL PostgreSQL来说问题不大。但是我听有人说过她们有300T甚至500T的Oracle。
所以500TB以上的单机数据库比较少。在这个以上可能就应该是分布式关系数据库的天下了。你要问我那hadoop呢？那意思是现在的硬件条件下，基本不用他比用他效果更好。现在TiDB和OB两个分布式的国内巨头，如果有500TB左右数据量的可以考虑他们。TiDB排名更好一些。
今天写这个的想法是看到一个PG群里说：分布式数据库第一定理：如果单机主从能解决你的问题，用单机主从。这个观点我是支持的。前面已经说了，我觉得分布式挺好的，属于高端路线解决方案。不过杀鸡不能用牛刀。如果一个系统数据量太小，我见过最小数据量的系统，就是表比数据多。一个库200个表，大部分是空的，有的表就几条数据，加起来不到200条。听起来是笑话是吧？这种excel不能搞吗？如果多人就在线金山文档吧。我在之前的文章中也说过，好好写SQL比起分库分表的代价要小很多。群里大佬说一万亿单机都可以，大佬就是大佬，我就搞过100亿。连1000亿都没有。甘拜下风（主要是我原来公司场景他没这个体量，不能全怪我）
如果真的经历过一个单机数据库被拆成N个数据库改做微服务以后，有这两个的对比的经历的人可能能发现一个问题。就是机器多了，团队人多了，交互多了，组件多了，技术栈多了，一致性差了，稳定性差了，性能低了，成本高了。如果只有单机经历或者只有分库经历没有过对比的，是感受不到这里的差异的。
很多懂行的人都知道单机的架构其实除了扩展以外都不是问题。而一般的数据量单机是足以应付的。当然我这里再次说，达到单机无法处理的还是要发挥出这个赛道的其他产品比如TiDB等等。
有一次看朋友，一位朋友说他当年大概是16C 64G，SATA的硬盘的配置服务了全省的一个系统，其实我也差不多是这样的。而现在你看我刚去京东上查了一下行情。要是20T数据不就是10块硬盘搞定的事情吗？10个插槽就行了。
