Sql 高写入（10000次插入/小时）、低读取（10次读取/秒）的最佳数据库？

我正在开发一个web应用程序，目前正在使用SQLServer2008。但是，为了提高性能，我正在考虑迁移到另一个数据库（simpledb）

我有一个后台进程，每小时将多达10000行插入到一个特定的表中。该表也可以从中读取以在web应用程序中显示数据。后台进程运行时，web应用程序不可用，因为db连接超时

---

因此，我正在考虑使用amazon的simpledb来提高性能。amazon的SimpleDB是否针对该用例进行了优化？如果没有，我是否可以使用另一种解决方案？

每秒插入3次以下不会给任何DBMS带来锻炼，除非在每次插入操作中插入的数据量是惊人的。类似地，每秒10次读取不太可能对任何有能力的DBMS造成过度压力，除非有一些您没有提到的复杂因素（例如“读取是整个DBMS上的聚合的集合，经过一段时间后，将累积数十亿条记录……好吧，对于前十亿条记录来说是100000个小时，大约是4000天，或者大约是10年）。

您的问题是您使用的隔离级别。除非您更改它，否则SQL Server（以及许多其他数据库）的运行模式是，selects将阻止未提交的读取。如果您希望更改SQL Server，使其改用它（Oracle的默认设置；MySQL和SQL Server都有），那么问题就会迎刃而解

发件人：

阅读承诺 指定语句不能读取 已修改但未修改的数据 由其他事务提交。此 防止脏读。数据可以被删除 由之间的其他交易更改 内部的个别声明 当前交易，导致 不可重复读取或虚拟数据。 此选项是SQL Server默认设置

读取提交的行为取决于 论网络环境的设置 读取提交的快照数据库 选项：

• 如果READ_COMMITTED_SNAPSHOT设置为OFF（默认设置），则数据库引擎 使用共享锁防止其他错误 修改行时的事务 当前事务正在运行一个 读取操作。共享锁也会被删除 阻止语句读取行 由其他交易修改，直到 其他事务已完成。 共享锁类型决定何时使用 它将被释放。行锁被禁用 在下一行之前释放 已处理。页面锁已释放 当阅读下一页时，和表 当语句 完成
• 如果READ_COMMITTED_SNAPSHOT设置为ON，则数据库引擎将使用row 显示每个语句的版本控制 具有事务一致性 数据在上存在时的快照 语句的开头。锁是 不用于保护数据免受攻击 由其他事务更新

当READ_提交快照时 数据库选项处于启用状态，您可以使用 READCOMMITTEDLOCK表提示 请求共享锁定而不是行 单个语句的版本控制 在读取时运行的事务中 提交隔离级别

（增加重点）

更改您的数据库配置，以将“读取\u提交的\u快照”打开

---

此外，尽量使事务保持尽可能短的生命周期，并确保在后台进程中提交事务（即每小时执行10000次插入），因为如果事务从不提交，则选择将永远阻止（默认设置下）.

正如其他人所说，写入数据库的数据量不是问题。SQL Server可以轻松处理比这多得多的数据。就我个人而言，我的表每小时占用数十万到数百万行，没有任何问题，而且人们整天都在阅读这些行，没有任何减速

您可能需要通过更改read语句的隔离级别或使用WITH（NOLOCK）提示来查看执行脏读

您应该考虑使用.NET中的大容量上载对象将数据加载到数据库中。根据测试期间看到的性能，使用1000-5000批。您需要使用数字来获得最佳性能。将数据大容量插入表将比插入数据提供更好的性能逐行记录。请确保不要在单个事务中完成整个上载。您应该每批执行一个事务

写入数据库时，磁盘IO是什么样子的

您为数据库设置了什么恢复模式？与使用简单恢复模式相比，对数据库进行完全恢复需要更多的IO。只有在实际需要随附的时间点恢复时才使用完全恢复

---

继Joel的回答之后，您可能需要考虑为索引上的PAD_INDEX和FILLFACTOR设置适当的值。如果您没有指定这些选项，您的insert可能会对索引进行大量重新分页，这将显著降低您的写入时间。

10000 inserts/hr=2.7…/sec不应杀死database.MySQL和PostgreSQL可以轻松做到这一点。SQL Server也应该能够做到。这就是我的想法……但我遇到了死锁。表在插入过程中被锁定，因此web应用程序会暂停，因为当后台进程插入数据时，它无法从数据库读取数据。@rksprst:可能发生了死锁，而不是因为data卷，但数据进入此表的方式。为什么每小时10000次写入“高”，而每小时36000次读取“低”（10/sec*3600 sec/hour）？这里有第一个问题。逐行插入是将数据放入SQL Server表的最有效方式。请参阅下面我关于批量插入da的回答