大规模数据展示该怎么做

数据库管理-第344期 大规模数据展示该怎么做（20240703）

胖头鱼的鱼缸4_01.png

在上周山东济南的大会期间，邦德提出了一个场景的问题，如果需要查询一个月（大概大几百GB）的数据，怎样才能更快的展示出来，为此咱们进行了一些探讨。 首先在不考虑需求是否合理的情况下，查询大规模数据可能会出现这些情况：按照相同条件使用count很快就能得到结果集行数的结果，但是做全量显示则会耗费很多时间，其实出现这种情况还是两个最终展示的数据量，众所周知查到数据结果后，数据库需要将需要的数据传输到应用程序再作展示。我们以100GB数据万兆网络的理想情况为例，大概需要100×1024÷1250=81.91s，接近一分半的时间（实际情况网络不可能满速，数据库内执行语句还需要时间，整体耗时还会更久）对于一些需要看数据人可能会觉得转圈比较久了。

cs.png

这种情况下我们往往可以通过分页查询来解决，每个分页仅展示一部分数据，单个页面需要传输的数据量小了，展示速度也就更快了。但是数据展示的要求往往是不可控的。

页面展示方式.png

在讨论中我们还考虑了是不是可以通过MPP/分布式来加速，最终结论是需要的结果需要汇总，这还是看网络。

cs1.png

在我维护过的数据库中，其实也出现过类似的问题，到了月底月初进行月结的时候，会有大量的人来查询几乎相同的内容，查询人数和数据量都是比较大的，这种情况往往会造成巨大的IO消耗，查询越多，查询效率可能会被拖得越慢，引起一些列性能问题。和前面邦德的需求类似，既然输出结果在一定周期内是没有多大变化的，那么是不是可以提前生成对应的结果集，以合适的方式存放在合适的位置，供应用访问，这样就不用每次都把压力给到数据库了。 但是这样就能解决尽可能快的展示结果么，还真不一定，毕竟页面到应用，应用读取已生成的结果集，还是得靠网络传输，还是得消耗不少的时间。这时候是不是进一步考虑，将这种大数据量展示的结果内容，在需要的时间点之前生成离线结果后在一个地方持续展示，这样需求的人就可以直接看到结果了，但是如果数据量真的很大，用来持续展示的软硬件基础要求也不低。 最后回到最早的那个前提，按照首席的说法就是，这个需求是否是合理的，取大规模数据是一定要花时间的，这和即时全量展示本质就是冲突的，耗时是否能被接受，或者取这么大规模的数据并展示的需求是否合理。