Siempre ha sido mi firme convicción de que un DBMS multiusuario a gran escala debe residir, de forma independiente, en un servidor o clústeres dedicados, sin otras aplicaciones, procesos o servicios innecesarios que puedan robar recursos del DBMS. También creo que el DBMS debería estar estrechamente integrado en un sistema operativo que haya sido diseñado para proporcionar al DBMS el máximo rendimiento posible. Con este objetivo se diseñaron sistemas propietarios como Pick, Terradata y otros. ¿El último sistema Sun/Oracle entraría en esta categoría? ¿Tendría sentido lograr este tipo de arquitectura con otros DBMS como INFORMIX?
Respuesta1
En general, existen ciertos atributos del ACID RDBMS que se combinan para producir características de rendimiento en tiempo polinomial cuando se juntan dos o más computadoras para servir una base de datos.
Hay varios intentos de resolver este problema:
Optimice la base de datos tanto como sea posible reduciendo la transaccionalidad, reduciendo las uniones, etc.
Optimice una computadora tanto como sea posible para servir a la base de datos, como optimizar el sistema operativo de soporte, optimizar los discos, etc.
Escalar verticalmente sirviendo la base de datos con una única computadora extraordinariamente poderosa.
Distribuir el RDBMS fragmentando o colocando diferentes tablas en diferentes bases de datos.
El uso de una base de datos verdaderamente distribuida elimina algunos de los atributos de un RDBMS ACID, pero ofrece una distribución real y el rendimiento correspondiente. Por ejemplo, Cassandra y otros. Y las bases de datos verdaderamente distribuidas pueden ejecutarse en hardware básico porque el rendimiento de una base de datos distribuida se basa principalmente en el número de nodos que hay, más que en el rendimiento de un nodo determinado.
Existen límites estrictos para los primeros cuatro métodos. No hay límites para el quinto.
Dado que las necesidades de las bases de datos se expanden muchas veces más rápido de lo que los ajustes y el hardware pueden seguir, la solución inevitable será una base de datos distribuida. Claro, muchas personas intentarán modificar sus servidores de bases de datos y luego se verán obligadas a actualizar a un hardware masivo, pero eso es sólo un recurso provisional, y cuando eso deje de ser suficiente, se verán obligados a cambiar a una base de datos distribuida.
Respuesta2
Si tiene algún cuarto de millón de dólares para gastar, puede considerar comprar una porción deuna máquina Oracle Exadata. Se trata de un dispositivo de base de datos altamente configurado con hardware altamente especificado elegido y Solaris ajustado hasta que chirría para optimizar el rendimiento de Oracle.
Respuesta3
La integración entre Oracle y Solaris es más estrecha que la mayoría. Sin embargo, no puedo confirmar que cumpla con su lista de requisitos.
Respuesta4
Supongo que quieres discusión en lugar de respuestas... pero mi respuesta es "No" de todos modos.
En una gran empresa corporativa, cada instalación de Oracle, Sybase y SQL Server puede utilizar el mínimo común denominador: SAN. Esto a su vez puede replicarse transaccionalmente fuera del sitio. Pregunte a cualquier DBA corporativo.
En cualquier tienda, la calidad del código será un factor más importante que el servidor/SO. Ninguna optimización e integración le salvará de una indexación deficiente, por ejemplo.
Otros puntos:
- Una base de datos de terabyte es más bien un problema de copia de seguridad/restauración/SLA en mi humilde opinión
- El conjunto activo de datos o el aumento diario es de lo que debe preocuparse, en cuanto al rendimiento.