|
锁定老帖子 主题：这样的应用有必要Hibernate？
精华帖 (0) :: 良好帖 (1) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-08-21
helei810304 写道 在数据量比较大的时候（百万级别以上），资深或正常的DBA ，看到HIBERNTE 打印出来的SQL 语句，会疯掉的，不是因为看不懂。
1 海量数据用表关联，并不是高效的做法 2 我们公司的 SQL 语句（用IBATIS） 每个都要DBA 审核，现在回头看HIBERNATE 的粗俗的SQL语句，只能说，适用于初学者和小型应用，因为风险实在不可控 3 高效的SQL 查询需要建索引，HIBERNATE 3.0里的，无论是HSQL 还是criteria 都不适合DBA 阅读建索引 4 不觉得对大量数据做缓存，是件很划算的事情，因为会消耗很多的系统资源，淘宝现在就有很多缓存服务器，与其这样，像LZ 这样的应用比如用 优化的SQL 语句来降低成本来的划算 你说风险不可控，是因为你们公司没有能控制hibernate的人，控制不了就说这个框架粗俗，你这个逻辑是不能成立的。 淘宝拥有国内最多的数据库方面的高手，你如何能臆想出他们没有优化sql这个能力？ 你凭什么说明优化sql语句能解决海量数据的计算问题？缓存服务器可以以相对非常低的成本scale out（横向扩展），数据库一般只能是scale up（性能纵向扩展，比如加CPU，换大型机，加内存，也是很容易到极限的），即使RAC，也是得不到线形回报的，而且RAC也很容易到极限的。 数据库服务器的硬件和软件成本要比缓存服务器贵得多的多，真不知道你说的降低成本从何而来。 总结，你以为淘宝的架构师团队是白痴啊。 |
| 返回顶楼 | |
|
发表时间：2008-08-21
才3个表，愿用啥用啥，出了问题大不了重写。
楼主如不是决策者就不必费心了。 |
| 返回顶楼 | |
|
发表时间：2008-08-21
当然要用啦。。。
你不正好多学点东西，有个项目让你练手还不乐意，反正就那3张表，多好的一个example啊。 最好，hibernate, ibita, ejb,jdbc全都实现一套。 |
| 返回顶楼 | |
|
发表时间：2008-08-21
Hibernate的最大特点就是OR mapping，说到性能方面不会比JDBC高，况且，你所说的缓存完全可以自己去实现。
|
| 返回顶楼 | |
|
发表时间：2008-08-21
icewubin 写道 murainwood 写道 Hibernate Shards，
Hiberante+AbstractRoutingDateSource（Spring） Hibernate+C-JDBC 这三种方案 PS：我喜欢拆表...不过要特别注意二级缓存的问题，特别是第二种方案。 楼主又不是问集群解决方案，有必要用这么重的牛刀么？ 二级缓存极难设计出合理的应用，代码代价往往非常高，建议关闭。 hibernate二级缓存这一级的cache策略更偏向于针对业务对象的缓存，自己设计性价比更高。 这个牛刀也不光光是为了解决集群方案。 我说的是水平拆表，这三种方案完全适合 |
| 返回顶楼 | |
|
发表时间：2008-08-21
sole 写道 我们用mysql数据库只是做中间存储,数据库不是最核心的。数据库的插入，删除，更新操作非常频繁，还要保证查询到及时更新的数据。
其实也有五六个表，我觉得主要是在数据库设计上下功夫（效率不行的话用视图，触发器，存储过程）。 对hibernate是现学现用，我觉得用hibernate也不能做到精确控制。 我觉得用jdbc ibats hibernate 都是可以的 毕竟项目规模不是很大 要及时查询到更新的数据，做到精确控制，hibernate绝对是没有问题的 不过大数据量的更新hibernate较前两种稍有逊色 但也不会坏到项目失败 |
| 返回顶楼 | |
|
发表时间：2008-08-21
helei810304 写道 在数据量比较大的时候（百万级别以上），资深或正常的DBA ，看到HIBERNTE 打印出来的SQL 语句，会疯掉的，不是因为看不懂。
1 海量数据用表关联，并不是高效的做法 2 我们公司的 SQL 语句（用IBATIS） 每个都要DBA 审核，现在回头看HIBERNATE 的粗俗的SQL语句，只能说，适用于初学者和小型应用，因为风险实在不可控 3 高效的SQL 查询需要建索引，HIBERNATE 3.0里的，无论是HSQL 还是criteria 都不适合DBA 阅读建索引 4 不觉得对大量数据做缓存，是件很划算的事情，因为会消耗很多的系统资源，淘宝现在就有很多缓存服务器，与其这样，像LZ 这样的应用比如用 优化的SQL 语句来降低成本来的划算 适合初学者和小型应用？ 我笑了。。。 没见过不是你的错，但是信口乱说就不应该了。 |
| 返回顶楼 | |
|
发表时间：2008-08-21
johnhan 写道 sole 写道 我们用mysql数据库只是做中间存储,数据库不是最核心的。数据库的插入，删除，更新操作非常频繁，还要保证查询到及时更新的数据。
其实也有五六个表，我觉得主要是在数据库设计上下功夫（效率不行的话用视图，触发器，存储过程）。 对hibernate是现学现用，我觉得用hibernate也不能做到精确控制。 我觉得用jdbc ibats hibernate 都是可以的 毕竟项目规模不是很大 要及时查询到更新的数据，做到精确控制，hibernate绝对是没有问题的 不过大数据量的更新hibernate较前两种稍有逊色 但也不会坏到项目失败 所谓的稍有逊色，最多就是java反射的一些消耗，几乎可以忽略不计，最终都是jdbc，没有区别。 |
| 返回顶楼 | |
|
发表时间：2008-08-22
IBATIS
|
| 返回顶楼 | |
|
发表时间：2008-08-22
icewubin 写道 helei810304 写道 在数据量比较大的时候（百万级别以上），资深或正常的DBA ，看到HIBERNTE 打印出来的SQL 语句，会疯掉的，不是因为看不懂。
1 海量数据用表关联，并不是高效的做法 2 我们公司的 SQL 语句（用IBATIS） 每个都要DBA 审核，现在回头看HIBERNATE 的粗俗的SQL语句，只能说，适用于初学者和小型应用，因为风险实在不可控 3 高效的SQL 查询需要建索引，HIBERNATE 3.0里的，无论是HSQL 还是criteria 都不适合DBA 阅读建索引 4 不觉得对大量数据做缓存，是件很划算的事情，因为会消耗很多的系统资源，淘宝现在就有很多缓存服务器，与其这样，像LZ 这样的应用比如用 优化的SQL 语句来降低成本来的划算 你说风险不可控，是因为你们公司没有能控制hibernate的人，控制不了就说这个框架粗俗，你这个逻辑是不能成立的。 淘宝拥有国内最多的数据库方面的高手，你如何能臆想出他们没有优化sql这个能力？ 你凭什么说明优化sql语句能解决海量数据的计算问题？缓存服务器可以以相对非常低的成本scale out（横向扩展），数据库一般只能是scale up（性能纵向扩展，比如加CPU，换大型机，加内存，也是很容易到极限的），即使RAC，也是得不到线形回报的，而且RAC也很容易到极限的。 数据库服务器的硬件和软件成本要比缓存服务器贵得多的多，真不知道你说的降低成本从何而来。 总结，你以为淘宝的架构师团队是白痴啊。 这回复好高深,专用名词没几个听的懂.啊能解释一下?? |
| 返回顶楼 | |
