SQL vs NoSQL - ¿Cuál debería usar para su próximo proyecto?

Una de las preguntas más frecuentes: ¿qué base de datos debo usar?

SQL son las siglas de Structured Query Language. Fue desarrollado por primera vez en la década de 1970 por un equipo de investigadores de IBM, las bases de datos NoSQL, por otro lado, fueron utilizadas por primera vez en 1998 por Carlo Strozzi.

La diferencia más común entre estos dos sistemas de bases de datos (DB) es que SQL es relacional y NoSQL no lo es.

Profundicemos en estas dos bases de datos para informar mejor su decisión la próxima vez que esté considerando una base de datos para su proyecto.

Estructura de la base de datos

Hablemos de estructurar.

SQL

SQL La base de datos tiene una estructura de esquema definida.

Un esquema contiene tablas y cada tabla contiene un número definido de columnas. Eso significa que un usuario no puede actualizar la tabla más allá del número de columnas especificado en la tabla. Esto es especialmente útil cuando necesita mantener la integridad de los datos y también para asegurarse del tipo de datos que se guardan en su base de datos.

Cada tabla de una base de datos SQL puede estar relacionada. es decir, puede tener relaciones entre tablas. Estas relaciones pueden ser de uno a muchos, de muchos a muchos o de uno a uno. El tipo de relación que implemente depende de lo que necesite.

Por ejemplo, consideremos la situación hipotética; tenemos una empresa con usuarios y los usuarios pueden realizar pedidos de productos. Entonces, podríamos decidir que los usuarios pueden crear múltiples pedidos, pero cada pedido solo puede ser creado por un usuario. Esta sería una relación entre varias, es decir, un usuario para muchas órdenes. Por lo tanto, la estructura de la tabla para ambas tablas se verá similar a la siguiente.

En nuestra base de datos podríamos tener una tabla de usuarios, estructurada como se muestra a continuación,

users_table
----------------------------------------------------
id          |          name       |           email
-----------------------------------------------------
1                    Idris              idris@idrislawal.com

Además, podríamos tener una tabla de pedidos.

orders_table
---------------------------------------------------------------------------------
id                   |             user_id             |             order_number
---------------------------------------------------------------------------------
1                                      1                               20000001

El user_id en la tabla de pedidos, facilita la asignación de cada pedido en la tabla de pedidos al usuario al que pertenece. En el caso de una relación uno a uno, podríamos tener la order_id también en el users_table si decidimos obtener el usuario por su ID de pedido relacionado.

Para situaciones de muchos a muchos, generalmente se trata de una tabla adicional, llamada tabla dinámica. Esto permite mapear varios registros entre sí. Usando la instancia anterior. Tendríamos

users_table
-------------------------------------------------------------------------------------
id               |                    name                   |                  email
-------------------------------------------------------------------------------------
1                               Idris                             idris@idrislawal.com

y la tabla de pedidos será

orders_table
---------------------------------------------------------
id                      |                    order_number
---------------------------------------------------------
1                                             2000001

y luego la tabla dinámica contendrá ambos ID como claves externas.

users_orders_table
------------------------------------------------------------------------------
id               |                  order_id              |           user_id
------------------------------------------------------------------------------
1                                     1                                 1

Con base en esta estructura proporcionada por SQL, puede escribir cómodamente uniones entre tablas que proporcionarán datos de diferentes tablas unidas en una consulta.

NoSQL

NoSQL Las bases de datos se crearon para ser más flexibles que las bases de datos SQL, y también para contener mayores cantidades de datos.

En las bases de datos NoSQL, no hay esquemas ni tablas predefinidos. Hay colecciones, y en cada colección hay documentos. Esto le permite guardar datos en diferentes formas a medida que vienen. Puede optar por tener varios documentos diferentes con diferentes campos en una colección. También es posible forjar manualmente relaciones entre Colecciones. Sin embargo, no son adecuados para tal fin. En su lugar, puede guardar todo lo necesario para una sola consulta en la misma colección.

Si es una persona de SQL, puede pensar en las colecciones como tablas y los documentos como filas con las tablas. Sin embargo, no existen restricciones en las columnas de datos que puede agregar con la tabla.

Volviendo a nuestra instancia hipotética definida anteriormente de una empresa con usuarios y pedidos.

Una colección de usuarios podría definirse como,

{id: 1, name: 'idris', email: 'idris@idrislawal.com'}

Y la colección de pedidos podría definirse como,

{id: 1, order_number: 2000001, user_id:1}

Sin embargo, en este caso, queremos evitar tener que unir manualmente ambas Colecciones (lo que no deberíamos, en este caso). Podemos guardar las entradas en la colección que se lea más. He decidido (para este ejemplo) que será la colección de Pedidos.

{id:1, order_number:200001, user{id:1, name: 'idris', email:'idris@idrislawal.com'}}

En este caso, ya no necesitamos leer de la Colección de usuarios y solo leer de la Colección de pedidos, que ahora contiene todos los datos que necesitamos.

