Nat*_*ley 6 sql-server performance database-design
我想要一些关于在线资源(博客,指南等 - 而不是论坛)的建议,以帮助我擅长设计高性能SQL Server数据库,这些数据库运行大量数据并且在数据周转和查询方面负担很重分钟.
建议？
编辑
我所说的负载主要是数据周转率.主表有多达一百万行,大约30个不同大小的数据字段,每天更新大约30-40000个新行,每天至少有200000行用新数据更新.这些更新在一整天内持续发生.除此之外,需要在一天内从数据库中提取所有更改和更新,以使最新的Lucene索引保持最新状态.
听起来像是中等服务器上的相当可管理的负载 - 您还没有说在进行这些插入和更新时发生了什么样的读取操作（除了 Lucene 的提取）以及大小（按字节/数据类型）明智的）数据（您给出的基数似乎很好）。
此时，我建议仅使用常规 SQL Server 最佳实践- 确定合适的模式（规范化，然后仅在必要时非规范化），检查执行计划，使用索引调整向导，使用 DMV查找未使用的索引并删除它们，仔细选择聚集索引来管理页面拆分，仔细选择数据类型和大小，并尽可能使用引用完整性和约束，为优化器提供尽可能多的帮助。除此之外，还有性能计数器并确保您的硬件/软件安装得到调整。
在许多/大多数情况下，您永远不需要超越这一点来实际重新设计您的架构。
然而，即使如此，如果读取负载很重，插入和更新可能会导致读取和写入之间的锁定问题，然后您需要考虑应用程序的架构决策。
另外，每天数百万行和 20 万次更新不会让我担心 - 但你提到了 Lucene（即全文索引），所以大概有些列相当大。更新大型列并导出它们显然需要更长的时间，并且需要更多的带宽和 IO。具有传统数据类型列的狭窄的百万行表中的 30 列将是一个完全不同的故事。您可能需要查看更新配置文件，看看是否需要对表进行垂直分区以将某些列移出行（如果它们很大，它们将已经存储在行外）以改进锁定行为。
因此，当读取负载很重时，关键是：插入和更新需要尽可能快，锁定尽可能少（避免锁定升级），更新尽可能少的索引以支持读取操作。
如果读取负载如此重（以致插入/更新开始冲突）但不需要 100% 最新信息（例如 5 分钟或 15 分钟延迟不明显），您可以使用只读版本维护的数据库（通过复制相同、为性能建立不同索引、非规范化或不同建模 - 如维度模型）。也许您的 Lucene 索引可以包含附加信息，以便昂贵的读取操作全部保留在 Lucene 中 - 即 Lucene 覆盖许多大型读取操作，从而将数据库上的读取负载减少到支持插入/更新的基本读取（这些通常是小读取）和应用程序的事务部分（即客户服务信息屏幕将使用常规数据库，而每小时仪表板将使用辅助数据库）。