Oracle parece tener una reputación de ser más escalable que otros RDBMS. Después de trabajar un poco, puedo decir que es más complejo que otros RDBMS, pero realmente no he visto nada que lo haga más escalable que otros RDBMS. Pero, de nuevo, no he trabajado mucho en profundidad.¿Qué hace que Oracle sea más escalable?
¿Qué características tiene Oracle que son más escalables?
La arquitectura RAC de Oracle es lo que la hace escalable donde puede equilibrar la carga entre los nodos y las consultas paralelas se pueden dividir y enviar a otros nodos para su procesamiento.
Algunos de los trucos, como cargar bloques de la memoria caché de búfer de otro nodo en lugar de ir al disco, hacen que el rendimiento sea mucho más escalable.
Además, la facilidad de mantenimiento de RAC con actualizaciones continuas ayuda a que el funcionamiento de un sistema grande sea más sensato.
También hay un aspecto diferente de escalabilidad: escalabilidad de almacenamiento. ASM hace que aumentar la capacidad de almacenamiento sea muy sencillo. Una solución ASM bien diseñada, debe escalar más allá de los 100s de tamaño de terabyte sin necesidad de hacer nada muy especial.
Si esto hace que Oracle sea más escalable que otros RDBMS, no lo sé. Pero creo que me sentiría menos feliz de intentar escalar una base de datos que no sea de Oracle.
Compartir el cursor es (o fue) una gran ventaja sobre la competencia. Básicamente, el mismo plan de consulta se usa para consultas coincidentes. Una aplicación tendrá un conjunto estándar de consultas emitidas (por ejemplo, obtener los pedidos para esta identificación de cliente). La forma más simple es tratar cada consulta individualmente, de modo que si ve 'SELECCIONAR * DE PEDIDOS DONDE ID_COMPRESOR =: b1', observa si la tabla ORDERS tiene un índice en CUSTOMER_ID etc. Como resultado, puede pasar tanto tiempo buscando trabajo hasta metadatos para obtener un plan de consulta como realmente recuperar los datos. Con simples búsquedas por clave, un plan de consulta es fácil. Las consultas complejas con varias tablas unidas en columnas sesgadas son más difíciles.
Oracle tiene un caché de planes de consulta, y los planes anteriores/menos usados se han agotado ya que se requieren nuevos.
Si no almacena en caché los planes de consulta, existe un límite en lo inteligente que puede hacer su optimizador, ya que mientras más inteligencia codifique, mayor será el impacto que tendrá en cada consulta procesada. Las consultas de caché significa que solo incurre en esa sobrecarga la primera vez que ve la consulta.
El 'inconveniente' es que para que el intercambio de cursor sea efectivo, debe usar variables de vinculación. Algunos programadores no se dan cuenta de eso y escriben código que no se comparte y luego se quejan de que Oracle no es tan rápido como mySQL.
Otra ventaja de Oracle es el registro de UNDO. A medida que se realiza un cambio, la 'versión anterior' de los datos se escribe en un registro de deshacer. Otra base de datos mantiene las versiones anteriores del registro en el mismo lugar que el registro. Esto requiere operaciones de limpieza de estilo VACUUM o te encuentras con problemas de espacio y organización. Esto es más relevante en bases de datos con alta actividad de actualización o eliminación.
También Oracle no tiene un registro de bloqueo central. Un bit de bloqueo se almacena en cada registro de datos individual. SELECT no toma un bloqueo. En las bases de datos donde SELECT se bloquea, puede hacer que varios usuarios lean datos y se bloqueen entre ellos o eviten actualizaciones, introduciendo límites de escalabilidad. Otras bases de datos bloquearían un registro cuando se realizara un SELECCIONAR para garantizar que nadie más pudiera cambiar ese elemento de datos (por lo que sería coherente si la misma consulta o transacción volviera a mirar la tabla).Oracle usa UNDO para su modelo de coherencia de lectura (es decir, busca los datos tal como aparecieron en un momento específico).
La "Arquitectura de base de datos Oracle experta" de Tom Kyte de Apress hace un buen trabajo al describir la arquitectura de Oracle, con algunas comparaciones con otros rDBMS. Vale la pena leer.