Una cosa clave a tener en cuenta aquí: Si está creando una aplicación que lee muchas veces que escribe, es probable que una opción NoSQL sea más adecuada para usted. Porque podría tener todos sus datos guardados en la misma colección, y podría leer de esa fuente cómodamente para obtener todos los datos necesarios.

Sin embargo, para una aplicación que requiere muchas escrituras (aproximadamente 10,000 escrituras por segundo) a esa escala, no es una buena idea tener la opción NoSQL donde necesita escribir los mismos datos en múltiples ubicaciones. En esta situación, es probable que una opción de SQL sea más adecuada, donde tiene relaciones existentes en todas las tablas y no es necesario escribir los mismos datos en varias ubicaciones repetidamente, la actualización de datos en una ubicación puede estar disponible para otras tablas a través de la salida relación. Esto, por supuesto, no significa que cada una de estas bases de datos no pueda manejar la escala.

Piel escamosa

Exploremos cómo funciona la escala.

SQL

Las bases de datos SQL no se pueden escalar horizontalmente sino solo verticalmente. ¿Qué significa esto incluso?

Escalar horizontalmente significa dividir los datos de una base de datos en varias bases de datos para facilitar la carga. Sin embargo, los datos SQL no se pueden dividir en bases de datos independientes debido a su naturaleza estricta. Lo correcto para escalar una base de datos SQL es aumentar la CPU, la memoria y el espacio en disco del servidor de base de datos existente, y esto es lo que significa escalarlo verticalmente.

NoSQL

Las bases de datos NoSQL se pueden escalar tanto horizontal como verticalmente. Esto se debe a la flexibilidad en su almacenamiento de datos. Esto, por lo tanto, permite que sus datos se dividan en múltiples bases de datos, como es el caso del escalado horizontal. También se puede escalar verticalmente si es necesario.

Una cosa clave a tener en cuenta aquí: Cuando se trata de escalar, las bases de datos SQL y NoSQL se pueden escalar de manera efectiva. Sin embargo, para bases de datos SQL, la escala vertical puede ser una limitación; un solo servidor de base de datos tendrá una limitación en la cantidad de potencia informática que puede transportar.

También es importante tener en cuenta aquí que para la mayoría de las aplicaciones que creará, es posible que no alcance el máximo de la capacidad informática de su servidor, pero es útil tener esto en cuenta. Sin embargo, para las aplicaciones de grandes empresas que implementan SQL, una opción popular para superar esta limitación es Sharding.

¿Qué es Sharding?

La fragmentación es el proceso de dividir las tablas grandes en trozos pequeños, que se denominan fragmentos. La fragmentación se puede realizar mediante la partición horizontal de una base de datos. Esto no debe confundirse con la escala horizontal y vertical. La partición horizontal se refiere al proceso de almacenar filas de una tabla en múltiples nodos de base de datos. La partición vertical, por otro lado, requiere guardar columnas de una tabla en diferentes nodos. Esto permite que la base de datos se escale de manera efectiva y mejore el rendimiento.

Ejemplos de bases de datos

SQL

• MySQL: una base de datos de código abierto muy popular. Sin embargo, la base de datos preferida por muchos desarrolladores de PHP también podría usarse con Node.js, C #, C ++, Java, Perl, Ruby y Python.
• MSSQL - Microsoft SQL proporciona mucha estabilidad ya que su desarrollo es directamente de Microsoft, que también ofrece cierto soporte en términos de recuperación ante desastres.
• MariaDB: esto fue construido en MySQL por los creadores de MySQL, con la intención de mantener MariaDB como una versión gratuita para siempre.
• PostgresSQL: una base de datos de código abierto muy popular. Se enorgullece de ser la base de datos de código abierto más avanzada del mundo
• Oracle: esto generalmente se adapta a las soluciones empresariales de Oracle con algunas limitaciones en su versión gratuita.

NoSQL

• MongoDB: probablemente la base de datos NoSQL más conocida, común entre los desarrolladores de aplicaciones que trabajan con la pila MERN (MongoDB, Express, React, Node) o la pila MEAN (MongoDB, Express, Angular, Node).
• Firebase: introducido en 2011 y adquirido por Google en 2014, está siendo ampliamente utilizado por desarrolladores de aplicaciones web y móviles.
• Apache Couch DB: una base de datos NoSQL basada en documentos que almacena datos como JSON.
• Redis: se trata de NoSQL DB, probablemente más conocido por su uso para almacenar datos con tiempo de vida opcional. También es conocido por su velocidad.

Conclusión

Puede crear cualquier tipo de aplicación con una base de datos SQL o NoSQL. Depende de sus requisitos. Si está considerando una base de datos en la que tenga más lecturas y menos escrituras, un NoSQL podría ser una buena opción. Sin embargo, si está considerando crear una aplicación con más escrituras que lecturas, un SQL podría ser la mejor solución. En cuanto a la escalabilidad, cuando su aplicación llega a una escala muy masiva, puede terminar usando ambas bases de datos.