艰难的选择 [英] tough choices
问题描述
您好：
我们正在设计两个多用户客户端服务器应用程序，它们在数据库服务器上执行大量事务。在一个
平均应用程序A有50％混合选择和更新/插入/删除
语句和应用程序B有80-20混合选择和
更新/插入/删除语句。能够将数据库扩展为所需的数据，以便性能不受影响，这是我们关键的b $ b b要求之一。我们一直在调查Oracle 10g RAC和DB2 ESE作为
的替代方案，不幸的是，在这两种情况下，我们获得了比实际答案更多的市场营销。我已经查看了oracle和ibm网站上的一些
新闻组的帖子，而且大多数的讨论似乎是关于高可用性（和技术
福音传道）。到目前为止我们收集的信息似乎指向：
1.甲骨文RAC的关键因素（可能是瓶颈）
性能是网络和存储访问速度 - 如果
网络没有足够的未使用带宽或者各个节点可以访问存储的速度达到
收益递减 - 我们不会通过增加节点数来获得额外的性能。
此外，
执行更多写入的应用程序将极大地增加网络流量，因为
的同步要求。
2. DB2可以提供更好的性能，但前提是一起访问的数据是物理布局的，并且应用程序
了解物理数据布局（因此它可以连接到集群中的
右侧节点）。但是，如果我们将应用程序
逻辑与数据的物理布局分开，那么性能将是不可预测的。
全部这只是假设 - 如果有人拥有一些真实的世界经验
这两个产品并且可以提供客观的意见 - 我们会给b $ b非常感激。
Sy Borg写道：您好：
我们正在设计两个多用户客户端服务器应用程序
在数据库服务器上执行大量事务。平均而言，应用程序A具有50％的select和update / insert / delete
语句组合，而应用程序B具有80-20混合的select和
update / insert / delete语句。能够按需扩展数据库以使性能不受影响，这是我们的关键要求之一。我们一直在研究Oracle 10g RAC和DB2 ESE作为替代方案，不幸的是，在这两种情况下，我们获得了比真实答案更多的营销旋转。我已经查看了oracle和ibm网站上的一些新闻组帖子，大多数讨论似乎都是关于高可用性（以及技术的传播）。到目前为止我们收集的信息似乎指出：
1. Oracle的RAC性能的关键因素（可能是瓶颈）是网络和存储访问速度 - 如果
网络没有足够的未使用带宽或各种节点可以访问存储的速率已经达到了收益递减的程度 - 我们不会得到通过简单地增加节点数量来增加任何性能。此外，由于同步要求，执行更多写入的应用程序将极大地增加网络流量。
2. DB2可以提供更好的性能，但仅当数据<一起访问的物理布局在一起，应用程序具有物理数据布局的知识（因此它可以连接到集群中的右侧节点）。但是，如果我们将应用程序的逻辑与数据的物理布局分开，那么性能将无法预测。
所有这些只是假设 - 如果有人有一些真实的世界经验
这两个产品可以提供客观的意见 - 我们会非常感激。
你有没有硬件/ os平台被选中，因为高事务率应用程序中的底层技术与您选择的数据库引擎一样重要。由于高交易
利率是非常主观的，你能否更多地量化这一点。
使用RAC，（并取决于您的平台） ）来自集群中所有节点的物理访问数据来源 - 同时 - 将是恕我直言。
有集群那些不允许从多个节点同时访问所有文件系统的技术，你需要
来仔细研究它们。
但是如果你想使用原始的话。 RAC，在OpenVMS集群上使用Oracle Rdb（不要与RDBMS混淆
- 以前的DEC Rdb）。一个
集群，可以是~256个节点，使用SAN存储，多个PB的存储空间。应用程序可以在
集群中的所有节点上同时运行。 BTW，大量的证券交易所依赖OpenVMS和Rdb
在交易大厅......得出你自己的结论。
Michael Austin。
" Sy Borg" <博********* @ yahoo.ca>在消息中写道
news：b2 ************************* @ posting.google.co m ... < blockquote class =post_quotes>您好：
2. DB2可以提供更好的性能，但前提是一起访问的数据在一起实际布局且应用程序具有了解物理数据布局（因此它可以连接到集群中的右侧节点）。但是，如果我们将应用程序逻辑与数据的物理布局分开，性能将无法预测。
我不确定你的意思是什么（2号），但我不认为这是正确的。但在通过最终判决之前，我想听听你的意思更好的解释。
此外，任何一个数据库都可能处理大多数应用程序<从性能的角度来看，同样好的是
。例外情况可能是你的b $ b有一些非常高的交易或查询量或非常大的
表（两者都没有详细说明，无法通过判断
on）..
关于DB2的观点在某些情况下是正确的，但并非所有情况都是如此。它当然是
意味着你正在使用带有DPF的DB2（分布式分区功能 - 在v8之前名为EEE的
）。
这是一篇关于在分区环境中加速插入的文章：
http://www-106.ibm.com/developerwork...04pooloth.html
Sy Borg写道：您好：
我们正在设计两个多用户客户端服务器应用程序，它们可以在数据库服务器上执行大量事务。平均而言，应用程序A具有50％的select和update / insert / delete
语句组合，而应用程序B具有80-20混合的select和
update / insert / delete语句。能够按需扩展数据库以使性能不受影响，这是我们的关键要求之一。我们一直在研究Oracle 10g RAC和DB2 ESE作为替代方案，不幸的是，在这两种情况下，我们获得了比真实答案更多的营销旋转。我已经查看了oracle和ibm网站上的一些新闻组帖子，大多数讨论似乎都是关于高可用性（以及技术的传播）。到目前为止我们收集的信息似乎指出：
1. Oracle的RAC性能的关键因素（可能是瓶颈）是网络和存储访问速度 - 如果
网络没有足够的未使用带宽或各种节点可以访问存储的速率已经达到了收益递减的程度 - 我们不会得到通过简单地增加节点数量来增加任何性能。此外，由于同步要求，执行更多写入的应用程序将极大地增加网络流量。
2. DB2可以提供更好的性能，但仅当数据<一起访问的物理布局在一起，应用程序具有物理数据布局的知识（因此它可以连接到集群中的右侧节点）。但是，如果我们将应用程序的逻辑与数据的物理布局分开，那么性能将无法预测。
所有这些只是假设 - 如果有人有一些真实的世界经验
这两个产品可以提供客观的意见 - 我们会非常感激。
Hello:
We are designing two multi-user client server applications that
performs large number of transactions on database servers. On an
average Application A has a 50% mix of select and update/insert/delete
statements and application B has 80-20 mix of select and
update/insert/delete statements. Being able to scale the databases as
needed so the performance is unaffected, is one of our critical
requirements. We''ve been investigating Oracle 10g RAC and DB2 ESE as
alternatives and in both cases unfortunately, we get a lot more
marketing spin than real answers. I''ve looked through some of the
newsgroup postings on oracle and ibm''s websites and most of the
discussions seem to be about high availability(and technology
evangelism). The information we''ve gathered so far seems to point to:
1. The critical factor (and possibly the bottleneck) for Oracle''s RAC
performance is the network and the storage access speed- if the
network does not have ample unused bandwidth or the rate at which
storage can be accessed by various nodes has reached the point of
diminishing returns - we won''t get any additional performance by
simply increasing the number of nodes. Also, the application that
performs more writes will hugely increase the network traffic because
of synchronization requirements.
2. DB2 can deliver better performance but only if the data that is
accessed together is physically laid out together and the application
has knowledge of the physical data layout (so it can connect to the
right node in the cluster ). However, if, we separate the application
logic from physical layout of the data the performance will be
unpredictable.
All this is just hypotheses - if anyone has some real world experience
with these two offerings and can offer an objective opinion - we''d
really appreciate it.
Sy Borg wrote:Hello:
We are designing two multi-user client server applications that
performs large number of transactions on database servers. On an
average Application A has a 50% mix of select and update/insert/delete
statements and application B has 80-20 mix of select and
update/insert/delete statements. Being able to scale the databases as
needed so the performance is unaffected, is one of our critical
requirements. We''ve been investigating Oracle 10g RAC and DB2 ESE as
alternatives and in both cases unfortunately, we get a lot more
marketing spin than real answers. I''ve looked through some of the
newsgroup postings on oracle and ibm''s websites and most of the
discussions seem to be about high availability(and technology
evangelism). The information we''ve gathered so far seems to point to:
1. The critical factor (and possibly the bottleneck) for Oracle''s RAC
performance is the network and the storage access speed- if the
network does not have ample unused bandwidth or the rate at which
storage can be accessed by various nodes has reached the point of
diminishing returns - we won''t get any additional performance by
simply increasing the number of nodes. Also, the application that
performs more writes will hugely increase the network traffic because
of synchronization requirements.
2. DB2 can deliver better performance but only if the data that is
accessed together is physically laid out together and the application
has knowledge of the physical data layout (so it can connect to the
right node in the cluster ). However, if, we separate the application
logic from physical layout of the data the performance will be
unpredictable.
All this is just hypotheses - if anyone has some real world experience
with these two offerings and can offer an objective opinion - we''d
really appreciate it.
Do you already have a hardware/os platform picked out, because the
underlying technology in a high-transaction rate application is just as
important as the database engine you choose. Since "high-transaction"
rate is quite subjective, can you quantify that point a bit more.
With RAC, (and depending on your platform) physical access to the data
from ALL nodes in the cluster - concurrently - would be IMHO imperative.
There are "cluster" technologies out there that do not allow
concurrent access to all file systems from multiple nodes and you need
to research them carefully.
But if you want to use the "original" RAC, use Oracle Rdb (not to be
confused with RDBMS - formerly DEC Rdb) on an OpenVMS cluster. A
cluster that can be ~256 nodes and using SAN storage, multiple-PB of
storage. And the application can run concurrently on all nodes in the
cluster. BTW, A large number of stock exchanges rely on OpenVMS and Rdb
on the trading floor... draw your own conclusions.
Michael Austin.
"Sy Borg" <bo*********@yahoo.ca> wrote in message
news:b2*************************@posting.google.co m...Hello:
2. DB2 can deliver better performance but only if the data that is
accessed together is physically laid out together and the application
has knowledge of the physical data layout (so it can connect to the
right node in the cluster ). However, if, we separate the application
logic from physical layout of the data the performance will be
unpredictable.
I am not sure what you mean by this (number 2), but I don''t think it is
correct. But before passing final judgment, I would like hear a better
explanation of what you mean.
Also, either database will probably handle the majority of applications
equally well from a performance standpoint. The exception might be if you
had some unusually high transaction or query volumes or unusually large
tables (neither of which was specified in enough detail to pass judgment
on)..
Your point about DB2 is true in some but not all cases. It certainly
implies you''re using DB2 with DPF (Distributed Partitioning Feature -
called EEE before v8).
Here is an article on speeding up inserts in a partitioned environment:
http://www-106.ibm.com/developerwork...04pooloth.html
Sy Borg wrote:Hello:
We are designing two multi-user client server applications that
performs large number of transactions on database servers. On an
average Application A has a 50% mix of select and update/insert/delete
statements and application B has 80-20 mix of select and
update/insert/delete statements. Being able to scale the databases as
needed so the performance is unaffected, is one of our critical
requirements. We''ve been investigating Oracle 10g RAC and DB2 ESE as
alternatives and in both cases unfortunately, we get a lot more
marketing spin than real answers. I''ve looked through some of the
newsgroup postings on oracle and ibm''s websites and most of the
discussions seem to be about high availability(and technology
evangelism). The information we''ve gathered so far seems to point to:
1. The critical factor (and possibly the bottleneck) for Oracle''s RAC
performance is the network and the storage access speed- if the
network does not have ample unused bandwidth or the rate at which
storage can be accessed by various nodes has reached the point of
diminishing returns - we won''t get any additional performance by
simply increasing the number of nodes. Also, the application that
performs more writes will hugely increase the network traffic because
of synchronization requirements.
2. DB2 can deliver better performance but only if the data that is
accessed together is physically laid out together and the application
has knowledge of the physical data layout (so it can connect to the
right node in the cluster ). However, if, we separate the application
logic from physical layout of the data the performance will be
unpredictable.
All this is just hypotheses - if anyone has some real world experience
with these two offerings and can offer an objective opinion - we''d
really appreciate it.
这篇关于艰难的选择的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
