使用Django从数据库中随机取N条记录的不同方法及其性能实测

【声明】:本文中的实验仅限于特定数据库和特定框架。不同数据库,数据库服务器的性能,甚至同一个数据库的不同配置都会影响到同一段代码的性能。具体情况请在自己的生产环境进行测试。

这里(stackoverflow)有一篇关于使用Django随机获取记录的讨论。主要意思是说

这样获取2个记录会导致性能问题,原因如下:

“ 对于有着相当多数量记录的表来说,这种方法异常糟糕。这会导致一个 ORDER BY RAND() 的SQL查询。举个栗子,这里是MYSQL是如何处理这个查询的(其他数据库的情况也差不多),想象一下当一个表有十亿行的时候会怎样:

  1. 为了完成ORDER BY RAND() ,需要一个RAND()列来排序
  2. 为了有RAND()列,需要一个新表,因为现有的表没有这个列。
  3. 为了这个新表,mysql建立了一个带有新列的,新的临时表,并且将已有的一百万行数据复制进去。
  4. 当其新建完了,他如你所要求的,为每一行运行RAND()函数来填上这个值。是的,你派mysql创建一百万个随机数,这要点时间:)
  5. 几个小时或几天后,当他干完这活,他要排序。是的,你排mysql去排序一个一百万行的,最糟糕的表(说他最糟糕是因为排序的键是随机的)。
  6. 几天或者几星期后,当排序完了,他忠诚地将你实际需要的可怜的两行抓出来返回给你。做的好。;)

注意:只是稍微说一句,得注意到mysql一开始会试着在内存中创建临时表。当内存不够了,他将会把所有东西放在硬盘上,所以你会因为近乎于整个过程中的I/O瓶颈而雪上加霜。

怀疑者可以去看看python代码引起的查询语句,确认是ORDER BY RAND(), 然后去Google下”order by rand()”(带上引号)。

一个更好的方式是将这个耗费严重的查询换成3个耗费更轻的:

如上Manganeez所说的方法,相应的获取n条记录的代码应该如下:

基于Python代码应该简洁优雅的想法,如上的代码似乎可以写成:

就性能问题,请教了stackoverflow上的大神 (虽然被踩和被教育了=。=)

Record.objects.count() 将被转换成一个相当轻量级的SQL请求:

Record.objects.all()[0]也会被转换成一个十分轻量级的SQL请求

Querying all 是一个耗费十分严重的请求

通常情况下Django会不显示其他的结果,这样你不会真正的获取到所有的记录。

任何时候你将一个Queryset转换成list的时候,将是资源消耗严重的时候。

如果我没错的话,在这个例子里,sample方法将把Queryset转换成list。

这样如果你result = random.sample(Record.objects.all(),n) 这样做的话,全部的Queryset将会转换成list,然后从中随机选择。

想象一下如果你有十亿行的数据。你是打算把它存储在一个有百万元素的list中,还是愿意一个一个的query?

在上边Yeo的回答中,freakish回复道:.count的性能是基于数据库的。而Postgres的.count为人所熟知的相当之慢。

某人说过,要知道梨子的滋味,就得变革梨子,亲口尝一尝。

测试环境:

  • Win8.1 pro x64
  • Wampserver2.4-x64 (apache2.4.4 mysql5.6.12 php5.4.12)
  • Python2.7.5
  • Django1.4.6

在一个已有的测试project中新建一个app,数据库是MYSQL:

在models.py中添加模型:

添加一万行数据:

15分钟以后我得到了这个MYSQL表。真的,不骗你,真的是15分钟。看了记录才知道 每次save都要调用一次insert和一次update。。。。下次一定用SQL语句初始化。。。。

先写了个脚本 在manage.py shell中调用了下 结果让我震惊了。我表示不敢相信 又写了view 并在settings.py中添加了显示SQL Query语句的log

这里是写的view:

运行结果如下,第一行是页面显示的时间,后边是Queryset实际调用的SQL语句

令人难以置信的,在10000行的MYSQL表中 方法1的效率是最高的。无论是结果上看(12ms)还是SQL语句的运行时间上看(9ms)方法1甩了其他方法一大截

即便数据量增加到21万,方法1也会比其他两种方法快:

数据量再次提升至百万级别 1066768条数据

第三种方法所用时间长到令人无法接受(19.65秒)。但有意思的是 SQL语句所花费的时间“只有”3.6秒。而大部分的时间都用在python上了。

既然第二种方法和第三种方法都需要random.sample 一个百万个数据的list,那就是说,有大量的时间花费在将SELECT到的结果转化为django对象的过程中了。

此后将不再测试第三种方法

最后,数据量增加到5,195,536个

随着表中数据行数的增加,两个方法的所用的时间都到了一个完全不能接受的程度。两种方法所用的时间也几乎相同。

 

值得注意的是,Mysql数据库有一个特点是,对于一个大表,OFFSET越大,查询时间越长。或许有其他方法可以在offset较大的时候加快select的速度,然而django明显没有做到。如果能够减少这种消耗,方法2明显会优于方法1。

附上三种方法数据量和SQL时间/总时间的数据图表:

table

20131205220333

总时间

 

最后总结,Django下,使用mysql数据库,数据量在百万级以下时,使用

来获取随机记录序列,性能不会比

差。

收藏 评论

关于作者:熊铎

野生业余程序员搞搞Android 玩玩前端 仅此而已 个人主页 · 我的文章 · 19 ·     

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部