Binary Coffee

La lucha entre SQL y noSQL

podcast espacio_binario
<iframe src="https://anchor.fm/espaciobinario/embed/episodes/Episodio-2-La-lucha-entre-SQL-y-NoSQL-ej04nh/a-a33mief" height="102px" width="400px" frameborder="0" scrolling="no"></iframe> <iframe src="https://anchor.fm/espaciobinario/embed/episodes/Episodio-3-La-lucha-entre-SQL-y-NoSQL-Parte-II-ejt0n6/a-a398vov" height="102px" width="400px" frameborder="0" scrolling="no"></iframe> ¿SQL o noSQL? Esta pregunta se ha propagado mucho en los últimos tiempos,y sería bueno sino responderla, por lo menos hablar sobre las diferencias entre ambas tecnologías, y de esta manera cada cual puede al final decir cuál es la más conveniente según su proyecto. A travez de algunas preguntas que nos planteamos a lo largo del podcast, vamos dando forma y definimos los términos necesarios para que de manera responsable seamos capaces de decirnos por una o la otra. ## ¿Qué es SQL? SQL son las siglas del inglés Structure Query Languages, que en español sería: Lenguaje de consulta estructurado. Este lenguaje aparece junto a muchos otros por la década de los 70. Estamos en una época, donde las computadoras están empezando a tomar mucho más fuerza en el mercado y ante una gran gama de variantes y soluciones para almacenar información, se hace necesario un lenguaje unificado que permitira abstraerse de la capa de datos y diera facilidades a la hora de hace operaciones sobre los mismo. En la actualidad, es el lenguaje de facto, que se utiliza en las BDs relacionales y permite todas las operaciones necesarias tanto para consulta, creación y modificación de datos, como comandos y herramientas para la creación y estructuración de dichos datos en formato de tablas y relaciones entre las mismas. **Bases de datos relacionales** A la hora de definir una BD relacional, hay ciertos aspectos que no podemos pasar por alto y son los siguientes: - Una base de datos se compone de varias tablas, denominadas relaciones. - No pueden existir dos tablas con el mismo nombre ni registro. - Cada tabla es a su vez un conjunto de campos (columnas) y registros (filas). - La relación entre una tabla padre y un hijo se lleva a cabo por medio de las llaves primarias y llaves foráneas (o ajenas). - Las llaves primarias son la clave principal de un registro dentro de una tabla y estas deben cumplir con la integridad de datos. - Las llaves ajenas se colocan en la tabla hija, contienen el mismo valor que la llave primaria del registro padre; por medio de estas se hacen las formas relacionales. Y es muy bueno mencionar también, que muchas veces se confunde el término relacional con relaciones, por lo que se tiene la errada idea: de que una BD no relacional (noSQL) no tiene relaciones. A lo largo del artículo verán cómo estas DBs también pueden tener relaciones entre sus datos. ## ¿Qué es noSQL? NoSQL es un témino acuñado a inicio de los 2000, y te utilizó para referirse a todas aquellas BD que no solo utilizaban el lenguaje SQL como lenguaje de consulta. Aunque existe una gran variedad de bases de datos noSQL, los tipos más conocidos de estas son: Document, Key-Value, Wide-column y Graph. A continuación veremos cada una de ellas y algunos ejemplos. ### Document ![](https://api.binary-coffee.dev/uploads/document_example_b6d95a64bd.png) - [MongoDB](https://www.mongodb.com/) - [CouchDB](https://couchdb.apache.org/) Son bases de datos de uso general, que se basa en la idea de documentos. Los documentos serían los datos que se almacenan en la misma, y si se el buscara un símil con las BDs SQL, pues serían las filas. Al mismo tiempo, los documents se guardan en las colecciones que serían las tablas en SQL. En este tipo de BD existen también las relaciones entre colecciones y se pueden hacer consultas complejas y lo que en SQL se maneja con joins entre tablas, aca se utiliza el concepto de populate, donde se popula (inserta) en la consulta, los elementos relacionados al que se está consultando. ### Key-Value ![](https://api.binary-coffee.dev/uploads/key_value_example_a3a910027f.png) - [Redis](https://redis.io/) - [DynamoDB](https://aws.amazon.com/de/dynamodb/) ### Wide-Column ![](https://api.binary-coffee.dev/uploads/wide_column_example_3ba34676cd.png) - [Cassandra](https://cassandra.apache.org/) - [HBase](https://hbase.apache.org/) ### Graph ![](https://api.binary-coffee.dev/uploads/graph_example_03dee768c7.png) - [Neo4j](https://neo4j.com/) - [Neptune]() ## ¿Que es escalabilidad vertical y horizontal? La escalabilidad de un proyecto, es la facilidad con que puedes tranformarlo o mejorarlo, de manera tal, que aumente los límites técnicos para los que inicialmente fue creado. En el desarrollo de software, existen 2 tipos de escalabilidad, vertical y horizontal. - Escalado vertical: Conciste en mejorar las propiedades del contexto del proyecto, o lo que sería lo mismo, aumentar las prestaciones del hardware, tales cómo: memoria RAM, capacidad de almacenamiento, mejorar el procesamiento entre otras cosas que positivamente afecten directamente a la aplicación. - Escalado horizontal: Conciste en poder ejecutar la aplicación en varios servidores al mismo tiempo aumentando proporcionalmente las limitaciones técnical del proyecto. Este tipo de escalado es más complejo y se hace necesario que el proyecto lo soporte y eficientemente se comparta la carga entre los servidores. ## Escalabilidad en las bases de datos En el caso de la escalabilidad vertical, esto puede ser aplicado a todos los tipos de BD, dado que se basa en mejorar el rendimiento del contexto en que se encuentra la BD. Para la escalabilidad horizontal existen varias maneras de ser aplicadas. Una de las formas de escalar horizontalmete una BD (tanto SQL como noSQL), puede ser con el modelo de réplica, que se basa en replicar la BD en diferentes servidores y tener una BD principal y todas las demás son secundarias. En este modelo, la principal es la única que acepta las actualizaciones y luego replica en las secundarias dichas actualizaciones, mientras que todas las replicas pueden ejecutar consultas sin problemas. Este escenario permite resolver el problema donde tenemos muchas consultas, pero pocas actualizaciones. Otra manera de escalar horizontalmente es por medio de la partición de la BD en trozos. Este método es principalmente aplicado en noSQL, porque las BDs SQL son muy complejas para aplicar este escalado. La idea de este método, es particionar la BD y en cada consulta, solo se hace uso de aquel pedazo que almacena los datos que se están consultando o modificando en ese momento. El problema principal que se resuelve, es que en BD grandes donde las consultas toman tiempo, producto de que se tiene todo un cúmulo de datos en un solo lugar, mientras que de esta manera, se puede distribuir este cúmulo de datos y cada consulta, sería focalizada en solo una porción de el total de la BD. ## ¿Qué debería utilizar en mi proyecto? ¿SQL o noSQL? A partir de todo los expuesto, claramente se puede deducir que no hay un ganador, no existe la mejor opción. A la hora de definirse por una tecnología o la otra, hay que analizar el proyecto y valorar cual es la que más se ajustaría. Lo que ahora ya sabes, que si no necesitas consultas complejas y buscas velocidad, pues puedes utilizar key-value de las noSQL, o cualquiera de las demás en dependencia de lo que necesites. Hay que tener en cuenta también, que tanto una BD SQL como una noSQL de las de tipo document, puden usarse de caracter general, por lo que admiten tanto relaciones entre tablas o colecciones y consultas sobre las mismas. ## Bases de datos gigantes ![](https://api.binary-coffee.dev/uploads/meshures_informatics_ea551648fa.png) |Bases de datos|Datos| |--|--| |*Bitcoin*|Tamaño actual 285 GB| |*Stackoverflow*|Tamaño actual 359 GB| |*Amazon*|Actualmente cuenta con 59 millones usuarios activos| ||Tamaño estimado 42 TB| |*World data center for climate*|Tamaño actual 220 TB| |*Facebook*|Se suben 350 millones fotos por día| ||Los usuarios dan 4 millones de likes por minuto| ||Tamaño estimado 300 PB distribuidos en 800000 tablas| |*Google*|Se realizan unos 40 millones de búsquedas por segundo que se traducen en 3.5 mil millones por día o lo que sería lo mismo, unos 1.2 billones por año| ||Se estima que las bases de datos deben estar por encima de 1 EB| ## Conclusiones Estamos muy interesados en su feedback, y que nos ayuden a mejorar. Por lo que sería muy bueno tener su apoyo en las redes sociales del podcast y que nos den sugerencias de qué temas tratar, así de qué partes o secciones deberíamos agregar o quitar al formato del podcast. Nos pueden encontrar en la cuenta en twitter [espac10binar10](https://twitter.com/espac10binar10) y en telegram en el grupo [espaciobinario](https://t.me/espaciobinario). Además de que pueden seguir el podcast en la plataforma que desees, ya que estamos en iboox, spotify, googlepodcast y muchas otras, y de esa manera no te pierdes los nuevos capítulos que estrenemos. ## Bibliografía - [MongoDB has not use case](https://dev.to/ankush981/mongodb-has-no-use-case-58ob) - [Database of Databases](https://dbdb.io/)
Opiniones