Odeio ser sarcástico, mas os DBAs são ... DBAs.
Eles são infinitamente mais inteligentes do que o administrador do servidor quando se trata de construir uma consulta complexa que não faz uma varredura de tabela bazillion, mas o administrador de hardware / servidor é infinitamente mais inteligente da mesma forma ao alocar recursos apropriados (supondo que ele tenha um cabelo grisalho ou quatro). :)
Minha resposta curta: É tudo sobre os fusos, e é tudo sobre fusos e, a partir dos últimos anos, a escolha do sistema de arquivos e a quantidade de memória RAM que esse sistema de arquivos pode absorver.
Eu tive um sucesso incrível segregando dbdata / logs / transacional entre (a) diferentes controladores físicos, (b) usando parâmetros de sistema de arquivos (especificamente, e este é um grande problema, combinando com os parâmetros do seu db escreve / lê / comete para o mesmo setor de tamanho / bloco que o fs foi construído sob) e (c) "Escolhendo meu veneno".
Dados não críticos, registros, reversão de dados e tais podem mais ou menos entrar em sistemas de arquivos "vulneráveis" (memfs, fast-io-fs sem registro no diário / preflight / precommit cache) enquanto arquivos de dados reais (dependendo do tipo de db) são bem espalhados em coisas tão baratas quanto um zpool bem construído.
O pôster anterior está absolutamente certo em que os logs trans são sequenciais, e podem / devem ir em volumes feitos para gravação rápida, não leitura (e sem dúvida não necessariamente "estabilidade"), como uma grande faixa. O respondente ("aqui está o atrito") também está na direita: Contenção de disco é desagradável se os dados não estiverem em memória RAM ou em cache de disco, e sem grave (pronunciado "longo, monótono, tedioso e propenso a adivinhar erro" ), você deve absolutamente evitar misturar discos com bancos de dados que funcionam de maneira diferente. (por exemplo, High trans read e low trans bigdata write - totalmente qualquer estratégia de cache do fubar).
Meu conselho "ISO Camada 8" é o seguinte: Aproxime-se do DBA e diga, hey, não vou dizer que você está errado e, em troca, você não vai me dizer como arquitetar meus sistemas: )
Eles frequentemente seguem recomendações padronizadas que, no longo prazo, raramente são ótimas. Não porque eles não saibam o que estão fazendo - mas porque estão depositando confiança em um documento intermediário empurrado pelo vendedor como "projetado para incomodar o menor número de clientes", resultando em menos ajuda chamadas ".
Se você quiser me enviar uma mensagem direta, fique à vontade; Mas tenha em mente - não há configuração ideal global. O número de linhas, as varreduras previstas, a cardinalidade e a eficiência de suas chaves / índices, consultas / s, tabelas completas por intervalo etc. É um jogo difícil de jogar.
Me lembra de WARGAMES ..
Would you like to play a game?
Sim. Vamos jogar a guerra termonuclear global.
..
How about a nice game of Database Architecture?
[Estratégia global de guerra termonuclear teria sido mais fácil ..]
:)