oracle 什么是数据库吞吐量?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/5656566/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is database throughput?
提问by Ricko M
Well, not much to ask apart from the question. What do you mean when you say a OLTP DB must have a high throughput.
好吧,除了这个问题,没什么好问的。当您说 OLTP 数据库必须具有高吞吐量时,您是什么意思。
Going to the wiki.
去维基。
"In communication networks, such as Ethernet or packet radio, throughput or network throughput is the average rate of successful message delivery over a communication channel. This data may be delivered over a physical or logical link, or pass through a certain network node. The throughput is usually measured in bits per second (bit/s or bps), and sometimes in data packets per second or data packets per time slot."
“在通信网络中,例如以太网或分组无线电,吞吐量或网络吞吐量是通过通信信道成功传递消息的平均速率。这些数据可以通过物理或逻辑链路传递,或者通过某个网络节点。吞吐量通常以每秒比特数(bit/s 或 bps)来衡量,有时以每秒数据包数或每时隙数据包数来衡量。”
So does this mean , OLTP databases need to have a high/quick insertion rate ( i.e. avoiding deadlocks etc)??
那么这是否意味着 OLTP 数据库需要具有高/快速插入率(即避免死锁等)??
I was always under an impression if we take a database for say an airline industry, it must have quick insertion , but at the same time quick response time since it is critical to it's operation. And in many ways this shouldn't this be limited to the protocol involved in delivering the message/data to the database?
我一直有一个印象,如果我们以航空业为例,它必须具有快速插入,但同时响应时间快,因为它对其运营至关重要。在许多方面,这不应该仅限于将消息/数据传递到数据库所涉及的协议吗?
I am not trying to single out the "only" characteristic of OLTP systems. In general I would like to understand, what characteristics are inherent to a OLTP system.
我并不是要挑出 OLTP 系统的“唯一”特征。一般来说,我想了解 OLTP 系统固有的特性。
Cheers!
干杯!
回答by Justin Cave
In general, when you're talking about the "throughput" of an OLTP database, you're talking about the number of transactions per second. How many orders can the system take a second, how many web page requests can it service, how many customer inquiries can it handle. That tends to go hand-in-hand with discussions about how the OLTP system scales-- if you double the number of customers hitting your site every month because the business is taking off, for example, will the OLTP systems be able to handle the increased throughput.
通常,当您谈论 OLTP 数据库的“吞吐量”时,您谈论的是每秒事务数。系统一秒钟可以处理多少订单,可以处理多少网页请求,可以处理多少客户查询。这往往与关于 OLTP 系统如何扩展的讨论密切相关——例如,如果您因为业务起飞而每月访问您网站的客户数量增加一倍,例如,OLTP 系统是否能够处理增加吞吐量。
That is in contrast to OLAP/ DSS systems which are designed to run a relatively small number of transactions over much larger data volumes. There, you're worried far less about the number of transactions you can do than about how those transactions slow down as you add more data. If you're that wildly successful company, you probably want the same number and frequency of product sales by region reports out of your OLAP system as you generate exponentially more sales. But you now have exponentially more data to crunch which requires that you tune the database just to keep report performance constant.
这与 OLAP/DSS 系统形成对比,OLAP/DSS 系统旨在在更大的数据量上运行相对较少的事务。在那里,您对可以执行的事务数量的担心远少于这些事务随着您添加更多数据而变慢的程度。如果您是那家非常成功的公司,您可能希望在您的 OLAP 系统中按区域报告的产品销售数量和频率与您产生的销售额成倍增加相同。但是您现在需要处理成倍增加的数据,这需要您调整数据库以保持报表性能不变。
回答by Mike Sherrill 'Cat Recall'
Throughputdoesn't have a single, fixed meaning in this context. Loosely, it means the number of transactions per second, but "write" transactions are different than "read" transactions, and sustained rates are different than peak rates. (And, of course, a 10-byte row is different than a 1000-byte row.)
在这种情况下,吞吐量没有单一的、固定的含义。松散地说,它意味着每秒的事务数,但“写”事务与“读”事务不同,持续速率与峰值速率不同。(当然,10 字节的行与 1000 字节的行不同。)
I stumbled on Performance Metrics & Benchmarks: Berkeley DBthe other day when I was looking for something else. It's not a bad introduction to the different ways of measuring "how fast". Also, this article on database benchmarksis an entertaining read.
前几天我在寻找其他东西时偶然发现了Performance Metrics & Benchmarks: Berkeley DB。对衡量“多快”的不同方法的介绍不错。此外,这篇关于数据库基准测试的文章很有趣。