什么是数据库吞吐量？
好吧，除了问题之外没什么可问的。当您说 OLTP 数据库必须具有高吞吐量时，您的意思是什么？
去维基百科吧。
“在通信网络中，例如 以太网或分组无线电、吞吐量 或者网络吞吐量是平均值 消息发送成功率 通过通信渠道。这 数据可以通过物理传输 或逻辑链接，或通过 某个网络节点。吞吐量 通常以每秒位数来衡量 （bit/s 或 bps），有时在数据中 每秒数据包数或每数据包数 时间段。”
那么这是否意味着，OLTP 数据库需要具有高/快速的插入率（即避免死锁等）？？
如果我们采用航空业的数据库，它必须具有快速插入，但同时快速响应时间，因为它对其操作至关重要，并且在很多方面，这不应该仅限于将消息/数据传递到数据库所涉及的协议吗
？ OLTP 系统的“唯一”特征 一般来说，我想了解 OLTP 系统固有的特征是什么
。
Well, not much to ask apart from the question. What do you mean when you say a OLTP DB must have a high throughput.
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."
So does this mean , OLTP databases need to have a high/quick insertion rate ( i.e. avoiding deadlocks etc)??
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.
Cheers!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一般来说，当您谈论 OLTP 数据库的“吞吐量”时，您谈论的是每秒的事务数。系统每秒可以处理多少个订单，可以服务多少个网页请求，可以处理多少个客户查询。这往往与有关 OLTP 系统如何扩展的讨论齐头并进——例如，如果由于业务腾飞而每月访问站点的客户数量增加一倍，那么 OLTP 系统是否能够处理增加吞吐量。
这与 OLAP/DSS 系统形成鲜明对比，OLAP/DSS 系统旨在在更大的数据量上运行相对少量的事务。在那里，您担心的远不是您可以执行的事务数量，而是担心随着您添加更多数据这些事务会如何减慢。如果您是一家非常成功的公司，您可能希望在 OLAP 系统中按区域报告产品销售的数量和频率，同时您的销售额呈指数级增长。但现在您需要处理的数据呈指数级增长，这需要您调整数据库以保持报告性能恒定。
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.
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.
吞吐量在此上下文中没有单一、固定的含义。宽松地说，它意味着每秒的事务数，但“写入”事务与“读取”事务不同，并且持续速率与峰值速率不同。 （当然，10 字节的行与 1000 字节的行不同。）
我偶然发现 性能指标和基准：Berkeley DB 有一天，当我在寻找其他东西时。这是对测量“多快”的不同方法的不错的介绍。另外，这篇关于数据库基准测试的文章读起来很有趣。
Throughput doesn'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.)
I stumbled on Performance Metrics & Benchmarks: Berkeley DB the 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 benchmarks is an entertaining read.