Los sistemas de gestión de bases de datos relacionales(RBDMS) que utilizan SQL se han utilizado durante décadas para almacenar información de aplicaciones. El modelo relacional de organización de datos en tablas con una clave de identificación para cada fila, que constituye la columna vertebral de sectores tan importantes como la sanidad y las finanzas, ha demostrado su fiabilidad y eficacia. Las bases de datos SQL modernas, como MySQL y PostgreSQL siguen siendo algunas de las bases de datos más populares en la actualidad. Pero, ¿cuándo no basta con SQL?
El auge de las bases de datos NoSQL(NotOnlySQL) a partir de finales de la década de 2000 coincidió con muchos otros avances. Mientras los procesadores multinúcleo y la virtualización se convertían en algo habitual, la nube despegaba y millones de usuarios de todo el mundo se conectaban a Internet por primera vez con teléfonos inteligentes. Todo necesitaba crecer, y la forma más práctica de lograr esta escala tan necesaria es escalado horizontal. A menudo vemos que SQL frente a NoSQL se simplifica en exceso a "SQL puede escalar verticalmente y NoSQL puede escalar horizontalmente", pero esto es incompleto e incorrecto.
Escala horizontal
Cuando hablamos de escalar horizontalmente, nos referimos a hacer crecer nuestro entorno añadiendo más nodos o máquinas. Mientras que las bases de datos SQL pueden escalar verticalmente con relativa facilidad añadiendo más RAM y capacidad de cálculo a un único nodo, repartir el conjunto de datos entre varios nodos es más complicado. Esto puede hacerse mediante una técnica llamada fragmentación. Cuando se trabaja con grandes conjuntos de datos y un alto rendimiento, la fragmentación ayuda a disminuir la carga en un solo servidor y permite escalar mediante la adición o eliminación de servidores, en función de las necesidades.
MySQL Sharding y limitaciones
Las bases de datos SQL pueden escalarse horizontalmente mediante fragmentación. El método y las características soportadas variarán significativamente entre bases de datos, pero hay que tener en cuenta algunas advertencias. Centrémonos en uno de los ejemplos más comunes: MySQL utilizando el motor de almacenamiento NDB. MySQL soporta clusters NDB que pueden dividir una única tabla grande en múltiples tablas más pequeñas. El proceso de dividir una tabla se denomina particionamiento. Cuando se almacenan en varios servidores, estas tablas más pequeñas constituyen los fragmentos. Cada una de las bases de datos de tu cluster almacena uno de los shards. Juntas, las bases de datos del clúster constituyen el conjunto de datos completo.
El uso de sharding en bases de datos SQL puede ofrecer un escalado muy alto del tamaño del conjunto de datos, pero también puede hacer que la lógica de su aplicación sea más compleja. Es necesario configurar cuidadosamente cómo se particionan los datos en varios fragmentos, ya que esta decisión afecta al rendimiento general de la base de datos. Además de la complejidad y el elevado tiempo necesario, hay que tener en cuenta otros obstáculos técnicos. Para contrarrestar una limitación comúnmente declarada, MySQL puede configurarse para realizar operaciones de unión a través de múltiples shards, pero a costa del rendimiento a escalas mayores. Esto puede hacer que las funciones analíticas resulten poco prácticas en estos entornos.
Entre en NoSQL
Muchos tipos diferentes de bases de datos NoSQL han explotado en uso desde su creación a finales de la década de 2000. Para este ejemplo, vamos a centrarnos en la base de datos NoSQL más popular, MongoDB. MongoDB (derivado de la palabra 'humongous') está orientada a documentos. Los datos se almacenan en documentos similares a objetos JSON y cada documento contiene pares de campos y valores. Esto se opone a las bases de datos SQL que utilizan tablas y filas para dar formato a los datos. Es posible que haya leído que las bases de datos NoSQL como MongoDB suelen ser más adecuadas para el escalado horizontal, pero veamos por qué.
Tenga en cuenta que MongoDB utiliza específicamente un formato llamado BSON, que se deriva de JSON, pero esto variará con cada base de datos.
Esquemas y fragmentos
MongoDB es sin esquema (o sin esquema), lo que significa que no requiere una estructura organizativa definida a nivel de base de datos. En su lugar, el esquema se construye dentro de su código a nivel de aplicación y esto nos da mucha flexibilidad para cambiar la estructura más tarde preservando nuestros datos. Aunque carecen de la consistencia rígidamente impuesta de las bases de datos SQL que cumplen con ACID, MongoDB y otras bases de datos NoSQL sobresalen en disponibilidad y tolerancia a la partición.
Cuando analizamos el escalado horizontal de bases de datos SQL, repasamos el proceso de dividir una tabla en fragmentos. Aunque es posible, conlleva una gran cantidad de limitaciones debido a la estructura rígida incorporada en la base de datos. MongoDB y otras bases de datos NoSQL, por otro lado, están diseñadas para acomodar la fragmentación a nivel estructural. Un fragmento es un subconjunto de datos y MongoDB nos permite escalar horizontalmente desplegando fragmentos como conjuntos de réplicas. Los conjuntos de réplica son agrupaciones de al menos tres nodos con copias redundantes de los mismos datos. Proporcionan disponibilidad y redundancia cuando se distribuyen en grandes entornos y no están limitados por un esquema predeterminado.
A partir de aquí, podemos ver inmediatamente las concesiones que hacen las bases de datos NoSQL para ser escalables. Las bases de datos NoSQL suelen utilizar bastante más almacenamiento que las bases de datos SQL debido a la cantidad de datos redundantes necesarios para lograr la disponibilidad en grandes despliegues horizontales. Las velocidades de escritura de las bases de datos NoSQL suelen superar a las de las bases de datos SQL, pero las consultas son más lentas. Al carecer de una estructura definida, las bases de datos NoSQL no son intrínsecamente compatibles con ACID, lo que las hace menos prácticas para aplicaciones que manejan grandes volúmenes de transacciones financieras. Como alternativa, podemos configurar clústeres NoSQL distribuidos masivos que mantienen el rendimiento, lo que los convierte en candidatos ideales para Big Data y análisis.
Entonces, ¿cuándo no basta con SQL? Como cabría esperar, la respuesta no es sencilla, pero existen algunas directrices generales que podemos tener en cuenta a la hora de diseñar nuestras aplicaciones. ¿Qué debe hacer nuestra aplicación y qué tamaño debe tener? A partir de ahí, podemos decidir nuestra prioridad número uno. Decir que "SQL escala verticalmente y NoSQL horizontalmente" no es cierto, pero podemos decir que "la mayoría de las bases de datos SQL se diseñaron pensando en la consistencia, mientras que la mayoría de las bases de datos NoSQL se diseñaron para adaptarse al escalado".
Siempre habrá contrapuntos a esa directriz general. MySQL se puede escalar horizontalmente, y MongoDB ha empezado a soportar transacciones ACID multidocumento. Cuanto más entendamos cómo están diseñadas estas bases de datos, más sabremos elegir la mejor herramienta para el trabajo.
Implantación de bases de datos en Linode
Obtenga más información sobre Linode Managed Databases o regístrese para recibir actualizaciones sobre su motor de base de datos preferido. También puede implementar sistemas gestionados de bases de datos como MongoDB desde Linode Marketplace o seguir nuestras guías para instalar una base de datos en una variedad de distribuciones de Linux, como Instalar MongoDB en CentOS 7.
Comentarios