我正在开发一个应用程序，每天捕获大量（1000 万以上）非常小的数据块（16 字节）。数据不是连续的（即有很多等待写入的数据），也不是恒定的流（有安静的一段时间）。
应用程序前面有缓存服务器，因此读取不是问题，我预计在某一天只有 1% 的数据会引起关注，并且这 1% 的数据将保留在缓存中。只有第一次读取会比较慢。
我的预算不错但有限，我想要 RAID 1，这使我的磁盘成本翻倍。
我的选择是：
- RAID 1 中的快速 SAS 磁盘 - 昂贵，存储空间不大但速度快。
- 控制器上的大型近线磁盘 RAID 1 + 1gb NVCache（PERC H700）
你会怎么做？或者换句话说，控制器上的大缓存是否可以在写入方面弥补较慢的寻道时间？
我们是一家戴尔商店，我正在看 R410/R510。
答案1
我不确定你在这里会得到有用的答案。我会对应用程序和预期硬件进行基准测试，以了解它的性能，因为我怀疑它有足够多的复杂性，以至于试图“粗略地”建模可能过于简单。
通常，控制器上的缓存可以缓冲写入，并允许 RAID 卷更快地响应操作系统。如果写入速率超过缓存可以提交到磁盘并持续足够长的时间以填充缓存的速度，则控制器将开始阻止写入（回落到物理磁盘的速度）。
听起来您没有使用现成的数据库管理系统，而是自己管理数据存储。您必须评估应用程序如何与操作系统缓存管理器和底层文件系统（假设您没有将数据存储在原始磁盘块上）以及 RAID 控制器交互。如果您正在使用数据库管理系统，那么显然，您也必须了解它是如何交互的。
当您说“正在开发”时，我想知道您是否参与了应用程序的开发。如果是这样，我认为值得研究一种应用程序架构，该架构将传入的写入缓冲到顺序写入的日志中，然后将该顺序日志延迟写入随机访问存储结构。实际上，您将完成与控制器缓存写入相同的操作，但您可以更精细地控制该过程（您可以明确地为顺序和随机访问日志分层存储）。
答案2
或者换句话说，从写入角度来说，控制器上的大缓存是否可以弥补较慢的寻道时间？
在一定程度上。需要考虑以下因素：
- 缓存只有在不超载的情况下才会发挥预期的效果 - 如果您的数据以突发或持续的速度涌入，而磁盘无法应对负载，则缓存将被填满，最坏的情况是 I/O 阻塞，直到缓存刷新到低水位才能进行进一步操作
- 缓存算法通常确保缓存中的数据不会早于“X”，即使还有空间容纳更多数据，也会启动刷新
- 缓存以“块”为单位进行，因此即使您的记录只有 16 字节大小，也不意味着您可以在 1 GB 的缓存 RAM 中存储 6700 万条记录
- 即使对于较大的缓存，混合随机读/写负载也很困难
- 即使使用大型缓存，您也可能会遇到命令队列填满的情况，因此如果您的存储要求不仅包括 IOPS 和带宽要求，还包括低延迟（低服务时间），那么使用给定的设置选项很难实现
一些估算：假设近线 SATA 磁盘单个请求的典型服务时间为 20 毫秒，I/O 子系统需要 200,000 秒才能将 10,000,000 写入磁盘 - 这就是磁盘利用率达到 100% 的时间超过 55 小时。如果您每天收到如此大量的写入请求，则您的 I/O 子系统可能会超负荷运行。
一个或另一个边界条件对您造成的影响有多大，很大程度上取决于控制器及其缓存机制的实现。您需要进行彻底的测试，以免出现不愉快的意外。
答案3
如果 RAID 缓存是一个限制因素（前面的一个答案表明它可能是），我会考虑在前面的缓存中添加一些智能，将写入条带化到单独的阵列上 - 比如说，4 个镜像，每个镜像有 2 个磁盘 - 并对目标进行散列，以便均匀分散负载。
这本身不会提高缓存的使用率，但它将为您提供 4 组独立的主轴以供写入，从而避免因必须一次写入所有主轴而产生的大部分延迟。
正如第一位响应者所说，您需要测试哪种方法最有效。
答案4
您是否考虑过使用 512 或 1GB 缓存的 H700，然后使用一个或两个 SSD 作为驱动器的额外缓存。戴尔称之为 Cachecade 技术。
看这里： http://www.dell.com/downloads/global/products/pedge/en/perc-h700-cachecade.pdf