为读写优化的数据库表答案

【问题标题】：Database tables optimized for both read and write为读写优化的数据库表
【发布时间】：2015-03-17 13:21:45
【问题描述】：

我们有一个 Web 服务，可将数据泵入 3 个数据库表，还有一个 Web 应用程序，可在 SQL Server + ASP.Net 环境中以聚合格式读取该数据。

有如此多的数据到达数据库表，并以如此高的速度从它们读取大量数据，以致系统开始出现故障。

这些表上有索引，其中一个是唯一的。其中一张表有数十亿条记录，占用数百 GB 的磁盘空间；另一张表较小，只有几百万条记录。每天清空。

我有哪些选项可以消除同时读写多个数据库表的明显问题？

我对每一个优化技巧都很感兴趣，尽管我们已经尝试了我们遇到的每一个技巧。

我们没有安装 SQL Server 企业版以使用分区和in-memory-optimized tables 的选项。

编辑：该系统用于从数以万计的设备收集健身追踪器数据，并将数据实时显示在数以千计的设备上。

【问题讨论】：

【解决方案1】：

要求和细节过于宽泛，无法给出具体答案。但建议是设置第二个数据库并将日志传送到它。所以原始数据库将是“写入”数据库，而新数据库将是“读取”数据库。

缺点

专业版 - 可能会删除“写入”数据库上的一些索引，这会/可能会提高性能 - 然后您可以在“读取”数据库中汇总表以提高查询性能

【讨论】：

这听起来正是我所需要的，但用户需要几乎实时的数据，所以我只能拒绝他们可能是最近 10 分钟的数据。如果我理解正确，在传输数据时无法读取只读数据库...
“rad-only”术语并不是真正的只读数据库，它更像是一个报告数据库。但是与主数据库分开，这将减轻主数据库的负载。您可以在加载日志时对报告/只读数据库运行查询。但是数据库中的数据将是“旧的”，因为日志文件将每 30 分钟发送一次（例如），因此数据将是 30 分钟旧的。

【解决方案2】：

这里有一些想法，有些想法比其他想法更复杂，它们的实用性在很大程度上取决于问题中未完全描述的用法。免责声明：我不是 DBA，但我在我的 DB 项目中与一些优秀的人合作过。

[简单]更多的系统内存总是有帮助的
[简单] 为 tempdb 使用多个文件（一个文件组，系统上每个核心 1 个文件。即使查询完全在内存中完成，它仍然可以阻止I/O 线程）
[Simple] SIMPLE 上的事务日志超过 FULL 恢复
[简单] 事务日志写入将主轴与其余数据分开。
[复杂] 自己将数据拆分到单独的表中，然后在查询中合并它们。
- [复杂] 尝试将未更新的数据放入单独的表中，这样就不需要重新构建静态数据索引。
[复杂] 如果可能，请确保您正在执行仅追加插入（自动递增 PK/聚集索引应该已经在执行此操作）。显然，尽可能避免更新。
[复杂] 如果查询不需要绝对最新数据，请将读取查询更改为对表使用 WITH NOLOCK，并从索引中删除行锁和页锁。您不会得到不完整的行，但如果在阅读的同时写入，您可能会错过几行。
[复杂] 为表数据和索引数据创建单独的文件组。如果可能，将这些文件组放在单独的磁盘轴上。 SQL Server 对每个文件都有单独的 I/O 线程，因此您可以在一定程度上并行读取/写入。
- 另外，请确保所有大表都位于不同的文件组中，也位于不同的主轴上。
[复杂]删除带有事务锁的插入
[复杂] 对数据使用批量插入
[复杂] 删除不必要的索引
- 如果不需要对包含的列进行排序，则优先选择包含的列而不是索引列

这是我过去在我从事的各种数据库项目中所做的事情的通用列表。数据库优化往往高度针对您的情况……这就是 DBA 有工作的原因。如果您的架构已经支持，一些“复杂”的答案可能很简单。

【讨论】：