Lia*_*iam 5 database architecture sql-server performance
我们正在新架构上设计现有产品的新版本.它是一个内部Web应用程序,可能有100个并发用户(最大)这将在SQL Server 2008数据库上运行.
最近的讨论项目是我们是否应该有一个单独的数据库,以便在两个不同的数据库中出于性能原因拆分数据库.
数据库可以在5年内从50-100GB增长到任何地方.
我们是开发人员而不是DBA,因此获得一些一般指导会很好.
[我知道答案并不简单,因为它取决于架构,存档策略,数据量等]
选项1单个主数据库 [这是我的首选选项].
计划是将所有表都放在一个数据库中,并且如果需要跨多个磁盘,可能使用文件组和分区来分隔数据.[如果合适,使用架构].这应该处理性能问题其中一个评论是,单个服务器实例仍然会处理这些数据,因此仍然会有一个处理瓶颈.
对于报告,我们可以有一个单独的报告数据库,但仍在讨论中.
选项2将数据库拆分为2个单独的数据库
DB1 - 客户,客户,客户资源等
DB2 - 这将包含大量数据[即车辆跟踪数据,金融交易表等].
这些表通常包含大量数据.[如果需要,它可以驻留在单独的服务器上]
该计划将涉及将主数据保存在较小的数据库[DB1]中,并将[主要]只读事务类型数据保留在单独的DB [DB2]中.UI主要从DB1读取,因此响应更快.[我知道这个选项会使参考完整性更难实施.]
需要考虑的因素由于我们处于设计阶段,我们至少可以正确使用索引来处理性能问题,这就是为什么选项1对我有吸引力而且更多的是标准方法.对于这两个选项,我们正在考虑实施归档数据库.
为长期问题道歉.总之,问题是1 DB还是2？
提前致谢,
利亚姆
在我看来,选项1是要走的路.
CPU不太可能成为您提供工作负载的100个并发用户的瓶颈.您可以通过热插拔技术获得具有额外CPU容量的单个多插槽服务器,以便根据需要提供增长空间.根据您的可用性要求,您还可以考虑使用群集解决方案,以允许通过强制故障转移到另一个节点来交换更多处理CPU资源.
磁盘子系统的性能将是您最关心的问题.您的设计决策将受到您使用的存储解决方案的影响,我认为这将是SAN技术.
您至少需要将LOG(RAID 1)和DATA文件(RAID 10或5取决于工作负载)放在不同的LUN上.
根据您的表访问,您可能希望考虑将不同的文件组放在单独的LUN上.对表数据进行分区可能对您有利,但仅适用于大型表.