|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-03-23
seele 写道 firebody 写道 seele 写道 SQL需要关联10张表，每张表有1000万数据以上。。最少。。需要进行复杂的查询。需要用多很多ORACLE特有的函数..写完的SQL在100行以上。。
不认为hibernate能够适合这样的环境 这个复杂的统计查询需求你就用SQL查询好了，难道你不知道hibernate也有SQLQuery吗？ 你这么一说，我个人感觉，hibernate的特点在于单体个增删改查上么？ 我认真地看完了前面的帖子，老实地说，楼主对大规模，高并发的项目没有一个明确的印象，或者说没有接触到过。 在税务，银行等系统中，内部系统或者外部系统，hibernate是不适用的 我自己也学习过hibernate，上手很快，做个小的demo出来也很好看。但是就是学习曲线不够平滑。 转变一个观念来学习东西肯定不是一个小demo就能够让你掌握的。 建设银行核心应用系统我参与过开发，我比你要了解得多。 这些系统的开发，对于框架的选择会评估很多东西，银行系统的开发大多都有成年累积下来的框架以及一整套成熟的中间件，数据中心作为核心的应用也是独立开发，然后账务系统以及外围的应用才得以接入进来，这一整套东西都是基本固定的模式，要采纳hibernate这个问题本身已经不是单纯从技术考虑。 所以你举得这些所谓大系统不用hibernate还根本没到考虑所谓性能问题就已经得出答案来，你在这里拿来说hibernate不适用大型系统开发，不知道的人还真被你唬住了。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
joehe 写道 lovemylover 写道 joehe 写道 lovemylover 写道 只有设计良好的模型，才能够真正体现hibernate的作用和优点，不过这个对系统设计者的要求很高，而且往往在实际项目中并没有那么充裕的时间去认真做，这往往也是大家认为hibernate性能不高的原因。你系统设计的不好，却非要怪hibernate不行，我都替它感到冤枉。
另外，关于专业数据库的性能优化问题，一来各种数据库本身的自动优化都已经做的很好了，像之前说的小表驱动问题在Oracle较新的版本中已经自动实现了；另外，如果数据库自己做不了的，比如像索引的指定问题，这个时候也可以使用hibernate的native查询。 总而言之，那些说hibernate性能不行的人，还是从自己身上找找原因吧，你自己的系统是否设计良好？你对hibernate是否真正了解？不然，你都没资格说这样的话。 不知道你是怎么设计的，是不是也是从数据库反向生成的？  我通常是先Power Desinger设计模型，然后生成到数据库。然后反向生成到项目中。这只是具体实现的手段，问题的核心还是在设计上。 那你还是没有用会面向对像设计 楼上的是不是以为PD只用来设计数据库表的啊，你用过pd的OOD功能吗？pd用很强大的UML设计功能你知道吗？！ 一般来说，Rational太过庞大，都使用PD来进行对象设计的 |
| 返回顶楼 | |
|
发表时间：2010-03-23
seele 写道 你这么一说，我个人感觉，hibernate的特点在于单体个增删改查上么？ 我认真地看完了前面的帖子，老实地说，楼主对大规模，高并发的项目没有一个明确的印象，或者说没有接触到过。 在税务，银行等系统中，内部系统或者外部系统，hibernate是不适用的 我自己也学习过hibernate，上手很快，做个小的demo出来也很好看。但是就是学习曲线不够平滑。 呵呵，又见“大规模，高并发”，如果是以前我对这个概念还有点儿印象，那么现在可以说是完全糊涂了，既然出来一个人就说“大规模，高并发”，怎么却一个能准确说出数量级的人都没有哦？ 说实话，我倒是真希望有谁跳出来说：“xx数量级以上的应用，必须用sql，一旦用了hibernate就会出现解决不了的问题。”可惜没有任何一个人能实现我这个微小的愿望，反对者都只能提出一个虚无的词汇“大规模，高并发”。 我觉得这种情况有两种可能。 1。人家这都是机密数据，怎么可能轻易告诉你呢？一旦你学会了，以后知道什么地方应该用sql，什么地方应该用hibernate，岂不是把钱都抢走了？ 2。人云亦云。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
最后修改：2010-03-23
lizhilin 写道 赞同你的观点 我说一个场景吧 每天千万次以上的访问 数据量在千万行以上 采用分库/分表 很多时候sql不是随便写的 楼上的场景是不是自己臆想的啊，太假了。 我自己，包括我认识的朋友，在碰到上千万词访问，且大数据量的时候，用到的多是缓存技术，多个级别的缓存，web文件应用层，当然也包括了数据库层（这里就包括hibernate的缓存技术）。 我的朋友在千橡（校内，现在叫人人）做sns，我在sohu。把具体的公司发出来不是显摆啥，就是要摆事实，不要老用臆想的概念误导大家。 你也可以问问天涯这样的大网站，他们是用缓存技术，还是让用户每次访问去查SQL哈~~~拜托，数据库就是存储为主的！ |
| 返回顶楼 | |
|
发表时间：2010-03-23
firebody 写道 seele 写道 firebody 写道 seele 写道 SQL需要关联10张表，每张表有1000万数据以上。。最少。。需要进行复杂的查询。需要用多很多ORACLE特有的函数..写完的SQL在100行以上。。
不认为hibernate能够适合这样的环境 这个复杂的统计查询需求你就用SQL查询好了，难道你不知道hibernate也有SQLQuery吗？ 你这么一说，我个人感觉，hibernate的特点在于单体个增删改查上么？ 我认真地看完了前面的帖子，老实地说，楼主对大规模，高并发的项目没有一个明确的印象，或者说没有接触到过。 在税务，银行等系统中，内部系统或者外部系统，hibernate是不适用的 我自己也学习过hibernate，上手很快，做个小的demo出来也很好看。但是就是学习曲线不够平滑。 转变一个观念来学习东西肯定不是一个小demo就能够让你掌握的。 建设银行核心应用系统我参与过开发，我比你要了解得多。 这些系统的开发，对于框架的选择会评估很多东西，银行系统的开发大多都有成年累积下来的框架以及一整套成熟的中间件，数据中心作为核心的应用也是独立开发，然后账务系统以及外围的应用才得以接入进来，这一整套东西都是基本固定的模式，要采纳hibernate这个问题本身已经不是单纯从技术考虑。 所以你举得这些所谓大系统不用hibernate还根本没到考虑所谓性能问题就已经得出答案来，你在这里拿来说hibernate不适用大型系统开发，不知道的人还真被你唬住了。 首先我赞成你说的银行的开发内容，不单有历史遗留下来的项目原因，当然也是有对性能的考虑。 其次，我是说hibernate不适合税务，银行等系统。。没有说hibernate不适合其他的大型系统。这个可能你理解得范围大了一些 再其次，楼主对于大型的系统没有接触过，也对前面别人的回帖有一定地反驳，或者是较真。我也只是提出自己的观点和想法 最后，我个人建议在je上大家心平气和地讨论问题，才能得到提高。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
夜是天堂 写道 首先我只想说明有些场景Hibernate是不适用的，并没有全盘否定Hibernate的意思，事实上我自己很多项目都用了Hibernate，包括当前的项目。
如果非要说一个高并发的例子，新浪，搜狐肯定是的，当然我不能断定他们肯定不用Hibernate，但是即使用，也是有限的地方。 再次强调，我没有要炸死Hibernater的意思，我只是表达一些看法而已:) 哥哥，我们不用hibernate是因为我们的系统有很多是在hibernate出现前就存在了，不是因为hibernate不好，我们解决高并发使用的是缓存技术。 你认为google的搜索时基于数据库嘛？Oracle还是DB2啊！！ 不要乱假设。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
最后修改：2010-03-23
linliangyi2007 写道 lizhilin 写道 赞同你的观点 我说一个场景吧 每天千万次以上的访问 数据量在千万行以上 采用分库/分表 很多时候sql不是随便写的 楼上的场景是不是自己臆想的啊，太假了。 我自己，包括我认识的朋友，在碰到上千万词访问，且大数据量的时候，用到的多是缓存技术，多个级别的缓存，web文件应用层，当然也包括了数据库层（这里就包括hibernate的缓存技术）。 我的朋友在千橡（校内，现在叫人人）做sns，我在sohu。把具体的公司发出来不是显摆啥，就是要摆事实，不要老用臆想的概念误导大家。 你也可以问问天涯这样的大网站，他们是用缓存技术，还是让用户每次访问去查SQL哈~~~拜托，数据库就是存储为主的！ 请问我哪里说了让用户每次访问去查SQL 都挑刺就一点意义都没有了 这帖子可以锁了 |
| 返回顶楼 | |
|
发表时间：2010-03-23
seele 写道 首先我赞成你说的银行的开发内容，不单有历史遗留下来的项目原因，当然也是有对性能的考虑。 其次，我是说hibernate不适合税务，银行等系统。。没有说hibernate不适合其他的大型系统。这个可能你理解得范围大了一些 再其次，楼主对于大型的系统没有接触过，也对前面别人的回帖有一定地反驳，或者是较真。我也只是提出自己的观点和想法 最后，我个人建议在je上大家心平气和地讨论问题，才能得到提高。 这样来说，就是你举的例子不恰当了，明明上面在研究性能问题，你却突然插上了一个需要综合考虑才能得出结果的情况。 那你后面银行的例子，似乎不足够证明我没接触过大型并发项目，也没能证明hibernate性能方面到底存在着哪些问题。那你这样冲出来说一句银行不会用hibernate，是为了证明什么呢？ 不客气的说，有点儿搅局的意思了。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
lizhilin 写道 xyz20003 写道 夜是天堂 写道 首先我只想说明有些场景Hibernate是不适用的，并没有全盘否定Hibernate的意思，事实上我自己很多项目都用了Hibernate，包括当前的项目。
如果非要说一个高并发的例子，新浪，搜狐肯定是的，当然我不能断定他们肯定不用Hibernate，但是即使用，也是有限的地方。 再次强调，我没有要炸死Hibernater的意思，我只是表达一些看法而已:) 原谅我这里的较真，因为“高并发”，“大项目”这些词实在太雷人，很容易被一些人作为把柄恶意引用，然后就会出现一群人因为对这些名词的理解不同而引发无谓的争吵，实际上，只要稍微用定语划一个范围就可以免去很多麻烦，毕竟群众的眼睛是雪亮的，只要讲的清楚大家都能明辨是非。
其实在下一直对千万级数据，分库分表的应用心驰神往，可以一直无缘得见，不知道这种项目里的组织机构是如何划分的，是否由dba前期一次性完成所有设计和封装工作，剩下的只要外围应用去调用就可以了。感觉对外部应用的限制很大，在这种项目里玩岂不是很无聊，每天的工作只是调用封装好的东西而已。 
想想sns项目 访问量和数据量 是否由dba前期一次性完成所有设计和封装工作 ----我是很期待这样 但是现实情况是 完全自己做 当然完全靠数据库肯定不行的 这就是其他方面的问题了 这就更假了，你知道现在sns的主流数据库是啥吗？不是SQL了拜托，是对象型数据库Apache Cassandra,FaceBook用的。 我们现在也开始对这块的研究转型。 就算是国内传统的大型SNS，对数据库的优化重点——可以给你透露一下——是自己设计的中间层的查询路由，而不是基于SQL的优化，因为对于大并发量的访问，SQL优化带来的性能杯水车薪啊！！ |
| 返回顶楼 | |
|
发表时间：2010-03-23
seele 写道 SQL需要关联10张表，每张表有1000万数据以上。。最少。。需要进行复杂的查询。需要用多很多ORACLE特有的函数..写完的SQL在100行以上。。
不认为hibernate能够适合这样的环境 这就是设计问题了，在我们公司，设计都通不过，还优化个啥啊！！ |
| 返回顶楼 | |
