Sempre tive a forte convicção de que um SGBD multiusuário em grande escala deveria residir, de forma independente, em um servidor ou clusters dedicados, sem outros aplicativos, processos ou serviços desnecessários que pudessem roubar recursos do SGBD. Eu também acredito que o SGBD deve ser totalmente integrado a um sistema operacional que foi adaptado para fornecer ao SGBD o máximo desempenho possível! Sistemas proprietários como Pick, Terradata e outros foram projetados com esse objetivo. O sistema Sun/Oracle mais recente se enquadraria nesta categoria? Faria sentido realizar esse tipo de arquitetura com outros SGBDs como o INFORMIX?
Responder1
Em geral, existem certos atributos do RDBMS ACID que se combinam para produzir características de desempenho em tempo polinomial quando você coloca dois ou mais computadores juntos para servir um banco de dados.
Existem várias tentativas para resolver este problema:
Otimize o banco de dados tanto quanto possível, reduzindo a transacionalidade, reduzindo junções, etc.
Otimize um computador tanto quanto possível para servir o banco de dados - como otimizar o sistema operacional de suporte, otimizar os discos, etc.
Dimensione verticalmente servindo o banco de dados com um único computador extraordinariamente poderoso.
Distribuir o RDBMS por fragmentação ou colocação de tabelas diferentes em bancos de dados diferentes.
Usando um banco de dados verdadeiramente distribuído, que elimina alguns dos atributos de um RDBMS ACID, mas oferece distribuição verdadeira e seu desempenho correspondente. Por exemplo, Cassandra e outros. E bancos de dados verdadeiramente distribuídos podem ser executados em hardware comum porque o desempenho de um banco de dados distribuído se baseia principalmente em quantos nós existem, e não no desempenho de qualquer nó específico.
Existem limites rígidos para os primeiros quatro métodos. Não há limites para o quinto.
Como as necessidades de banco de dados se expandem muito mais rapidamente do que os ajustes e o hardware conseguem acompanhar, a solução inevitável será um banco de dados distribuído. Claro, muitas pessoas tentarão ajustar seus servidores de banco de dados e então serão forçadas a atualizar para um hardware massivo, mas isso é apenas uma solução provisória e, quando isso deixar de ser suficiente, elas serão forçadas a mudar para um banco de dados distribuído.
Responder2
Se você tiver um quarto de milhão de dólares para gastar, pode considerar comprar uma fatia deuma máquina Oracle Exadata. Este é um dispositivo de banco de dados altamente configurado com hardware altamente especificado escolhido e Solaris ajustado até que ele consiga otimizar o desempenho do Oracle.
Responder3
A integração entre Oracle e Solaris é mais estreita do que a maioria. Não posso confirmar se ele atende à sua lista de requisitos.
Responder4
Presumo que você queira discussão em vez de respostas... mas minha resposta é "Não" de qualquer maneira
Em uma grande loja corporativa, cada instalação do Oracle, Sybase e SQL Server pode usar o menor denominador comum: a SAN. Isso pode ser replicado transacionalmente fora do local. Pergunte a qualquer DBA corporativo.
Em qualquer loja, a qualidade do código será um fator maior que o servidor/SO. Nenhuma quantidade de otimização e integração irá salvá-lo de uma indexação deficiente, por exemplo.
Outros pontos:
- Um banco de dados de terabyte é mais um problema de backup/restauração/SLA IMHO
- O conjunto ativo de dados ou aumento diário é o que você deve se preocupar, em termos de desempenho