|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-03-24
linliangyi2007 写道 lizhilin 写道 赞同你的观点 我说一个场景吧 每天千万次以上的访问 数据量在千万行以上 采用分库/分表 很多时候sql不是随便写的 楼上的场景是不是自己臆想的啊，太假了。 我自己，包括我认识的朋友，在碰到上千万词访问，且大数据量的时候，用到的多是缓存技术，多个级别的缓存，web文件应用层，当然也包括了数据库层（这里就包括hibernate的缓存技术）。 我的朋友在千橡（校内，现在叫人人）做sns，我在sohu。把具体的公司发出来不是显摆啥，就是要摆事实，不要老用臆想的概念误导大家。 你也可以问问天涯这样的大网站，他们是用缓存技术，还是让用户每次访问去查SQL哈~~~拜托，数据库就是存储为主的！ 千橡，sohu这种网站架构都是前端有squid server, 后端集群app server, 个人觉得并不是高并发场景。 大型网络游戏，比如Wow（随便举例）, real time统计每个人的积分排名，每个公会的排名，简直太费劲了。有些可以定时刷新的统计不算。 |
| 返回顶楼 | |
|
发表时间：2010-03-24
guanliScott 写道 gdpglc 写道 1.。可以说每一条SQL语句都是优化的对象。 象这样的sql有什么可以优化的： select c.no, c.name from m_customers; 2 join不好吗？ 你的意思，不用join，用多次查询数据库的办法获得数据？ 1.。可以说每一条SQL语句都是优化的对象。 象这样的sql有什么可以优化的： select c.no, c.name from m_customers; ****a. 上亿的注册用户，考虑是否需要分页，是否需要按国家，按号码区间查询，必须用hints严格指定索引，不许order by, 按照每个字段排序都作成索引 2 join不好吗？ 你的意思，不用join，用多次查询数据库的办法获得数据？ ****3千万数据的table join 2亿数据的table, 你试试。（现实项目的数据库） 根据具体情况，解决方法有很多。 1.。可以说每一条SQL语句都是优化的对象。 象这样的sql有什么可以优化的： select c.no, c.name from m_customers; ****a. 上亿的注册用户，考虑是否需要分页，是否需要按国家，按号码区间查询，必须用hints严格指定索引，不许order by, 按照每个字段排序都作成索引 你说的很有道理，我很同意，我的确没想这么多。但是我觉得，是否需要优化，和软件的非功能性需求有很大关系， 而这个并不是能从sql上直接看出来的，解决方案应该也不都是DBA给出的。这更象是根据实际场景的一种设计决定。 我想表达的是，软件的性能问题，不是一个sql就决定了的，DBA真那么重要吗？ 不好意思我没这方面经验，这里向各位求教了。 难到一个软件团队，还要搭配一个DBA？ 2 join不好吗？ 你的意思，不用join，用多次查询数据库的办法获得数据？ ****3千万数据的table join 2亿数据的table, 你试试。（现实项目的数据库） 根据具体情况，解决方法有很多。 这个我也同意，只是这时sql也不灵了呀，用这个指责hibernate不是没意义吗？ |
| 返回顶楼 | |
|
发表时间：2010-03-24
gdpglc 写道 guanliScott 写道 gdpglc 写道 1.。可以说每一条SQL语句都是优化的对象。 象这样的sql有什么可以优化的： select c.no, c.name from m_customers; 2 join不好吗？ 你的意思，不用join，用多次查询数据库的办法获得数据？ 1.。可以说每一条SQL语句都是优化的对象。 象这样的sql有什么可以优化的： select c.no, c.name from m_customers; ****a. 上亿的注册用户，考虑是否需要分页，是否需要按国家，按号码区间查询，必须用hints严格指定索引，不许order by, 按照每个字段排序都作成索引 2 join不好吗？ 你的意思，不用join，用多次查询数据库的办法获得数据？ ****3千万数据的table join 2亿数据的table, 你试试。（现实项目的数据库） 根据具体情况，解决方法有很多。 1.。可以说每一条SQL语句都是优化的对象。 象这样的sql有什么可以优化的： select c.no, c.name from m_customers; ****a. 上亿的注册用户，考虑是否需要分页，是否需要按国家，按号码区间查询，必须用hints严格指定索引，不许order by, 按照每个字段排序都作成索引 你说的很有道理，我很同意，我的确没想这么多。但是我觉得，是否需要优化，和软件的非功能性需求有很大关系， 而这个并不是能从sql上直接看出来的，解决方案应该也不都是DBA给出的。这更象是根据实际场景的一种设计决定。 我想表达的是，软件的性能问题，不是一个sql就决定了的，DBA真那么重要吗？ 不好意思我没这方面经验，这里向各位求教了。 难到一个软件团队，还要搭配一个DBA？ 2 join不好吗？ 你的意思，不用join，用多次查询数据库的办法获得数据？ ****3千万数据的table join 2亿数据的table, 你试试。（现实项目的数据库） 根据具体情况，解决方法有很多。 这个我也同意，只是这时sql也不灵了呀，用这个指责hibernate不是没意义吗？ 呵呵，我从没有说过hibernate不好，性能不好怎么会是J2EE的标准实现。没有什么不好的技术，只有不恰当的使用。我只是从我的理解，举了几个互联网app的大数据，高并发的场景。无论用什么技术，如果在设计的时候不去深入考虑问题，最后都可能得不到好的结果。 |
| 返回顶楼 | |
|
发表时间：2010-03-24
我们一般是团队没有专职DBA，有指定的DBA支援。
数据库设计团队做，DBA要看。 SQL代码设计团队写，DBA不主动去看，团队要识别性能问题点主动找DBA。 测试中的性能问题是一定要一起坐下来看的。 如果数据量大一些，性能方面的考虑要尽早，基本冒烟过了压力测试就会冲上来。 |
| 返回顶楼 | |
|
发表时间：2010-03-24
最后修改：2010-03-24
miaow 写道 抛出异常的爱 写道 下一个项目的同志门就把opensessioninview 研究明白上了。
之后有人把set 查出来在页面上过滤set找到对应的实体用来显示。。。。。。。 这辈子没见过那么精彩的数组变幻了 PS：想当年我是救火队的， 为了能看的懂，自己摸着改代码， 实在是在一个页面中上百个不同的属性 有相似的不相似的。 你说我E文差我也认了。 没法子想要改就得看的懂。 求数组变换，长个见识。 老抛的这个项目是不是为了性能以数据库设计为核心，映射写得很憋屈，只能硬顶着处理。 这种情况确实郁闷。 呸根本上是由于那个程序员懒。。。。。 Set getXXs() 在页面上返回的数组后直接用过滤条件<%for { if(){ %> <tr><%=((xx)it.next()).getName()%></tr><%}}%> |
| 返回顶楼 | |
|
发表时间：2010-03-24
数据库约200+表，关联关系较复杂，大表约100字段，500w-2kw记录，目前还未出现hibernate引起的效率问题，复杂的sql(3表以上关联，查询过滤条件5个以上)或时效性要求较高的复杂查询，会考虑在数据库中做，而不是放到webapp中
不过上2kw记录，oracle本身就比较慢了 |
| 返回顶楼 | |
|
发表时间：2010-03-24
小声说，如果是1对多、又只要看部分的“多”，这样写虽然难看点也没啥吧。
|
| 返回顶楼 | |
|
发表时间：2010-03-24
讨论得这么热闹，忍不住了还是要说两句。
老抛跟我观点一致  ，这里讨论的有些东西容易走极端，喜欢举大规模大并发的大系统来作为讨论的基础。
但是很遗憾，我相信大部分草根程序员可能没有机会接触到。 以高 ，大并发系统中出现的问题来指责甚至怀疑hibernate，哪怕其他任何一个流行框架，都是不公平的。 那么最终还是回到这个问题上，你们用hibernate的动机是什么？ 我先说说我的，之前有几个项目都用过hibernate，我当初喜欢他的理由还是之前说过的，ORM，面向对象。以领域模型的方式去解决问题，多美啊。这简直就是终极目标了。于是我忍受了mid-gen给我生成的xml还有一堆的贫血模型。我也忍受了那怪异的HQL，甚至某些解决方案里提到的opensessioninview模型我也忍了。 我都付出这么多代价了，那后来呢，我发现我和我的搭档们无非就是把SQL换成了HQL。 我开始怀疑并检讨我的水平了，一定是我用的不对，我买来了很多宝典，evans的领域驱动开发，pojos in action，泡javaeye看robbin以及众多大牛们关于领域模型的讨论。但不幸的是，依然没有结论，而且大牛们开始搞ruby了。 不过幸运的是，性能问题不是困扰我的原因。几个项目也能上线，虽然过程丑陋了点。 这个过程，我依然不敢质疑hibernate。我怕有人说我拉不出屎来怪茅坑。 那最后就只能怪我没有领悟领域驱动的精髓了。在我没有领悟之前，现在还是踏实的继续jdbctemplate吧。 虽然目标仍在，但依然飘渺。 |
| 返回顶楼 | |
|
发表时间：2010-03-24
最后修改：2010-03-24
nighthawk 写道 讨论得这么热闹，忍不住了还是要说两句。
老抛跟我观点一致 ，这里讨论的有些东西容易走极端，喜欢举大规模大并发的大系统来作为讨论的基础。
但是很遗憾，我相信大部分草根程序员可能没有机会接触到。 以高 ，大并发系统中出现的问题来指责甚至怀疑hibernate，哪怕其他任何一个流行框架，都是不公平的。 那么最终还是回到这个问题上，你们用hibernate的动机是什么？ 我先说说我的，之前有几个项目都用过hibernate，我当初喜欢他的理由还是之前说过的，ORM，面向对象。以领域模型的方式去解决问题，多美啊。这简直就是终极目标了。于是我忍受了mid-gen给我生成的xml还有一堆的贫血模型。我也忍受了那怪异的HQL，甚至某些解决方案里提到的opensessioninview模型我也忍了。 我都付出这么多代价了，那后来呢，我发现我和我的搭档们无非就是把SQL换成了HQL。 我开始怀疑并检讨我的水平了，一定是我用的不对，我买来了很多宝典，evans的领域驱动开发，pojos in action，泡javaeye看robbin以及众多大牛们关于领域模型的讨论。但不幸的是，依然没有结论，而且大牛们开始搞ruby了。 不过幸运的是，性能问题不是困扰我的原因。几个项目也能上线，虽然过程丑陋了点。 这个过程，我依然不敢质疑hibernate。我怕有人说我拉不出屎来怪茅坑。 那最后就只能怪我没有领悟领域驱动的精髓了。在我没有领悟之前，现在还是踏实的继续jdbctemplate吧。 虽然目标仍在，但依然飘渺。 我认为主要是书。。。。培训跟不上。 看了24小时学会系列的ssh同学们太多。 大牛们对新手这样那样的问题视而不见。。。。。 说什么早就说过不能这样用了。。。。。 哪本书能把这些东西收全了？ Oracle我有三本板砖 hibernate我的书更多但写的都差不多。 |
| 返回顶楼 | |
|
发表时间：2010-03-24
nighthawk 写道 讨论得这么热闹，忍不住了还是要说两句。
老抛跟我观点一致 ，这里讨论的有些东西容易走极端，喜欢举大规模大并发的大系统来作为讨论的基础。
但是很遗憾，我相信大部分草根程序员可能没有机会接触到。 以高 ，大并发系统中出现的问题来指责甚至怀疑hibernate，哪怕其他任何一个流行框架，都是不公平的。 那么最终还是回到这个问题上，你们用hibernate的动机是什么？ 我先说说我的，之前有几个项目都用过hibernate，我当初喜欢他的理由还是之前说过的，ORM，面向对象。以领域模型的方式去解决问题，多美啊。这简直就是终极目标了。于是我忍受了mid-gen给我生成的xml还有一堆的贫血模型。我也忍受了那怪异的HQL，甚至某些解决方案里提到的opensessioninview模型我也忍了。 我都付出这么多代价了，那后来呢，我发现我和我的搭档们无非就是把SQL换成了HQL。 我开始怀疑并检讨我的水平了，一定是我用的不对，我买来了很多宝典，evans的领域驱动开发，pojos in action，泡javaeye看robbin以及众多大牛们关于领域模型的讨论。但不幸的是，依然没有结论，而且大牛们开始搞ruby了。 不过幸运的是，性能问题不是困扰我的原因。几个项目也能上线，虽然过程丑陋了点。 这个过程，我依然不敢质疑hibernate。我怕有人说我拉不出屎来怪茅坑。 那最后就只能怪我没有领悟领域驱动的精髓了。在我没有领悟之前，现在还是踏实的继续jdbctemplate吧。 虽然目标仍在，但依然飘渺。 呵呵，握手下。 其实对于性能来说，企业级应用，我们被用户投诉，比以前慢些，那是感觉，最后也忽悠过去。久了大概也和光同尘了。 就如某位朋友说的，这个是程序员的问题，没用好，我们承认。 性能问题，还不是最困扰的问题，其实多数情况下，一般应用cpu占用啊什么的都是极为富裕的情况。 困扰程序员的，恐怕还是诸多陷阱，技巧，层出不穷，碰上个bug，纠察半天，发现是xx配置没配对。青涩时代学个demo就自以为掌握世界，后来发现整个世界还广阔的很。 当接触到世界的景色时候，就又有迷茫，我费这么大劲头，跳到这个世界，比起我停留在原来的世界有多少好处？ 新世界有一堆伟大的名词，比如领域模型，比如UML，最大牌的就是面向对象啊什么的，虽然老，但是一句你领会不深就诚惶诚恐的了。 |
| 返回顶楼 | |
