|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-05-11
想法不错,有参考性,不过有些东西多吸收一些其他朋友意见会更好
|
| 返回顶楼 | |
|
发表时间：2012-05-13
最后修改：2012-05-13
evanzzy 写道 非要拿掉Hibernate的主要原因就是在一个“大”字，做大型网站，是不能用Hibernate的。
我平常做金融类产品居多，深知这个东西的害处。onecan说的对，Hibernate用来做简单操作确实省时省力，使用通用Dao的话那是非常痛快的。但做到后期，分表分库，集群，不同类型数据库混用阶段，Hibernate是重构的第一大障碍。而且这个阶段还涉及到人员的素质问题，Hibernate这东西用好不易，开发人员水平参差不齐，乱写乱用，看似省事，其实隐患很大，此时进行培训改进又遇到各种各样问题导致无法顺利进行。我多次遇到使用Hibernate操作数据库资金管理类库表导致数据不一致记错账的事情，管钱的记错账那都是一级生产事故啊，教训极惨痛。 onecan做的业务和我的领域比较重合，正好我也负责过电子商务网站的后台系统，如果你还不理解为什么要避免使用Hibernate，咱们可以慢慢聊，都是花大钱买来的经验教训，大家就不要再重蹈覆辙了。 道中人，可谓经验之谈啊，深有同感！ 我自己的大型B2B和B2C网站原来也是用Hibernate，但是后来不得不换成mybatis， 第一是用Hibernate 由于它封装得太高了，很多东西是隐式进行的，经常引起问题，很难定位。毕竟凡事有利必有弊； 第二大型网站肯定不是一个数据库，这点Hibernate是很麻烦的，用Jdbc或Mybatis 可以轻松应付之，我自己写的shard分库框架目前就是支持mybatis和Jdbc Template。 另，觉得割舍不了Hibernate的iteyer,其实也是建议直接再用Hibernate，待遇到痛苦时，再换，这样体会会更深些 
|
| 返回顶楼 | |
|
发表时间：2012-05-13
最后修改：2012-05-13
stamen 写道 evanzzy 写道 非要拿掉Hibernate的主要原因就是在一个“大”字，做大型网站，是不能用Hibernate的。
我平常做金融类产品居多，深知这个东西的害处。onecan说的对，Hibernate用来做简单操作确实省时省力，使用通用Dao的话那是非常痛快的。但做到后期，分表分库，集群，不同类型数据库混用阶段，Hibernate是重构的第一大障碍。而且这个阶段还涉及到人员的素质问题，Hibernate这东西用好不易，开发人员水平参差不齐，乱写乱用，看似省事，其实隐患很大，此时进行培训改进又遇到各种各样问题导致无法顺利进行。我多次遇到使用Hibernate操作数据库资金管理类库表导致数据不一致记错账的事情，管钱的记错账那都是一级生产事故啊，教训极惨痛。 onecan做的业务和我的领域比较重合，正好我也负责过电子商务网站的后台系统，如果你还不理解为什么要避免使用Hibernate，咱们可以慢慢聊，都是花大钱买来的经验教训，大家就不要再重蹈覆辙了。 道中人，可谓经验之谈啊，深有同感！ 我自己的大型B2B和B2C网站原来也是用Hibernate，但是后来不得不换成mybatis， 第一是用Hibernate 由于它封装得太高了，很多东西是隐式进行的，经常引起问题，很难定位。毕竟凡事有利必有弊； 第二大型网站肯定不是一个数据库，这点Hibernate是很麻烦的，用Jdbc或Mybatis 可以轻松应付之，我自己写的shard分库框架目前就是支持mybatis和Jdbc Template。 另，觉得割舍不了Hibernate的iteyer,其实也是建议直接再用Hibernate，待遇到痛苦时，再换，这样体会会更深些 1、单库不分表 用hibernate是没有问题的，如果开发人员水平参差不齐，我的建议是只使用Hibernate的单实体CRUD，不使用关联映射或慎重选择。 2、分库分表：当遭遇分库分表 正如stamen说的 痛苦来了，我认为最致命的是一级缓存的延迟flush和二级缓存无法利用。 我自己现在就用hibernate，项目比较小 没有分库分表  其实大部分用hibernate开发企业应用的很少关心性能，如OA因为用的人不可能很多，所以用用也无妨 在合适的地方使用合适的框架
|
| 返回顶楼 | |
|
发表时间：2012-05-14
楼主和我类似，但orm我比较好ibatis或者jdbc这口
|
| 返回顶楼 | |
|
发表时间：2012-05-14
看来大家认为hibernate不太合适做互联网，我曾经也想过是否要换掉Hibernate呢，要用什么来换呢？但想来想去就目前的情况还是hibernate最合适我们。这个要从我们目前的定位和客户需求讲起，我们目标要使得那些使用廉价jsp空间的用户也能使用我们的系统，而且这部分对于我们的推广而言是不可缺少的，
基本的配置能支撑他们能有多大的访问量？ 曾经看到一些数据说国内的大型团购网站的日PV也就是在千万级别，转化为transaction/second = 10000000 / 24/ 3600 = 115.74, 理想状态下每秒只要支持115个请求，一天就能接受1千万的点击量。算高峰值*10 = 115.74, 而单个mysql最大支持的tps也能上到1000个tps, 加上cache，静态页面等已经分担了不少数据库的压力，所以说1台mysql可以支持千万级的日pv的访问量了。前面假设性能弱点在于数据库的情况下，而对于前面可以有apache tomcat等级群在挡着。分表分库离我们的需求还有十万八千里，不过hibernate也可以分的，这个就不在这里展开讲了。 要换掉hibernate的一个原因是我们系统一启动就会吃掉100m的内存，导致部分人出现out of memery. 把hibernate的二级缓存取掉貌似已经降到50-60m了，尚算还可以接受，最新的缓存机制正在研究中。老师曾教导：饭要一口一口吃，路要一步一步走，一个良好的系统是不能一蹴而就的。 |
| 返回顶楼 | |
|
发表时间：2012-05-14
onecan 写道 看来大家认为hibernate不太合适做互联网，我曾经也想过是否要换掉Hibernate呢，要用什么来换呢？但想来想去就目前的情况还是hibernate最合适我们。这个要从我们目前的定位和客户需求讲起，我们目标要使得那些使用廉价jsp空间的用户也能使用我们的系统，而且这部分对于我们的推广而言是不可缺少的，
基本的配置能支撑他们能有多大的访问量？ 曾经看到一些数据说国内的大型团购网站的日PV也就是在千万级别，转化为transaction/second = 10000000 / 24/ 3600 = 115.74, 理想状态下每秒只要支持115个请求，一天就能接受1千万的点击量。算高峰值*10 = 115.74, 而单个mysql最大支持的tps也能上到1000个tps, 加上cache，静态页面等已经分担了不少数据库的压力，所以说1台mysql可以支持千万级的日pv的访问量了。前面假设性能弱点在于数据库的情况下，而对于前面可以有apache tomcat等级群在挡着。分表分库离我们的需求还有十万八千里，不过hibernate也可以分的，这个就不在这里展开讲了。 要换掉hibernate的一个原因是我们系统一启动就会吃掉100m的内存，导致部分人出现out of memery. 把hibernate的二级缓存取掉貌似已经降到50-60m了，尚算还可以接受，最新的缓存机制正在研究中。老师曾教导：饭要一口一口吃，路要一步一步走，一个良好的系统是不能一蹴而就的。 我认为使用hibernate最可能用不好的几个点： 1、关联 2、二级缓存 |
| 返回顶楼 | |
|
发表时间：2012-05-14
Hibernate要是不用，我好像就不会写程序了
|
| 返回顶楼 | |
|
发表时间：2012-05-14
jinnianshilongnian 写道 onecan 写道 看来大家认为hibernate不太合适做互联网，我曾经也想过是否要换掉Hibernate呢，要用什么来换呢？但想来想去就目前的情况还是hibernate最合适我们。这个要从我们目前的定位和客户需求讲起，我们目标要使得那些使用廉价jsp空间的用户也能使用我们的系统，而且这部分对于我们的推广而言是不可缺少的，
基本的配置能支撑他们能有多大的访问量？ 曾经看到一些数据说国内的大型团购网站的日PV也就是在千万级别，转化为transaction/second = 10000000 / 24/ 3600 = 115.74, 理想状态下每秒只要支持115个请求，一天就能接受1千万的点击量。算高峰值*10 = 115.74, 而单个mysql最大支持的tps也能上到1000个tps, 加上cache，静态页面等已经分担了不少数据库的压力，所以说1台mysql可以支持千万级的日pv的访问量了。前面假设性能弱点在于数据库的情况下，而对于前面可以有apache tomcat等级群在挡着。分表分库离我们的需求还有十万八千里，不过hibernate也可以分的，这个就不在这里展开讲了。 要换掉hibernate的一个原因是我们系统一启动就会吃掉100m的内存，导致部分人出现out of memery. 把hibernate的二级缓存取掉貌似已经降到50-60m了，尚算还可以接受，最新的缓存机制正在研究中。老师曾教导：饭要一口一口吃，路要一步一步走，一个良好的系统是不能一蹴而就的。 我认为使用hibernate最可能用不好的几个点： 1、关联 2、二级缓存 你说的这2个确实是不好掌握，因此我们都给去掉了，就是用hibernate做做简单的CURD, 基本不会让hibernate偷偷的干活的，可能有些人说我们没有掌握好hibernate的核心思想了。 复杂的都用jdbcTemplate实现了，要换hibernate我们就会换成jdbcTemplate.当初struts1.x 直接换成spring mvc, 这个时候就整体用spring的解决方案了。 二级缓存我们已经另外实现，参看 http://www.iteye.com/topic/1123669 |
| 返回顶楼 | |
|
发表时间：2012-05-14
最后修改：2012-05-14
onecan 写道 jinnianshilongnian 写道 onecan 写道 看来大家认为hibernate不太合适做互联网，我曾经也想过是否要换掉Hibernate呢，要用什么来换呢？但想来想去就目前的情况还是hibernate最合适我们。这个要从我们目前的定位和客户需求讲起，我们目标要使得那些使用廉价jsp空间的用户也能使用我们的系统，而且这部分对于我们的推广而言是不可缺少的，
基本的配置能支撑他们能有多大的访问量？ 曾经看到一些数据说国内的大型团购网站的日PV也就是在千万级别，转化为transaction/second = 10000000 / 24/ 3600 = 115.74, 理想状态下每秒只要支持115个请求，一天就能接受1千万的点击量。算高峰值*10 = 115.74, 而单个mysql最大支持的tps也能上到1000个tps, 加上cache，静态页面等已经分担了不少数据库的压力，所以说1台mysql可以支持千万级的日pv的访问量了。前面假设性能弱点在于数据库的情况下，而对于前面可以有apache tomcat等级群在挡着。分表分库离我们的需求还有十万八千里，不过hibernate也可以分的，这个就不在这里展开讲了。 要换掉hibernate的一个原因是我们系统一启动就会吃掉100m的内存，导致部分人出现out of memery. 把hibernate的二级缓存取掉貌似已经降到50-60m了，尚算还可以接受，最新的缓存机制正在研究中。老师曾教导：饭要一口一口吃，路要一步一步走，一个良好的系统是不能一蹴而就的。 我认为使用hibernate最可能用不好的几个点： 1、关联 2、二级缓存 你说的这2个确实是不好掌握，因此我们都给去掉了，就是用hibernate做做简单的CURD, 基本不会让hibernate偷偷的干活的，可能有些人说我们没有掌握好hibernate的核心思想了。 复杂的都用jdbcTemplate实现了，要换hibernate我们就会换成jdbcTemplate.当初struts1.x 直接换成spring mvc, 这个时候就整体用spring的解决方案了。 二级缓存我们已经另外实现，参看 http://www.iteye.com/topic/1123669 如果不涉及分表分库（分布式/集群） 二级缓存没有问题，，或者直接弃之，自己写（这样可以根据自己的需求控制） 去下你的代码瞧瞧
|
| 返回顶楼 | |
|
发表时间：2012-05-15
onecan 写道 刚才review了整个帖子，也该做个总结了，总不能虎头蛇尾的，看到到不同朋友的意见，对于我本人也是获益良多。收到了十来个精华贴的投票，也有一些朋友加入了关注，这点还是比较高兴的。上面提到了需要采用图表方式来表达整个系统的，可能要缓一下了，因为我们将会采纳部分意见和根据现有用户的需求来改进我们的系统，例如缓存/模板/搜索等方面。我们将会基于最新的代码来重整思路，届时会图表/文档/代码方式上传上来的。 争取在代码开源的时候能少些批评，多些建议。我们的目标是很简单的，要做Java版的ecshop和ecmall, 使得Java商城相对火起来，商家能用免费或者比较便宜的价格来享用高性能的JAVA商城服务，这些跟技术关系不大，将会在以后的帖子再讨论。 同时我相信那些搞JSP空间和云空间的运营商是比较高兴和支持我们的。另外我们以前在google code发布过代码的，也发布了2个Demo的地址, ITEYE貌似不喜欢我们发外连接，这里就不说了。心急的朋友自己google了。目前Java商城一般只是处于起步阶段，借助开源的力量也许能有的一玩。呵呵
最后非常感谢ITEYE提供的这个平台，能让大家一起交流进步。敬请期待我们更精彩的博文和开源进程。 支持网络协作开发么？可以贡献写代码，把它做好 |
| 返回顶楼 | |
