|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-03-23
gdpglc 写道 1.。可以说每一条SQL语句都是优化的对象。
象这样的sql有什么可以优化的： select c.no, c.name from m_customers; 这条语句如果返回99999万条数据，你觉得不需要优化么？ |
| 返回顶楼 | |
|
发表时间：2010-03-23
lovemylover 写道 joehe 写道 lovemylover 写道 只有设计良好的模型，才能够真正体现hibernate的作用和优点，不过这个对系统设计者的要求很高，而且往往在实际项目中并没有那么充裕的时间去认真做，这往往也是大家认为hibernate性能不高的原因。你系统设计的不好，却非要怪hibernate不行，我都替它感到冤枉。
另外，关于专业数据库的性能优化问题，一来各种数据库本身的自动优化都已经做的很好了，像之前说的小表驱动问题在Oracle较新的版本中已经自动实现了；另外，如果数据库自己做不了的，比如像索引的指定问题，这个时候也可以使用hibernate的native查询。 总而言之，那些说hibernate性能不行的人，还是从自己身上找找原因吧，你自己的系统是否设计良好？你对hibernate是否真正了解？不然，你都没资格说这样的话。 不知道你是怎么设计的，是不是也是从数据库反向生成的？  我通常是先Power Desinger设计模型，然后生成到数据库。然后反向生成到项目中。这只是具体实现的手段，问题的核心还是在设计上。 那你还是没有用会面向对像设计 |
| 返回顶楼 | |
|
发表时间：2010-03-23
听课...
|
| 返回顶楼 | |
|
发表时间：2010-03-23
joehe 写道 lovemylover 写道 joehe 写道 lovemylover 写道 只有设计良好的模型，才能够真正体现hibernate的作用和优点，不过这个对系统设计者的要求很高，而且往往在实际项目中并没有那么充裕的时间去认真做，这往往也是大家认为hibernate性能不高的原因。你系统设计的不好，却非要怪hibernate不行，我都替它感到冤枉。
另外，关于专业数据库的性能优化问题，一来各种数据库本身的自动优化都已经做的很好了，像之前说的小表驱动问题在Oracle较新的版本中已经自动实现了；另外，如果数据库自己做不了的，比如像索引的指定问题，这个时候也可以使用hibernate的native查询。 总而言之，那些说hibernate性能不行的人，还是从自己身上找找原因吧，你自己的系统是否设计良好？你对hibernate是否真正了解？不然，你都没资格说这样的话。 不知道你是怎么设计的，是不是也是从数据库反向生成的？ 我通常是先Power Desinger设计模型，然后生成到数据库。然后反向生成到项目中。这只是具体实现的手段，问题的核心还是在设计上。 那你还是没有用会面向对像设计 这种反向一般会把关系表当作实体生成出来，其实关系表根本不应该作为实体类存在在系统中。应该用inheritance和jointable等方式去除掉实体里的关系类型。 楼主说的一点很对， 大家摆出数据和实例来。继续观望。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
joehe 写道 lovemylover 写道 joehe 写道 lovemylover 写道 只有设计良好的模型，才能够真正体现hibernate的作用和优点，不过这个对系统设计者的要求很高，而且往往在实际项目中并没有那么充裕的时间去认真做，这往往也是大家认为hibernate性能不高的原因。你系统设计的不好，却非要怪hibernate不行，我都替它感到冤枉。
另外，关于专业数据库的性能优化问题，一来各种数据库本身的自动优化都已经做的很好了，像之前说的小表驱动问题在Oracle较新的版本中已经自动实现了；另外，如果数据库自己做不了的，比如像索引的指定问题，这个时候也可以使用hibernate的native查询。 总而言之，那些说hibernate性能不行的人，还是从自己身上找找原因吧，你自己的系统是否设计良好？你对hibernate是否真正了解？不然，你都没资格说这样的话。 不知道你是怎么设计的，是不是也是从数据库反向生成的？ 我通常是先Power Desinger设计模型，然后生成到数据库。然后反向生成到项目中。这只是具体实现的手段，问题的核心还是在设计上。 那你还是没有用会面向对像设计 恩，那你举个面向对象设计的实现方法例子来。我说过了，这只是具体实现的手段，我是这样用习惯了，不要看了几句话就断章取义，谢谢 |
| 返回顶楼 | |
|
发表时间：2010-03-23
berlou 写道 joehe 写道 lovemylover 写道 joehe 写道 lovemylover 写道 只有设计良好的模型，才能够真正体现hibernate的作用和优点，不过这个对系统设计者的要求很高，而且往往在实际项目中并没有那么充裕的时间去认真做，这往往也是大家认为hibernate性能不高的原因。你系统设计的不好，却非要怪hibernate不行，我都替它感到冤枉。
另外，关于专业数据库的性能优化问题，一来各种数据库本身的自动优化都已经做的很好了，像之前说的小表驱动问题在Oracle较新的版本中已经自动实现了；另外，如果数据库自己做不了的，比如像索引的指定问题，这个时候也可以使用hibernate的native查询。 总而言之，那些说hibernate性能不行的人，还是从自己身上找找原因吧，你自己的系统是否设计良好？你对hibernate是否真正了解？不然，你都没资格说这样的话。 不知道你是怎么设计的，是不是也是从数据库反向生成的？ 我通常是先Power Desinger设计模型，然后生成到数据库。然后反向生成到项目中。这只是具体实现的手段，问题的核心还是在设计上。 那你还是没有用会面向对像设计 这种反向一般会把关系表当作实体生成出来，其实关系表根本不应该作为实体类存在在系统中。应该用inheritance和jointable等方式去除掉实体里的关系类型。 楼主说的一点很对， 大家摆出数据和实例来。继续观望。 你用反向生成的时候不会有选择性的吗？关系表是可以不选的，你不选它，自然就不会成为实体类了，你要是不会用，我可以告诉你一个好办法，手动写hbm.xml吧，保证很面向对象 |
| 返回顶楼 | |
|
发表时间：2010-03-23
xyz20003 写道 夜是天堂 写道 看上去楼主应该没做过什么高并发的系统。
对一个高并发系统来说，数据库往往是整个系统的瓶颈。可以说每一条SQL语句都是优化的对象。 实际操作中，开发人员会拿着可能用到的SQL语句与DBA进行充分沟通。从这一点就可以解释，为什么说Hibernate对DBA不友好（你总不能拿着映射关系去找DBA吧）。 另外一点，Hibernate动不动就做join,对高并发系统来说这是一件很奢侈的事情。往往采取数据冗余的方式。 至于数据库迁移，楼主做的项目应该不少，碰到过多少这样的案例？ 当然，Hibernate是一个非常好的东西，对一般项目来说确实能省很多工作量，对高并发系统来说也不是完全不能用，用Hibernate来做简单对象的增、删、改是没有任何问题的。 感谢对我们讨论的问题提出建议，那么恳请这位同志准确的定义一下“高并发”。最好给出大致的数量级别，以及系统反应速度。否则其他人难以通过一个模糊的修饰词汇进行判断哪些情况属于高并发，这样就无助于我们根据具体的情况来选择使用的技术。还记得以前有人告诉过我，mysql可以撑住300w的数据存储，数据量超过300w，oracle的价值就体现出来了。这方面我确实没有经验，因此再谈到这类话题，我还是要提醒对方这是听到的。那么这里所说的 “高并发”到底属于一个级别呢？希望同志能给出一个大致的范围，这样有同类开发经验的朋友才有可能加入讨论，与我们分享宝贵经验，先谢谢了。 PS：我们遇到的项目应该不叫数据库迁移，而是面向的客户会选择不同的数据库，一般是mysql，sqlserver和oracle这三者中，因此我们需要提供这三个数据库下都能运行的系统。 具体多少数字算高并发，我给不了，应该也没严格的定义。毕竟一个求1+1=几的系统和一个求2的n次方的系统是不一样的。 务实的数据总是来之经验，最好的方法是在相同的环境下做测试、比较。楼主不妨假设一个场景，然后让正反双发出优化方案。 “关键不是在技术，而是在人”这句话很有道理，我们普遍认为Linux/Unix系统做服务器性能比Windows系统要好，我就见过一个 Windows系统高手优化的系统，性能比Linux系统要好得多（Linux系统也有专人优化）。 人的较量+技术的较量 决定最后的成败（扯远了...） 至于产品的数据库兼容问题，我想大部分产品都没什么性能问题，因此也就不再我们讨论的范围内。对于有性能压力的产品，恐怕需要提供不同数据库平台的SQL脚本，和优化手册了（这也是我们常见的）。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
夜是天堂 写道 具体多少数字算高并发，我给不了，应该也没严格的定义。毕竟一个求1+1=几的系统和一个求2的n次方的系统是不一样的。 务实的数据总是来之经验，最好的方法是在相同的环境下做测试、比较。楼主不妨假设一个场景，然后让正反双发出优化方案。 “关键不是在技术，而是在人”这句话很有道理，我们普遍认为Linux/Unix系统做服务器性能比Windows系统要好，我就见过一个 Windows系统高手优化的系统，性能比Linux系统要好得多（Linux系统也有专人优化）。 人的较量+技术的较量 决定最后的成败（扯远了...） 至于产品的数据库兼容问题，我想大部分产品都没什么性能问题，因此也就不再我们讨论的范围内。对于有性能压力的产品，恐怕需要提供不同数据库平台的SQL脚本，和优化手册了（这也是我们常见的）。 具体数字给不了很正常，但是连规模描述都不说清楚一下，就有误导观众的嫌疑了。不怕您怪罪，您在这里抛下一个“高并发”的爆弹，却不说明这个爆弹的杀伤范围，基本就等于把所有人都炸死了，以后再遇到客户有任何并发要求，没多少经验的人心里都会敲鼓，暗自念叨：“据说hibernate搞不定高并发啊，咱们还是用别的吧。”所以至少给一个大略的范围，百万，千万，上亿，这样也给我们这些没做过高并发的同志们一个标杆可以衡量。 技术和人的比较，我不是很赞成，因为我们偏向业务系统，目标是项目成功，而不是培养出超人来，一个技术是否能被广泛接受，关键是看它是否易用，能否满足开发者群体中大部分需求，如果一个工具是为高手专门准备的利刃，那么在开源世界里就等于给自己判了死刑。不否认确实拥有因为xx人的无上神力化腐朽为神奇，可是这种奇迹不能改变历史的潮流。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
夜是天堂 写道 xyz20003 写道 夜是天堂 写道 看上去楼主应该没做过什么高并发的系统。
对一个高并发系统来说，数据库往往是整个系统的瓶颈。可以说每一条SQL语句都是优化的对象。 实际操作中，开发人员会拿着可能用到的SQL语句与DBA进行充分沟通。从这一点就可以解释，为什么说Hibernate对DBA不友好（你总不能拿着映射关系去找DBA吧）。 另外一点，Hibernate动不动就做join,对高并发系统来说这是一件很奢侈的事情。往往采取数据冗余的方式。 至于数据库迁移，楼主做的项目应该不少，碰到过多少这样的案例？ 当然，Hibernate是一个非常好的东西，对一般项目来说确实能省很多工作量，对高并发系统来说也不是完全不能用，用Hibernate来做简单对象的增、删、改是没有任何问题的。 感谢对我们讨论的问题提出建议，那么恳请这位同志准确的定义一下“高并发”。最好给出大致的数量级别，以及系统反应速度。否则其他人难以通过一个模糊的修饰词汇进行判断哪些情况属于高并发，这样就无助于我们根据具体的情况来选择使用的技术。还记得以前有人告诉过我，mysql可以撑住300w的数据存储，数据量超过300w，oracle的价值就体现出来了。这方面我确实没有经验，因此再谈到这类话题，我还是要提醒对方这是听到的。那么这里所说的 “高并发”到底属于一个级别呢？希望同志能给出一个大致的范围，这样有同类开发经验的朋友才有可能加入讨论，与我们分享宝贵经验，先谢谢了。 PS：我们遇到的项目应该不叫数据库迁移，而是面向的客户会选择不同的数据库，一般是mysql，sqlserver和oracle这三者中，因此我们需要提供这三个数据库下都能运行的系统。 具体多少数字算高并发，我给不了，应该也没严格的定义。毕竟一个求1+1=几的系统和一个求2的n次方的系统是不一样的。 务实的数据总是来之经验，最好的方法是在相同的环境下做测试、比较。楼主不妨假设一个场景，然后让正反双发出优化方案。 “关键不是在技术，而是在人”这句话很有道理，我们普遍认为Linux/Unix系统做服务器性能比Windows系统要好，我就见过一个 Windows系统高手优化的系统，性能比Linux系统要好得多（Linux系统也有专人优化）。 人的较量+技术的较量 决定最后的成败（扯远了...） 至于产品的数据库兼容问题，我想大部分产品都没什么性能问题，因此也就不再我们讨论的范围内。对于有性能压力的产品，恐怕需要提供不同数据库平台的SQL脚本，和优化手册了（这也是我们常见的）。 赞同你的观点 我说一个场景吧 每天千万次以上的访问 数据量在千万行以上 采用分库/分表 很多时候sql不是随便写的 |
| 返回顶楼 | |
|
发表时间：2010-03-23
首先我只想说明有些场景Hibernate是不适用的，并没有全盘否定Hibernate的意思，事实上我自己很多项目都用了Hibernate，包括当前的项目。
如果非要说一个高并发的例子，新浪，搜狐肯定是的，当然我不能断定他们肯定不用Hibernate，但是即使用，也是有限的地方。 再次强调，我没有要炸死Hibernater的意思，我只是表达一些看法而已:) |
| 返回顶楼 | |
