如何解决BI反应速度太慢，无法快速做出决策？ - 决策与信息杂志社投稿_期刊论文发表|版面费|电话|编辑部|论文发表- 决策与信息

一、本刊要求作者有严谨的学风和朴实的文风，提倡互相尊重和自由讨论。凡采用他人学说，必须加注说明。二、不要超过10000字为宜，精粹的短篇，尤为欢迎。三、请作者将稿件（用WORD格式）发送到下面给出的征文信箱中。四、凡来稿请作者自留底稿，恕不退稿。五、为规范排版，请作者在上传修改稿时严格按以下要求： 1．论文要求有题名、摘要、关键词、作者姓名、作者工作单位（名称，省市邮编）等内容一份。 2．基金项目和作者简介按下列格式：基金项目：项目名称（编号）作者简介：姓名（出生年－），性别，民族（汉族可省略），籍贯，职称，学位，研究方向。 3．文章一般有引言部分和正文部分，正文部分用阿拉伯数字分级编号法，一般用两级。插图下方应注明图序和图名。表格应采用三线表，表格上方应注明表序和表名。 4．参考文献列出的一般应限于作者直接阅读过的、最主要的、发表在正式出版物上的文献。其他相关注释可用脚注在当页标注。参考文献的著录应执行国家标准GB7714-87的规定，采用顺序编码制。

如何解决BI反应速度太慢，无法快速做出决策？

作者:

关键词:

摘要：

大多数 BI 工具都基于 B/S 架构。浏览器的每次点击都会通过 HTTP 协议向服务器发送一个 Request 请求。报表查询本质上是通过程序翻译将SQL查询命令发送到应用服务器，然后到数据库服务器执行数据查询动作。

如果SQL查询本身比较复杂，底层数据模型没有建立好，或者数据库服务器硬件环境配置本身不好，这个SQL的执行可能会花费很多很长时间。这是第一个时间损失点。第二点，SQL查询可能会返回大量的数据，比如几十万、几百万、几千万、几亿条数据。这个数据最终通过HTTP协议的Response响应打包返回，需要通过网络返回给Browser。在浏览器端，几十万条数据可能有几百兆，几百万甚至几千万条数据可能有几百兆（MB）甚至1GB。试想一下，下载一部电影通常需要多长时间，下载数百兆字节的文件需要多长时间。这与网络带宽有很大关系。这是时间损失的第二点。

数据返回到前面在浏览器端，显示图形时，如果编写了大量复杂的表达式和聚合函数，数据需要消耗本地浏览器所在计算机的大量内存才能完成数据计算。前端指标计算、条件表达式和各种聚合函数设计得越多，所需的时间就越长。这是时间损失的第三点。最后是页面的渲染。图表越多，结构越复杂，列数越多，数据通过 HTML 组织呈现到最终呈现的时间就越长。这是第四点时间损失。

页面加载完成后，HTTP请求终止，服务器断开。

在这个过程中，大量的时间损失主要集中在数据查询、大量数据的返回、前端聚合函数和基于条件表达式的时间损失上。大量数据。因此，报表优化首先要解决的就是在数据库服务器上的查询效率。 SQL的结构和底层数据模型的结构必须合理。这是SQL层面的优化，也是数据模型的优化。同时，减少返回的数据量，减少网络带宽的消耗，返回的数据量小，最终前端聚合和渲染速度也会加快。这样，从查询到返回到展示的整个时间将大大缩短。

有朋友说，用户只是想查询一张二维表上显示的大量数据，或者根据刚才的四点来分析。一是通过设置合理的联动查询条件，逐步减少返回的数据量。其次，通过设置分页来分散每次与服务器交互的查询，也可以减少返回的数据量。三、可以聚合的数据逻辑提前在服务器端完成，计算预先定位，或者采用列数据库或者分布式计算，减少查询阶段的时间消耗，可以实现优化纯二维报告。

当然有朋友说C/S架构的BI工具能不能解决这个问题。 C/S架构的原理是Client客户端和Server服务器的架构。它将数据加载到本地计算机内存中进行计算。在性能和效率上确实比B/S架构快很多。但是C/S架构意味着需要在每个用户的本地计算机上安装一套客户端软件，因为需要安装很多用户，并且在程序升级方面需要单独独立的升级，不适合大规模用户。 .与B/S架构相比，B/S架构的用户只需要通过电脑自带的浏览器随时访问报表，所有程序升级都可以一次在服务器上完成。

B/S架构和C/S架构没有优劣之分，但在不同场景下各有优劣。

文章来源：《决策与信息》网址: http://www.jcyxxzz.cn/zonghexinwen/2021/0626/1159.html