Python Django+SQL+Pandas+Pyecharts自建在线数据分析平台(十二)

文章来源:Python Django+SQL+Pandas+Pyecharts自建在线数据分析平台(一)
作者:ccpic
感谢:感谢作者 ccpic 分享的优质内容,本网页主要用于学习知识的存档备份,欢迎点击原网页支持作者。
(一)需求分析&技术实现
(二)初步搭建Django环境
(三)页面布局&Django模板
(四)SQL+Pandas初步处理数据
(五)前端表单交互
(六)Ajax异步传参与加载
(七)前端数据格式的处理
(八)DataTables接管前端表格
(九)Pyecharts实现交互图表
(十)静态图表的展示
(十一)“导出数据至Excel”功能
(十二)添加和配置缓存
(十三)用户登录系统
(十四)部署Django至生产环境
缓存机制相当容易理解,无非就是系统在第一次请求时把某段时间内不会发生改变的返回内容存储在更快的介质当中,一段时间内相同的后续请求动作就不需要再重复完整的后端工作,而可以直接从缓存中读取结果。
落实到Django层面上,大部分场景下缓存机制发生在最前端,在模板层和视图层之前,也就是Django的缓存能同时减少重复的数据库请求、视图层的计算以及渲染的过程。
无疑,缓存机制能大大加强系统的性能并同时提升用户体验,但并不是任何场景都适用。如果后台频繁地更新数据,缓存会变得没有意义,且还可能返回某种意义上“错误的“(过时的)response。
**缓存最适合的场景是前端请求频率高+后台更新频率低。**在类似我们这个项目的数据查询项目中,后台的数据更新频率完全取决于行业的不同和数据业务的方向。对于我用来测试的这版等级医院药物销售数据,是非实时更新的月度收集数据,缓存的价值是很大的。
Django支持多种类型的缓存,包括Memcached, Redis,数据库,文件系统,本地内存等等……官方文档是最推荐Memcached的,但在实际操作中我发现Memcached对windows环境支持不佳,所以本章以文件缓存为例。
先在工程的setting.py文件(注意不是app的,是整个工程的setting)中加入缓存的设置语句:
CACHES = { |
具体操作时Django又分为以下5种缓存对象应用到不同内容:
- 整站缓存
- 视图缓存
- URL缓存
- 模板碎片缓存
- low-level API缓存
其中视图缓存和URL缓存应用的场景较多,这两者在大部分时候是等价没区别的。
视图缓存和URL缓存都要先引用缓存装饰器:
from django.views.decorators.cache import cache_page |
缓存装饰器可以放在views.py核心方法的前面,而最重要的是需要声明duration,以秒数为单位。这个值应该充分考虑后台数据的更新频率,并且可以使用公式的方式更加明确这个duration到底是什么:
# 缓存30天 |
视图缓存和URL缓存代码非常简单,需要添加的语句不多。但需要你的返回内容相对每个参数是完全静态的。如果整站缓存或模板层缓存操作需要稍微复杂点,一个要添加中间件,一个要标识缓存DOM。Low-level API缓存操作最为复杂,需要object-by-object地操作。
这时再进行查询,可以观察到缓存文件夹里实时新生成的缓存文件:
实际操作中,缓存过的页面再查询的返回速度变成了毫秒级别,效果很明显。

Django的缓存在应用层面很简单,可以折腾的花样不多。唯一还需要注意的一点是——缓存机制可能对开发环境的测试有所不便,建议开发时把缓存的backend改成下方的dummy。它仅仅实现了缓存的接口而不做任何实际的事情,可以在不修改缓存代码的情况下正常开发测试。
CACHES = { |
如在测试期间遇到经常需要手动删除缓存的情况,可以在app\management\command下建一个clearcache.py(当然别忘了空白的_init_.py)
clearcache.py内容为:
from django.core.management.base import BaseCommand |
之后即可在terminal手动输入命令清除缓存
python manage.py clearcache |


