IT分销/经销数据库
传统OLTP系统的云迁移方案
现在正在做一个WEB证券系统的云迁移方案，
如果单纯把应用服务器移动到云里，必然面临应用服务器与关系数据库之间的延迟问题，
对大量的小数据存取是比较致命的。
原来的数据库是ORACLE，俺现在想到的方案是在云里配置In-Memory Database来根本的改进性能问题，
oracle就是Timesten了，但问题来了oracle实在是太贵了。
另一个方案就是后端迁到DB2+前端solidDB,但这边的证券公司没怎么用过IBM的东西，迁移会有很多问题。
比如原系统的AQ怎么办？
各位有什么好的建议吗？
如果单纯把应用服务器移动到云里，必然面临应用服务器与关系数据库之间的延迟问题，
对大量的小数据存取是比较致命的。
原来的数据库是ORACLE，俺现在想到的方案是在云里配置In-Memory Database来根本的改进性能问题，
oracle就是Timesten了，但问题来了oracle实在是太贵了。
另一个方案就是后端迁到DB2+前端solidDB,但这边的证券公司没怎么用过IBM的东西，迁移会有很多问题。
比如原系统的AQ怎么办？
各位有什么好的建议吗？
18同行回答
已经脱离了DB2，这个贴到此为止。》hongtao2000 我们换个地方谈论。cedarbird 发表于 2012-2-2 12:55
呵呵，完全同意。浏览1541
谢谢回复。
1.设想的层级结构是：
客户端--internet-》AMAZONAWS FireWall/LoadBalancer -》应用服务器----专线-----》DB(公司DataCenter)--》交易转接系统(他系统，多个交易系统同时接入)--》证券交易所
即使是专线，我也相当担心网络延迟。
2.如果网络因素是致命的，所以需要云里要配前端缓存服务器。
因为原有系统没有设计成读写分离，简单的memcached基本就没法用了，这也正是打算使用前段的
InMemoryDB的主要依据，就是价钱太坑爹。
3.
>从目前国内来看，专线上上海到深圳的ping包一个来回大约30多个毫秒，大概会在100公里左右
>加一个ms如果有选择，还是不建议应用服务器通过广域网来访问数据，毕竟广域网除了响应速度比lan
>差以外，还存在可能的网络断、不稳定的情况，而这些数据库的连接协议处理并不是那么的好。
谢谢提供参考。收起
1.设想的层级结构是：
客户端--internet-》AMAZONAWS FireWall/LoadBalancer -》应用服务器----专线-----》DB(公司DataCenter)--》交易转接系统(他系统，多个交易系统同时接入)--》证券交易所
即使是专线，我也相当担心网络延迟。
2.如果网络因素是致命的，所以需要云里要配前端缓存服务器。
因为原有系统没有设计成读写分离，简单的memcached基本就没法用了，这也正是打算使用前段的
InMemoryDB的主要依据，就是价钱太坑爹。
3.
>从目前国内来看，专线上上海到深圳的ping包一个来回大约30多个毫秒，大概会在100公里左右
>加一个ms如果有选择，还是不建议应用服务器通过广域网来访问数据，毕竟广域网除了响应速度比lan
>差以外，还存在可能的网络断、不稳定的情况，而这些数据库的连接协议处理并不是那么的好。
谢谢提供参考。收起
浏览1595
1。
>>--您所说的延迟是指什么？从我这边的实际看如果应用服务器与数据库分开部署延时增加还算比较有限，
>>但是如果应用服务器和数据库服务器大量的sql会导致大量的网络交换从而消耗大量的资源
很多SQL，带宽可以通过专线解决，但每个处理都不大，累计起来，延迟也就很可观了。(存在业务实现不妥当的情况，但是改起来成本比较大)毕竟LAN和WAN的区别太大了。
2.
>>从您的描述看实质上是使用虚拟机来承担应用服务器职能？
应用服务器比较多，如果能成功的部署到云里，那么成本可以大大节省。我们主要的目标是AMAZON EC2。
3.
>>从解决这个问题来说，个人建议也可以考虑应用服务用一些共享内存或者free的memdb，
>>这样对应用服务器做修改修改可能会相对大一点，考虑到大部分的sql查询应该都是很简单的，
>>应该修改量还可以接受。
这也是我们准备使用缓存服务器的主要目的，如果使用一些免费的memcached 或者是 memdb,
也担心同步不好，因为还有很多的后台BATCH处理。比较头疼。系统比较大，要考虑的因素也比较复杂。
等专线拉好后，要测下速度，从地理上看到是离AMAZON的DC不是很远。
我的mail: [email]cedarbirdcn@hotmail.com[/email]收起
>>--您所说的延迟是指什么？从我这边的实际看如果应用服务器与数据库分开部署延时增加还算比较有限，
>>但是如果应用服务器和数据库服务器大量的sql会导致大量的网络交换从而消耗大量的资源
很多SQL，带宽可以通过专线解决，但每个处理都不大，累计起来，延迟也就很可观了。(存在业务实现不妥当的情况，但是改起来成本比较大)毕竟LAN和WAN的区别太大了。
2.
>>从您的描述看实质上是使用虚拟机来承担应用服务器职能？
应用服务器比较多，如果能成功的部署到云里，那么成本可以大大节省。我们主要的目标是AMAZON EC2。
3.
>>从解决这个问题来说，个人建议也可以考虑应用服务用一些共享内存或者free的memdb，
>>这样对应用服务器做修改修改可能会相对大一点，考虑到大部分的sql查询应该都是很简单的，
>>应该修改量还可以接受。
这也是我们准备使用缓存服务器的主要目的，如果使用一些免费的memcached 或者是 memdb,
也担心同步不好，因为还有很多的后台BATCH处理。比较头疼。系统比较大，要考虑的因素也比较复杂。
等专线拉好后，要测下速度，从地理上看到是离AMAZON的DC不是很远。
我的mail: [email]cedarbirdcn@hotmail.com[/email]收起
浏览1636
现在正在做一个WEB证券系统的云迁移方案，
如果单纯把应用服务器移动到云里，必然面临应用服务器与关系数据库之间的延迟问题，
对大量的小数据存取是比较致命的。--现有系统的应用服务器和数据库是部署在一起的吗？
--您所说的延迟是指什么？从我这边的实际看如果应用服务器与数据库分开部署延时增加还算比较有限，但是如果应用服务器和数据库服务器大量的sql会导致大量的网络交换从而消耗大量的资源。
原来的数据库是ORACLE，俺现在想到的方案是在云里配置In-Memory Database来根本的改进性能问题，
oracle就是Timesten了，但问题来了oracle实在是太贵了。
--从您的描述看实质上是使用虚拟机来承担应用服务器职能？
--从解决这个问题来说，个人建议也可以考虑应用服务用一些共享内存或者free的memdb，这样对应用服务器做修改修改可能会相对大一点，考虑到大部分的sql查询应该都是很简单的，应该修改量还可以接受。
另一个方案就是后端迁到DB2+前端solidDB,但这边的证券公司没怎么用过IBM的东西，迁移会有很多问题。
比如原系统的AQ怎么办？
--我也是在证券行业的，如果有需要，我们可以互相交流，我的msn:hongtao2000@msn.com收起
如果单纯把应用服务器移动到云里，必然面临应用服务器与关系数据库之间的延迟问题，
对大量的小数据存取是比较致命的。--现有系统的应用服务器和数据库是部署在一起的吗？
--您所说的延迟是指什么？从我这边的实际看如果应用服务器与数据库分开部署延时增加还算比较有限，但是如果应用服务器和数据库服务器大量的sql会导致大量的网络交换从而消耗大量的资源。
原来的数据库是ORACLE，俺现在想到的方案是在云里配置In-Memory Database来根本的改进性能问题，
oracle就是Timesten了，但问题来了oracle实在是太贵了。
--从您的描述看实质上是使用虚拟机来承担应用服务器职能？
--从解决这个问题来说，个人建议也可以考虑应用服务用一些共享内存或者free的memdb，这样对应用服务器做修改修改可能会相对大一点，考虑到大部分的sql查询应该都是很简单的，应该修改量还可以接受。
另一个方案就是后端迁到DB2+前端solidDB,但这边的证券公司没怎么用过IBM的东西，迁移会有很多问题。
比如原系统的AQ怎么办？
--我也是在证券行业的，如果有需要，我们可以互相交流，我的msn:hongtao2000@msn.com收起
浏览1594