我正在devise一个数据仓库的解决scheme，我是一个新手在磁盘configuration问题，让我解释一下。
我们的存储分布在6个存储设备上，每个存储设备有5个raid-1磁盘arrays，每个磁盘arrays有2个LUN，总计48个LUN（这是微软对数据仓库架构的快速通道build议）。
我想分割我的数据，在我以前工作过的其他项目中，我们总是遵循1个分区 – 1个文件组规则。 在微软的快速轨道推荐build议创build一个文件组，然后为该文件组每个月的数据文件…但我假装有一个星期级别分区…如果我应用该规则，我认为我会得到太多的文件和复杂的布局。
我正在考虑只创build一个文件组（使用48个lun数据文件），但是仍然要创build分区，因为我想保留分区切换等分区的好处…这种情况不推荐使用吗？ 你会build议什么？
回答这个问题需要潜入存储极客。 我提前道歉。
微软似乎build议48个独立分区的原因是一个原因：最大化I / O的in-OS并行化。 通过拥有48个LUN，操作系统必须保留48个独立的I / O队列，理论上这些队列可以并行服务。 如果一个LUN特别慢（它正在执行繁重的随机写入），则不会阻止访问其他LUN。
在现代硬件上，这是一个很大的存储头痛的百分比收益。 除非你知道你会将你的数据仓库压到绝对的上限，否则不值得。 现代RAID卡速度足够快，可以为您处理这个问题。 有4个LUN可以产生收益。 48可能实际上受伤了。
现在的存储通常以每秒I / O操作（I / O Ops）的性能指标为特征。 每个驱动器都有自己的随机I / O的上限（根据RPM和其他一些事情，每个驱动器的范围在90-180之间）。 当你一起驱动，比如在一个RAID10集合中，这个I / O Ops计数是相加的 。 12个磁盘的RAID10集合将具有与6个Raid1对相同的I / O Ops容量，并且不会强制您创build6个独立的DB文件。 通过创build一个大的RAID10集，您可以创build一个可处理大量负载的大型DB文件。
回过头来看，我在第二段中提到的一个缓慢的LUN不能阻止对其他LUN的访问，这就是为什么最大化LUN的I / O操作的原因。 如果它有足够的I / O操作系统开销，则根本不可能阻止它。 通过创build一个大的RAID10arrays，并行化被推到RAID卡上，而不是操作系统，这使操作系统免费做其他事情。 您仍然可以获得并行化优势，并利用专用硬件。
对于数据库服务器，在不同的主轴上保存数据文件和日志文件I / O是明智的。 确切的比例， 我将留给SQL Server专家 （我不是一个），并可能基于您的确切configuration和使用模式。 因为这是一个数据仓库，所以您需要大量的日志空间来处理批量加载。 日志I / O是非常连续的，其中数据I / O是非常随机的，所以通过将日志放在不同于数据文件的不同主轴上可以发现最大的日志logging性能。
就你而言，你可能能够摆脱2个LUN。 为您的数据文件设置一个大的RAID10，为您的日志文件设置较小的RAID10。