图数据库 | 21、无深度，不成图！

书接上文，图数据库如何做容量规划呢？

图系统的容量一直是个非常有趣的问题。笔者试图从两个角度来帮助读者厘清并抓住系统容量规划的核心，核心问题解决了，其他问题自然迎刃而解。

·受大数据流派影响而追求万亿级图系统；

·受传统数据库影响对于数据容量的计数偏差。

受到大数据浪潮的洗礼，很多技术人员在刚开始接触图系统的时候，会很容易把Hadoop/HDFS的理念套在图系统上面，并且直接把系统的数据容量预期设置为“万亿”量级，尽管现在手头的数据在可预见的未来连1亿都没有。

关于图的容量大小，本质上取决于业务，或者说是真实世界的挑战用何种数据、何种建模方式来解决，而不是能否去构建万亿级图系统。

这个问题如果搞反了，一定是本末倒置。如果用Hadoop（或Spark）的模式去做图系统，当然可以存储万亿级的数据，老夫在前面的内容中已经多次提及相关的议题，然而这种系统能存下数据却未必能完成计算，这才是致命的。

换言之，图系统解决的挑战是对多维数据的关联、穿透、下钻和聚合，并在更短的时间、更低的（硬件）资源消耗情况下完成任务，这些任务都是计算驱动的，以计算为核心的。

笔者发现业界在近些年有一个趋势，就是在突出存储与计算分离的同时，又忽略了计算的时