RAC更适合跑OLTP还是OLAP？

wzy25

原帖由 blue_prince 于 2008-11-20 10:03 发表
说一下业务分割吧，这个也是可行的，浙江移动几乎所有的关键系统都运行在RAC上面，他们也都是业务分割了，一个节点就跑一个自己的东西，互不相干，这样可能会好一些，因为跨节点的争用就会少了许多，实际使用我感觉这也是比较成熟可靠的运行方式。虽然这样违背了RAC设计的初衷，RAC更建议通过SERVICE来分离应用，可以做到SERVICE的接管，不过这样其实一个节点就是一个独立的SERVICE，也可以再设置SERVICE，做到一个节点一个SERVICE，其他节点可以接管，这样对用户来说宕一个节点是透明的。

分割应用，减少节点间通讯提高通讯效率，提高local cache命中率，oracle一直都是这么建议，而且程序代码都是朝着这个方向前进的。。。。。

应用分割好了，或者加上合适的分区，RAC跑OLTP一样强的很，比如中彩在线，4各节点的RAC跑OLTP，效果好的很。。。。
主要取决与应用。


当然，这么做的主要目的是更加有效的跑OLTP，避免同一block在不同节点间频繁传输而导致效率下降。如果跑OLAP，那么cache fusion就越多越好了，毕竟是查询的时候占多数，cache fusion效率毕竟比磁盘读取要快很了。

[ 本帖最后由 wzy25 于 2008-11-20 11:52 编辑 ]

anlinew

原帖由 wzy25 于 2008-11-20 11:43 发表


分割应用，减少节点间通讯提高通讯效率，提高local cache命中率，oracle一直都是这么建议，而且程序代码都是朝着这个方向前进的。。。。。

应用分割好了，或者加上合适的分区，RAC跑OLTP一样强的很，比如中彩在线，4各节点的RAC跑OLTP，效果好的很。。。。
主要取决与应用。

支持，好的业务分割能够达到增加一个node几乎就能增加一个node的处理能力

而由于OLTP的业务特点，分割业务能够更容易实现，所以对于OLTP系统来说，使用RAC来提升性能，提高可扩展性，提升可用性是比较合适的选择

蛋白粉

原帖由 biti_rainy 于 2008-11-20 11:32 发表


和架构、业务一起去解决问题，而不是在数据库内部解决问题
mysql的问题不在数据库比oracle好，而在 软件费用的问题

我们经历了快一年时间终于跟oracle签下了ula，2008年11月25日生效，oracle无限制使用3年！ 但这只是给我们留了3年时间来解决 数据库的分拆和转移，而不是现在我们就放任自流。
pc server的性能发展和成本下降非常快，ssd的可能使用也非常值得期待，但是oracle要架在pc server上带来巨大的 license费用，我们必须在3年内解决这个问题。

jinguanding

学习了....

anlinew

还是这里讨论能套出料来
至少大家能够对taobao的技术方向有个大概的了解了，HOHO
老虎该来精了。。。

wzy25

原帖由 anlinew 于 2008-11-20 11:51 发表

支持，好的业务分割能够达到增加一个node几乎就能增加一个node的处理能力

而由于OLTP的业务特点，分割业务能够更容易实现，所以对于OLTP系统来说，使用RAC来提升性能，提高可扩展性，提升可用性是比较合适的选择

对的，前面通过f5根据url来转发到不同的中间件instance,实现对不同rac instance的访问，就可以有效的分割应用。
再不济也可以通过partition来实现对数据的隔离访问，实现更高的oltp效率。

yxyup

原帖由 biti_rainy 于 2008-11-20 11:32 发表


和架构、业务一起去解决问题，而不是在数据库内部解决问题
mysql的问题不在数据库比oracle好，而在 软件费用的问题

我们经历了快一年时间终于跟oracle签下了ula，2008年11月25日生效，oracle无限制使用3年！ 但这只是给我们留了3年时间来解决 数据库的分拆和转移，而不是现在我们就放任自流。
pc server的性能发展和成本下降非常快，ssd的可能使用也非常值得期待，但是oracle要架在pc server上带来巨大的 license费用，我们必须在3年内解决这个问题。

yanggq

Great

biti_rainy

原帖由 wzy25 于 2008-11-20 11:57 发表


对的，前面通过f5根据url来转发到不同的中间件instance,实现对不同rac instance的访问，就可以有效的分割应用。
再不济也可以通过partition来实现对数据的隔离访问，实现更高的oltp效率。

ebay在 f5 分析url规则来转发 ＋ shareplex 同步  是成功的，但这个也要再架构层面布局做好基础，现有的比较复杂的系统要去改造成本还是蛮大的。就我们现在的情况而言，如果要在 rac 的intance之间分割应用，其实不困难的，因为只要分割主要的压力大但关联少的应用就可以了。但没下这个决定的原因也是多方面的，毕竟比如 4c core 的 pc，4个节点，那么license数量就是 4*4/2*4*1.75=56个。这样的软件成本其实也蛮高的了。 而如果是 p590，16c的 590的license是  16*0.75*1.25=15，那么license数量差异是 41个（费用上有多少大家心里就有数了）。 而基本上以前我们会认为4个pc server的rac 不会强于一台 16c的 590 的 oltp能力。 一台 16c的 590 的价格大约在 280万左右。 所以以前在 oltp上采用了 ibm小型机这样的策略，毕竟风险也低一些。

但是未来 p590 满足不了需要，必须要分割，既然分割，那么就没必要依赖小型机了。

biti_rainy

移动过来，跟大家分享一下