> Write-back caching at the controller level can reduce write latencies. This is especially true with RAID 5/50/6/60 as RAID parity calculations introduce additional latency.
>Also, write-back caching helps with merging smaller sequential write transfers into larger write transfers. Size of the resulting larger transfers equals the write-back cache element size, which typically equals stripe unit size. Merging write transfers is important when there are concurrent sequential write threads with small transfer sizes (for example, database transaction logs).
That is, it cites what appear to be exactly my earlier points regarding full stripe writes.
> I guess if you want or need to squeeze out the max performance on RAID5
Since the whole premise of the article is performance, max performance is the goal.
> test your own system
That still, however, does not address my original question, which is about the general advice that RAID5 performs poorly for databases.
My suspicion remains that this accepted wisdom is outdated (i.e. rendered irrelevant my modern technology).
Indeed, though I suspect, in the context of a storage fabric "behind" a RAID card, it will just be a costly bandwidth increase.
>I've found some benchmarks for SATA-SSDs
Unfortunately, that's not a very useful one, as it uses a small number of low-performance (by today's standards) SSDs.
Also, if Google Translate correctly translate the below text to English, the author turned off caching:
>der Controller Cache auf Write-Through gestellt.
Oddly, the author references https://www.intel.com/content/dam/www/public/us/en/documents... as a reason for doing so, except that document supports using caching:
> Write-back caching at the controller level can reduce write latencies. This is especially true with RAID 5/50/6/60 as RAID parity calculations introduce additional latency. >Also, write-back caching helps with merging smaller sequential write transfers into larger write transfers. Size of the resulting larger transfers equals the write-back cache element size, which typically equals stripe unit size. Merging write transfers is important when there are concurrent sequential write threads with small transfer sizes (for example, database transaction logs).
That is, it cites what appear to be exactly my earlier points regarding full stripe writes.
> I guess if you want or need to squeeze out the max performance on RAID5
Since the whole premise of the article is performance, max performance is the goal.
> test your own system
That still, however, does not address my original question, which is about the general advice that RAID5 performs poorly for databases.
My suspicion remains that this accepted wisdom is outdated (i.e. rendered irrelevant my modern technology).