我们以大约 5000 pr 的速率接收实时 GPS 数据。分钟（来自 4 个 TCP 服务器）。每个服务器使用单个连接来插入数据，并在插入之间缓冲数据。每隔 15 分钟左右，服务就会获取这些数据，并将其处理为行程。一旦生成了行程，实际的 GPS 数据通常就不那么重要了，只有当用户想在地图上查看路线时才会如此。
问题是数据库似乎正在努力跟上插入数据的速度。有时，当负载增加时，插入时间突然急剧增加（> 30 秒），这反过来又允许缓冲更多数据，从而导致更大的插入和更长的插入持续时间。
我希望得到一些关于当前设计的评论，一些我们必须提高性能的想法，以及我们一些问题的答案 - 以及人们可能有的任何其他提示！
当前设计
数据目前被分成代表一周的表格，并且超过一年的数据被存档到辅助数据库中。整个事情在一个可编辑的视图中连接在一起，用于插入和读取。
餐桌设计
指数
目前每周大约占用 10 GB 包括索引，目前主数据库中有大约 300 GB 数据。
主数据库中的数据表有自己的包含 1 个文件的文件组，但它与主数据库中的所有其他表在同一磁盘上。辅助数据库在不同的磁盘上，但在同一台机器上。
我认为我们也每周运行一次索引重建作业，当一个新的表分区（周）被使用时。不执行收缩。
该机器是具有 12 GB 内存的 8 核 HP，保存主数据库的磁盘运行 RAID 10。
想法