在我的工作中,我们有一个小型数据库(如200个表中,可能总共有100万行左右).
我一直期望它以每秒几十万次插入的顺序非常快,并且一旦建立连接就需要几毫秒的查询.
恰恰相反,我们遇到了一些性能问题,因此我们每秒只能进行几百次插入和查询,即使是最简单的插入也是永远需要的.
如果这是标准的行为/表现,或者我们做错了什么,我并不确定.例如,1500个查询意味着在一个键列上连接4个表大约需要10秒.在不违反任何约束的情况下,使用简单插入将xml格式的300K数据加载到数据库中需要3分钟.
该数据库是sql Server 2005,具有丰富的关系依赖模型,意味着对数据的大量关系和分类以及分类代码和其他一些事项的全套检查约束.
解决方法
进行粗略的比较：
TPC-C benchmark record for SQL Server是每分钟大约1.2万个事务处理,并且在过去4年左右就是这样(由64 cpu OS限制).这是每秒约16k交易量的事情.这是在超高端机器,64个cpu,大量RAM,每个NUMA节点的亲和客户端和服务器短剥离的I / O系统(每个主轴仅使用1-2％左右).请记住那些是TPC-C事务,因此它们包含多个操作(我认为平均每个操作4-5次读取和1-2次写入).
现在,您应该将此顶级硬件缩减到实际部署,并将获得设置您对整个OLTP事务处理的期望的大概.
对于数据上传当前world record is about 1TB in 30 minutes(如果仍然是当前…).每秒几万次插入是非常雄心勃勃的,但是如果在严肃的硬件上正确完成,则可以实现.链接中的文章包含ETL高吞吐量的提示和技巧(例如,使用多个上传流并将它们与NUMA节点关联).
根据您的情况,我会首先提出建议,以便找出瓶颈,然后询问具体问题如何解决特定的问题.一个很好的起点是Waits and Queues whitepaper.
