c*e
2 楼
sigh,由不得自己啊,现在就是改改legacy code,没啥前途,连spring,hibernate都没
用上。
用上。
z*e
4 楼
你会就行了
以后跳槽你以前公司用什么
没有人知道
以后跳槽你以前公司用什么
没有人知道
a*p
5 楼
这个是舒淇吧,我觉得很像啊。
b*y
16 楼
我负责做的电商网站就是用简单的jdbc + db connection pooling. 对于我们来说,追
求速度和用户体验最重要,越简单越好其实。
但对于找工作来说,如果新单位要求spring/hibernate的话,你自学,加上业余做些项
目,比如说,把你的项目上线做成demo。这样我觉得可以convince单位你有这个能力也
用过这个技术。
求速度和用户体验最重要,越简单越好其实。
但对于找工作来说,如果新单位要求spring/hibernate的话,你自学,加上业余做些项
目,比如说,把你的项目上线做成demo。这样我觉得可以convince单位你有这个能力也
用过这个技术。
t*a
19 楼
继续
s*r
20 楼
hibernate很多公司不用,比较restrict,不如直接上jdbc。
spring是个好东西
spring是个好东西
b*y
21 楼
那没办法,我觉得你可以找不需要多年hibernate经验的公司,不就完了。而且,如果
这个公司不赏识你肯钻研,愿意接受挑战的精神,只盯着你是否是experienced spring
/hibernate developer来判断你的能力的话,你也趁早别进这种公司了事。否则,进去
了也不舒服。
我的感觉是,有的时候,我们需要转换点观念。公司找合适的developer, 也不容易。
你不用觉得好像他们挑这个挑那个的。其实,往往真正的原因不是你不会哪些技术,而
是他们就不喜欢你,或者不欣赏你。那你完全可以去找欣赏你的地方去工作。
世界之大,有的是公司。我当初挺烦Google, Amazon, Microsoft等公司,动不动就面
试抠算法,有些老印也是诚心的给你使绊的感觉。但后来想了,我热爱编程技术,喜欢
computer science, 居然tnnd进不去这些公司??那就说明我不适合这种公司而已。此
处不留爷,自有留爷处。
【在 c*********e 的大作中提到】
: 用过这个技术,是entry-level,还是高手专家级别,人家一问就能问出来啊。。。
g*g
39 楼
store procedure的最大问题不是vendor lockin,是高并发下的性能问题。
高并发下通常数据库会是瓶颈,你再把一堆代码堆到数据库服务器上,只会更快到
瓶颈,这问题无解。当然,不是所有的应用都高并发。
有些应用,比如每天半夜产生的报表,用SP还是可以的。
高并发下通常数据库会是瓶颈,你再把一堆代码堆到数据库服务器上,只会更快到
瓶颈,这问题无解。当然,不是所有的应用都高并发。
有些应用,比如每天半夜产生的报表,用SP还是可以的。
F*n
43 楼
高并发下不管实现在哪里都会有瓶颈问题
比如放到app server一样会有瓶颈,
所以这根本不是stored procedure的问题,
而是system design的失误,
没有正确identify scaling component
只有一种情形下你说的 make sense
就是stored procedure的code和 db query可以完全分开来并行处理
但这种情况比较少见,多数条件下stored procedures 需要直接 access db,
分开来反而增加traffic
【在 g*****g 的大作中提到】
: store procedure的最大问题不是vendor lockin,是高并发下的性能问题。
: 高并发下通常数据库会是瓶颈,你再把一堆代码堆到数据库服务器上,只会更快到
: 瓶颈,这问题无解。当然,不是所有的应用都高并发。
: 有些应用,比如每天半夜产生的报表,用SP还是可以的。
比如放到app server一样会有瓶颈,
所以这根本不是stored procedure的问题,
而是system design的失误,
没有正确identify scaling component
只有一种情形下你说的 make sense
就是stored procedure的code和 db query可以完全分开来并行处理
但这种情况比较少见,多数条件下stored procedures 需要直接 access db,
分开来反而增加traffic
【在 g*****g 的大作中提到】
: store procedure的最大问题不是vendor lockin,是高并发下的性能问题。
: 高并发下通常数据库会是瓶颈,你再把一堆代码堆到数据库服务器上,只会更快到
: 瓶颈,这问题无解。当然,不是所有的应用都高并发。
: 有些应用,比如每天半夜产生的报表,用SP还是可以的。
z*e
46 楼
但是store procedure怎么优化?
如果全部剥离出来用java code写
就有很多方法予以优化
比如singleton,就是很好的优化手段
sp怎么搞singleton?
还有spring和jvm的gc调整,这些sp都做不到0
这些都可以在关键时刻提升性能,如果出现瓶颈,加server也容易
如果绑定在db上的话,db的负担会加重
app server出现瓶颈,这是没错,不过理论上这个瓶颈可远比sp的瓶颈要宽得多
traffic问题可以用建立连接池的方式予以解决
还可以自行写cache
另外可以调整存储策略,比如利用临时存储来减少sp跟db之间的互动
还有现在流行的nosql其实也是对db性能不满意的产物
其实早期之所以app server大流行,sp不堪重负也是一个很主要的原因
把所有东西全部推给db做其实是偷懒的想法
【在 F****n 的大作中提到】
: 高并发下不管实现在哪里都会有瓶颈问题
: 比如放到app server一样会有瓶颈,
: 所以这根本不是stored procedure的问题,
: 而是system design的失误,
: 没有正确identify scaling component
: 只有一种情形下你说的 make sense
: 就是stored procedure的code和 db query可以完全分开来并行处理
: 但这种情况比较少见,多数条件下stored procedures 需要直接 access db,
: 分开来反而增加traffic
如果全部剥离出来用java code写
就有很多方法予以优化
比如singleton,就是很好的优化手段
sp怎么搞singleton?
还有spring和jvm的gc调整,这些sp都做不到0
这些都可以在关键时刻提升性能,如果出现瓶颈,加server也容易
如果绑定在db上的话,db的负担会加重
app server出现瓶颈,这是没错,不过理论上这个瓶颈可远比sp的瓶颈要宽得多
traffic问题可以用建立连接池的方式予以解决
还可以自行写cache
另外可以调整存储策略,比如利用临时存储来减少sp跟db之间的互动
还有现在流行的nosql其实也是对db性能不满意的产物
其实早期之所以app server大流行,sp不堪重负也是一个很主要的原因
把所有东西全部推给db做其实是偷懒的想法
【在 F****n 的大作中提到】
: 高并发下不管实现在哪里都会有瓶颈问题
: 比如放到app server一样会有瓶颈,
: 所以这根本不是stored procedure的问题,
: 而是system design的失误,
: 没有正确identify scaling component
: 只有一种情形下你说的 make sense
: 就是stored procedure的code和 db query可以完全分开来并行处理
: 但这种情况比较少见,多数条件下stored procedures 需要直接 access db,
: 分开来反而增加traffic
z*e
47 楼
只能说你们的developer比较懒
这种join其实是很老旧的设计
应该把关键数据剥离出来,单独用transaction保证其数据安全
transaction可以用container来做
也可以自己用jdbc设置start&end point
或者交给hibernate去管理
然后其它的非关键数据,全部用nosql来搞定
真正一个公司最关键的数据无非两个,一个账户信息,还有一个交易信息
这两个需要transaction,其它的其实无关紧要,什么crm都应该上nosql
就是银行也可以用nosql,更何况其它商业公司
【在 B*****g 的大作中提到】
: 有时一个sp会涉及几十个table,如果整个转到java里用hibernate实现,有什么可以注
: 意的?咱公司的java developer我看多过3个table就开始说no了,常年哭着喊着说谁给
: 写个sp他们call一下就行了
这种join其实是很老旧的设计
应该把关键数据剥离出来,单独用transaction保证其数据安全
transaction可以用container来做
也可以自己用jdbc设置start&end point
或者交给hibernate去管理
然后其它的非关键数据,全部用nosql来搞定
真正一个公司最关键的数据无非两个,一个账户信息,还有一个交易信息
这两个需要transaction,其它的其实无关紧要,什么crm都应该上nosql
就是银行也可以用nosql,更何况其它商业公司
【在 B*****g 的大作中提到】
: 有时一个sp会涉及几十个table,如果整个转到java里用hibernate实现,有什么可以注
: 意的?咱公司的java developer我看多过3个table就开始说no了,常年哭着喊着说谁给
: 写个sp他们call一下就行了
z*e
48 楼
以我曾经干过的一个行业为例
这个行业最核心的数据保存在主机里面
全世界没几台这种主机,可能整个欧洲那个行业就那么几台
这是上游的企业,然后上游的企业开放接口给中游的公司去用
中游的公司建自己的db,然后开放接口给下游的分销商去用
下游的分销商用nosql现在用得是如火如荼
我觉得这是很好的一个模型
这个行业最核心的数据保存在主机里面
全世界没几台这种主机,可能整个欧洲那个行业就那么几台
这是上游的企业,然后上游的企业开放接口给中游的公司去用
中游的公司建自己的db,然后开放接口给下游的分销商去用
下游的分销商用nosql现在用得是如火如荼
我觉得这是很好的一个模型
c*e
52 楼
现在哪个大公司在全球不是有多个server? 如果出现瓶颈,多用几个server分布在不同
的地理位置就行了。比如aws,在全球好多分支。
【在 z****e 的大作中提到】
: 但是store procedure怎么优化?
: 如果全部剥离出来用java code写
: 就有很多方法予以优化
: 比如singleton,就是很好的优化手段
: sp怎么搞singleton?
: 还有spring和jvm的gc调整,这些sp都做不到0
: 这些都可以在关键时刻提升性能,如果出现瓶颈,加server也容易
: 如果绑定在db上的话,db的负担会加重
: app server出现瓶颈,这是没错,不过理论上这个瓶颈可远比sp的瓶颈要宽得多
: traffic问题可以用建立连接池的方式予以解决
的地理位置就行了。比如aws,在全球好多分支。
【在 z****e 的大作中提到】
: 但是store procedure怎么优化?
: 如果全部剥离出来用java code写
: 就有很多方法予以优化
: 比如singleton,就是很好的优化手段
: sp怎么搞singleton?
: 还有spring和jvm的gc调整,这些sp都做不到0
: 这些都可以在关键时刻提升性能,如果出现瓶颈,加server也容易
: 如果绑定在db上的话,db的负担会加重
: app server出现瓶颈,这是没错,不过理论上这个瓶颈可远比sp的瓶颈要宽得多
: traffic问题可以用建立连接池的方式予以解决
F*n
53 楼
application logic/algorithm用Java
query-intensive的用stored procedure
很多stored procedure只是为了方便query
比如select columnA into varB
然后紧接着用varB进行更多的query
这种code也剥离到Java中就属于bad design
【在 z****e 的大作中提到】
: 但是store procedure怎么优化?
: 如果全部剥离出来用java code写
: 就有很多方法予以优化
: 比如singleton,就是很好的优化手段
: sp怎么搞singleton?
: 还有spring和jvm的gc调整,这些sp都做不到0
: 这些都可以在关键时刻提升性能,如果出现瓶颈,加server也容易
: 如果绑定在db上的话,db的负担会加重
: app server出现瓶颈,这是没错,不过理论上这个瓶颈可远比sp的瓶颈要宽得多
: traffic问题可以用建立连接池的方式予以解决
query-intensive的用stored procedure
很多stored procedure只是为了方便query
比如select columnA into varB
然后紧接着用varB进行更多的query
这种code也剥离到Java中就属于bad design
【在 z****e 的大作中提到】
: 但是store procedure怎么优化?
: 如果全部剥离出来用java code写
: 就有很多方法予以优化
: 比如singleton,就是很好的优化手段
: sp怎么搞singleton?
: 还有spring和jvm的gc调整,这些sp都做不到0
: 这些都可以在关键时刻提升性能,如果出现瓶颈,加server也容易
: 如果绑定在db上的话,db的负担会加重
: app server出现瓶颈,这是没错,不过理论上这个瓶颈可远比sp的瓶颈要宽得多
: traffic问题可以用建立连接池的方式予以解决
z*e
60 楼
如果只是查询的话,用sp主要考量是降低io操作,更靠近db
但是问题在于,如果数据存储本身如果是分布式的话
比如a数据在这个server,b数据在那个server
那光是一个rpc就够折腾sp了,数据量一旦上去
最后恐怕还是要回到java code上去
hadoop不就是这样,直接上一个job tracker
然后一堆的task tracker跑在不同的机器上
【在 F****n 的大作中提到】
: application logic/algorithm用Java
: query-intensive的用stored procedure
: 很多stored procedure只是为了方便query
: 比如select columnA into varB
: 然后紧接着用varB进行更多的query
: 这种code也剥离到Java中就属于bad design
但是问题在于,如果数据存储本身如果是分布式的话
比如a数据在这个server,b数据在那个server
那光是一个rpc就够折腾sp了,数据量一旦上去
最后恐怕还是要回到java code上去
hadoop不就是这样,直接上一个job tracker
然后一堆的task tracker跑在不同的机器上
【在 F****n 的大作中提到】
: application logic/algorithm用Java
: query-intensive的用stored procedure
: 很多stored procedure只是为了方便query
: 比如select columnA into varB
: 然后紧接着用varB进行更多的query
: 这种code也剥离到Java中就属于bad design
o*i
65 楼
我觉得吧,这种东西没有一个通用的方案的,说到底,得看实际情况去考量。
1.有些公司吧,就根本不太可能会换数据库,一条路走到黑的,那管个p的通用性呀。有
些非标准的sql,就是很有用很方便,才会出现呀。
2.瓶颈嘛,哪里都会出现,关键是要合理安排,安排到db层也不是问题呀,有些特别的
情况下,只有安排到db层才是最合理的,比如我们专门有个报表数据库,每天的任务就
是join一大堆表,生成报表数据,这个如果已到java去处理,累死,而且增加很多开销
呀。
3.另一方面,设计一个系统,要整体考虑,因地制宜,想清楚各个瓶颈,合理地分配到
各个层去,最大可能的利用起各个资源。比如说,你搞个很高性能的db server,结果只
是作为一个存储机能,不是很大浪费么?有些非高并发的,join什么的操作你都挪到ap
p server上,那又何苦呢?db有他的优势,也有不足。不能因噎废食。
【在 B*****g 的大作中提到】
: 是这个理,我现在想说服公司把这种逻辑转到app层,不过我自己也不知道如何搞好
1.有些公司吧,就根本不太可能会换数据库,一条路走到黑的,那管个p的通用性呀。有
些非标准的sql,就是很有用很方便,才会出现呀。
2.瓶颈嘛,哪里都会出现,关键是要合理安排,安排到db层也不是问题呀,有些特别的
情况下,只有安排到db层才是最合理的,比如我们专门有个报表数据库,每天的任务就
是join一大堆表,生成报表数据,这个如果已到java去处理,累死,而且增加很多开销
呀。
3.另一方面,设计一个系统,要整体考虑,因地制宜,想清楚各个瓶颈,合理地分配到
各个层去,最大可能的利用起各个资源。比如说,你搞个很高性能的db server,结果只
是作为一个存储机能,不是很大浪费么?有些非高并发的,join什么的操作你都挪到ap
p server上,那又何苦呢?db有他的优势,也有不足。不能因噎废食。
【在 B*****g 的大作中提到】
: 是这个理,我现在想说服公司把这种逻辑转到app层,不过我自己也不知道如何搞好
g*g
69 楼
当然不是,app server cluster很容易做,往上堆机器就行了。相反,Relational DB
scale up,不scale out。这也是NoSQL现在火的原因。
不用SP就是把所有计算的部分都剥离到app server,只把存储相关的留给DB。这样可以
降低数据库服务器CPU和内存的压力。数据库服务器license一般都是按CPU算钱的。
【在 F****n 的大作中提到】
: 高并发下不管实现在哪里都会有瓶颈问题
: 比如放到app server一样会有瓶颈,
: 所以这根本不是stored procedure的问题,
: 而是system design的失误,
: 没有正确identify scaling component
: 只有一种情形下你说的 make sense
: 就是stored procedure的code和 db query可以完全分开来并行处理
: 但这种情况比较少见,多数条件下stored procedures 需要直接 access db,
: 分开来反而增加traffic
scale up,不scale out。这也是NoSQL现在火的原因。
不用SP就是把所有计算的部分都剥离到app server,只把存储相关的留给DB。这样可以
降低数据库服务器CPU和内存的压力。数据库服务器license一般都是按CPU算钱的。
【在 F****n 的大作中提到】
: 高并发下不管实现在哪里都会有瓶颈问题
: 比如放到app server一样会有瓶颈,
: 所以这根本不是stored procedure的问题,
: 而是system design的失误,
: 没有正确identify scaling component
: 只有一种情形下你说的 make sense
: 就是stored procedure的code和 db query可以完全分开来并行处理
: 但这种情况比较少见,多数条件下stored procedures 需要直接 access db,
: 分开来反而增加traffic
g*g
72 楼
For end user, expose a web interface, for clients in other languages, expose
a web service interface. You can aggregate, enhance, limit data usage, of
course you have a lot of flexibilities.
【在 B*****g 的大作中提到】
: 用hibernate功能怎么share比较好。
: 写一个sp,谁都可以用,例如直接用sql call,或者一个dotnet也需要这个功能,比较
: 简单。
: 用hibernate是不是要搞一个service,要不然别人怎么用呀?
a web service interface. You can aggregate, enhance, limit data usage, of
course you have a lot of flexibilities.
【在 B*****g 的大作中提到】
: 用hibernate功能怎么share比较好。
: 写一个sp,谁都可以用,例如直接用sql call,或者一个dotnet也需要这个功能,比较
: 简单。
: 用hibernate是不是要搞一个service,要不然别人怎么用呀?
r*s
78 楼
I meant I was not convinced so.
sigh ...
谦虚一点都不行
拿个Beberley+MIT的Theroem就能prove NoSQL了?
你有点被netflix洗脑了,
抱歉,
说的有点难听。
这个HA, Scalability,ACID本来就是个大标题,
就像你说的,
RDB availability就差“点”,
NoSQL差的地方不是一点了,
小心有一天NoSQL也终于支持SQL statement那就是笑话了,
呵呵。
【在 g*****g 的大作中提到】
: 这个自己google吧,本质上distributed application,consistency跟availability只
: 能挑一个。
: rdbms要保证consistency,availability就差点。
sigh ...
谦虚一点都不行
拿个Beberley+MIT的Theroem就能prove NoSQL了?
你有点被netflix洗脑了,
抱歉,
说的有点难听。
这个HA, Scalability,ACID本来就是个大标题,
就像你说的,
RDB availability就差“点”,
NoSQL差的地方不是一点了,
小心有一天NoSQL也终于支持SQL statement那就是笑话了,
呵呵。
【在 g*****g 的大作中提到】
: 这个自己google吧,本质上distributed application,consistency跟availability只
: 能挑一个。
: rdbms要保证consistency,availability就差点。
g*g
79 楼
这不是一个猜想,这是一个被证明的定理。被提出这么多年还没有反例,
你信不信有用吗?
NoSQL在很多方面有不足毫无疑问,这个本来就是个取舍问题。你要放炮之前,
是不是应该先学习一下基本常识?NoSQL支持SQL也不奇怪,CQL就是这方面的努力之一,
但支持SQL跟支持transaction是两码事。
【在 r*****s 的大作中提到】
: I meant I was not convinced so.
: sigh ...
: 谦虚一点都不行
: 拿个Beberley+MIT的Theroem就能prove NoSQL了?
: 你有点被netflix洗脑了,
: 抱歉,
: 说的有点难听。
: 这个HA, Scalability,ACID本来就是个大标题,
: 就像你说的,
: RDB availability就差“点”,
你信不信有用吗?
NoSQL在很多方面有不足毫无疑问,这个本来就是个取舍问题。你要放炮之前,
是不是应该先学习一下基本常识?NoSQL支持SQL也不奇怪,CQL就是这方面的努力之一,
但支持SQL跟支持transaction是两码事。
【在 r*****s 的大作中提到】
: I meant I was not convinced so.
: sigh ...
: 谦虚一点都不行
: 拿个Beberley+MIT的Theroem就能prove NoSQL了?
: 你有点被netflix洗脑了,
: 抱歉,
: 说的有点难听。
: 这个HA, Scalability,ACID本来就是个大标题,
: 就像你说的,
: RDB availability就差“点”,
r*s
80 楼
车轱辘话我不愿意老讲:
这个proven case is a narrow case。
好的,
我们都来学习一下:
http://en.wikipedia.org/wiki/CAP_theorem
The proof of the CAP theorem by Gilbert and Lynch is a bit narrower than wha
t Brewer had in mind. The theorem sets up a scenario in which a replicated s
ervice is presented with two conflicting requests arriving at distinct locat
ions on a time when a link between them is failed. The obligation to provide
availability despite partitioning failures leads the services to respond; a
t least one of these responses shall necessarily be inconsistent with what a
service implementing a true one-copy replication semantic would have done.
The researchers then go on to show that other forms of consistency are achie
vable, including a property they call t-eventual consistency.
Thus the theorem doesn't rule out achieving consistency in a distributed sys
tem, and says nothing about cloud computing per se or about scalability.
一,
【在 g*****g 的大作中提到】
: 这不是一个猜想,这是一个被证明的定理。被提出这么多年还没有反例,
: 你信不信有用吗?
: NoSQL在很多方面有不足毫无疑问,这个本来就是个取舍问题。你要放炮之前,
: 是不是应该先学习一下基本常识?NoSQL支持SQL也不奇怪,CQL就是这方面的努力之一,
: 但支持SQL跟支持transaction是两码事。
这个proven case is a narrow case。
好的,
我们都来学习一下:
http://en.wikipedia.org/wiki/CAP_theorem
The proof of the CAP theorem by Gilbert and Lynch is a bit narrower than wha
t Brewer had in mind. The theorem sets up a scenario in which a replicated s
ervice is presented with two conflicting requests arriving at distinct locat
ions on a time when a link between them is failed. The obligation to provide
availability despite partitioning failures leads the services to respond; a
t least one of these responses shall necessarily be inconsistent with what a
service implementing a true one-copy replication semantic would have done.
The researchers then go on to show that other forms of consistency are achie
vable, including a property they call t-eventual consistency.
Thus the theorem doesn't rule out achieving consistency in a distributed sys
tem, and says nothing about cloud computing per se or about scalability.
一,
【在 g*****g 的大作中提到】
: 这不是一个猜想,这是一个被证明的定理。被提出这么多年还没有反例,
: 你信不信有用吗?
: NoSQL在很多方面有不足毫无疑问,这个本来就是个取舍问题。你要放炮之前,
: 是不是应该先学习一下基本常识?NoSQL支持SQL也不奇怪,CQL就是这方面的努力之一,
: 但支持SQL跟支持transaction是两码事。
g*g
87 楼
你最好理解一下这段话什么意思再跟我争。tunable consistency的意思就是,颜色不
一顶要黑的,或者白的,也可以是灰色的。一个系统甚至可以黑一块白一块灰一块,但
不会改变任意一块不会同时又黑又白的本质。而一个RDBMS,但凡支持transaction,就
意味着是白的。
如果RDBMS灰了,就不是传统意义上的RDBMS了。
wha
s
locat
provide
a
【在 r*****s 的大作中提到】
: 车轱辘话我不愿意老讲:
: 这个proven case is a narrow case。
: 好的,
: 我们都来学习一下:
: http://en.wikipedia.org/wiki/CAP_theorem
: The proof of the CAP theorem by Gilbert and Lynch is a bit narrower than wha
: t Brewer had in mind. The theorem sets up a scenario in which a replicated s
: ervice is presented with two conflicting requests arriving at distinct locat
: ions on a time when a link between them is failed. The obligation to provide
: availability despite partitioning failures leads the services to respond; a
一顶要黑的,或者白的,也可以是灰色的。一个系统甚至可以黑一块白一块灰一块,但
不会改变任意一块不会同时又黑又白的本质。而一个RDBMS,但凡支持transaction,就
意味着是白的。
如果RDBMS灰了,就不是传统意义上的RDBMS了。
wha
s
locat
provide
a
【在 r*****s 的大作中提到】
: 车轱辘话我不愿意老讲:
: 这个proven case is a narrow case。
: 好的,
: 我们都来学习一下:
: http://en.wikipedia.org/wiki/CAP_theorem
: The proof of the CAP theorem by Gilbert and Lynch is a bit narrower than wha
: t Brewer had in mind. The theorem sets up a scenario in which a replicated s
: ervice is presented with two conflicting requests arriving at distinct locat
: ions on a time when a link between them is failed. The obligation to provide
: availability despite partitioning failures leads the services to respond; a
z*e
94 楼
hibernate可以有batch做啊
http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/batch
而且越是复杂的逻辑越应该让java code去搞
sp太复杂的话,很难维护
【在 s*****r 的大作中提到】
: 这个还是用sp吧,hibernate不是拿来做复杂sql的,而且不支持result set和cursor,
: 不适合复杂的db processing,尤其是需要batch processing的时候。
http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/batch
而且越是复杂的逻辑越应该让java code去搞
sp太复杂的话,很难维护
【在 s*****r 的大作中提到】
: 这个还是用sp吧,hibernate不是拿来做复杂sql的,而且不支持result set和cursor,
: 不适合复杂的db processing,尤其是需要batch processing的时候。
s*r
96 楼
报表啥的可以用hive去做,非常适合map-reduce的应用
。有
果只
ap
【在 o***i 的大作中提到】
: 我觉得吧,这种东西没有一个通用的方案的,说到底,得看实际情况去考量。
: 1.有些公司吧,就根本不太可能会换数据库,一条路走到黑的,那管个p的通用性呀。有
: 些非标准的sql,就是很有用很方便,才会出现呀。
: 2.瓶颈嘛,哪里都会出现,关键是要合理安排,安排到db层也不是问题呀,有些特别的
: 情况下,只有安排到db层才是最合理的,比如我们专门有个报表数据库,每天的任务就
: 是join一大堆表,生成报表数据,这个如果已到java去处理,累死,而且增加很多开销
: 呀。
: 3.另一方面,设计一个系统,要整体考虑,因地制宜,想清楚各个瓶颈,合理地分配到
: 各个层去,最大可能的利用起各个资源。比如说,你搞个很高性能的db server,结果只
: 是作为一个存储机能,不是很大浪费么?有些非高并发的,join什么的操作你都挪到ap
。有
果只
ap
【在 o***i 的大作中提到】
: 我觉得吧,这种东西没有一个通用的方案的,说到底,得看实际情况去考量。
: 1.有些公司吧,就根本不太可能会换数据库,一条路走到黑的,那管个p的通用性呀。有
: 些非标准的sql,就是很有用很方便,才会出现呀。
: 2.瓶颈嘛,哪里都会出现,关键是要合理安排,安排到db层也不是问题呀,有些特别的
: 情况下,只有安排到db层才是最合理的,比如我们专门有个报表数据库,每天的任务就
: 是join一大堆表,生成报表数据,这个如果已到java去处理,累死,而且增加很多开销
: 呀。
: 3.另一方面,设计一个系统,要整体考虑,因地制宜,想清楚各个瓶颈,合理地分配到
: 各个层去,最大可能的利用起各个资源。比如说,你搞个很高性能的db server,结果只
: 是作为一个存储机能,不是很大浪费么?有些非高并发的,join什么的操作你都挪到ap
z*e
99 楼
报表可以直接写java code来搞
只要不频繁写数据,java code其实没啥问题
主要开销都在insert和update这两个操作上
报表相对简单,因为只读不改,所以就不需要全部锁定所有表
每次fetch数据之后放在内存里,然后挨个执行
最后再归并,其实跟普通的mapreduce操作没有太大差别
【在 s*****r 的大作中提到】
: 所以俺不看好Oracle,这些transaction data,至少historic的,放进nosql没有什么
: 问题,query时候搞两次就好,一个去Oracle找最近的,一个去nosql找老的。麻烦是
: join,但join on历史数据的要求并不多,主要是报表才需要,这个也可以用nosql来解
: 决。
: 如果hibernate开始支持CQL,Oracle估计可以砍掉一半人。
只要不频繁写数据,java code其实没啥问题
主要开销都在insert和update这两个操作上
报表相对简单,因为只读不改,所以就不需要全部锁定所有表
每次fetch数据之后放在内存里,然后挨个执行
最后再归并,其实跟普通的mapreduce操作没有太大差别
【在 s*****r 的大作中提到】
: 所以俺不看好Oracle,这些transaction data,至少historic的,放进nosql没有什么
: 问题,query时候搞两次就好,一个去Oracle找最近的,一个去nosql找老的。麻烦是
: join,但join on历史数据的要求并不多,主要是报表才需要,这个也可以用nosql来解
: 决。
: 如果hibernate开始支持CQL,Oracle估计可以砍掉一半人。
c*e
102 楼
g*g
113 楼
You probably want to discuss it in case by case manner.
e.g. MySQL cluster allows lagging readonly instances, it has high
availability for read, but it's not consistent when you read from readonly
instances.
That's the point of my back and white Metaphor. RDBMS can implement non-
transaction operation too for high availability, but those operations won't
be consistent.
【在 r*****s 的大作中提到】
: 那请问MySQL、Oracle允许灰吗?
: 还是不是传统意义上的RDBMS?
e.g. MySQL cluster allows lagging readonly instances, it has high
availability for read, but it's not consistent when you read from readonly
instances.
That's the point of my back and white Metaphor. RDBMS can implement non-
transaction operation too for high availability, but those operations won't
be consistent.
【在 r*****s 的大作中提到】
: 那请问MySQL、Oracle允许灰吗?
: 还是不是传统意义上的RDBMS?
相关阅读
请问Hadoop要怎么学?Java里面的SWT或者Swing为啥还有书在介绍呢现在除了pc,基本上都是精简指令集的天下了吧?最近玩linkedin,觉得那些花花绿绿的公司logo很好看AOP这东西听起来很不错先放一个preview的图片一个员工到底值多钱 (转载)网上web services的免费书,哪本好点?c#或者java都可以。 (转载)请教:软件开发流程美国政府因安全问题要求禁用Java软件 (转载)新手求助 ARR里添加Tomcat的问题 (转载)入门问题:以Spring+JPA开发back end,那么表现层只能用jsp吗?Java用在Server Side的技术是哪些?新手问题Free Coursera course: Algorithms, Part I started求教一个Java问题 IllegalMonitorStateExceptionSSH lib for Javawhere is the best place to learn Java online?Java SE6 LinkedList implementation issue.NET 何去何从 (转载)