首页 > 代码库 > 互联网项目开发效率与系统性能的一个取舍问题

互联网项目开发效率与系统性能的一个取舍问题

问题起源
    今天,leader看了我写的代码,提了一个建议。我在写p2p业务系统的时候,数据库底层使用了“关联查询,left-join”,leader觉得这样性能不好。他建议,不使用关联查询,每次都是单表查询,如果需要查询关联数据,增加一次查询,然后再把两次甚至多次的数据合并。
即通过程序而不是sql,合并数据。

   他的思考逻辑:
   他之前在淘宝工作过,web系统对性能要求比较高。Web前端等程序可以使用分布式,量再大,多台应用服务器就可以应付了。而数据库,最多也就是主从结构,很容易成为瓶颈。使用关联查询,比较耗费性能,并且访问量大的时候,不够稳定。
   他的观点:数据库的核心作用是,提供存储和查询服务,left join等高级查询不是数据库的强项。如果只是用单表,每次都很快,而且有保障,出错的可能性比关联查询小很多,而且单表查询容易做缓存,建索引。

  我的思考逻辑:
   我写的程序基本不考虑性能问题,因为我还没有遇到过性能瓶颈问题,可能是我参与的大多数小访问量的业务系统,而非海量普通消费者用户的大型互联网系统。 
   写程序,最基本的原则是,保证按时交付、质量过关、可读性强、容易维护。

   如果自己去合并多次查询的数据,要多写不少Java代码,显然会增加工作量。

  取舍
  我们正在开发的是p2p系统,如果客户买我们的系统,运营得比较好的话,量也会比较大。为了应对潜在流量大的问题,开发还是需要注意性能。所以,我需要重构代码。这个合并数据的逻辑不难,用node.js写程序的时候,写过。把公共的合并逻辑或者方法,总结下来或写成工具方法,花的时间也可以少点。

  一点实际经验
  从过去的开发经验来看,我也非常只想写“单表查询的sql语句” ,非常容易写。更关键的是,针对一张表的CRUD操作,用Hibernate和Mybatis等数据库框架,可以很容易实现。多张表的CRUD API很难写。

  扩展话题
象性能与效率的取舍等问题 ,在我看来都是一个“标准”或者“最佳实践”的问题。
我想把这5年多学习Web开发的经验,总结下,比如前端用哪些技术、后端Java用哪些框架、管理代码、打包部署 、备份、网站监测。

 为什么想这么做呢?重复的问题,标准话之后,工作会轻松许多。
此外,虽然作为一个技术人员,我还是想通过写程序搞点外快的。 如果常见的功能,我都可以很快地实现,那么在相同的条件下,我可以实现更多的系统,只要有一个可以卖出去,比如5万一套,也是非常多的。

这些都是我的一点想法,希望有一天可以实现,哪怕只是一小部分。 

小雷FansUnion-博学的互联网技术工作者
2014年10月30日
湖北武汉 

互联网项目开发效率与系统性能的一个取舍问题