sql-server - 每天3000万条记录，SQL Server跟不上，需要其他类型的数据库系统吗？

Question

不久前，我考虑为我们拥有数百万用户的网站设计一个新的统计系统，以记录和报告客户的用户操作。

数据库设计非常简单，包含一个表，一个表，一个foreignId(200,000个不同的id)，一个日期时间字段，一个actionId(30个不同的id)，以及另外两个包含一些元信息(只是小整数)的字段。其他表没有任何限制。此外，我们有两个索引，每个索引包含 4 个字段，不能删除它们，因为当我们拥有较小的索引时，用户会超时。 foreignId 是最重要的字段，因为每个查询都包含此字段。

我们选择使用 SQL Server，但实现后关系数据库似乎不太适合，因为我们无法每天插入 3000 万条记录(它只是插入，我们不做任何更新)对数据库进行大量随机读取；因为索引更新得不够快。因此:我们有一个大问题:-)我们已经暂时解决了问题，但是

关系数据库似乎不适合解决这个问题!

像 BigTable 这样的数据库是更好的选择吗？为什么？或者在处理此类问题时还有其他更好的选择吗？

注意。此时我们使用具有 4 GB 内存和 Win 2003 32 位的单 8 核 Xeon 系统。据我所知，RAID10 SCSI。索引大小约为表大小的 1.5 倍。

Answer 1

您说您的系统在没有索引的情况下每秒能够插入 3000 条记录，但在有两个附加非聚集索引的情况下只能插入大约 100 条记录。如果 3k/s 是您的 I/O 允许的最大吞吐量，那么理论上添加两个索引应该会降低大约 1000-1500/秒的吞吐量。相反，您会发现性能下降了 10 倍。正确的解决方案和答案是“视情况而定”，并且必须进行一些认真的故障排除和瓶颈识别。考虑到这一点，如果我大胆猜测，我会给出两个可能的罪魁祸首:

A.附加的非聚集索引将脏页的写入分布到更多的分配区域。解决方案是将聚集索引和每个非聚集索引放入其自己的文件组中，并将这三个文件组分别放入 RAID 上的单独 LUN 上。

B.非聚集索引的低选择性会造成读取和写入之间的高争用(键冲突以及 %lockres% conflicts )，从而导致插入和选择的锁定等待时间较长。可能的解决方案是使用带有 read committed snapshot mode 的快照，但我必须警告在 version store 中添加大量 IO 的危险。 (即在 tempdb 中)在可能已经处于高 IO 压力下的系统上。第二种解决方案是使用 database snapshots对于报告而言，它们会导致较低的 IO 压力，并且可以更好地控制它们(不涉及 tempdb 版本存储)，但报告不再基于实时数据。

我倾向于相信 B) 是可能的原因，但我必须再次强调需要进行适当的调查和适当的根本案例分析。

“RAID10”并不是一个非常精确的描述。

• RAID 0 部分有多少个主轴？它们是短条纹的吗？
• 有多少个 LUN？
• 数据库日志位于何处？
• 数据库位于哪里？
• 有多少个分区？
• tempdb 位于哪里？

至于关系数据库是否适合这样的问题，是的，绝对适合。还有很多因素需要考虑，可恢复性、可用性、工具集生态系统、专业知识、开发的简易性、部署的简易性、管理的简易性等等。关系数据库可以轻松处理您的工作负载，它们只需要适当的调整。每天 3000 万次插入，每秒 350 次，对于数据库服务器来说只是很小的变化。但是，无论 CPU 数量有多少，32 位 4GB RAM 系统都很难成为数据库服务器。