好吧，除了这个问题，没什么可问的。当您说 OLTP DB 必须具有高吞吐量时，您是什么意思。
去维基。
“在通信网络中，例如以太网或分组无线电，吞吐量或网络吞吐量是通过通信信道成功传递消息的平均速率。这些数据可以通过物理或逻辑链路传递，或通过某个网络节点。吞吐量通常以每秒位数（bit/s 或 bps）为单位，有时以每秒数据包或每个时隙的数据包为单位。”
那么这是否意味着，OLTP 数据库需要具有高/快速的插入率（即避免死锁等）？
如果我们以航空业为例，我总是有这样的印象，它必须具有快速插入，但同时又要快速响应，因为它对其运营至关重要。在许多方面，这不应该仅限于将消息/数据传递到数据库所涉及的协议吗？
我并不是要挑出 OLTP 系统的“唯一”特征。一般来说，我想了解 OLTP 系统固有的特性。
干杯!
通常，当您谈论 OLTP 数据库的“吞吐量”时，您指的是每秒的事务数。系统一秒钟能处理多少订单，能服务多少网页请求，能处理多少客户查询。这往往与关于 OLTP 系统如何扩展的讨论密切相关——例如，如果您因为业务起飞而每月访问您的网站的客户数量增加一倍，那么 OLTP 系统是否能够处理增加的吞吐量。
这与 OLAP/DSS 系统形成鲜明对比，后者旨在在更大的数据量上运行相对较少的事务。在那里，您对可以执行的事务数量的担忧要远远少于对添加更多数据时这些事务如何减慢的担忧。如果您是一家非常成功的公司，您可能希望从您的 OLAP 系统中按地区报告的产品销售数量和频率与您产生成倍增长的销售额相同。但是您现在要处理的数据呈指数级增长，这需要您调整数据库以保持报告性能不变。
在这种情况下，吞吐量没有单一的、固定的含义。粗略地说，它表示每秒的事务数，但“写入”事务与“读取”事务不同，持续速率与峰值速率不同。（当然，10 字节的行与 1000 字节的行不同。）
前几天我在寻找其他东西时偶然发现了Performance Metrics & Benchmarks: Berkeley DB 。对衡量“多快”的不同方法的介绍也不错。此外，这篇关于数据库基准测试的文章也很有趣。