往返读取后台数据的代价

数据库最重要是的为前台应用服务。 在众多决定应用性能的因素中, 如何快速有效从后台读取数据很大程度上地影响到最终效果。本文将对不同的数据往返(round-trip)读取进行比较和归纳总结。最后的结果非常出人意料。往往在时间紧迫的情况下,我们会本能地使用最简单的方法来完成任务,但是这种编译习惯会让我们的前台应用的性能大打折扣。

返回 15,000 条数据:这个测试会从一个表格里面读取15000条数据。我们通过用三种不同的编译方式来看如何提高数据库提取的效率。

以下这个脚本用来创建表格然后放入一百万条数据。因为我们需要足够多的数据来完成3个测试,每个测试读取新鲜的数据,所以创建了一百万条。我创建的这个列表每15000条数据一小组,这样确保了测试读取15000条数据的准确性。不会因为数据的不同,而影响测试的结果。

这个脚本稍作修改就可以放在MS SQL服务器上跑:

测试-:基本代码

最简单的代码就是通过一个直白的查询语句跑15000次往返。

测试二:准备语句(Prepared Statement)

这个代码通过在循环前做一个准备语句,虽然还是跑15000个往返,但是每次只是变化准备语句的参数。

测试三:一个往返

我们准备一个语句命令去拿到所有15000条数据,然后把他们一次返回过来。

结果

 

 

一共跑了5次,平均结果如下

基本 准备 一次往返
~1.800 秒 ~1.150 秒 ~0.045 秒

相比基本代码,最后一个一次往返的逻辑快了大概40倍,比用准备语句快了25倍左右。

服务器和语言是否会影响性能呢?

这个测试是在PHP/PostgresSQL上做的。其他语言和服务器上会不会得到不同的结果呢?如果是同样的硬件,有可能这个数据绝对值会有所差异,但是相对的差距应该是差不多。从一个往返里面读取所有要索引的数据条比人和多次往返的语句都要快。

活用活学

这次测试最显而易见的结论就是任何多于一条数据的索引都应该使用这个方法。实际上,我们应该把这个设置为默认语法,除非有绝好的理由。那么有哪些好理由呢?

我跟我们的程序员聊过,有一位同学说:“你看,我们的应用每次都是只要20-100个数据。绝对不会多了。我实在想象不出20-100个数据的读取值得翻新所有代码。”所以我听了以后,又去试了一下,实际上是这个方法确实只有100以上的才能看见显著区别。在20的时候,几乎没有区别。到了100, 一次往返的比基本的快6倍,比第二种方法快4倍。所以,使用与否的判断在于个人。

但是这里还有一个要考虑的因素是有多少同时进行的读取在进行。如果你的系统是基于实时的设计,那么就有可能是不同的情况。我们这个测试是基于一个用户,如果是多个用户同时读取,这种用户行为会带给数据库一些额外的负担,我们需要一个更加宏观的环境来比较。

还有一个反对的声音有可能是“我们是从不同的表格里面读取数据。我们在某些线程上我们走一条条的,需要从不同的表格里面一条条读取。”如果是这样的话,你绝对需要使用一次往返,用几个JOIN一次拿到。如果一个表格,都是慢10倍,几个就慢好几十倍了。

 

原文:database-programmer    编译:伯乐在线 – 潘文佳

【如需转载,请标注并保留原文链接、译文链接和译者等信息,谢谢合作!】

1 收藏 评论

关于作者:潘文佳

潘文佳:软件工程师。从事iPhone/iPad、Android手机应用开发。关注移动应用产品设计和市场展望。(新浪微博:@小粉豬潘小佳) 个人主页 · 我的文章

相关文章

可能感兴趣的话题



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