=本文内容纯属个人猜想，仅供参考=

=增量数据卡尺和减量数据卡尺=

增量数据和减量数据，本身就是一种源文件+增量和减量和修改数据日志的方式来记录。

本身就是对数据的每一次改动和注释，都可追溯。

比如：

某地星期一，西红柿的售价是5元每斤；西瓜的售价是10元每斤；胡萝卜的售价是2元每斤。

到了星期二，价格有所改变，西红柿变成了3元每斤（记为星期一西红柿价格-2元每斤=星期二西红柿价格）；西瓜变成9元每斤（记为星期一西瓜价格-1元每斤=星期二西瓜价格）；胡萝卜变成3元每斤（记为星期一胡萝卜价格+1元每斤=星期二胡萝卜价格）。

也就是说，当一个大数据，只有一部分有改动，改动只要没有达到百分之五十兼或设定值，那么就只能以日志的方式来存储，避免需要两个三个数据库硬件，一个数据库硬件为源文件数据库，一个数据库硬件为日志改动数据库，还有一个数据库为结果数据库，当用源文件+日志=结果数据库的方式，把结果数据库作为源文件数据库，那么就能够当做新的源文件数据库，这对于不需要调用历史数据的数据库很方便，然而对于需要调用历史数据库的数据，就很成问题。

特别是相互关联数据的调用，这也就导致一个包含100年时间1ZB数据中，可能需要调用的，只是其中特定10年的1GB数据，这就导致了无端的解压缩过程中的硬件调用资源浪费，也就是非要把所有数据都解压缩成压缩前文件，才能应用，那么问题来了，物理考古学家，需要特定10年的物理当时的科研数据，生物考古学家，需要特定100年的生物当时的科研数据，古语言学家需要调用20年当时的语言数据，而物理数据包含在一个100年时间1ZB数据中，生物数据包含在一个1000年1024ZB数据中，语言数据包含在一个5000年4096ZB数据中，怎么弄？

全部都全网在单机，每个使用者对应一个超级电脑用于解压缩，然后索引需要用到的内容？

70亿个使用者呢？是不是需要建造70亿个超级电脑硬件啊？

特别是有很多历史变迁问题，比如10年前，某个学科专有名词的学术名是A，10年后，该学科专有名词的学术名是B，然后每隔一段时间，学术名都有改变，突然一下去找100年前，这个学术名，那就麻烦了。