La escalabilidad de una base de datos es la capacidad de una base de datos de manejar demandas cambiantes agregando o quitando recursos. Las bases de datos utilizan una serie de técnicas para hacer frente a las demandas. [1] Según Marc Brooker: "un sistema es escalable en el rango en el que el costo marginal de la carga de trabajo adicional es casi constante". Las tecnologías sin servidor se ajustan a esta definición, pero es necesario considerar el costo total de propiedad, no solo el costo de la infraestructura. [2]
La historia inicial de la escalabilidad de las bases de datos fue la de proporcionar servicio en computadoras cada vez más pequeñas. Los primeros sistemas de gestión de bases de datos, como IMS, se ejecutaban en computadoras mainframe . La segunda generación, que incluía Ingres , Informix , Sybase , RDB y Oracle, surgió en minicomputadoras . La tercera generación, que incluía dBase y Oracle (de nuevo), se ejecutaba en computadoras personales. [3]
Durante el mismo período, la atención se centró en gestionar más datos y cargas de trabajo más exigentes. Una innovación clave en el software a finales de los años 1980 fue reducir la granularidad del bloqueo de actualizaciones de tablas y bloques de disco a filas individuales. Esto eliminó un cuello de botella crítico en la escalabilidad, ya que los bloqueos más gruesos podían retrasar el acceso a las filas aunque no estuvieran directamente involucradas en una transacción. Los sistemas anteriores eran completamente insensibles al aumento de recursos. [4]
Una vez que se abordaron las limitaciones del software, la atención se centró en el hardware. La innovación se produjo en muchas áreas. La primera fue la compatibilidad con computadoras multiprocesador . Esto implicaba permitir que varios procesadores manejaran solicitudes de bases de datos simultáneamente, sin bloquearse entre sí. Esto evolucionó hacia la compatibilidad con procesadores multinúcleo .
Un cambio mucho más significativo implicó permitir que las transacciones distribuidas afecten a los datos almacenados en computadoras separadas, utilizando el protocolo de confirmación de dos fases , estableciendo la arquitectura de nada compartido . [5]
Más tarde aún, Oracle introdujo la arquitectura de todo compartido , que proporcionaba funcionalidad completa en clústeres de múltiples servidores. [6]
Otra innovación fue almacenar copias de tablas en múltiples computadoras ( replicación de base de datos ), lo que mejoró la disponibilidad (el procesamiento podía continuar en una copia incluso si el sistema principal no estaba disponible) y la escalabilidad, particularmente para consultas/análisis, ya que las solicitudes podían enrutarse a la copia si el sistema principal alcanzaba su capacidad. [7]
A principios del siglo XXI, los sistemas NoSQL ganaron popularidad frente a las bases de datos relacionales para algunas cargas de trabajo. Las motivaciones incluían una escalabilidad aún mayor y compatibilidad con documentos y otros tipos de datos "no relacionales". A menudo se sacrificaban los estrictos protocolos de consistencia ACID que garantizaban una consistencia perfecta en todo momento en favor de una consistencia final que aseguraba que todos los nodos eventualmente devolverían los datos más recientes. Algunos incluso permitían que ocasionalmente se perdieran transacciones, siempre que el sistema pudiera manejar suficientes solicitudes. [8] El sistema inicial más destacado fue BigTable / MapReduce de Google , desarrollado en 2004. Logró una escalabilidad casi lineal en múltiples granjas de servidores , a costa de características como transacciones de múltiples filas y uniones. [9]
En 2007 se desarrolló el primer sistema NewSQL , H-Store . Los sistemas NewSQL intentan combinar la escalabilidad de NoSQL con transacciones ACID e interfaces SQL. [10]
La escalabilidad de las bases de datos tiene tres dimensiones básicas: cantidad de datos, volumen de solicitudes y tamaño de las solicitudes. Las solicitudes vienen en muchos tamaños: las transacciones generalmente afectan pequeñas cantidades de datos, pero pueden acercarse a miles por segundo; las consultas analíticas son generalmente menos, pero pueden acceder a más datos. Un concepto relacionado es la elasticidad , la capacidad de un sistema de agregar y quitar capacidad de manera transparente para satisfacer cargas de trabajo cambiantes. [11]
El escalamiento vertical de la base de datos implica que el sistema de base de datos puede aprovechar al máximo los sistemas configurados al máximo, incluidos los multiprocesadores con memorias grandes y una gran capacidad de almacenamiento. Estos sistemas son relativamente fáciles de administrar, pero pueden ofrecer una disponibilidad reducida. Sin embargo, cada computadora individual tiene una configuración máxima. Si las cargas de trabajo se expanden más allá de ese límite, las opciones son migrar a un sistema diferente, aún más grande, o rediseñar el sistema para lograr una escalabilidad horizontal. [11]
El escalamiento horizontal de bases de datos implica agregar más servidores para trabajar en una sola carga de trabajo. La mayoría de los sistemas escalables horizontalmente conllevan compromisos de funcionalidad. Si una aplicación requiere más funcionalidad, la migración a un sistema escalable verticalmente puede ser preferible. [11]
Las bases de datos se ejecutan en hardware individual que varía en capacidad desde relojes inteligentes hasta supercomputadoras y múltiples granjas de servidores reconfigurables de forma transparente. [3] Las bases de datos también se escalan verticalmente para ejecutarse en microprocesadores de 64 bits , CPU de múltiples núcleos y multiprocesadores SMP grandes , utilizando implementaciones de múltiples subprocesos .
Para aprovechar al máximo una configuración de hardware se requieren diversas técnicas de bloqueo, que van desde el bloqueo de una base de datos completa hasta el de tablas enteras, bloques de discos o filas de tablas individuales. La granularidad de bloqueo adecuada depende de la carga de trabajo. Cuanto más pequeño sea el objeto que se bloquea, menos posibilidades hay de que las solicitudes de la base de datos se bloqueen entre sí mientras el hardware está inactivo. Normalmente, los bloqueos de filas son necesarios para soportar aplicaciones de procesamiento de transacciones de gran volumen a costa de la sobrecarga de procesamiento para gestionar la mayor cantidad de bloqueos. [4]
Además, algunos sistemas garantizan que una consulta obtenga una vista coherente en el tiempo de la base de datos al bloquear los datos que está examinando una consulta para evitar que una actualización los modifique, lo que retrasaría el trabajo. Alternativamente, algunas bases de datos utilizan la coherencia de lectura de múltiples versiones para evitar (bloquear) los bloqueos de lectura y, al mismo tiempo, proporcionar resultados de consulta coherentes. [12]
Otro posible cuello de botella puede ocurrir en algunos sistemas cuando muchas solicitudes intentan acceder a los mismos datos al mismo tiempo. Por ejemplo, en los sistemas OLTP, muchas transacciones pueden intentar insertar datos en la misma tabla al mismo tiempo. En un sistema de no uso compartido, en un momento dado, todas esas inserciones son procesadas por el único servidor que administra esa partición ( shard ) de la tabla, posiblemente abrumando a la misma, mientras que el resto del sistema tiene poco que hacer. Muchas de esas tablas usan un número de secuencia como su clave principal que aumenta para cada nueva fila insertada. El índice para esa clave también puede experimentar contención (sobrecalentamiento) mientras procesa esas inserciones. Una solución para esto es invertir los dígitos de la clave principal . Esto distribuye las inserciones tanto en la tabla como en la clave en múltiples partes de la base de datos. [13]
Una técnica básica consiste en dividir tablas grandes en varias particiones en función de los rangos de valores de un campo clave. Por ejemplo, los datos de cada año podrían almacenarse en una unidad de disco independiente o en una computadora separada. La creación de particiones elimina los límites en el tamaño de una sola tabla.
Las bases de datos replicadas mantienen copias de tablas o bases de datos en varias computadoras. Esta técnica de escalamiento es particularmente conveniente para datos que rara vez se actualizan o que nunca se actualizan, como el historial de transacciones o las tablas de impuestos. [7]
Se utilizan diversos enfoques para escalar más allá de los límites de una sola computadora. NonStop SQL de HP Enterprise utiliza la arquitectura de no compartir nada , en la que ni los datos ni la memoria se comparten entre los límites del servidor. Un coordinador dirige las solicitudes de la base de datos al servidor correcto. Esta arquitectura proporciona una escalabilidad casi lineal.
El estándar X/Open XA, ampliamente compatible , emplea un monitor de transacciones global para coordinar transacciones distribuidas entre recursos de transacciones semiautónomos compatibles con XA.
Oracle RAC utiliza un modelo diferente para lograr la escalabilidad, basado en una arquitectura de "todo compartido". Este enfoque incorpora el enfoque de disco compartido que permite que varias computadoras accedan a cualquier disco en el clúster. El almacenamiento conectado a la red (NAS) y las redes de área de almacenamiento (SAN) acopladas con redes de área local y tecnología de canal de fibra permiten tales configuraciones. El enfoque incluye un caché lógico "compartido" en el que los datos que se han almacenado en caché en la memoria del servidor se ponen a disposición de otros servidores sin necesidad de que vuelvan a leer los datos del disco. Cada página se mueve de un servidor a otro para satisfacer las solicitudes. Las actualizaciones generalmente se realizan muy rápidamente, de modo que una página "popular" puede actualizarse mediante múltiples transacciones con poca demora. Se afirma que este enfoque admite clústeres que contienen hasta 100 servidores. [14]
Algunos investigadores cuestionan las limitaciones inherentes de los sistemas de gestión de bases de datos relacionales . GigaSpaces , por ejemplo, sostiene que se requiere una arquitectura basada en el espacio para lograr rendimiento y escalabilidad. Base One defiende la escalabilidad extrema dentro de la tecnología de bases de datos relacionales convencional. [15]
{{cite journal}}: Requiere citar revista |journal=( ayuda )